Agile Projekte führen nach Scrum Guide

Transkript

1 Agile Projekte führen nach Scrum Guide Informatik-Kolloquium der Friedrich-Schiller-Universität Jena Regionalgruppe Ostthüringen der Gesellschaft für Informatik (GI) Ernst-Abbe-Hochschule Jena

2 Klare Trends Quelle: Google Trends,

3 Warum Agil? Produkte für Individuen Lokale Märkte: Handwerk Enge, globale Märkte: Winner takes all heute t (und Produktkomplexität) Produkte für Massen Weite, träge Märkte: Tayloristische Industrie Basierend auf: BetaCodex Network Associates, Organize for complexity, BetaCodex Network White Paper 12 & 13 3

4 Erfolgsfaktoren für Unternehmen Industrielles Zeitalter Kosten-Effizienz Skalierbarkeit Reproduzierbarkeit Zuverlässigkeit Post-industrielles Zeitalter Durchlaufzeit Anpassungsfähigkeit Beweglichkeit Ausdauer 4

5 Agenda 1. Das Referenzdokument 2. Drei Säulen der Scrum-Theorie 3. Rollen in Scrum 4. Scrum Ereignisse und Artefakte 5. Zusammenfassung:

6 Das Referenzdokument Letzte Ausgabe: Juli

7 Iterativ-Inkrementelles Vorgehen Jede Iteration enthält alles von Anforderungs-Analyse bis System- / Abnahme-Test Leistungsumfang ~ Inkremente Iteration 0 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Release 1 Iteration 6 Iteration 8 Iteration 7 Release 2 Zeit ~ Iterationen 7

8 Drei Säulen der Scrum-Theorie 8

9 Drei Säulen der Scrum-Theorie 9

10 Transparenz zuwider einer traditionellen Linie der Sichtbarkeit Liefertermin Anforderungsanalyse Design Integrationstest Verspäteter Liefertermin Abnahmetest Linie der Sichtbarkeit Implementierung Unittest Änderungen... gegen Widerstände Offenbarung t 10

11 Rollen in Scrum 11

12 Rollen in Scrum

13 Stakeholder im Scrum Guide nicht definiert, aber 5-mal verwendet Endkunden. Dies sind die Menschen, die das Produkt nutzen oft um Ziele für die Auftraggeber zu erreichen. In der Regel wollen die Endkunden Lösungen, die benutzerfreundlich sind und ihnen erlauben ihre Arbeit effektiv zu erledigen. Auftraggeber. Dies sind die Entscheider, die letztendlich für das Produkt zahlen und es einsetzen. Zu ihnen gehört der Projektsponsor, die Geschäftsleitung, und die Einkäufer, die das Produkt ggf. bestellen. Partner. Diese Menschen bringen die Lösung in der Produktion zum Laufen. Dazu gehören Betrieb, Technischer Support, Schulungspersonal, Rechtsberater, Servicetechniker, Hoster, oder Anwendungsentwickler von Systemen, die mit dem Produkt zu integrieren sind. Insider. Dies sind die Mitglieder des Entwicklungsteams und Kollegen, die technische und Unternehmens-bezogene Unterstützung leisten. Zu ihnen gehören Unternehmens- Architekten, Datenbank-Administratoren, Sicherheits- und Netzwerkexperten, Betreuer der Entwicklungs und Testumgebungen, sowie Marketing und Vertrieb. 13

14 Product Owner Vertritt im Sinne der Wertmaximierung die Bedürfnisse und Interessen der Stakeholder gegenüber dem Scrum Team. Versteht, klärt, konsolidiert und priorisiert die verschiedenen Anforderungen an das Produkt mittels Product Backlog. PO ist eine einzelne Person, kein Komitee! Die eine Stimme aller Stakeholder Setzt nicht unbedingt die Produktstrategie oder Ziele, sondern gestaltet das Product Backlog zu deren optimaler Erreichung. Beantwortet Fragen des Scrum Teams und trifft mit ihm Entscheidungen zur Produktgestaltung; beschafft ggf. Antworten. Lädt zum Sprint Review ein und erklärt welche PB-Einträge Done sind; darf als Einziger einen Sprint abbrechen. entscheidet über die Auslieferung von Inkrementen. Dem Entwicklungsteam ist es nicht erlaubt, nach den Angaben einer anderen Person als denen des Product Owners zu arbeiten. 14

15 Scrum Master Coacht das Scrum Team bei der Anwendung der Scrum Vorgehensweise und deren kontinuierlicher Verbesserung. Unterstützt bei Bedarf die Durchführung von Scrum Ereignissen. Beseitigt Hindernisse ( Impediments ) für das Entwicklungsteam und schützt es vor äußeren Störungen. Hilft dem Scrum Team vollständig funktional und produktiv zu sein; insbes. gesunder Teamgeist und reibungloses Zusammenspiel mit Product Owner und Stakeholdern. Unterstützt den Product Owner bei seiner Wertmaximierung mittels Product Backlogs, u.a. durch Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld. Leiten und Coachen der Organisation bei der Einführung von Scrum. 15

16 Scrum Ereignisse und Artefakte 16

17 Rollen 1. Product Owner 2. Scrum Master 3. Teammitglied Artefakte 1. Product Backlog 2. Sprint Backlog 3. Inkrement Ereignisse 1. Sprint 2. Sprint Planung 3. Daily Scrum 4. Sprint Review 5. Sprint Retrospektive Transparenz der Artefakte 1. Definition of Done 17

18 Drei Scrum Artefakte und fünf Scrum Ereignisse SPRINT 1 Monat 2. SPRINT PLANUNG 4. SPRINT REVIEW 5. SPRINT RETRO- SPEKTIVE 18

19 Sprint Planung 1 Mit dem ganzen Scrum Team beantwortet die Sprint Planung binnen max. 8 Std.: 1. Was können wir in diesem Sprint fertigstellen? 2. Wie gehen wir dabei vor? Der Product Owner erklärt die Zielvorstellung für den Sprint anhand der aktuellen Roadmap und des letzten Inkrements. Dann rekapituliert er die entsprechenden User Stories von der Spitze des Product Backlogs. Auf Grundlage der veranschlagten Kapazität und seines bisherigen Durchsatzes bestimmt das Entwicklungsteam wieviele der gewünschten User Stories es für machbar hält. Im Rahmen dieser Vorgaben vereinbart ( crafts ) das Scrum Team gemeinsam ein vorläufiges Sprintziel. 19

20 Sprint Planung 2 Wie erledigen wir unsere Arbeit? Systemdesign der Lösung Aufschlüsselung der Arbeit, wobei nur für die ersten Tage des Sprints gilt: oft heruntergebrochen auf die Größenordnung eines Tages oder weniger Klärungen und Verhandlungen mit PO, bei denen das vorläufige Ergebnis von Sprint Planung 1 angepasst wird. Abschließend ist das Entwicklungsteam in der Lage PO und Scrum Master zu erklären, wie es selbst-organisiert vorgehen will, um das Sprintziel zu erreichen und das Inkrement zu realisieren. Sprint Backlog: Ausgewählte Stories + Plan zur Erreichung des Sprintziels 20

21 Daily Scrum Konzentrierte Besprechung im Stehen Dauert maximal 15 Minuten! Jeden Tag gleiche Zeit, gleicher Ort Jedes Mitglied des Scrum-Teams beantwortet drei Fragen: Was habe ich seit dem letzten Scrum zur Erreichung des Sprintziels getan? Was habe ich bis zum nächsten Scrum für die Zielerreichung vor? Was für Hindernisse liegen in meinem Weg? Nichts sonst! Keine Diskussionen, keine Lösungssuchen, 21

22 Sprint Review Überprüfung des Inkrements am Sprintende Demo des Done, Erklärung des Not Done & Anpassung des Product Backlogs: PO stellt den Stand des Product Backlogs vor und gibt Ausblick auf Liefertermine Teilnehmer: ganzes Scrum-Team + wichtige Stakeholder, die der PO eingeladen hat 4-Std.-Timebox bei einem 1-Monats-Sprint Schafft hohe Transparenz und die Gelegenheit mit Erwartungen umzugehen Bietet Stakeholdern eine Plattform, um sich zum Produkt bzw. Lösungsansatz zu äußern 22

23 Sprint Retrospektive Überprüfung & Anpassung nach jedem Sprint Review und vor der Sprint Planung Fokus auf Menschen, Beziehungen, Prozess und Tools Das ganze Scrum-Team nimmt teil 3-Std.-Timebox bei einem 1-Monats-Sprint Hauptpunkte, die gut gelaufen sind oder die Verbessungspotential haben Konkreter Plan für Verbesserungsmaßnahmen 23

24 Product Backlog Höhere Priorität & feinere Granularität Streng Sortiert! Iteration Release Niedrigere Priorität & gröbere Granularität Product Backlog Eisberg Zukünftige Releases 24

25 Definition of Done (DoD) Im Sinne einer Qualitätssicherung beschreibt die DoD für alle PB-Einträge einheitliche Abnahmekriterien. Schafft ein gemeinsames Verständnis für alle Teammitglieder und Stakeholder, welche Arbeiten und Aufwände anfallen, um einen PB-Eintrag und ein Inkrement fertig zustellen. Die aktuelle DoD gilt für den aktuellen Sprint. Sie wird vor allem bei der Retrospektive überprüft und weiterentwickelt. Im Scrum Guide ist nicht festgelegt, wer anhand der DoD ein Inkrement oder einen PB- Eintrag abnimmt. Die DoD wird erstellt und fortgeschrieben als 1. Teil der Konventionen, Standards oder Richtlinien einer Entwicklungsorganisation 2. Vereinbarung eines Entwicklungsteams für ein einzelnes Produkt 3. Vereinbarung mehrerer Entwicklungsteams, die am selben System- oder Produktrelease arbeiten. 25

26 Zusammenfassung

27 Zusammenfassung Drei Rollen Fünf Ereignisse Drei Artefakte Transparenz der Artefakte Sprint Product Owner Product Backlog Sprint Review Sprint Backlog Definition of Done Sprint Planung Scrum Master Daily Scrum Entwicklungs -team Inkrement Retrospektive 27

28 Agile development will not solve any of your problems it will only make them so painfully visible that it s harder to ignore them Ken Schwaber Co-Founder of SCRUM 28