Scrum – IT-Berufe-Podcast #162

IT-Berufe-Podcast - En podcast af Stefan Macke - Mandage

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.

Visit the podcast's native language site