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
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.