Wer macht die UX bei einem Scrum-Projekt?

IN ORDNUNG. Angenommen, Sie arbeiten an einem Lehrbuch-Scrum-Projekt. Sie haben einen Scrum Master, der mit einem Product Owner zusammenarbeitet. Der nächste Sprint ist UI-schwer - von der Zeit , Ihre Programmierer bauen Bildschirme beginnen, wollen Sie wirklich haben einige Ahnung , was sie gehen , wie zu suchen.

Wer macht das Wireframing und wann? Der Produktbesitzer? Jemand, der den Produktbesitzer unterstützt? Der Scrum Master? Wenn Sie einen UX-Experten haben, arbeiten diese nach dem Start des Sprints mit den Programmierern zusammen oder liefern sie im Voraus Drahtmodelle und Modelle, die neben Ihren Story Cards und Einschränkungen stehen, um die Arbeit der Entwickler zu leiten und zu informieren?

Ich bin mir ziemlich sicher, dass wir UX-Hilfe brauchen, aber ich bin mir wirklich nicht sicher, wo ich sie anwenden soll ...

EDIT: Lassen Sie mich die Frage umformulieren.

Wie liefern Sie eine konsistente, qualitativ hochwertige Benutzererfahrung in einem agilen Projekt?

Der Interaktionsdesigner

UX! = UI Sie benötigen einen erfahrenen Interaktionsdesigner, um eine gute Benutzererfahrung zu erzielen, entgegen der weit verbreiteten Meinung, dass dies kein Programmierer ist. Für alle Programmierer, die glauben, UX zu können (das schließt mich ein), möchte ich dies sagen. Gute Interaktionsdesigns erfordern mindestens so viel Zeit wie gute Programmierkenntnisse. Wie viel Zeit haben Sie mit reinem Interaktionsdesign verbracht?

In der Anfangsphase liegt es in der Verantwortung der Interaktionsdesigner:

1. Extrahieren der tatsächlichen Ziele der Lösung vom Product Owner
2. Definieren Sie die Personas, die die Lösung verwenden sollen.
3. Schreiben Sie Szenarien, die Geschichten darüber enthalten, wie die Lösung verwendet wird.
4. Kompilieren Sie ein Designdokument, das unter UX-Gesichtspunkten wenig Raum für Mehrdeutigkeiten lässt

Während des Projekts ist es Aufgabe der Interaktionsdesigner, sicherzustellen, dass diese Richtlinien eingehalten werden, und alle zusätzlichen Probleme zu beheben, die auftreten werden (und dies auch tun werden).

Ich bin mir sicher, dass viele Programmierer diesen Ansatz vorwegnehmen werden, da jeder der Meinung ist, dass sie die Ausnahme sind, die "wunderbare" Schnittstellen entwerfen kann, was Sie wahrscheinlich nicht sind. Andererseits ist eine gute Beziehung zwischen Interaktionsdesigner und Programmierer für den Programmierer oft sehr nett, da er nicht gegen eine "dumme Spezifikation" kämpfen muss. Leider sind gute Interaktionsdesigner meiner Erfahrung nach schwer zu finden, aber sie sind da draußen.

Wie immer empfehle ich Alan Coopers Bücher zu diesem Thema ("About Face" und "The Inmates are the asylum")

Ich schlage vor, die Arbeit des UX-Mannes genauso zu organisieren wie den Rest des Teams. Er sollte als gleichberechtigtes Mitglied des Teams betrachtet werden, an Stand-ups teilnehmen und eng mit Programmierern kommunizieren.

Idealerweise sollten die Modelle mindestens einen Sprint im Voraus ausgeführt werden. Bei kleineren Funktionen kann es jedoch sinnvoll sein, Modelle als Teilaufgabe einer für die aktuelle Iteration geplanten Geschichte zu erstellen.

Verwenden Sie wie immer bei Agile den gesunden Menschenverstand, experimentieren Sie mit verschiedenen Ansätzen und halten Sie sich an den, der für Ihre spezielle Situation gut geeignet ist.

Meiner Meinung nach ist dies irgendwie ein Sonderfall, der auf besondere Weise behandelt werden muss. Scrum Master wird definitiv nicht daran teilnehmen - es ist überhaupt nicht seine Rolle. Das Team besteht normalerweise aus einer Gruppe von Entwicklern, und die meisten von ihnen haben keine Erfahrung mit UX. Es wird Zeitverschwendung sein, sie dazu zu zwingen. Sie werden einen UX-Experten einstellen und der Experte wird nicht Teil des Teams sein - das Team sollte funktionsübergreifend sein und der UX-Experte wird wahrscheinlich kein Entwickler sein. Auch UX-Experten werden während der gesamten Dauer nicht am Projekt teilnehmen. Der UX-Experte wird mit dem Produktbesitzer einen Sprint im Voraus zusammenarbeiten, um Modelle und Drahtmodelle für kommende User Stories vorzubereiten, damit das Team weiß, was im nächsten Sprint zu tun ist. Modelle werden während des Planungstreffens verfügbar sein.

Bearbeiten:

Ich habe einige zusätzliche Nachforschungen angestellt, weil ich wusste, dass ich irgendwo darüber gelesen habe, und ich finde es schließlich in Erfolgreich mit Agile: Softwareentwicklung mit Scrum von Mike Cohn . Mike bespricht genau die Rolle des UX-Designers im Team. Seine anfängliche Beschreibung ähnelt meiner und er betrachtet sie als natürliche Verschiebung, wenn das Unternehmen die Entwicklungsmethode von Wasserfall zu Scrum ändert, aber später kommt er zu dem Schluss, dass dies nicht empfohlen wird. Der Grund dafür ist, dass UX-Designer, die nicht Teil des Teams sind, sich selbst als separates Team betrachten können und nicht das Engagement des Entwicklungsteams teilen müssen.

Trotzdem sieht die Antwort von @Adam Byrtek wie die richtige aus. Machen Sie UX zu einem Teil des Teams und lassen Sie ihn mit Entwicklern an aktuell implementierten User Stories zusammenarbeiten. Es wird nicht die ganze Zeit dauern, bis der UX-Typ mit dem Produktbesitzer oder Kunden zusammenarbeitet, um Modelle und Drahtmodelle für die nächsten ein oder zwei Sprints vorzubereiten.

Ich habe Jakob Nielsens Alertbox abonniert (hauptsächlich wegen seiner Kritik an nervigen Webdesign-Praktiken) und ich erinnere mich, dass ich kürzlich einige Artikel zum Thema gelesen habe (obwohl ich kaum ein geringes Verständnis für den gesamten agilen Entwicklungsprozess habe), vielleicht wären sie es von Nutzen für Sie:

• Agile User Experience-Projekte
• Agile Entwicklungsprojekte und Benutzerfreundlichkeit

Für "Lehrbuch Scrum":

Zunächst einmal arbeiten Scrum Masters nicht mit Produktbesitzern zusammen - auch nicht in irgendeiner Weise, außer dass das gesamte Team, einschließlich SM und PO, beim Aufbau des Systems zusammenarbeitet.

Zweitens sollen Scrum-Teams mit funktionsübergreifenden Teammitgliedern homogen sein. Sie hätten also keinen "UX Guy".

Außerdem würden Sie die UX a Sprint wahrscheinlich nicht vor dem Funktionscode erstellen. Die Funktionen werden vollständig in einem einzigen Sprint geliefert. Wenn die einem Feature zugeordnete UX zu komplex ist, um zusammen mit dem Funktionscode in einem einzelnen Sprint bereitgestellt zu werden, können Sie das gesamte Feature auf etwas reduzieren, das in einem einzigen Sprint ausgeführt werden kann, einschließlich der UX-Elemente.

Wer macht UX bei einem Wasserfallprojekt? Wer entwickelt Mainframes für ein XP-Projekt?

Die Projektmethodik spielt keine Rolle. Jedes Technologieprojekt erfordert bestimmte spezielle Rollen. Manchmal kann ein Projekt ohne einen vollständig lizenzierten und gebundenen "Interaktionsdesigner" davonkommen (was auch immer das bedeutet). Manchmal braucht man jemanden, der sich spezialisiert hat. Das Gleiche gilt für jede andere Rolle.

Kommen wir also zu Ihrer zweiten Frage, wie Sie mit Agile eine qualitativ hochwertige Benutzererfahrung bieten. Wir haben es im letzten Scrum-Projekt geschafft, an dem ich beteiligt war, indem wir den Geschäftsanalysten und den Kunden früh und häufig einbezogen haben. Wir hatten auch einen Entwickler, der ein besonders gutes Auge für UX hatte. Er neigte dazu, kleinere Änderungen an den Benutzeroberflächen vorzunehmen, an denen die Entwickler arbeiteten, nachdem sie Commits durchgeführt hatten.

Wir haben am Ende jedes Sprints nicht die perfekte UX geliefert. Die Demos enthüllten im Allgemeinen ein oder zwei Probleme aus UX-Sicht. Aber wir haben diese für den nächsten Sprint repariert (wenn sie sich für den Kunden gelohnt haben) und als wir zur Produktion freigegeben wurden, hatten wir eine sehr solide UX.

Wenn Sie unter UX den Benutzeroberflächendesigner verstehen, sind diese nur eine weitere Rolle oder Ressource für das Team. Das Design der Benutzeroberfläche schneidet wie jedes Design ein Projekt ab. Es gibt eine angemessene Menge an Architektur- / Designarbeiten, die im Voraus erledigt werden sollten, und es gibt eine Menge, die im Laufe der Zeit erledigt werden kann.

Es ist zu beachten, dass UI-Entwurfsaufgaben häufig nicht in den gleichen Bereich wie ein Entwicklungssprint passen. Beim Entwerfen einer UI-Komponente kann das Implementieren des Designs zahlreiche Sprints erfordern.

In der Praxis stelle ich fest, dass UI / UX-Designer eine angemessene Vorlaufzeit benötigen, um Aspekte zu behandeln, die in der gesamten Lösung konsistent sein müssen. Ich stelle es mir gerne als Softwarearchitektur vor. Spezifisches Komponentendesign kann oft vor der Implementierung im Sprint ausgeführt werden, aber ich bin der Meinung, dass die Designer, sobald sie in Betrieb sind, die Implementierung weit beschleunigen können. Spätere Sprints sind in der Regel ein guter Ort, um Look & Feel zu implementieren / zu erkunden und um Feedback zur Benutzerfreundlichkeit zu erhalten, sobald die Lösung Gestalt annimmt. Die Ergebnisse dieser späteren Übungen fließen in die Planung des nächsten Sprints ein.