Scrum Überblick Teil 1

Scrum OverviewTeil 1

Christof Zahn

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

Was ist ScrumScrum 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."

Rollen

• Product Owner

• Scrum Master

• Entwickler Team

bilden zusammen das Scrum Team

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

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

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

Weitere Rollen

• Benutzer

• Käufer

• Höheres Management

sind in Review Meetings involviert

Scrum Prozesse und Artefakte

• Vorplanung

• Product Backlog

• Sprint Backlog

• Sprint

Der Scrum Prozess

Quelle : http://www.scrum-kompakt.de/files/2010/03/abb10_scrum_prozess.jpg

Der Scrum Prozess

Quelle : https://www.3m5.de/scrum/

Vorplanung

• Teammitglieder definieren

• Werkzeuge definieren

• Konventionen definieren

• erstes Product Backlog erstellen (Sammlung der Anforderungen)

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

User Stories

"Als <Person> möchte ich

<Funktion> um

<Nutzen> zu haben"

Wer?

Was?

Wozu?

User Stories

"Als Informatiker möchte ich

arbeiten um

Spass zu haben"

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

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

Der Sprint

Quelle : https://www.3m5.de/scrum/

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

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

Scrum Taskboard

Quelle: http://www.mountaingoatsoftware.com/scrum/task-boards

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

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

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

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

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

Vorteile Daily Scrum

• verbessert Kommunikation

• effizientes Update

• fokussiert schnelle Entscheidungsprozesse

• verbessert Projektwissen aller Beteiligten

Ende Teil 1, Ausblick Teil 2

• Sprint Ende, Review und Retrospektive

• Der Abschluss

• Fortschrittskontrolle / Reporting

• Releasemanagement

• Scrum implementieren

Quellen

• http://de.wikipedia.org/wiki/Scrum

• http://scrum-master.de/

• offical scrum rulebook, http://www.scrum.org/

• http://www.scrum-kompakt.de/