Ich bin in einem agilen Team mit einigen Entwicklern, einem Designer und einem UX-Typen. Manchmal teilen wir einige User Stories in Aufgaben auf, wenn wir denken, dass sie zu groß sind.
Dabei habe ich immer gelesen, dass wir User Stories in kleine Features aufteilen sollten (damit wir nach jeder Aufgabe ein potenziell auslieferbares Produkt haben). Die meisten meiner Teammitglieder bestehen jedoch darauf, Aufgaben nach Arbeitstypen aufzuteilen (z. B. eine Aufgabe für Wireframes für diese User Story, dann eine weitere für das Design und eine weitere für die Implementierung). Ich verstehe, dass dies ein schlechter Weg ist, da wir keine potenziell lieferbaren Produkte erhalten, aber ich kann ihnen anscheinend nicht klar machen, dass wir dies ändern müssen. Wie könnte ich das tun?
Sie haben beide Recht. (Oder falsch, je nach Perspektive).
Eine mögliche Richtlinie für die Definition von Stories ist, dass sie „die kleinstmögliche Menge an Arbeit sein sollten, die für sich genommen einen Geschäftswert bietet“. Eine andere ist die INVEST-Methode . Beachten Sie die Anforderung „Klein“.
Fühlen Sie sich also frei, Stories in kleinere Stories aufzuteilen. Jedoch...
Es ist völlig in Ordnung (und üblich), dass das Entwicklerteam Storys nach Arbeitstyp in Aufgaben aufteilt. Denken Sie daran, dass die Story nicht fertig ist, nur weil eine Aufgabe erledigt ist. Die Arbeit für eine Story sollte nicht in den Hauptzweig des Produkts aufgenommen werden, bis alle seine Aufgaben abgeschlossen sind. Nur weil eine Story halbfertig ist, heißt das nicht, dass Ihr Inkrement nicht lieferbar ist – versenden Sie diese Story einfach nicht!
Eine User Story sollte innerhalb eines Sprints (in der Regel 1-3 Wochen) umgesetzt werden. Der Spint selbst lässt sich beliebig organisieren, eigentlich empfiehlt das agile Manifest eine selbstorganisierte Struktur im Team. Wenn dies der Fall ist, sind Ihre Teamkollegen richtig.
Wenn die User Story zu groß ist und nicht in einen Sprint passt, sollte sie in kleinere Storys aufgeteilt werden, die passen. Wenn dies der Fall ist, liegen Ihre Teamkollegen falsch. Und jede andere Organisation wird nicht innerhalb der agilen Methodik sein, und dies sollte Ihr größtes Argument gegen sie sein.
Ich denke, @Sarov hat in seiner Antwort einige gute Punkte gemacht, und der wichtigste Teil ist die Unterscheidung zwischen Geschichten und Aufgaben .
Es sollte niemals vorkommen, dass Geschichten basierend auf dem Level des Tech-Stacks, mit dem Sie arbeiten, aufgeteilt werden, es sei denn, Sie können ein vollständiges Feature vollständig auf dem Front- oder Back-End erstellen. Der Artikel hier beschreibt die SPIDR-Technik von Mike Cohn zum Aufteilen von User Stories. Beachten Sie, dass keines davon nach „Level of the Technology Stack“ aufgeteilt ist. Das Aufteilen von Stockwerken sollte immer vertikal und nicht horizontal erfolgen. Wenn es Ihnen schwer fällt, Ihr Team davon zu überzeugen, habe ich eine Strategie verwendet, die Entwickler daran erinnert, dass wir durch die vertikale Aufteilung den Stakeholdern immer den Geschäftswert zeigen können, was sie normalerweise vom Rücken des Engineering-Teams fernhält!
Aufteilungsaufgaben können horizontal sein, insbesondere wenn die meisten Ihrer Ingenieure keine Full-Stack-Ingenieure sind. Wenn Sie dedizierte Front- und Back-End-Teams haben, ist es kein Problem, Aufgaben für jede Story zu haben, an denen verschiedene Mitglieder des Teams an verschiedenen Stellen des Stacks beteiligt sind. Denken Sie nur daran, dass Scrum funktionsübergreifende Funktionen fördert und Teammitglieder immer den Wunsch haben sollten, mehr über die verschiedenen Teile des von Ihnen verwendeten Stacks zu erfahren. Je funktionsübergreifender Ihr Team ist, desto weniger müssen Sie sich um ein solches Problem kümmern.
Daniel
Todd A. Jacobs