SCRUM Erfahrungen im Kleinen und Großen

Transkript

1 SCRUM Erfahrungen im Kleinen und Großen Matthias Niete Felix Kugel Orientation in Objects GmbH Weinheimer Str Mannheim Version: Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools 2

2 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Big Picture Sprints und Rollen Meetings Artefakte 3 Hintergrund 1986: Hirotaka Takeuchi & Ikujiro Nonaka kleine, interdisziplinäre teams produzieren die besten Ergebnisse The New New Product Development Game Lernende Organisation Erfolg z.b. bei Toyota 1995: The Knowledge Creating Company 4

3 SECI - Modell 5 Artefakte und Rollen 6

4 Wir verlieren den Staffellauf Der Staffellauf-Ansatz in der Produktentwicklung kann in Konflikt stehen mit Zielen wie maximale Flexibiltiät und Geschwindigkeit. Anstelle dessen mag ein holistischer Rugby Ansatz - in dem ein Team eine Entfernung durch Pässe rückwärts und vorwärts überbrückt - den heutigen Wettbewerbsanforderungen besser dienen. Quelle der Folien Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, Harvard Business Review, January Mountain Goat Software, LLC Worte über Scrum Scrum ist ein Agiler Prozess der uns einen Fokus auf die Auslieferung des höchsten Geschäftswerts in der kürzesten Zeit erlaubt. Er erlaubt uns häufig und wiederholend laufende Software zu begutachten. Der Fachbereich setzt die Prioritäten. Die Teams organisieren sich selbst, um den besten Weg zu finden, die Features mit der höchsten Priorität auszuliefern. Man kann mit 14 Tagen zum Ende eines Monats entscheiden, ob die Software released wird oder noch einen Sprint weiter entwickelt wird. 8

5 Big Picture 9 Done Potentially Shippable Code...integriert...getestet...dokumentiert 10

6 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Big Picture Sprints und Rollen Meetings Artefakte 11 Sprints Scrum Projekte laufen entlang einer Serie von Sprints Ähnlich wie den Iterationen von XP Typische Sprint Dauern sind 2-4 Wochen Eine konstante Dauer hilft der Rhythmusbildung Das Produkt wird während des Sprints entworfen, entwickelt und gestestet 12

7 Keine Veränderungen während des Sprints Änderungen Planen Sie die Sprintdauer abhängig davon, wie lange Veränderungen vom Sprint ferngehalten werden können 13 Rollen im Scrum Product Owner Scrum Master Team 14

8 Der Product Owner Definiert Produkt-Features Bestimmt Auslieferungsdatum und Inhalt Ist verantwortlich für das finanzielle Ergebnis des Projekts Priorisiert Features abhängig vom Marktwert Passt Features und Prioritäten nach Bedarf für jeden Sprint an Akzeptiert oder weist Arbeitsergebnisse zurück 15 Der Scrum Master Repräsentiert das Management gegenüber dem Projekt Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken Beseitigt Impediments (Hindernisse) Stellt sicher, dass das Team vollständig funktional und produktiv ist Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen Schützt das Team vor äußeren Störungen 16

9 Das Team Typischerweise 5-9 Personen Funktionsübergreifend: QS, Programmierer, UI-Designer, etc. Mitglieder sollten Vollzeitmitglieder sein Wenige Ausnahmen (z.b. Systemadministratoren) Teams organisieren sich selbst Ideal: keine Titel (aber manchmal nicht vermeidbar) Mitgliedschaft kann sich nur zwischen Sprints verändern 17 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Big Picture Sprints und Rollen Meetings Artefakte 18

10 Zeremonien Pre-Game: Sprint Planning Estimation In- Game: Daily Scrum Post- Game: Sprint Review Sprint Retrospective 19 Estimation Meeting Backlog item Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue-peravailable-room) 8 Improve exception handling Estimate Ziele Vermessung der User Stories (Features) Wissenstransfer und Produktidentifikation Planungsvorbereitung Teilnehmer Product Owner Scrum Master alle Teammitglieder Durchführung Product Owner jede Story kurz vor Team stellt fragen Team schätzt jede Story (z.b. mit StoryPoints) 20

11 Sprint Planungsmeeting Team Kapazität Product Backlog Sprint-Planungsmeeting Sprint Priorisierung Product Backlog analysieren und auswerten Sprint Ziel festlegen Sprint Ziel Business Umgebung Sprint-Planung Aktuelles Produkt Technologie Entscheiden, wie man das Sprint Ziel erreichen kann (Design) Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen Sprint Backlog in Stunden schätzen Sprint Backlog 21 Die Sprint Planung Team wählt Einheiten, zu deren Implementierung es sich verpflichten kann, aus dem Product Backlog aus Sprint Backlog wird erstellt Tasks werden identifiziert und geschätzt (1-16 Stunden) Dieses wird gemeinschaftlich getan, nicht vom ScrumMaster allein Highlevel-Design wird berücksichtigt As a vacation planner, I want to to see photos of of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4) 22

12 Das tägliche Scrum-Meeting Parameter: Täglich 15 Minuten lang Stand-up Nicht zur Problemlösung Alle sind eingeladen Aber nur Team-Mitglieder, der ScrumMaster, und der Produkt-Owner dürfen reden Hilft, andere/überflüssige Meetings zu vermeiden 23 Jeder beantwortet 3 Fragen 1 Was hast du gestern getan? 2 Was wirst du morgen tun? Welche Hindernisse sind in deinem Weg? 3 Diese sind kein Statusberichte für den ScrumMaster, sondern Verpflichtungen in Anwesenheit der Kollegen 24

13 Das Sprint-Reviewmeeting Das Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo der neuen Features oder der zugrunde liegenden Architektur Informell Zwei Stunden zur Vorbereitung -Regel Keine Folien Das ganze Team nimmt teil Laden Sie die ganze Welt ein! 25 Die Sprint-Retrospektiven Prüfen Sie regelmäßig, was gut und nicht so gut funktioniert Typischerweise Minuten lang Nach jedem Sprint Das ganze Team nimmt teil ScrumMaster Produkt-Owner Team Vielleicht Endkunden und andere Personen (aber Vorsicht!) 26

14 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Big Picture Sprints und Rollen Meetings Artefakte 27 Artefakte im Scrum Product Backlog Sprint Backlog Burndown-Diagramm Impediment Backlog 28

15 Das Product Backlog Die Anforderungen Eine Liste aller gewünschten Projektarbeiten Idealerweise soll jeder Eintrag wertvoll für Benutzer des Produktes oder Kunden sein Vom Produkt-Owner priorisiert Zu Beginn jedes Sprints re-priorisiert Product Backlog 29 Product Backlog: Beispiel Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue-per-availableroom) 8 Improve exception handling

16 Management des Sprint Backlog Team-Mitglieder wählen Tasks aus (Arbeit wird nie zugewiesen) Die geschätzte restliche Arbeit wird täglich aktualisiert Jedes Team-Mitglied kann Tasks hinzufügen, löschen oder ändern Neue, für den Sprint benötigte Arbeit taucht auf Wenn Arbeit unklar ist, definieren Sie eine Task mit einer größeren Zeitschätzung und brechen diese später herunter Updaten Sie verbleibende Arbeit sobald Sie mehr wissen 31 Sprint Backlog: Beispiel Tasks Mo Di Mi Do Fr Code the user interface Code the middle tier Test the middle tier Write online help 12 Write the foo class Add error logging

17 Das Sprint Burndown-Diagramm Stunden 33 Impediment Backlog: Beispiel Impediment von wem gestellt Status Verantwortlich Teambuild-Server to less memory FKU, TME, ABU in arbeit MNI Komponente xy von Firma Z noch immer nicht da LMU neu DMS Whiteboard für die Raucherecke KPU,FKU in arbeit DMS 34

18 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools 35 Agiles Manifest Manifesto for Agile Software Development (Beck, Fowler, Cockburn, uvm,. 2001) Einzelpersonen und Interaktionen wichtiger als Prozesse und Werkzeuge Laufende Systeme wichtiger als umfangreiche Dokumentation Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen Fähigkeit auf Änderungen zu reagieren wichtiger als Verfolgen eines Plans 36

19 Welche Fähigkeiten verlangt Scrum von den Beteiligten? Product Owner muss Produktideen initiieren, verfolgen, vertreten und erklären können 37 Welche Fähigkeiten verlangt Scrum von den Beteiligten? Teammitglieder muss technische Ideen entwickeln können/wollen muss teamfähig sein Probleme selber einschätzen und Lösungen umsetzen können KISS Prinzip lieben muss eigenverantwortlich handeln können/wollen 38

20 Welche Fähigkeiten verlangt Scrum von den Beteiligten? ScrumMaster muss soziale Kompetenz besitzen muss ausgeprägte Moderationsfähigkeiten besitzen muss angstfrei sein Nur wenn diese Fähigkeiten bei allen Projektmitgliedern vorhanden sind wird Scrum produktiv funktionieren! 39 Wie muss eine Organisation für Scrum gestrickt sein? Management Don t push, let them pull! Respekt und Vertrauen gegenüber den Entscheidungen der Product Owner, Teams und Scrum Master Notausgang für Non Scrumer Infrastruktur ein Team ein Raum mit Platz für daily Scrums, Whiteboards und PairProgramming Plätzen einen ruhigen Arbeitsplatz für den Product Owner extra Raum für Estimations, Planning, Reviews und Retrospektiven Meetings Hardwareausrüstung für Teamarbeit Ohne die Akzeptanz der Agilen Grundwerte im Management, bleibt alles wie es war... 40

21 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools 41 Rahmenbedingungen Entwicklung eines Prototypen keine Roadmap 1-3 Entwickler (Dienstleister) 1 Kernentwickler initial (Scrum zunächst, um Prozess einzuüben) 2 kamen während des Projektes hinzu 1 Product Owner (Kunde) 2 - Wochen - Sprints Der Kernentwickler als ScrumMaster (!) 42

22 Erfahrungen - Probleme Manches wurde als Overhead empfunden Retrospektiven- Dokumentation Burndown Chart Rollenschizophrenie Mischung zwischen Kunde und Dienstleister bei Retrospektiven Kritik am Product Owner nur verhalten Kommunikationsprobleme der Entwickler untereinander teilweise nicht offengelegt TimeBoxing wurde in Meetings oft nicht eingehalten Estimation Meetings wurden zu Spezifikations Meetings kaum Priorisierung des Backlog Durch kleine Gruppengröße leidet Respekt vor dem Prozess Könnt ihr mal bitte kurz Was lief gut? Iterationsziele wurden fast immer erreicht TaskBoard sehr hilfreich Gute Identifikation mit dem Produkt Hohes Qualitätsniveau Kontinuierliche Entwicklungsgeschwindigkeit durch kurze Sprints Alle fühlten sich im Prozess gut aufgehoben 44

23 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Wie skaliert Scrum? Erfahrungen 45 Skalierbarkeit Typische Teams bestehen aus 7 ± 2 Personen Teams von Teams ermöglichen Skalierbarkeit Faktoren des Skalierens Typ der Anwendung Teamgröße Teamverteilung (örtlich) Projektdauer Scrum ist mehrmals für 500-Personenprojekte verwendet worden 46

24 Wie Skaliert Scrum? Organisches Wachstum Primär Teamzelle Primär Teamzelle Neue Teamzelle 47 Scrum of Scrums 48

25 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools Wie skaliert Scrum? Erfahrungen 49 Erfahrungen aus einem Großprojekt Rahmenbedingungen ~ 60 Leute ein Produkt aus vielen unabhängigen Modulen 7 Teams verteilt auf zwei Länder jeweils ein Teamleiter ~ 5 Produktverantwortliche 1/2 Jahres Releasezyklen 50

26 Erfahrungen aus einem Großprojekt Umsetzung 7 Teams (3 hier, 4 da) Teamstärke ~7 Personen Team QA Architekt junior & senior Softwareengineers 7 Scrum Master 5 Product Owner ein Chefarchitekt jeweils ein Entwicklungsleiter separates QA Team Architekturboard Release Planning Game Daily Scrum of Scrum (30 min Telko) 51 Erfahrungen aus einem Großprojekt Was lief gut? Transparenz der eigentlichen Probleme Aktivierung verborgener Fähigkeiten Halbierung des Entwicklungszyklus Teilung von Entwicklungsverantwortung 52

27 Erfahrungen aus einem Großprojekt Was waren die Probleme? kein organisches Wachstum teilzeit Scrum Master zu wenige Product Owner fehlendes Vertrauen und Verständnis des Management zu viele Abhängigkeiten zw. den Lokationen keine alternativ Teamstrukturen 53 Gliederung Was ist Scrum? Wer soll überhaupt Scrum machen? Scrum in kleinen Projekten Scrum in großen Projekten Nützliche Scrum Tools 54

28 Jira PlugIn GreenHopper - Task Board 55 Jira PlugIn GreenHopper - Planning Board Features feat. 1 -feat. 2 -feat feat 7 -feat. n Features feat. 4 -feat. 5 -feat feat. m 56

29 Scrum Pokercards The Scrum Game Scrum Alliance TM - Scrum Game ( 58

30 Links Scrum Alliance Jira Green Hopper Ken Schwaber OOPSLA Vielen Dank für Ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim Version:

31 ??? Orientation in Objects GmbH Weinheimer Str Mannheim? Fragen?? Version: