Scrum – IT-Berufe-Podcast #162

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

Probeabo bei Audible (Affiliate)

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.

Ablauf von Scrum inkl. Artefakten 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:

  1. Was habe ich seit dem letzten Daily Scrum gemacht?
  2. Was werde ich bis zum nächsten Daily Scrum tun?
  3. 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.

Scrum: Agiles Projektmanagement erfolgreich einsetzen (Affiliate)*

Links

Portrait von Stefan Macke
Polyglot Clean Code Developer
Über den Autor
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax