1 / 11

Pina- Collada

Pina- Collada. Vorgehensmodell mit Scrum -Elementen. Rollen. Auftraggeber: Prof. Knauth Projektleiter: Angelo Hannes KEINE sonstigen klassischen Scrum -Rollen wie Product-Owner , Scrum -Master. Meetings. Sprint Planning Meeting 1 (Montag) Komplettes Team WAS steht im Vordergrund

kay
Télécharger la présentation

Pina- Collada

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Pina-Collada Vorgehensmodell 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 ProductBacklogs 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 • ProductBacklog • (Geordnete) Liste mit allem, was in dem App benötigt wird. Bei uns sind die ProductBacklog Items alle die Items auf Google-Code, welche als „New“ deklariert sind. Hier keine klare (räumliche) Trennung zwischen ProductBacklog 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 • ProductBacklog • 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 ProductBacklogIssues • 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

  11. Artefakte • Definition ofDone • 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

More Related