Was ist der beste Weg, um Aufgabenabhängigkeiten innerhalb einer Story zu handhaben? Die Story selbst ist unabhängig von anderen Storys und wir haben funktionsübergreifende Teams (Design, Backend, Frontend).
Bei den meisten Aufgaben – insbesondere zu Beginn eines Projekts – wird die Frontend-Arbeit in der Regel durch die Backend- und Design-Arbeit blockiert.
Nehmen wir an, wir wollen eine Login-Story implementieren:
Als Kunde möchte ich mich anmelden, um auf die privaten Bereiche der Seite zugreifen zu können
Diese Geschichte besteht aus drei Teilen:
So können Aufgabe 1 und 2 parallel erledigt werden, während Aufgabe 3 von beiden abhängig ist.
Sie haben auch sehr unterschiedliche Aufwandsniveaus, die für die Fertigstellung benötigt werden.
Meine Fragen sind:
Ich habe die meisten Themen gelesen, in denen Abhängigkeiten erwähnt werden, konnte aber keine gute Lösung für dieses Problem finden
Mit Mocks und Stubs kann viel getan werden.
Beispielsweise könnte das Team zuerst ausarbeiten, wie die API aussehen wird, und dann schnell eine Stub-API erstellen, die gefälschte Daten zurückgibt.
Dies hilft bei der Trennung der Front-End- und Back-End-Entwicklungsaufgaben. Jetzt arbeiten die Frontend-Entwickler mit dem Stub und die Backend-Entwickler arbeiten daran, die Implementierung der API zu konkretisieren.
Es kann sein, dass ein Stub nicht ausreicht, um das Frontend richtig zu steuern, und in diesem Fall möchten Sie vielleicht eine ausgefeiltere Mock-API erstellen.
Dies ist nur ein Beispiel für die Denkweise, Abhängigkeiten zu reduzieren, damit das Team mehr parallel arbeiten kann. Dies ist ein lohnender Ansatz, da es für das Team einfacher ist, sich auf die Fertigstellung einer User Story zu konzentrieren, anstatt viele Stories gleichzeitig in Bearbeitung zu haben.
Für die Schätzung möchten Sie auf der Ebene des Product Backlog Items schätzen. Wenn Sie User Storys verwenden, ist die User Story normalerweise das Product Backlog Item. Und bei der Schätzung möchten Sie die gesamte Arbeit berücksichtigen, die erforderlich ist, um es in den Status „Erledigt“ zu bringen, gemäß der Definition of Done des Teams und allen Akzeptanzkriterien in der Story selbst.
Der beste Weg, um mit Abhängigkeiten umzugehen, besteht darin, sie zu reduzieren oder sogar zu eliminieren. Dies wird Ihnen helfen, Überschwappungen zu vermeiden (oder zumindest zu reduzieren), sich darauf zu konzentrieren, die Arbeit anderer nicht zu schätzen und klare Zustände zu haben, bereit und fertig zu sein.
In Ihrem speziellen Fall glaube ich, dass Sie die Abhängigkeit von UX / UI-Designaufgaben beseitigen können. Ich würde normalerweise erwarten, dass diese Arbeit als Teil der Definition der Arbeit erledigt wird. Ich würde erwarten, dass ein UI-Design vollständig ist, zumindest auf Wireframe-Ebene, bevor das Product Backlog Item vom Team verfeinert wird. Wenn Sie nicht wissen, wie das Formular aussehen soll und wie sich die UI-Elemente (aus UX-Sicht) verhalten sollen, wie können Sie die Arbeit einschätzen und ordnen?
Wenn Sie Design (vom UX-Typ) als Voraussetzung für die Verfeinerung der Arbeit durch das Entwicklungsteam verschieben, können Sie verschiedene Möglichkeiten für die Verwaltung der Entdeckungsarbeit von Produktmanagern und User-Experience-Designern eröffnen.
- Sollte bei der Schätzung jeder Teil separat geschätzt werden? Wie berechnet man die „Gesamt“-Schätzung?
Alle Teams nehmen an derselben Sprint-Planung teil, diskutieren alle Aspekte der User Story und schätzen sie vollständig ein.
Wie?
Sie benötigen zunächst eine Referenz-User Story mit 1 Story Point. Sie besprechen diese User Story, damit alle Teile verstanden werden. Es kann sein:
"Als Webbenutzer möchte ich mein Passwort zurücksetzen, damit ich mein Konto weiterhin verwenden kann."
Es hat Design, Frontend, Backend-Arbeit.
Dann fragen Sie die Entwickler (Design, Frontend, Backend) nach ihrer Einschätzung, wie viel komplexer Ihre Geschichte ist als die Referenzgeschichte. Wenn es genauso komplex ist wie die Referenz-User Story, erhält es 1 SP.
Die User-Story-Schätzung enthält die gesamte Arbeit, um sie „fertig“ zu machen. Alles davon.
2. Wie vermeide ich ein Überlaufen? Wenn die meisten Aufgaben auf diese Weise verschränkt sind, ist es möglich, dass nur wenige Aufgaben erledigt werden, da die Arbeit seriell statt parallel ist
Sie müssen die iterative Entwicklung üben, insbesondere die Überprüfung und Anpassung.
In Ihrem Fall:
Diese Geschichte besteht aus drei Teilen:
1. Entwurf des Anmeldeformulars
2.Backend-API-Implementierung
3.Frontend-Implementierung (mit Stilen und Verbindung zum Backend)
Beim Product Backlog Refinement erstellen Sie erste Entwürfe für die drei Teile und fügen sie der User Story hinzu. Dann haben Sie eine unvollkommene User Story, aber immer noch eine, die alle Teile enthält, sodass alle Entwickler damit beginnen können, daran zu arbeiten. Die User Story wird für einen Sprint ausgewählt und während der Sprintplanung weiter besprochen. Weitere Details werden hinzugefügt.
Dann fängst du an, daran zu arbeiten.
Iteration Nr. 1:
Basierend auf den User Story-Details verwendet das Frontend den Designentwurf und erwartet einige Backend-Endpunkte, verspottet sie. Die gesamte Arbeit ist in die Entwicklungsumgebung integriert.
Ein bis zwei Tage später sehen sich die Entwickler und der Product Owner es an (buchstäblich auf der Benutzeroberfläche). Das ist Inspektion. Und entscheiden Sie, wie Sie es weiter modifizieren. Als nächstes kommt die Anpassung.
Iteration Nr. 2:
Das Design wird aktualisiert. Das Frontend aktualisiert es. Das Backend lieferte einige Endpunkte. Das Frontend entfernt einige Mocks und verwendet tatsächliche Endpunkte. Das ist Anpassung.
Ein-zwei Tage später ist es wieder Feedback-Zeit. Jemand klickt auf den Login-Button, es funktioniert nicht. Ist es Frontend- oder Backend-Fehler? Backend. Das Design könnte eine andere Schriftart verwenden. Das ist Inspektion.
Iteration Nr. 3
Das Backend behebt und liefert alle Endpunkte. Das Design wird mit der neuen Schriftart aktualisiert. Das Frontend fügt alles zusammen.
Einen Tag später ist es wieder Feedback-Zeit. Jetzt sieht es gut aus und funktioniert wie erwartet. Das ist Inspektion.
Jetzt führen Sie das Zeug zusammen und stellen es in der Staging-Umgebung bereit. Der Product Owner kann es jetzt Stakeholdern zeigen, um mehr Feedback zu erhalten.
Weitere Iterationen können passieren, bis es "Fertig" ist.
Es ist keine exakte Wissenschaft, es ist komplex, aber das ist der Fluss der Arbeit und Zusammenarbeit.
Da ein Teil möglicherweise langsamer als die anderen geliefert wird, können Sie (der schnellere) auf etwas anderes umsteigen. Sie können sogar Feedback zu Teilarbeiten (Design und Frontend mit vollständig verspottetem Backend) verlangen.
Diese Dinge können in der Sprint-Retrospektive geglättet werden. In einem echten funktionsübergreifenden Team kann das Frontend etwas Design und das Backend etwas Frontend machen (und/oder umgekehrt), sodass alle Entwickler gleichzeitig liefern und Sie nicht aufeinander warten müssen. Es ist alles Planung, Know-how und Kapazität.
Die Leute nach Fachwissen zu trennen, hilft überhaupt nicht, es macht alles nur schlimmer. Es verlängert die Rückkopplungsschleifen. Während Sie vielleicht denken, dass die User Story "fertig" ist, haben Sie tatsächlich (noch) kein Feedback erhalten, das Sie dazu veranlassen würde, sie erneut als "Fehler" zu aktualisieren.
Es gibt kein Überschwappen, wenn Sie es erwarten. Sie sollten eigentlich wollen, dass dieses Feedback SO BALD WIE MÖGLICH „Fertig“ wird. Wenn Sie denken, dass es "fertig" ist und ein unerwartetes Feedback kommt, müssen Sie natürlich mehr Arbeit hineinstecken und haben weniger Zeit für andere User Stories oder Bugs.
3. Wie kann man sich auf etwas einlassen, das so ungewiss ist (die Arbeit anderer Leute)?
Transparenz ist neben Inspektion und Anpassung die dritte Scrum-Säule . Seien Sie einfach ehrlich und arbeiten Sie zusammen, um die gemeinsame User Story zu liefern und das gemeinsame Sprint-Ziel zu erreichen. Das ist Verpflichtung.
In Scrum wurde Commitment in Forecast geändert , da Ersteres negative Auswirkungen auf die Qualität der Arbeit hat.
Nachdem sich das Scrum Team, vor allem der Product Owner und insbesondere die Stakeholder verpflichtet haben, eine Liste von Product Backlog Items zu liefern, fühlen sie sich möglicherweise verpflichtet, alle am Ende des Sprints tatsächlich zu liefern.
Wenn ich Sie richtig verstehe, wollten Sie die Frage mit "Intra-Team-Abhängigkeiten" überschreiben - die Abhängigkeiten treten innerhalb des Teams auf. Sie sollten versuchen, funktionsübergreifende Entwickler aufzubauen, nicht nur funktionsübergreifende Teams.
Nutzen Sie Pairing von Entwicklern unterschiedlicher Disziplinen (ein Backend mit einem Frontend-Entwickler) oder Mob Programming (das ganze Team sitzt um einen Rechner), um die fehlenden Fähigkeiten der Teammitglieder zu verbessern.
Im Idealfall kann jeder Entwickler des Teams jede Aufgabe zu jeder Zeit erledigen. In der Praxis haben Sie Experten für jedes Thema, und der Rest weiß mehr oder weniger, was und wie in diesem Thema zu entwickeln ist. Die Experten werden während der Entwicklung zu Rate gezogen oder erläutern Details, wenn die Schätzungen zwischen den Teammitgliedern große Unterschiede aufweisen.
Sie könnten an Suchergebnissen für „Scrum Comb Shaped“ wie https://www.linkedin.com/pulse/which-letter-shaped-employee-you-gaurav-sharma interessiert sein
Für die Schätzungen hat @alexandru-jieanu bereits eine hervorragende Erklärung geschrieben.
Erik
retro
Patrick McElhaney