Scrum
Scrum ist eine prominenter Vertreter der Agilen Methoden. Entstanden in den frühen 1990er Jahren, wurde es erstmals bei der OOPSLA 1995 offiziell präsentiert. Maßgeblich zur Entstehung beigetragen haben Jeff Sutherland, Jeff McKenna, Ken Schwaber, Mike Smith, Chris Martin, Mike Beedle und Martine Devos. Eingesetzt und laufend verbessert wurde es allen voran bei den Unternehmen Individual, Inc., Fidelity Investments, und IDX (heute GE Medical) (vgl. [Schwaber & Sutherland, 2010]).
Scrum als iterativer, inkrementeller Ansatz dient der Berechenbarkeitsoptimierung sowie der Risikokontrolle, und basiert auf Theorie zur empirischen Prozesskontrolle, welche auf drei Säulen baut: Transparenz, Inspektion und Adaption. Das tatsächliche Scrum Framework besteht aus Scrum Teams und ihren Rollen, sowie Time-Boxes, Artifacts und Rules. Diese Rules sind integrativer Bestandteil der Beschreibung von Time-Boxes und Artifacts, in ihrem vollen Umfang sind sie daher am besten in [Schwaber & Sutherland, 2010] zu finden.
In einem Scrum Team gibt es drei Rollen:
- Der ScrumMaster ist für den Scrum Prozess und dessen konsequente Einhaltung durch das Team verantwortlich, insbesondere was die Rules angeht. Beim ScrumMaster handelt es sich um eine beliebige Person aus dem Team, jedoch nie um den Product Owner.
- Der Product Owner kümmert sich um die Maximierung des Nutzens der Arbeit, die das Team leistet und ist für das Endprodukt verantwortlich. Er kann Teil des Teams sein, muss dies aber nicht. Er ist nie zugleich ScrumMaster.
- Das Team, das die Arbeit in der Produktentwicklung leistet, besteht aus Entwicklern mit den nötigen Fähigkeiten. Es umfasst idealerweise sieben Personen, jedoch mindestens fünf und höchstens neun. Das Team ist organisiert sich selbst, niemand bestimmt wie genau es aus dem Product Backlog auslieferbare Versionen erstellt, auch nicht der ScrumMaster.
Das Scrum Team kommt in verschiedenen Time-Boxes zusammen, um den Fortschritt des Produktes zu besprechen, der in den Sprints realisiert wird (vgl. [Schwaber & Sutherland, 2010]). Bei diesen Time-Boxes handelt es sich im Wesentlichen um Meetings, also Besprechungen.
- Release Planning Meeting – Ziel: das Formulieren von Zielen für das Endprodukt und das Erstellen eines Planes. Ergebnis: Ziel des Release, die Product Backlog Elemente mit höchster Priorität, die größten Risiken, alle Features und Funktionalitäten des Release, wahrscheinliches Fertigstellungsdatum und Kosten wenn sich nichts ändert. Der Release Plan kann dann von Sprint zu Sprint überarbeitet werden.
- Sprint – das Herz von Scrum, bestehend aus dem dem Sprint Planning Meeting, der eigentlichen Softwareentwicklung, dem Sprint Review und dem Sprint Retrospective. Sprints stellen unmittelbar aufeinanderfolgende Iterationen dar, die immer gleich lang sind und jeweils maximal einen Monat dauern. Der ScrumMaster stellt sicher, dass es keine Veränderungen gibt die sich negativ auf das Sprint-Goal auswirken. Ergebnis eines Sprints sind potentiell auslieferbare, inkrementelle Funktionalitäten des Endproduktes.
- Sprint Planning Meeting – Ziel: das Planen eines Sprints. Vorgesehen sind maximal 8 Stunden für Sprints mit einer Dauer von einem Monat, das ganze Team einschließlich Product Owner nimmt teil. Das Meeting besteht aus zwei Teilen: in der ersten Hälfte („Was“) wird entschieden was in dem Sprint passieren soll. Input dazu sind Product Backlog, die letzte Version, Team-Kapazität und Team-Performance. Output ist ein Sprint-Goal, das die zu erstellende Funktionalität im Hinblick auf ihren Zweck beschreibt anstatt alleine auf der technischen Umsetzungsebene, und ein Teil des Release Goals ist. In der zweiten Hälfte des Meetings („Wie“) bestimmt das Team, wie es diese Funktionalität zu einer potentiell auslieferbaren Produkt-Version macht. Ergebnis ist der Sprint Backlog, eine Liste von möglichst atomaren Aufgaben mit einer Dauer von maximal je einem Tag, die das Product Backlog von Sprint zu Sprint in funktionierende Software verwandeln.
- Sprint Review – am Ende jedes Sprints besprechen Team und Stakeholder, wie der vergangene Sprint verlaufen ist und was die nächsten Schritte sind. Vorgesehen sind maximal 4 Stunden für Sprints mit einer Dauer von einem Monat.
- Sprint Retrospective – findet zwischen Sprint Review und dem nächsten Sprint Planning Meeting statt. Der ScrumMaster erarbeitet mit dem Team, wie der Software-Entwicklungsprozess im nächsten Sprint noch effektiver und zufriedenstellender laufen kann („Inspektion“). Hinterfragt werden die Bestandteile Personen, Beziehungen, Prozess und Werkzeuge. Die identifizierten Verbesserungsmöglichkeiten werden als Änderungen umgesetzt („Adaption“). Vorgesehen sind maximal 3 Stunden für Sprints mit einer Dauer von einem Monat.
- Daily Scrum – tägliche, 15minütige Besprechung des Teams, in der jedes Team-Mitglied in aller Kürze drei Punkte einbringt: was wurde seit dem letzten Meeting umgesetzt, was wird bis zum nächsten Meeting passieren, und welche Hürden gibt es dabei. Der ScrumMaster stellt sicher dass das Meeting stattfindet und das Team sich an die Regeln hält, allen voran: kurz und klar kommunizieren unter Einhaltung des zeitlichen Rahmens. Der Daily Scrum ist eine essentielle Inpektions- und Adaptions-Besprechung im empirischen Prozess von Scrum. Der ScrumMaster stellt sicher dass das Meeting stattfindet und das Team sich an die Regeln hält, allen voran: kurz und klar kommunizieren unter Einhaltung des zeitlichen Rahmens.
Scrum verwendet die vier folgenden Artifacts (vgl. [Schwaber & Sutherland, 2010]):
Man sieht also an dieser Kurzfassung von [Schwaber & Sutherland, 2010], des als „Scrum Body Of Knowledge“ anerkannten Dokumentes mit nur 21 Seiten, dass bei Scrum wesentlich weniger formale Aspekte und Dokumente im Spiel sind – die Praxis und eine tägliche Kurzabstimmung zwischen den Beteiligten steht im Vordergrund. Ob dieser Ansatz in jedem Fall durchsetzbar, durchführbar oder ratsam ist, wird in der Kritik an Agilen Methoden kritisch hinterfragt.
Letzte Änderung: 08.11.2010, 18:08 | 862 Worte