UX-Designer arbeiten einen Sprint voraus

13

Unsere UX-Designer haben normalerweise eine Geschichte in Sprint X, die die Entwickler in Sprint X + 1 implementieren werden (Die UX-Designer und die Entwickler / Tester sind in einem Team). Ich denke, dies ist sinnvoll, da Sie die Arbeit während der Sprint-Planung nicht wirklich einschätzen können, wenn Sie keine Bildschirmmodelle und klare Spezifikationen haben.

In Scrum sollten Sie jedoch nur User Stories haben, die dem Benutzer einen Mehrwert bieten. In unserem Fall bieten die UX-Design-Storys keinen solchen Wert (sie ähneln eher einer Rückstandsbereinigungsaktivität). Außerdem empfehlen Scrum-Trainer in der Regel, vor dem Start des Sprints keine vollständigen Spezifikationen zu haben, eine Empfehlung, die ich schwer zu verstehen finde.

Sehen Sie Nachteile in unserem Ansatz? Es scheint für uns zu funktionieren, verstößt jedoch etwas gegen die Scrum-Prinzipien.

Eugene
quelle
3
Warum würde UX Design dem Benutzer keinen Mehrwert bieten? Angenommen, Sie arbeiten weiter mit UX-Designern, kann ich nicht erkennen, dass es eine Alternative gibt, und wenn Sie keine Alternative haben, wie kann es dann Nachteile geben?
Michael Shaw
Weil ein Bildschirmmodell und eine Liste der Benutzeroberflächenanforderungen dem Benutzer keinen direkten Wert liefern. Diese liefern erst Wert, nachdem sie in der Geschichte des nächsten Sprints umgesetzt wurden.
Eugene
Ihr Problem könnte sein, dass Sie keine Designer oder im Idealfall UX-Ingenieure haben, sondern Grafiker. Sie benutzen einfach Photoshop, oder? Kein CSS JS oder XAML oder Interface Builder oder irgendwelche technischen Front-End-Abstriche? Sie haben also keine Designer. Sie brauchen echte Designer. Dann wirst du diese Verwirrung nicht haben.
RibaldEddie
Nein. Wir haben sowohl Designer für Benutzerinteraktionen als auch Grafikdesigner. Beide arbeiten einen Sprint vor der Entwicklung
Eugene
10
Wie bringt die Interaktion mit Ihrem Kundenstamm mithilfe von Mockups und Prototypen dem Benutzer keinen Mehrwert? Der Wert ist nicht als Versandcode definiert. Die Greifbarkeit ist sehr gut, aber nicht wesentlich für den Wert.
BobDalgleish

Antworten:

15

In Scrum sollten Sie jedoch nur User Stories haben, die dem Benutzer einen Mehrwert bieten.

Der Wert wird nicht nur in Zeilen des versendbaren Codes gemessen.

Sie scheinen zu implizieren, dass eine gut gestaltete Benutzeroberfläche keinen Wert bietet. Natürlich tut es das. Natürlich hat der Endbenutzer einen Mehrwert, aber auch Ihr Entwicklerteam, das ein perfekter Stakeholder ist, hat einen Mehrwert. Wenn Sie nicht über die Werkzeuge und Materialien für Ihre Arbeit verfügen, können Sie dem Endbenutzer keinen Mehrwert bieten.

Lass dich nicht auf Scrum Dogma ein. Scrum soll Sie effizienter machen. Wenn Sie einen UX-Story-One-Sprint durchführen, bevor Sie die Benutzeroberfläche implementieren, können Sie eine bessere Software bereitstellen.

Bryan Oakley
quelle
2
"Arbeitssoftware ist das primäre Maß für den Fortschritt.", Nicht UX. UX ist nichts wert, wenn es nicht mit Software funktioniert. Sie hätten einen Sinn, wenn Sie befürworten würden, UX zur gleichen Zeit oder später mit dem eigentlichen Feature zu verwenden, aber Sie tun dies nicht, daher ist diese Antwort völlig falsch.
Sklivvz
3
@Sklivvz: Ich denke, wir müssen zustimmen, nicht zuzustimmen. Es stimmt zwar, dass funktionierende Software das primäre Maß für den Fortschritt ist, aber es ist nicht das einzige Maß. Bevor ein Team mit dem Codieren beginnen kann, muss ein gewisses Maß an Design im Voraus erstellt werden. UX kann man nicht einfach am Ende angehen.
Bryan Oakley
4
@BryanOakley Ich stimme zu, dass einige Überlegungen an alle Arbeiten von vornherein erforderlich sind , nicht nur an UX. Der Wert dieser Arbeit wird jedoch von den Stakeholdern festgelegt. Wenn ein Sprint voraus ist, wurde die Rückkopplungsschleife um mindestens einen Sprint erweitert. Ich würde vorschlagen, dass dies ein unnötiges Risiko ist. UX unterscheidet sich nicht von Design, Architektur, Datenbankdesign oder Berichtsformat. Dies kann alles in einem Sprint erfolgen, wobei die Product Backlog-Elemente als vertikale Funktionsbereiche erstellt werden.
Derek Davidson PST CST
Es kann in einem Sprint durchgeführt werden, aber ohne zu wissen, wie die Benutzererfahrung aussehen wird, können Sie den Rest der Arbeit planen? Wenn Sie das detaillierte Softwaredesign nicht kennen, können Sie die Arbeit dennoch planen. Aber wenn Sie nicht einmal wissen, wie der Bildschirm und die Funktionen aussehen werden, wie können Sie dann etwas planen?
Eugene
1
Indem Sie inkrementell arbeiten, wie es bei agilen Methoden üblich ist. Die Entwickler erstellen einen Prototyp entweder in Echtzeit in Zusammenarbeit mit einem UX-Designer oder basierend auf ihren eigenen Vorstellungen von UX. Sobald ein Prototyp arbeitet, überprüft ein Designer ihn und stellt eine Liste der Änderungen bereit. Eine Geschichte braucht keine detaillierte Planung; Alles, was es braucht, ist eine Schätzung der Größe (und einige streiten sich sogar darüber).
Jules
13

Die Hauptnachteile sind diese:

  1. Sie sind in der Pipeline: Wenn sich Ihre Designer verspäten, haben Ihre Entwickler keine Arbeit mehr. Wenn sich Ihre Entwickler verspäten, wird Ihr Designer möglicherweise mehr als eine Iteration im Voraus ausführen. Es ist keine stabile Situation - es ist nicht nachhaltig .

  2. Ihre Designer arbeiten im Voraus, Sie zahlen Kosten für Geschichten, die möglicherweise entwickelt werden oder nicht. Auch wenn es selten vorkommt, wirfst du immer noch Geld weg.

  3. Ihre UX-Designer treffen Entscheidungen im Voraus, ohne die Entwickler einzubeziehen. Sie verpassen nützliche Erkenntnisse und erhöhen das Risiko, dass die Entwürfe völlig falsch oder unrealistisch sind. Dies ist nicht selten der Fall, da UX-Design keine "abstrakte" Aufgabe ist - es muss aus den Merkmalen der Anwendung heraus erstellt werden (einschließlich dessen, was technisch machbar / ratsam ist oder nicht).

  4. Das Ausschließen oder Deaktivieren Ihrer Entwickler ist keine nachhaltige Möglichkeit, ein Projekt auszuführen.

  5. Designer liefern keinen Wert: Dies bedeutet, dass es schwierig, wenn nicht unmöglich ist, ihre Arbeit richtig zu priorisieren. In der Regel wird die Entwicklerarbeit nach unterschiedlichen Gesichtspunkten wie Wert, Durchführbarkeit im nächsten Sprint und Aufwand priorisiert. Viele Zeitgeschichten werden ausgehandelt und geändert, um sie "fit" zu machen oder aufgrund nützlicher Diskussionen: Wenn sich die Benutzeroberfläche dadurch ändert (und Sie können davon ausgehen, dass dies nicht nur ein Implementierungsdetail ist), was tun Sie dann? mit der Geschichte? Du kannst es nicht mehr spielen.

  6. Sie gehen davon aus, dass eine Story, die für die Designer in eine Iteration passt, für die Entwickler in eine Iteration passt: Wie können Sie die Storys so aufteilen, dass diese Annahme korrekt ist?

Sklivvz
quelle
Die Kommentare waren weitestgehend vom Thema entfernt worden.
ChrisF
1
Sie sagen: "Ihre UX-Designer treffen Entscheidungen ... ohne die Entwickler einzubeziehen." Woher weißt du das? Nur weil sie einen Sprint voraus arbeiten, heißt das nicht, dass sie nicht mit den Entwicklern zusammenarbeiten. Vielleicht sind die Entwickler ihre Stakeholder. Dies gilt auch für Punkt 4 - Sie gehen davon aus, dass Entwickler ausgeschlossen werden, aber das ist nicht unbedingt der Fall. Was "Designer liefern keinen Wert" betrifft, könnte ich nicht mehr widersprechen. Sie sehen keinen Wert in richtig gestalteten UX? Während ich denke, dass Sie einige diskussionswürdige Punkte ansprechen, treffen Sie eine Reihe von Annahmen, die möglicherweise nicht zutreffen.
Bryan Oakley
@bry entweder arbeiten sie unter ux oder sie tun es nicht. Sich in den UX-Prozess zu involvieren, bedeutet, an einer Geschichte zu "arbeiten". In Bezug auf Ihre Wertschätzung ... Sie schaffen keinen Mehrwert, wenn sie im Voraus arbeiten, weil sie nichts produzieren, was eingesetzt werden kann. Wenn etwas den Kunden nie erreicht, hat es für ihn keinen Wert.
Sklivvz
re: "am ux-prozess beteiligt zu sein, bedeutet, an einer geschichte zu" arbeiten "." Nicht unbedingt. Die Leute kommen und fragen mich die ganze Zeit, das heißt nicht, dass ich an ihren Geschichten arbeite.
Bryan Oakley
2
@BryanOakley Sicher, aber die Probleme bestehen immer noch: Vergleichen Sie das "Zurücksenden" eines Designs, weil es unrealistisch ist, es auszuführen, oder es gleich beim ersten Mal richtig zu machen, weil es ausgeführt wird, während ein Entwickler daran arbeitet. Darüber hinaus gibt es Probleme, die erst während der Implementierung entdeckt werden, und in diesem Stadium macht der Designer die nächste Geschichte ...
Sklivvz
6

Ich mag es aus zwei Gründen:

  1. es scheint für dich zu funktionieren; Es ist schwer, mit Erfolg zu streiten!
  2. Das UX-Team nimmt die Geschichte auf und beginnt das Gespräch früh - und Gespräche sind so etwas wie der Sinn von Geschichten
Steven A. Lowe
quelle
4

Eine Grundvoraussetzung von Scrum ist, dass das Scrum-Team über alle Fähigkeiten verfügt, die zur Erstellung eines potenziell ablösbaren Produkts erforderlich sind. In der von Ihnen beschriebenen Situation geschieht dies nicht.

Das UX-Team stellt keine potenziell freigebbaren Produkte her, und das Scrum-Team kann keine vertikalen Funktionsbereiche erstellen, da es nicht über alle erforderlichen Fähigkeiten verfügt. Dies sind Funktionsstörungen.

Sklivvz hat einen ausgezeichneten Beitrag über die Probleme geschrieben, zu denen die oben genannten Funktionsstörungen führen könnten. Zusammenfassend glaube ich nicht, dass Sie Scrum üben.

Aber daran ist absolut nichts auszusetzen. Wenn Sie eine Arbeitsweise gefunden haben, die für Sie alle von Nutzen ist und mit der Sie alle zufrieden sind, machen Sie weiter. Mein einziger Rat wäre, häufig zu inspizieren und anzupassen.

Beachten Sie jedoch, dass Sie die festgestellten Funktionsstörungen beheben müssen, wenn Sie Software mit Scrum bereitstellen möchten.

Derek Davidson PST CST
quelle
Wie ich in meinem ursprünglichen Beitrag sagte: "Die UX-Designer und die Entwickler / Tester sind in einem Team"
Eugene
2
@Eugene Inwiefern gehören sie zum selben Team? Ich würde sagen, wenn sie einen Sprint voraus arbeiten, gehören sie nicht zum selben Team. Im Übrigen ist Scrum auch klar, dass es keine "Subteams" erkennt, also würde ich sagen, dass Ihre Situation nicht nach Scrum klingt. Sicher nicht so wie ich es kenne.
Derek Davidson PST CST
Sie arbeiten einen Sprint voraus mit dem Rest der Zeit. Der Rest des Teams überprüft in der Regel zumindest ihre Arbeit und hilft manchmal beim Entwurf.
Eugene
4

Hier gibt es zwei Probleme: das benutzerzentrierte Design und das Sprint-Alignment.

Erstens : User Stories sollten auf die Bedürfnisse der Benutzer abgestimmt sein, nicht nur auf den Rückstand. Die UX-Storys müssen für die Benutzer einen eindeutigen Wert haben. Dies erfordert keine vollständige Spezifikation und eine kurze Aussage wie:

"Benutzer haben einen einfacheren Zugriff auf die Kontoaktivität auf einer einzelnen Seite als auf mehrere Seiten aufgeteilt."

ist zugänglich und anpassbar an verschiedene Implementierungen und dennoch klar über den Wert für den Benutzer (einfacherer Zugriff auf Kontoaktivität).

Zweitens : Sprintausrichtung. UX entwirft Funktionen in Sprint X, die Entwickler in Spring X + 1 implementieren. In der Praxis passiert dies in vielen Geschäften und manchmal ähnelt es eher der Implementierung in Sprint X + 2 oder X + 3. Mit einem eingespielten und erfahrenen Team kann dieses Setup funktionieren. Es wird schwierig, wenn Sie ein neues Team oder neue Mitglieder haben, die mit den Fähigkeiten, Vorlieben, Gewohnheiten, Arbeitsstilen und Tendenzen anderer Teammitglieder nicht vertraut sind. Wenn Sie weniger als 6 Monate zusammengearbeitet haben, ist dies wahrscheinlich ein Problem.

Machen Sie einen Schritt zurück und überdenken Sie. Positiv ist, dass die UX-Designer und -Entwickler Seite an Seite arbeiten, was ein Segen ist. Stellen Sie zunächst sicher, dass Ihre Geschichten für die Benutzer einen eindeutigen Wert haben.

atimba
quelle
2

Eines der möglichen Probleme, die ich sehe, ist, dass in Scrum der Bereich für Sprint N + 1 normalerweise direkt vor dem Start festgelegt wird. Wie können Sie UX für Sprint N + 1-Storys in Sprint N ausführen, bevor Sie wissen, welche Storys in den Geltungsbereich fallen. Wenn Sie den Bereich für Sprint N + 1 zu Beginn von Sprint N festlegen, verlieren Sie Flexibilität.

Frank Bakker
quelle
1

In Scrum sollten Sie jedoch nur User Stories haben, die dem Benutzer einen Mehrwert bieten. In unserem Fall bieten die UX-Design-Storys keinen solchen Wert (sie ähneln eher einer Rückstandsbereinigungsaktivität).

So wie ich es sehe, bieten sie ihren Nutzern viel Wert. Die Sache ist: Der Benutzer ist nicht der Endbenutzer des Unternehmens, sondern das Entwicklerteam, das die Funktion bei Sprint X + 1 implementiert.

mverardo
quelle
1

Sie bleiben in der Religion des Prozesses stecken und auf dem Weg sehe ich, dass Scrum / Agile missbraucht und Benutzer falsch beschriftet werden. Scrum ist kein universelles Werkzeug, es ist ein Mittel zum Zweck.

Ich denke, dass Ihre Gruppe die Benutzer falsch benannt hat und für die falsche Zielgruppe plant.

Die UX-Gruppe nutzt Scrum auf klassische Weise, um den Benutzerwert und die agile Anpassung an die Eingaben einiger magischer Endbenutzer zu verbessern. Sie sind die mit den Benutzern. Ihre Gruppe missbraucht Scrum, weil Sie lediglich die Mechanik ausfüllen, um ein vorhandenes Design zu erstellen, nichts Agiles erforderlich ist und Scrum die Rolle des Management-Trackings übernimmt.

Aus diesem Grund fühlt sich das für Sie falsch an. Sie brauchen oder profitieren in keiner Weise von Scrum, da Sie zu einer Servicegruppe gehören und Ihre Arbeit von den UX-Leuten weitergeleitet wird, die bereits die Agile / Scrum-Teile ausgeführt haben.

Da ist nichts wirklich Schlimmes, nur ein anderer Prozess ist im Gange als das, was dir gesagt wurde.

Patrick Hughes
quelle