PINA-COLLADAVorgehensmodell mit Scrum-Elementen

2

Rollen• Auftraggeber: Prof. Knauth• Projektleiter: Angelo Hannes

• KEINE sonstigen klassischen Scrum-Rollen wie Product-Owner, Scrum-Master

3

Meetings• Sprint Planning Meeting 1 (Montag)

• Komplettes Team• WAS steht im Vordergrund

• Priorisierung und Überführung des Product Backlogs in das Sprint-Backlog (Sprintziel)

• Besprechung des Projektfortschritts mit dem Auftraggeber

• Ergebnis: Sprint-Backlog

4

Meetings• Sprint Planning Meeting 2 (Mittwoch)

• Es müssen nicht alle Entwickler anwesend sein• WIE steht im Vordergrund

• Technische Umsetzung der Issues wird besprochen• Kleingruppen

• Ergebnis: Tasks, welche nicht länger als 1 Tag dauern sollten

5

Meetings• Sprint Review

• Immer am Ende des Sprints (Jeden Montag)• Informelles Meeting

• Präsentation des Inkrements• Team diskutiert, was im Sprint gut lief, welche Probleme es gab

und wie diese gelöst wurden• Teamleiter präsentiert den aktuellen Stand des Backlogs• Das Team erarbeitet gemeinsam, was als nächtes angegangen

werden sollte, damit der nächste Sprint den größt möglichen Wertzuwachs liefert

6

Artefakte• Product Backlog

• (Geordnete) Liste mit allem, was in dem App benötigt wird. Bei uns sind die Product Backlog Items alle die Items auf Google-Code, welche als „New“ deklariert sind. Hier keine klare (räumliche) Trennung zwischen Product Backlog und Sprint Backlog

• Das PB wird niemals vollständig sein. Es werden also im Laufe des Projektes immer neue Items hinzu kommen (ist ein dynamisches Dokument welches sind permanent ändert)

• Es führt alle Features, Funktionen, Andorderungen, Verbesserungen und Fehlerbehebungen auf

• Die Issues (sollten ab sofort) alle über eine Beschreibung, Rangfolge und Schätzung! Verfügen

7

Artefakte• Product Backlog

• Höherrangige Einträge sind klarer und detaillierter als Niedrigere angeordnet

• Eine Präzise Schätzung kann nur auf Basis der größeren Klarheit und Detailtiefe erfolgen

8

Artefakte• Sprint Backlog

• Das Sprint Backlog ist die Menge der für den Sprint (1 Woche) ausgewählten Product Backlog Issues

• Die Fertigstellung des Sprint Backlogs wird bei uns automatisch das Sprintziel sein

• Es ist eine Prognose des Teams darüber, welche Funktionalitäten im nächsten Inkrement enthalten sein werden

• Wenn weitere Arbeiten möglich sind (z.B. frühere Fertigstellung), werden vom Entwickler aus dem PB neue Items in das SB aufgenommen

9

Artefakte• Burndown Chart

• Ein Burndownchart wird jeden Montag aktualisiert, so dass der Projektfortschritt eingeschätzt werden kann

• Zu JEDEM Issue werden Punkte vergeben, um den Umfang im Vergleich zu den Anderen einschätzen zu können

• Keine Toolunterstützung sondern lediglich ein Excel-Diagramm

• Durch die Tendenz der fertiggestellten Issues und deren Wertigkeit, kann eine Prognose über zukünftige Sprints sowie den gesamten Projektfortschritt gegeben werden.

10

Artefakte

1 20

200

400

600

800

1000

Burndown Chart

PunkteLinear (Punkte)Puffer

11

Artefakte• Definition of Done

• Der Code erfüllt die ihm zugedachten Aufgaben, ist kompilierfähig• Der Code erfüllt die Konventionen, ist sauber geschrieben• Die Fehlerbehandlung entspricht den internen Standards• Es gibt für alle nichttrivialen Klassen Unit Tests welche fehlerfrei

durchlaufen und dokumentiert wurden• Der Code sowie dessen Dokumentation (Testprotokoll) sind

eingecheckt