Scrum – IT-Berufe-Podcast #162

Um Scrum, eines der bekanntesten agilen Vorgehensmodelle, geht es
in der einhundertzweiundsechzigsten Episode des
IT-Berufe-Podcasts.
Inhalt

Scrum ist einer der bekanntesten und praxiserprobten agilen
Entwicklungsprozesse. Die Bezeichnung „Scrum“ (deutsch: Gedränge)
kommt aus dem Rugby und bezeichnet das Aufeinandertreffen
verschiedener Spieler „auf einem Haufen“.


Entwickelt wurde Scrum von Ken Schwaber und Jeff Sutherland für
die Softwareentwicklung, aber Scrum wird heute in allen möglichen
Bereichen eingesetzt.


Scrum ist lediglich ein Framework und definiert z.B. keine
konkreten Methoden für die Softwareentwicklung, wie es z.B. bei
Extreme Programming der Fall ist (dort gibt es z.B. TDD,
Refactoring, 40-Hour-Workweek etc.). Stattdessen verlässt sich
Scrum auf selbstorganisierende Teams.


Scrum ist ein agiler, iterativer und
inkrementeller Prozess, was bedeutet, dass er sich an
die Gegebenheiten in konkreten Projekten anpassen lässt, in
mehreren gleich ablaufenden Iterationen zum Ziel gelangt und
dieses mit wachsendem Funktionsumfang erstellt wird.
Grundsätzlicher Ablauf von Scrum

Zunächst werden alle bekannten Anforderungen erfasst und
geschätzt.

Dann werden die Anforderungen für die nächste Iteration
identifiziert (z.B. wichtigste, kritischste, einfachste) und
geplant.

Die Iteration ist time boxed. Sie wird nicht
unterbrochen und auch nicht verlängert. Die Iteration heißt auch
Sprint. Er ist üblicherweise 30 Tage lang.

Am Ende der Iteration steht dem Kunden ein „fertiges“ Produkt
zur Verfügung, das er sich anschauen und zu dem er Feedback geben
kann.

Der Fortschritt der Arbeit wird täglich in einem kurzen
Meeting im gesamten Team besprochen.

Die wichtigste Zahl bei Scrum ist die Drei: Es gibt jeweils
drei Rollen, Artefakte und Meetings.

Rollen

Bei Scrum gibt es drei verschiedene Rollen: Team, Product Owner
und Scrum Master.


Das Team führt die Arbeit aus und entscheidet
wie viele Anforderungen es in einem Sprint umsetzen kann. Seine
Arbeitsweise ist völlig frei durch das Team selbst bestimmbar, es
gibt keine Vorgaben („selbstorganisierendes Team“).


Der Product Owner repräsentiert die
Kundenbedürfnisse. Ihm „gehört“ das Produkt und er trifft die
nötigen Entscheidungen (in Abstimmung mit dem Kunden). Er
entscheidet, welche Anforderungen für eine Version umgesetzt
werden und wann die Software ausgeliefert wird. Er arbeitet eng
mit dem Team zusammen und ist weit mehr als ein einfacher
Produktmanager oder Projektleiter, hat aber keine
Weisungsfunktion.


Der Scrum Master hilft allen Beteiligten, Scrum
korrekt anzuwenden und unterstützt das Team, indem er z.B.
„Impediments“ (Hindernisse) beseitigt. Der Scrum Master ist kein
Projektleiter, sondern sollte eher als „Consultant“ oder „Coach“
verstanden werden, der penibel prüft, ob die Regeln von Scrum
eingehalten werden. Er hat daher auch keine Weisungsbefugnis.
Artefakte

Im Rahmen von Scrum werden drei verschiedene Artefakte erzeugt
und bearbeitet: Das Product Backlog, die Sprint Backlogs und das
(End-)Produkt. Die obige Darstellung zeigt die Zuordnung der
einzelnen Artefakte zu den Phasen von Scrum.


Das Product Backlog ist das zentrale Instrument
zum Erfassen und Managen von Anforderungen. Aus ihm werden die in
den einzelnen Sprints umzusetzenden Aufgaben oder Tasks
abgeleitet. Vereinfacht gesagt ist das Product Backlog eine
absteigend nach Priorität sortierte Liste aller bereits
geschätzten (!) Anforderungen an das Produkt.


Aus dem Poduct Backlog werden im Rahmen des Sprint Plannings die
wichtigsten Anforderungen herausgenommen und für den nächsten
Sprint in das Sprint Backlog übertragen. Dort
werden alle nötigen Aktivitäten zum Erreichen des Sprint-Ziels
aufgelistet und detailliert beschrieben. Das Team schwört sich
auf das Sprint Backlog ein und verpflichtet sich zur Umsetzung
der dort definierten Punkte („commitment“). Das Sprint Backlog
wird täglich aktualisiert.


Das Produkt(-inkrement) ist das wichtigste
Artefakt, da letztlich nur die erstellte Software dem Kunden
einen Mehrwert bietet und kein Product Backlog oder Sprint
Backlog. Um den Kundenanforderungen bestmöglich zu entsprechen
wird es in Iterationen entwickelt, um sich nicht von den
Vorstellungen des Kunden wegzuentwickeln. Das Produkt beinhaltet:
Das Programm, die Dokumentation und die nötigen Tests
(„definition of done“).
Meetings

Bei Scrum werden drei Meetings abgehalten: Das Sprint Planning,
der Daily Scrum und der Sprint Review. Die obige Darstellung
zeigt auch die Zuordnung der Meetings zu den Phasen von Scrum.


Beim Sprint Planning werden die im nächsten
Sprint umzusetzenden Anforderungen vom Team realistisch geschätzt
(z.B. muss die verfügbare Entwicklungszeit realistisch definiert
werden, etwa mit 2 Tagen/Woche) und das Team legt sich
verbindlich auf das Ziel des Sprints fest. Die Aufgaben werden an
die Teammitglieder verteilt. Für die Schätzung kann z.B.
Planning Poker gespielt werden.


Das Daily Scrum ist ein „time-boxed
Standup-Meeting“, das max. 15 Minuten dauern sollte und am besten
direkt vor dem Sprint Backlog durchgeführt wird. Ziel ist, das
Sprint Backlog auf den neusten Stand zu bringen und drei Fragen
durch jedes einzelne Teammitglied beantworten zu lassen:
Was habe ich seit dem letzten Daily Scrum gemacht? Was werde
ich bis zum nächsten Daily Scrum tun? Was hat mich bei meiner
Arbeit behindert? (das sind die Impediments, die der Scrum Master
beheben muss)

Beim Sprint Review am Ende eines Sprints wird
das Produkt dem Kunden vorgeführt, damit dieser Feedback geben
kann. Im besten Fall wird immer eine lauffähige Software
präsentiert und keine theoretischen Überlegungen oder
UML-Diagramme. Auf Basis des Kundenfeedbacks können im nächsten
Sprint dann gezielt die Probleme behoben oder die nächstwichtigen
Anforderungen umgesetzt werden.
Sonstiges

Optional wird von Zeit zu Zeit eine Sprint
Retrospective am Ende eines Sprints durchgeführt, um
sicherzustellen, dass die Arbeit im Projekt regelmäßig verbessert
wird. Der Scrum-Prozess soll ständig optimiert werden und somit
ein noch besseres Ergebnis geliefert werden.


Die Velocity des Teams sagt aus, wie schnell
dieses Aufgaben abarbeiten kann. Sie pendelt sich im Laufe des
Projekts auf einen stabilen Wert ein, da zu Beginn des Projekts
die Schätzungen häufig ungenauer sind, weil z.B. die Domäne nicht
bekannt ist, Technologien evaluiert werden müssen usw.


Auf dem Burndown Chart kann zu jedem Zeitpunkt
der aktuelle Fortschritt des Projekts abgelesen werden. Hier
werden im Daily Scrum die Schätzungen der aktuellen Aufgaben
aktualisiert, wobei sich diese nach unten (erfolgreich
bearbeitet) oder oben (Probleme aufgetreten) entwickeln können.
Es geht nicht darum, die aufgewendete (vergangene) Arbeitszeit zu
protokollieren, sondern darum, die Schätzung der zukünftigen
Aufwände an die aktuellen Erkenntnisse anzupassen.
Literaturempfehlungen

In diesem Video erklärt Ken Schaber, einer der „Erfinder“ von
Scrum, den Prozess: Scrum et al..


Ein gutes deutsches Buch, das Scrum im Detail erklärt, ist Scrum:
Agiles Projektmanagement erfolgreich einsetzen* von Roman
Pichler. Ich habe es damals selbst während meines Studiums
gelesen.


*
Links

Permalink zu dieser Podcast-Episode

RSS-Feed des Podcasts

Das agile Manifest

Scrum – Wikipedia

Das Minimum Viable Product (MVP) (Grafik mit Auto vs.
Skateboard/Roller)

Agile Ausbildung bei DATEV mit Uwe Ritthammer