Überblick WPF - IN, WI, TI, IAM

Transkript

1 Scrum

2 Überblick

3 Scrum Was ist Scrum? Scrum ist eine agiles Projektmanagement Rahmenwerk Scrum ist eine Methode zum Management komplexer Systeme (Inspect & Adapt) Scrum ist eine Methode zur Einführung agiler Projektmanagementmethoden in Unternehmen (Enterprise Scrum)

4 Scrum Was ist Scrum? Selbst-organisierende Teams Produkt schreitet in Serien von monatlichen Sprints fort Anforderungen sind als Listeneinträge im Produkt-Backlog festgehalten Keine spezifischen Entwicklungsvorgehen vorgeschrieben Benutzt generative Regeln um ein agiles Umfeld für die Auslieferung von Produkten zu schaffen Einer der agilen Prozesse

5 Scrum

6 Scrum-Rollen

7 Scrum- Rollen Product Owner

8 Scrum- Rollen Product Owner

9 Scrum- Rollen Product Owner ist verantwortlich für den Erfolg der gesamten Entwicklungsvorhaben eines Produktes oder einer Produktlinie. bringt die Produktvision ins Team. beschreibt die Anforderungen und verwaltet das Product Backlog. erstellt den Releaseplan und die Releaseberichte. managed die Stakeholder und arbeitet eng mit dem Team während der gesamten Projektlaufzeit zusammen.

10 Scrum- Rollen Product Owner Definiert Produkt-Features Bestimmt Auslieferungsdatum und Inhalt Ist verantwortlich für den Gewinn des Projekts (ROI) Priorisiert Features abhängig vom Marktwert Passt Features und Prioritäten nach Bedarf für jede Iteration an Akzeptiert oder weist Arbeitsergebnisse zurück

11 Scrum- Rollen Scrum-Master

12 Scrum- Rollen Scrum-Master

13 Scrum- Rollen Scrum-Master Verantwortlich für die Einhaltung von Scrum-Werten und - Techniken Entfernt 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 hilft, Scrum richtig anzuwenden. Repräsentiert das Management gegenüber dem Projekt unterstützt das Team und stellt die direkte Arbeit zwischen ProductOwner und Team sicher

14 Scrum- Rollen Scrum-Master beseitigt Impediments und hilft dem Team, seine Produktivität kontinuierlich zu steigern. ist der Trainer und Moderator des Teams. Er hat immer einen Trainingsplan für sein Team - das Impediment Backlog. hält die "inspect and adapt" Zyklen von Scrum unter Kontrolle. beschützt das Team und arbeitet zusammen mit dem Product Owner an der Maximierung der Rendite.

15 Scrum- Rollen Exkurs: Scrum Master

16 Scrum- Rollen Exkurs: Scrum Master

17 Scrum- Rollen Das Team

18 Scrum- Rollen Das Team

19 Scrum- Rollen Das Team Typischerweise fünf bis zehn Leute funktionsübergreifend QA, Programmierer, UI-Designer, etc. Teams organisieren sich selbst Mitgliedschaft kann sich nur zwischen Sprints verändern besteht aus unterschiedlichen Spezialisten, damit alle notwendigen Kenntnisse zur Realisierung des Produktes vorhanden sind.

20 Scrum- Rollen Das Team muss die Vision und die Sprint Ziele des Product Owners verstehen, um funktionsfähige Produktinkremente zu liefern ist bevollmächtigt und autonom organisiert seine Arbeit selbst interdisziplinär besetzt

21 Scrum Meetings Überblick Visions Workshop Estimation Meeting Sprint Planning 1 Sprint Planning 2 Daily Scrum Scrum of Scrums Review Retrospektive

22 Scrum-Meetings Visions Workshop

23 Scrum-Meetings Estimation Meeting

24 Scrum-Meetings Sprint Planning 1 + 2

25 Scrum-Meetings Daily Scrum und Scrum of Scrums

26 Scrum Meetings Review

27 Scrum Meetings Retrospektive

28 Scrum-Meetings Visions Workshop

29 Scrum- Anforderungsmanagement Anforderungen "Unter einer Anforderung oder einem Requirement versteht man einen Aspekt, den die zu erstellende Software erfüllen soll. Unter der Summe aller Anforderungen verstehen wir alle die Aspekte des Einsatzkontextes, die vom zukünftigen System abgedeckt werden sollen."

30 Scrum-Anforderungsmanagement Anforderungen Problem: Detaillierungsgrad wenige Dokumente - schnelle Software wenig im Voraus kleine Anforderungen überschaubare Iterationen so aufnehmen, dass Umfang geschätzt werden kann Lernprozess

31 Scrum-Anforderungsmanagement Anforderungen in Scrum Pragmatischer Weg: kommender Sprint Klarheit zwischen Entwickler und Kunde "User-Stories" zur Beschreibung der Anforderungen Story als "Versprechen" Story als Kommunikationsmittel so genau, dass man schätzen kann Karteikarten Stories aus Nutzersicht beschreiben, nicht technisch

32 Scrum-Anforderungsmanagement Story Card Als XY möchte ich folgendes Feature damit...

33 Scrum-Anforderungsmanagement Story Card Abnahmekriterien: Rahmenbedingungen: Lieferantenbeziehung: Story Points: Wichtigkeit:

34 Scrum - User Stories Story Card - Advanced Ist die Story schätzbar? Zerlegen von großen in kleinere Stories Vertikal schneiden Fachlich trennen Fachliche Entität Rolle Kontext Ergebnis Details Aufgabe

35 Scrum- Anforderungsmanagement Story Card - Advanced Straßenmetapher Größe von Pareto

36 Scrum - User Stories User Story Kriterien nach dem INVEST Prinzip Independent (I) Sie ist nicht von einer anderen User Story abhängig Negotiable (N) Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden. Valuable (V) Sie stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar Estimatable (E) Sie ist schätzbar. Sie hat also soviel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann Small (S) Sie hat die richtige Größe Testable (T) Sie kann getestet werden.

37 Scrum - User Stories Gute Stories schreiben Aus Anwendersicht Teamwork ist gefragt Kommunikation ist wichtig Keep it simple Abnahmekriterien (Akzeptanzkr.) sind wichtig Mit Papierkarten arbeiten (alternativ: visuelles Taskboard) Immer im Blick behalten

38 Scrum-Meetings Estimation Meeting

39 Scrum-Schätzen Definition Of Ready Wann ist eine Story "Ready to estimate"?

40 Scrum-Schätzen Definition Of Ready Wann ist eine Story "Ready to estimate"? Ist dem Team alles klar? Abnahmekriterien Lieferantenbeziehung Tests

41 Scrum-Schätzen Wie schätzen wir Aufwände Wetter von gestern Fachliche Nachfragen ermöglichen Entwicklerteams schätzen Abstrakte Schätzmaße Demokratisches Schätzen

42 Scrum-Estimation Estimation Meeting - Agenda Planning Poker Diskussionen sind wichtig Fibonacci Reihe als Wertebereich Nivillierung (Referenz) Definition Of Ready Referenzstory Niedrigste und höchste Schätzung diskutieren

43 Scrum-Estimation Estimation Meeting - Details Zunächst erhält jedes Teammitglied einen Stapel mit Schätz-Karten (Alternativ: Scrum App -> Suche im Market unter: "Scrum"). Der PO stellt eine zu schätzende Story vor. Das Team klärt etwaige Unklarheiten mit dem PO. Dann bespricht das Team die wesentlichen zur Umsetzung des Eintrags notwendigen Schritte. Jedes Teammitglied wählt eine Karte aus und legt sie verdeckt vor sich auf den Tisch. Zeitgleich drehen alle Teammitglieder ihre Karten um. Liegt kein Konsens vor, so erklären die beiden Teammitglieder, deren Schätzwerte am weitesten auseinander liegen, warum sie den jeweiligen Wert gewählt haben. Dann erfolgt eine neue Schätzrunde. Der ScM moderiert und stellt sicher, dass die Besprechung pünktlich endet (Timebox). Das Meeting endet, wenn alle Einträge abgeschätzt, oder die Zeit abgelaufen ist. Anhand der geschätzten Komplexitäten können dann Dauer und Kosten errechnet werden.

44 Scrum-Estimation Schnelles Schätzen - Alternative "Magical Estimation" geeignet für sehr grobe Schätzungen alle Stories werden ausgedruckt an Teammitglieder verteilt jeder hängt seine Stories an die Wand links die einfachsten, rechts die komplexesten danach werfen alle nochmal einen Blick darauf evtl. Nachbesserungen Einigung, wo man die Fibonacci Zahlen positioniert Wichtig: solche Schätzungen müssen als "magic" markiert werden

45 Scrum-Estimation Gesamtlaufzeit - Alternative Machbarkeit und Kosten/Nutzen bewerten Ein Schätzverfahren für unterschiedliche Größen Zu Beginn alle Storys kennen: Unrealistisch! Hirarchie aus Subsystem, Feature und Story Story Effort Points "step" Feature Effort Points "feep" System Effort Points "syep" Schätzeinheiten: vollkommen unabhängig Schätzung hier: Gewichtung Wertebereich: 1-5 Sching-Schang-Schong-Schätzen Top Down schätzen - Bottom Up umrechnen

46 Scrum-Meetings Sprint Planning 1 + 2

47 Scrum-Meetings - Planning Sprint Planning 1 Im Sprint Planning 1 erstellt das Team ein Sprint Backlog welches festlegt, welche Stories innerhalb des Sprints umgesetzt werden können. Zentrale Frage "Was machen wir?"

48 Scrum-Meetings - Planning Ablauf Der Scrum-Master macht die Eckdaten des Sprints sichtbar Product Owner stellt Sprint-Ziel und die Vorauswahl der umzusetzenden Anforderungen vor Team legt fest, welche und wie viele der vom Product Owner vorbereiteten Stories innerhalb des Sprints umgesetzt werden können Scrum Master moderiert und achtet auf die Einhaltung der Regeln (vor allem Wahrung des Pull-Prinzips, d.h.: Das Team nimmt sich die Aufgaben, NICHT: Der Product Owner weist die Aufgaben zu) Team verpflichtet sich, die ausgwählten Stories komplett umzusetzen

49 Scrum-Meetings - Planning Sprint Planning 2 Im Sprint Planning 1 bricht das Team die einzelnen Stories in Tasks herunter und plant die Abarbeitungsreihenfolge. Zentrale Frage "Wie machen wir es?"

50 Scrum-Meetings - Planning Sprint Planning 2 Entwicklungsteam weiß bereits, was es zu erledigen hat technische Umsetzung klären (ohne jedoch mit der eigentlichen Umsetzung zu beginnen). Dieses Meeting organisiert das Entwicklungsteam eigenverantwortlich Ergebnis dieses Meetings: Aufgaben oder Tasks, (dauer pro Task: max 1 Tag) WS 2011/12 WPF - IN7, WI7, TI7, IAM7

51 Scrum-Meetings - Planning Sprint Planning 2 Taskcards zusammen mit User Stories an Pinnwand (Taskboard) Pro Teammitglied ein "Bereich, in den er seine Tasks hängen kann Übersichtlich anordnen, damit erkennbar welche Aufgaben zu bearbeiten / in Bearbeitung sind, und welche bereits bearbeitet wurden Anzahl Tasks auf "Burndown Chart" markieren WS 2011/12 WPF - IN7, WI7, TI7, IAM7

52 Scrum-Meetings Daily Scrum und Scrum of Scrums WS 2011/12 WPF - IN7, WI7, TI7, IAM7

53 Scrum-Meetings Pigs and Chickens Beteiligte heißen Personen Pigs (Schweine) Außenstehende heißen Chickens (Hühner). A chicken and a pig were brainstorming... Chicken: Let's start a restaurant! Pig: What would we call it? Chicken: Ham 'n' Eggs! Pig: No thanks. I'd be committed, but you'd only be involved! WS 2011/12 WPF - IN7, WI7, TI7, IAM7

54 Scrum-Meetings Pigs and Chickens Leute, die tatkräftig mitarbeiten und auch ein echtes Risiko auf sich nehmen. Sie sind "committed". In Scrum nennen man solche Leute daher "Pigs". Personen, die zwar gern mitreden, kritisieren und schlußendlich am Erfolg partizipieren wollen, ansonsten aber eher unbeteiligt sind Sie wollen gern "involved" sein. In Scrum nennt man sie daher "Chickens". WS 2011/12 WPF - IN7, WI7, TI7, IAM7

55 Scrum-Meetings Pigs Direkt am Projekt beteiligte Personen, die auch eine Last bzw. ein Risiko im Projekt tragen Arbeiten in durch die Scrum-Regeln definierter Weise zusammen Treffen sich regelmäßig zu kurzen, effizienten Meetings Halten ihre jeweiligen Scrum-Artefakte auf dem neuesten Stand, damit alle - auch die Chickens - sich selbständig über den Fortschritt informieren können WS 2011/12 WPF - IN7, WI7, TI7, IAM7

56 Scrum-Meetings Chicken Am Projekt interessierte, jedoch nicht direkt an der Umsetzung und am Projektrisiko beteiligte Personen Geben vor, wissen zu müssen, was passiert, weil es angeblich ihre Arbeit in irgendeiner Weise berührt/beeinflußt Overhead in Meetings und im gesamten Prozeß Bekommen in Scrum einmal pro Sprint Gelegenheit, sich zu informieren und Feedback zu geben Werden ansonsten gleich zu Beginn aus dem Prozeß eliminiert dürfen bestenfalls in Meetings zuhören WS 2011/12 WPF - IN7, WI7, TI7, IAM7

57 Scrum-Meetings Daily Scrum ist ein Abstimmungsmeeting für die Teammitglieder. findet jeden Tag zur gleichen Zeit und am gleichen Ort statt. Die Dauer des Meetings ist auf 15 Minuten beschränkt. Dabei beantwortet jedes Teammitglieder die folgenden 3 Fragen: 1. Was habe ich seit dem letzten Daily Scrum erreicht? 2. Was hat mich daran behindert? 3. Was werde ich bis zum nächsten DailyScrum erreichen? WS 2011/12 WPF - IN7, WI7, TI7, IAM7

58 Scrum-Meetings Daily Scrum - Benefits verbessert die Kommunikation, machet andere Meetings überflüssig, identifiziert und beseitigt Hindernisse für die Entwicklung betont und fördert die schnelle Entscheidungsfindung verbessert den Kenntnisstand über das Projekt für alle Der ScrumMaster sorgt dafür, dass das Team dieses Meeting durchführt Das Team ist für die Durchführung des Daily Scrums verantwortlich WS 2011/12 WPF - IN7, WI7, TI7, IAM7

59 Scrum-Meetings Daily Scrum - übliche Fehler Der ScrumMaster bringt dem Team bei, wie es das Daily Scrum kurz hält, indem er die Regeln durchsetzt und dafür sorgt, dass sich die Teilnehmer kurz fassen. Der ScrumMaster setzt auch die Regel durch, dass Hühner" während des Daily Scrums nicht sprechen oder sich auf andere Weise in das Daily Scrum einmischen. WS 2011/12 WPF - IN7, WI7, TI7, IAM7

60 Scrum-Meetings Daily Scrum - Do's and Don'ts kein Reportmeeting nicht für jeden gedacht, sondern nur für die Mitarbeiter, die aus den Product Backlog-Einträgen ein Produkt-Inkrement erstellen (das Team). ist eine Inspektion des Fortschritts in Richtung auf dieses Sprintziel (die drei Fragen). Folgemeetings werden häufig eingeplant, um Anpassungen an der aufkommenden Arbeit im Sprint vorzunehmen. Die Zielsetzung ist es, die Wahrscheinlichkeit zu erhöhen, dass das Team sein Ziel erreicht. Schlüsselmeeting zur Inspektion und Adaption in Scrum. WS 2011/12 WPF - IN7, WI7, TI7, IAM7

61 Scrum-Meetings Scrum of Scrums Bei großen Projekten arbeiten deutlich mehr als sieben Personen zusammen mehrere Teams werden gebildet, die sich in der Folge untereinander mit möglichs wenig Overhead koordinieren und abgleichen müssen Jedes Team eigenständig mit jeweils eigenem Sprint Backlog, eigenen Daily Scrums usw. Jedes Team: ein Mitglied in den Scrum of Scrums Ablauf nach Muster des Daily Scrum Teambotschafter berichten aus ihrem Teilprojekt Sie nehmen Informationen mit zurück in ihre jeweiligen Teams WS 2011/12 WPF - IN7, WI7, TI7, IAM7

62 Scrum Meetings Review WS 2011/12 WPF - IN7, WI7, TI7, IAM7

63 Scrum Meetings Review WS 2011/12 WPF - IN7, WI7, TI7, IAM7

64 Scrum Meetings - Review Review Findet als Sprintabschluss statt ein auf vier Stunden beschränktes Meeting für einmonatige Sprints für kürzere Sprints: nicht mehr als 5% der gesamten Sprintzeit Scrum Team und Stakeholder arbeiten zusammen an der Betrachtung der Arbeitsergebnisse Auf dieser Basis erarbeiten sie die nächsten möglichen Schritte Rein informelles Meeting Vorführung der Funktionalität ist dazu gedacht, die Zusammenarbeit für die weitere Planung zu fördern. WS 2011/12 WPF - IN7, WI7, TI7, IAM7

65 Scrum Meetings - Review Ablauf Der Product Owner identifiziert, was fertig gestellt wurde und was nicht. Das Team diskutiert, was während des Sprints funktioniert hat, wobei es Probleme gegeben hat UND wie diese Probleme gelöst worden sind. Das Team demonstriert die geleistete Arbeit und beantwortet Fragen dazu. Der Product Owner diskutiert den aktuellen Stand des Product Backlogs. Alle Teilnehmer erarbeiten was ihr Eindruck über das gerade gesehene in Bezug auf die weitere Planung bedeutet. WS 2011/12 WPF - IN7, WI7, TI7, IAM7

66 Scrum Meetings Retrospektive WS 2011/12 WPF - IN7, WI7, TI7, IAM7

67 Scrum Meetings Retrospektive WS 2011/12 WPF - IN7, WI7, TI7, IAM7

68 Scrum Meetings Retrospektive Zeitpunkt: nach Review und vor Planning Entwicklungsprozess nach Scrum-Vorgaben inspizieren Ziel: kommenden Sprint effektiver und angenehmer gestalten Sinn: Wie ist der letzte Sprint gelaufen im Bezug auf: Menschen Beziehungen Prozess Werkzeuge wesentlichen Punkte identifizieren und priorisieren, die gut funktioniert haben WS 2011/12 WPF - IN7, WI7, TI7, IAM7

69 Scrum Meetings Retrospektive Punkte identifizieren, die noch besser gelaufen wären, wenn sie anders angegangen worden wären Themen: Teamzusammensetzung Meeting-Arrangements Werkzeuge die Definition von fertig" Kommunikationsmethoden Prozesse, um aus dem Product Backlog etwas fertiges" herzustellen Scrum Team identifiziert umsetzbare Verbesserungsmaßnahmen WS 2011/12 WPF - IN7, WI7, TI7, IAM7

70 Scrum Meetings Retrospektive Viele Techniken für Retrospektiven Retrospektiven werden meist in den folgenden 5 Schritten durchgeführt: 1. Intro 2. Daten sammeln 3. Einsichten gewinnen: Warum sind die Dinge wie sie sind? 4. Maßnahmen beschließen 5. Abschluss WS 2011/12 WPF - IN7, WI7, TI7, IAM7

71 Scrum Meetings Retrospektive - weitere Techniken Mad, Glad, Sad Wandernder Stift Fist of Five (Happiness Histogram) Offene Diskussion Brainstorming Energy Seismograph (Gefühlswelle) Sailboat Spiderchart WS 2011/12 WPF - IN7, WI7, TI7, IAM7

72 Scrum Meetings Checkliste für eine erfolgreiche Retrospektive Gibt es einen Moderator und ist jedem klar, wer das ist? Bereitet der Moderator die Retrospektive vor? Hält sich der Moderator aus der inhaltlichen Diskussion heraus? Setzt der Moderator Hilfsmittel wie Moderationswände und -karten angemessen ein? Variiert der Moderator die konkrete Durchführungsform der Retrospektive? Wird die Timebox für die Retrospektive eingehalten? Findet die Retrospektive in einer angstfreien, energiegeladenen Atmosphäre statt? Partizipieren alle Teilnehmer aktiv an der Retrospektive? Werden die Ursachen für Probleme analysiert? Generiert die Retrospektive konkrete, umsetzbare Maßnahmen (SMART)? Werden die beschlossenen Maßnahmen schnell umgesetzt? WS 2011/12 WPF - IN7, WI7, TI7, IAM7