UX-Designer arbeiten einen Sprint voraus

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.

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.

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?

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

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.

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.

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.

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.

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.