Sprints, Daily Stand-Ups & Demo
Anbei ein weiterer Artikel über die in unserem Unternehmen durchgeführten internen Scrum-Schulungen. Wir laden unsere Leser ein, sich mit der nächsten praktischen Schulung vertraut zu machen, die zu einer Reihe von investigativen Schulungen für die folgenden Scrum-Artefakte gehört: Sprints, tägliche Stand-ups und Demo-Meetings.
Trainingsziel
Das dritte Training in unserer Teamtrainingsreihe für die Methodik der agilen Softwareentwicklung im Rahmen von Scrum war die Produktentwicklung auf der Grundlage eines bestehenden „Product Backlogs“ unter Verwendung von Scrum-Framework-Artefakten wie Sprint, „Daily Stand-up Meeting“ und „Product Increment Demo“.
Während des Trainings wurde an die Teammitglieder folgende Aufgabenstellung gerichtet:
- Wähle Elemente für den 1., 2. und 3. Sprint Backlog aus, basierend auf dem bestehenden Product Backlog.
- „Set Definition of Done (DoD)“ für die Sprint Backlog Elemente.
- Produziere eine Produktzunahme im Rahmen von Sprint Backlog Items.
- Demonstriere die entwickelten Produkte einander zwischen den Teams.
Durchführung des Trainings
Vorbereitung
Die Teammitglieder blieben in den gleichen Teams wie beim vorherigen Training (Schulung 2: „Auffüllen und Abschätzen von Projektrückständen“). Die Product Owners & Scrum Masters behielten ihre eigenen Rollen.
Für den Product Backlog haben wir Backlogs verwendet, die von beiden Teams beim vorherigen Training erstellt wurden: die Herstellung eines Mehrzweckstuhls gemäß den Anforderungen, die von jedem Team vorbereitet wurden.
Die Agenda war für 3 „zweitägige“ Sprints mit einer Dauer von je 15 Minuten geplant, plus 5 Minuten für tägliche Stand-up-Meetings, die von beiden Teams gleichzeitig durchgeführt werden. Nach jedem Sprint hielten die Teams ihre jeweiligen Demo-Meetings für alle Teilnehmer des Trainings ab: 5 Minuten für jedes Team.
Festlegen der Definition von erledigt
Die erste Stufe des Trainings endete mit der Erstellung von „Definition of Done for Sprint Backlog Items“ in beiden Teams. Die Entwicklung des Mehrzweckstuhls impliziert daher die folgende Definition von Done:
- Ergebnisdatenanalyse zur Problemanalyse;
- Verfügbarkeit einer visuellen Implementierung, um die Ergebnisse für jeden Artikel im Backlog zu bewerten;
- Möglichkeit, sich in das entstehende Produkt zu setzen.
Produktentwicklung
In beiden Teams wurde die Produktentwicklung wie folgt durchgeführt:
- Die Teams planten gleichzeitig den 1. Sprint mit dem bestehenden „Product Backlog“ (5 Minuten Aufwand).
- Hauptperiode für die Produktentwicklung: 15 Minuten als „Tag 1“, dann ein 5-minütiger Stand-up und 15 Minuten für „Tag 2“.
- Demo-Meeting und Planung des 2. Sprints (5 Minuten pro Team).
- Einen Backlog für den 2. Sprint erstellen.
Die Basis der Teams für ihre Entwicklungsarbeit waren Kinderbausätzen verschiedener Art. Es war auch erlaubt, improvisierte Mittel wie Papier, Karton, Aufkleber, Scheren, Schraubendreher usw. zu verwenden.
Nach Abschluss jedes Sprints erhielten die Teams bereits in der Planungsphase ein „Product Increment“, das die im Sprint Backlog festgelegten Anforderungen erfüllte. Jede Anforderung wurde im Detail ausgearbeitet, um die Spezifikation aus der Definition von „Done“ zu beantworten. Basierend auf dem oben Gesagten waren die Produkte bereit, im Rahmen der gegebenen Anforderungen demonstriert und eingesetzt zu werden.
Produktdemo
Beide Teams verfolgten abwechselnd die Demonstration der einzelnen Produkte: eines war in der Rolle des Entwicklungsteams (Sprint-Team), während das andere als Produktverwender (Stakeholder) fungierte.
Die Darstellung des Produkts wurde vom „Product Owne“r in jedem Team durchgeführt. Im Laufe der Demo äußerte jedes Entwicklungsteam das von ihm gewählte Sprint-Ziel sowie die für den aktuellen Entwicklungs-Sprint ausgewählten „Product Backlog Items“, um das Sprint-Ziel bis zum Limit zu erreichen.
Darüber hinaus zeigten die „Product Owners“, wie die Teams die Einhaltung der individuellen Sprint Backlog-Anforderungen sowie möglicher Anwendungsfälle des Produkts gemäß seinem Verwendungszweck erreicht hatten.
Im Anschluss an die Produktdemo für den aktuellen Sprint beantworteten der „Product Owner“ und das gesamte Entwicklungsteam Fragen des Kundenteams, klärten den Rest der Produktanforderungen und sammelten neue Anforderungen zur Planung des nächsten Sprints.
Weiterentwicklung
Nachdem das erste Sprint Inkrement angezeigt wurde, planten beide Teams den zweiten Sprint, dessen Teile ebenfalls im Rahmen des „zweitägigen“ Programms entwickelt wurden. Der zweite Sprint kam auch zur „Product Increment“ Demonstration in beiden Teams.
Obwohl noch Positionen im „Product Backlog“ vorhanden waren, wurde der Entwicklungsprozess nach dem zweiten Sprint eingestellt. Dies geschah mit dem Ziel, die Instabilität der „verschränkten“ Umgebung im „Cynefin-Framework“ zu demonstrieren, das von den meisten Software-Entwicklungsteams verwendet wird.
Die im „Product Backlog“ verbleibenden Positionen wurden überprüft, um die Richtigkeit der Priorisierung für diejenigen zu analysieren, die in den ersten Sprints verwendet werden.
Wesentliche Merkmale der Ausbildung
- Die Teams lernen die Produktentwicklung im Rahmen der Scrum Framework Events kennen: Sprints, tägliche „Stand-ups“, Demo.
- Sprint Backlog Elemente sind so weit wie möglich, mit einer bestimmten Richtung im Hinterkopf, zu gruppieren, um die Sprint Goal Ausgabe zu maximieren.
- Zeitnahe Demonstration der Produkt- und Rückkopplungssteuerung, die notwendig ist, um die Produktanforderungen just in time zu aktualisieren.
- Jeder Sprint kann sich jederzeit als der letzte für das jeweilige Produkt erweisen, aufgrund verschiedener Umstände: Unterfinanzierung, Änderung der Prioritäten durch den Kunden, etc. Die Teams sollten darauf vorbereitet sein.
