Kurze Antwort
Das Entwicklerteam schreibt die technischen Dinge. Scrum hilft Ihnen ein bisschen, aber nicht viel bei der technischen Aufschlüsselung bzw. Erste Schritte mit einer User Story. Scrum ist fast nur What-World . Die technische Aufschlüsselung lautet How-World .
Die von Scrum bereitgestellte Aufschlüsselung lautet:
- User Story -> Akzeptanzkriterien
Die Aufschlüsselung, die Menschen häufig zusätzlich verwenden, ist:
- Episch -> User Stories
- User Story -> Unteraufgaben
- Abnahmekriterien -> Abnahmetests
Außerdem kann das Team technische Aufgaben für Dinge schreiben, von denen sie wissen, dass sie erledigt werden müssen (dh IntelliJ IDEA für alle zu Beginn des Projekts installieren), die jedoch keinen geschäftlichen Wert haben.
Weitere Anleitungen zur Aufschlüsselung der Arbeit finden Sie unter XP (Extreme Programming), Clean Code , Pragmatische Programmierung , Software-Engineering , CRC-Karten , OOP / OOA / OOD , Entwurfsmuster , Refactoring , Effektives Arbeiten mit Legacy-Code , TDD ( Testgetriebene Entwicklung), BDD (Verhaltensgetriebene Entwicklung), ATDD (Akzeptanztestgetriebene Entwicklung).
Lange Antwort
Wie Scrum denkt
Was-Welt und Wie-Welt
Es gibt eine Was-Welt und eine Wie-Welt . Wie Sie richtig gefühlt, User Story ist für Benutzer , Erzeugen von Business Value aka Sekundärwert in der Was-Welt . Scrum ist meistens nur What-World. Es sagt wenig bis gar nichts über die How-World aus , im Grunde nicht mehr als "How-World liegt in der Verantwortung des Dev-Teams".
User Story vs Aufgabe
Normalerweise werden Backlog-Elemente, die für die How-World bestimmt sind, nicht als User Story, sondern als technische Aufgabe oder Unteraufgabe bezeichnet . Viele Tools ermöglichen die Aufteilung der User Story aus der What-World in Unteraufgaben in der How-World .
Wie Scrum hilft und wo diese Hilfe endet
Die Hilfe von Scrum for the How-World endet an einigen Punkten des Sprint Planning Meeting :
- [Sprint-Planungstreffen] Das Team entdeckt ein Missverständnis der Geschichte, wenn verschiedene Teamkollegen während des Planungs-Pokers -> Diskussion unterschiedliche Schätzungen für den Story-Punkt erstellen.
- [Definition von Ready] Das Team akzeptiert keine zu großen User Stories (Story Points zu hoch). Als Faustregel in vielen Definitionen von "Bereit" gilt, dass die Story-Punkte weniger als die Hälfte der Geschwindigkeit des Teams betragen müssen.
- [Definition von Ready] Das Team akzeptiert keine User Stories ohne ausreichende Beschreibung der Akzeptanzkriterien. Akzeptanzkriterien sind ausreichend, wenn das Team genügend Vertrauen hat, wie mit dem Schreiben der Akzeptanztests begonnen werden soll.
Ein paar Tipps zum Level von Scrum
Ich fand es hilfreich, User Stories während der Backlog Refinement- Meetings oder zumindest des zweiten Teils des Sprint Planning Meeting (für einige Teams Sprint Planning 2 Meeting) in Unteraufgaben aufzuteilen .
Bei unerfahrenen Teams fand ich es hilfreich, während der Backlog-Verfeinerung und Sprint-Planung nach Atomic User Stories zu streben . Eine Atomic User Story ist eine User Story, die nicht weiter in kleinere User Stories unterteilt werden kann, ohne ihren Geschäftswert vollständig zu verlieren. Im Allgemeinen müssen User Stories nicht atomar sein. Ich habe gerade festgestellt, dass sie mir bei unerfahrenen Teams helfen.
Und machen Sie nicht "(Architektur | Design | Implementierung | Test) von Feature X" als User Stories. Ich empfehle, dass Sie sogar versuchen, dies als Unteraufgabe zu vermeiden.
Wenn ich Atomic User Stories habe und diese neben den zu implementierenden Akzeptanzkriterien eine weitere Aufschlüsselung benötigen, bedeutet dies für mich, dass etwas nicht auf dem optimalen Niveau funktioniert. Entweder ist die Architektur falsch / zu kompliziert, dh technisch statt geschäftsorientiert. Oder das Team ist unerfahren. Oder beides. In jedem Fall wären Maßnahmen erforderlich, um die Situation durch Schulung und Verbreitung von Wissen zu verbessern.
Jenseits von Scrum
Der Scrum Master jenseits von Scrum
Heutzutage wird der Scrum Master meistens als Führungsrolle verstanden , und das ist Schwachsinn. Ursprünglich war der Scrum Master, und ich befürworte dies, eine technische Rolle , keine Führungsrolle, genau wie der Coach in XP .
Es ist allzu einfach, sich auf Scrum und den Scrum Master zu verlassen und so in eine große Lücke zu geraten, weil Scrum fast nichts über die How-World sagt.
Rotierender Scrum Master
Im Idealfall wechselt der Scrum Master zu den erfahrenen Entwicklern, die auch über ausreichende Management- und Kommunikationsfähigkeiten verfügen, bis alle im Team "Inspect and Adapt" so tief im Herzen leben, dass der Scrum Master überflüssig wird. niemand und jeder würde gleichzeitig Scrum Master sein.
Aber Vorsicht, Scrum Mastery ist eher wie Kochen, nicht wie Tisch putzen und Geschirr spülen. Vielleicht möchten Sie drehen, wer den Tisch putzt und das Geschirr spült, da dies jeder tun kann. Aber Sie möchten das Kochen nicht auf alle übertragen, da es Menschen gibt, die nicht kochen können oder nicht gerne kochen, und Sie möchten gutes Essen essen.
Das Gute am Rotieren des Scrum Masters zwischen erfahrenen Entwicklern ist, dass das Team mit größerer Wahrscheinlichkeit mehr über Methoden erfährt.
Das selbstorganisierende Team
Aus der Sicht von Scrum muss sich das Team selbst herausfinden, idealerweise mithilfe des Scrum Masters .
Scrum spricht auch nur vom Dev-Team . Rollen wie Architect oder Lead Engineer gibt es in Scrum nicht. Das bedeutet nicht, dass sie verboten sind, es bedeutet nur, dass Scrum nichts über sie sagt. Scrum proklamiert ein selbstorganisierendes Team . Wenn das Team einen Architekten deklariert, hat das Team einen Architekten. Das wird von Scrum nicht definiert, ist aber mit Scrum kompatibel. Ich proklamiere keine engagierten Architekten (ich habe jahrelang als designierter Architekt gearbeitet, und obwohl es mir gefallen hat, bin ich grundsätzlich gegen die Idee eines designierten Architekten), sondern gebe nur ein Beispiel.
Akzeptanztests
User Stories haben Akzeptanzkriterien . Diese Abnahmekriterien werden in Abnahmetests umgewandelt
Andere Sachen
Eine Liste mit weiteren Informationen zur Aufschlüsselung finden Sie unter Aufteilen eines Programmierprojekts in Aufgaben für andere Entwickler.
Hoffe das hilft.