2. Was ist Scrum
• schlankes Projektmanagement Framework
• einfache Regeln
• besonderst für Projekte mit "schwammigen" Anforderungen geeignet
• Änderungen während des Projektes sind erwünscht
• selbstorganisiertes und eigenverantwortliches Team steht im
Vordergrund
• stark beeinflusst durch Extreme Programming (XP)
• iteratives Vorgehen und Verbesserung der Vorhersehbarkeit
3. Was ist Scrum
Scrum basiert auf der Theorie des Empirismus
"Empirismus basiert auf der Grundannahme,
dass Wissen aus Erfahrung gewonnen wird
und dass Entscheidungen auf Grundlage
bekannter Fakten getroffen werden."
5. Product Owner
• Primärer Kontakt zum Kunden
• konzipiert und vermittelt Produktstrategie und Vision
• vertritt Stakeholder / Auftraggeber
• betrachtet Wirtschaftlichkeit
• verwaltet und priorisiert die Produkt Anforderungen (Product Backlog)
• sollte immer greifbar sein
• hat keinen Einfluss auf Sprints oder Daily Scrums. Wohnt diesen lediglich
bei
• ist kein Teil des Entwickler Teams
6. Scrum Master
• gleiches Level wie Entwickler Team / kein Vorgesetzter
• Schnittstelle zur "Außenwelt" / Product Owner
• kontrolliert Scrum Regeln und Prozesse
• verantwortlich für korrekte Umsetzung von Scrum
• beseitigt anfallende Hindernisse
• moderiert die Scrum-Meetings
• hat die Verantwortung über die Scrum-Dokumente (Product Backlog, Sprint
Backlog, Burndown Charts)
• schützt das Team vor Einflüssen während des Sprints
• ist kein Teil des Entwickler Teams
7. Entwickler Team
• zwischen 5 bis 9 Entwickler (in der Realität auch weniger)
• bei mehr Entwicklern erfolgt Aufteilung auf mehrere Teams
• verschiedene Rollen (Entwickler, Architekt, Tester, Redakteure, etc.)
• organisiert sich selbst
• Entwicklung findet i.d.R in einem "war room" statt
• gleichgestellt zu Product Owner und Scrum Master
• entwickelt das Produkt in den Sprints
• jedes Team Mitglied kennt das "große Ganze"
• aktualisiert täglich das Sprint Backlog
13. Das Product Backlog
• wird vom Product Owner verwaltet
• enthält alle Anforderungen
• Beschreibung in "User Stories"
• Reihenfolge = Priorität
• enthält Schätzung in Form von "Story Points"
• wird stetig aktualisiert (Priorität, Anzahl, Schätzung, etc.)
• Änderungen während des Projektes sind erwünscht
16. Requirement
Engineering
• im Scum FW nicht weiter detailliert
• verweis auf bestehende Normen (CMMI,
ISO, Cohn)
• erfolgt über "natürliche Sprache" oder
Modellierung (z.b. UML)
• Ziel: gemeinsames Verständnis schaffen
17. Schätzung
• geschätzt wird in Story Points "gefühlte Größen"
• Relative Kennzahl / Vergleichsgrösse zwischen den Backlog
Items
• Umrechnung in absolute Zahlen erfolgt nach Sprints
• Werkzeuge bei Schätzung:
• Planning Poker,
• fibonacci Sequenz 0,1,2...55,89
• Pert/Dreipunkt-Schätzung
19. Sprint Planning
Meeting 1 und 2
• Kickoff
• wird in zwei Meetings aufgeteilt, möglichst an einem Tag
• Dauer: je 1 h pro Meeting pro Sprint Woche
• Teil 1
• Bestimmung des "was"
• Anwesend: Gesamtes Scrum Team
• Besprechung der Product Backlog Issues mit höchster Priorität
• Definition des Sprint Goals. Vorschlag des Product Owners. Commit durch Teams
• Verplichtende Bestimmung des Lieferumfangs anhand der Anfordeungen
• Entwickler Team entscheidet was in Sprint realistisch ist
20. Sprint Planning
Meeting 1 und 2
• Teil 2
• Bestimmung des "wie"
• Anwesend: Gesamtes Scrum Team. optional : Product Owner (aber
passiv). Weitere beratende Personen
• Entwickler Team arbeitet selbstorganisiert
• Breakdown der Anforderungen in Tasks für Sprint Backlog
• Dauer der Tasks <= 1 Tag. Ansonsten weiteres Breakdown
• Ggf. Nachverhandlung über Arbeitsumfang des Sprints
• Werkzeuge: Scrum Taskboard (Kanban Ansicht). Hängt im war room
22. Vorteile Scrum Board
• alle Tasks auf einen Blick (ähnlich Kanban)
• trotzdem Fokus aufs wesentliche
• I.d.r In Form eines physikalischen Tafel, nicht online.
Somit
• effizienter,
• leichter pflegbar,
• immer im Blick
23. Sprint Backlog
• beinhaltet priorisierte Sprint Tasks
• steht in Beziehung zu Items aus dem Product
Backlog (i.d.r. 1 Item = n Tasks)
• Status wird durch Team täglich aktualisiert
• Scrum Master kontrolliert Status und sorgt für
Einhaltung des Sprint Goals
24. Im Sprint
• definierter Timeslot. I.d.r 4 Wochen oder weniger
• umsetzung aller Sprint Backlog Tasks
• Team arbeitet selbstständig und unterstützt sich gegenseitig
• keine Änderungen/Einflüsse während des Sprint erlaubt
• bestmögliche Abarbeitung aller Tasks während des Sprints
• Zum Start: Sprint Planning Meeting
• während des Sprints: Daily Scrums
• zum Ende: Sprint Review Meeting
• Scrum Master: kümmert sich um Hindernisse
• Das Team organisiert sich selbst
25. Hindernisse - der
Impediments Backlog
• alle Hindernisse (Blocker) werden in eine
Liste aufgenommen
• Liste wird bei Daily Scrum besprochen
• enthält Priorisierung, Datum, Beschreibung
• Scrum Master muss diese Hindernisse
zügig beseitigen
26. Daily Scrum
• 15 minütiges Stand-Up Meeting
• startet pünktlich (wie alle Scrum Meetings)
• erfolgt täglich immer am selben Ort
• Product Owner und Scrum Master nehmen als passive Zuhörer Teil
• abgleich der Aktivitäten seit und bis zum nächste Daily Scrum
• Hindernisse identifizieren und beseitigen. Protokollierung im "Impedment Backlog"
• Was wurde seit dem letzten Meeting erreicht?
• Was wird vor dem nächsten Meeting erledigt?
• Welche Hindernisse („Impediments“) sind dabei im Weg?
• Ggf. Folge-Gespräche unter den Entwicklern
28. Ende Teil 1,
Ausblick Teil 2
• Sprint Ende, Review und Retrospektive
• Der Abschluss
• Fortschrittskontrolle / Reporting
• Releasemanagement
• Scrum implementieren
