Was ist Scrum?
Scrum ist ein Vorgehensmodell aus dem Bereich der agilen Softwareentwicklung, dass aus der Produktentwicklung heraus entstanden ist und maßgeblich von Jeff Sutherland und Ken Schwaber ausgebaut wurden ist.
Das Modell Scrum definiert im wesentlichen Rollen und Hilfsmittel um die Entwicklung eines (Software-) Produkts erfolgreich durchzuführen. Eine Grundannahme ist dabei, dass die komplexen Prozesse weder in grob abgeschlossene Phasen zerlegt noch als fein granulare Aufgaben in Stunden abgeschätzt werden können.
Begrifflichkeiten und Prinzipien:
Product Owner
Gruppe oder Person die den Kunden repräsentiert. Als Kunde definiert und priorisiert die Funktionen und legt die Abgabezeitpunkte der einzelnen Releases fest. Ebenso ist er dafür verantwortlich Ergebnisse abzunehmen oder abzulehnen.
Scrum Master
Person die das Team führt und Störungen von außen während der Sprint-Phasen (dazu später) blockt und weitere Aufgaben des Managements übernimmt.
Team
Das Team setzt die erarbeiteten Aufgaben (Stories aus dem Sprint-Backlog) um, stellt Ergebnisse vor und trägt maßgeblich dazu bei den Prozess zu verbessern (Retrospective).
Product-Backlog
Beinhaltet alle priorisierten Anforderungen die der Kunde an das Produkt hat.
Sprint-Backlog
Teilmenge an Anforderungen/Funktionen aus dem Product-Backlog die in einem Sprint umgesetzt werden.
Sprint
Als Sprint bezeichnet man die Phase (ca. 30 Tage) im Projekt in der die Stories aus dem Sprint-Backlog umgesetzt werden und (das ist entscheidend) keine Einflussnahme von außen mehr erfolgt. Die typischen Änderungen in letzter Minute bleiben hier aus. Anpassungen können aber nachträglich in das Product-Backlog aufgenommen, priorisiert und einen nächsten Sprint mit eingesteuert werden.
Story
Eine Story ist ein Eintrag aus dem Sprint-Backlog. Im Allgemeinen werden diese Stories auf Papier ausgedruckt und an ein Whiteboard geheftet. Start- und Restaufwand sowie zu erledigende Aufgaben die zum Abschluss dieser Aufgabe gehören werden (neben der Beschreibung) darauf vermerkt. Erst wenn diese Aufgaben der Story (z.B. Technische Doku, Test) erledigt sind ist die Story wirklich abgeschlossen. Um dieses Prinzip von einer final beendeten Aufgabe noch mehr in den Vordergrund zu rücken spricht man von "Done Done". Dies soll dem 90%-Syndrom entgegenwirken.
Sprint-Planning
Vor jeder Sprint-Phase müssen die nächsten Stories aus dem Product-Backlog ausgewählt werden. Das hängt von den Prioritäten im Product-Backlog ab aber auch von Rahmenbedingungen wie: Verfügbarkeit von Mitarbeitern und aktueller Produktzustand. Wichtig ist hierbei die Anforderungen des Product-Owner in zuzuordnende Aufgaben zu teilen. Aus der Praxis heraus kann ich sagen, dass diese Aufteilung nicht zwingend erforderlich ist. Wer über ein Team mit umfassendem Know-How hat muss die Aufteilung von UI, Business-Logic, etc. nicht unbedingt in unterschiedliche Hände legen.
In einem (meist zweiten) Sprint-Planning wird das Team dazu beitragen, die vereinbarten Stories für diesen Sprint zu bewerten.
Daily-Scrum
In einem täglichen, kurzen (15min) Meeting zwischen Scrum-Master und Team erläutert jeder was er seit dem letzten Meeting getan hat und bis zum nächsten geplant hat. Er berichtet auch wenn abhängige Aufgaben oder äußere Bedingungen sie oder ihn abhalten eine Aufgabe zu erledigen.
Sprint Review
Im Review werden die Ergebnisse des Teams dem Product-Owner vorgestellt. Dabei geht es nicht darum die schönsten Präsentationen zu zeigen, sondern vielmehr die umgesetzte Funktionalität vorzuführen. Die Resultate können genehmigt oder auch abgelehnt werden.
Retrospective
Das Reprospective-Meeting dient der kontinuierlichen Verbesserung des eigenen Scrum-Prozesses. Das Team stellt fest was gut oder nicht so gut gelaufen ist und versucht diese während des nächsten Sprints zu berücksichtigen (abhängig von Rahmenparametern).
Mehr dazu kann man in der Präsentation "zen of Scrum" von Jurgen Appelo lesen (s. letzten Blog-Eintrag)