2
28.06.2012
Rolf Prünte

Software-Entwicklung mit und nach SCRUM, Teil 2: SCRUM kurz und knapp

Dieser Blog-Eintrag ist eine Fortsetzung des ersten Teils über SCRUM.

Die Umsetzung der Prinzipien Transparenz, Überprüfung und Anpassung wird in SCRUM durch folgende Elemente abgebildet:

Rollen:

  • Der Product Owner gibt die fachliche und strategische Ausrichtung des Produkts vor.
  • Das Entwicklungs-Team setzt die Vorgaben des Product Owners um.
  • Der SCRUM-Master ist für das Gelingen des SCRUM-Prozesses verantwortlich. Er arbeitet mit dem Product Owner und dem Entwicklungsteam zusammen, gehört aber nicht dazu. Er beseitigt Probleme, die den Fortschritt des Projekts verhindern und achtet darauf, dass alle Projektteilnehmer nach den Regeln spielen.

Artefakte:

  • Im Product Backlog hält der Product Owner in Form von User Stories, also Beschreibungen aus Benutzersicht, Anforderungen an sein Produkt fest.
  • Im Sprint Backlog ist, für jedes Team-Mitglied ersichtlich, der aktuelle Projektstatus festgehalten. Das Sprint Backlog beinhaltet unter anderem abgeschlossene und offene Aufgaben sowie den Fortschritt in Form eines Burndown-Charts.
  • In der Impediment-Liste werden Probleme festgehalten, die das Team bei der Arbeit behindern. Es ist Aufgabe des SCRUM-Masters diese Probleme zu beseitigen.

Der Ablauf von SCRUM ist durch seine Zeremonien definiert:

  • Ein Sprint beschreibt einen festen Zeitraum von mindestens zwei, maximal vier Wochen, in denen ein Produkt entwickelt wird. Ziel eines Sprints ist immer ein „potentially shippable Product“, also ein Produkt, das soweit gereift ist, dass es theoretisch mit der neuen Funktionalität an Kunden herausgegeben werden kann und einen Mehrwert bietet.
  • Im Sprint Planning wird durch den Product Owner und das Entwicklungs-Team zunächst festgelegt, welche User-Stories im kommenden Sprint umgesetzt werden. Der Product Owner stellt die von ihm hoch priorisierten Stories vor. Dabei schätzt das Team die Größe der User-Stories und wie viel in einem Sprint umgesetzt werden kann. Im zweiten Teil des Meetings, das nun ohne den Product Owner stattfindet, legt das Team anschließend fest, wie die gewählten Stories umzusetzen sind. Die einzelnen Stories werden in Tasks aufgebrochen und im Sprint umgesetzt.
  • Das Daily Scrum findet jeden Morgen während des gesamten Sprints statt und dauert nicht länger als 15 Minuten. Während des Daily Scrums erklärt jedes Mitglied des Entwicklungs-Teams, was es am Vortag getan hat, was es plant am aktuellen Tag zu tun und ob es Hindernisse bei der täglichen Arbeit gibt, die vom Scrum-Master beseitigt werden müssen. Das Sprint Backlog und die Impediment-Liste werden entsprechend aktualisiert.
  • Das Sprint Review findet am Ende eines Sprints statt. Das Entwicklungs-Team präsentiert dem Product Owner, ggf. auch einem Benutzer oder Auftraggeber, die Ergebnisse des vergangenen Sprints. Der Product Owner bewertet und beurteilt die Ergebnisse. Es wird überprüft, ob die im Sprint Planning gesteckten Ziele im Sprint erreicht worden sind. Bei der Bewertung werden keine Kompromisse eingegangen. Eine User-Story aus dem Product Backlog gilt erst dann als abgeschlossen, wenn sie die „Definition Of Done“, einer vor Umsetzung festgelegten Menge von Anforderungen, entspricht. Sollten User-Stories nicht vollständig abgeschlossen sein oder Änderungsbedarf bestehen, so kann der Product Owner sie zurück ins Product Backlog aufnehmen und neu bewerten.
  • Im Sprint Retrospective, welches zwischen Sprint Review und Sprint Planning stattfindet, reflektiert das Team gute und schlechte Erfahrungen, die während des letzten Sprints gemacht worden sind. Das Sprint Retrospective soll dem Entwicklungs-Team die Möglichkeit geben, aus diesen Erfahrungen zu lernen.

Alle Zeremonien in SCRUM sind „time-boxed“, das bedeutet, dass sie für einen fest angegebenen Zeitrahmen angesetzt sind, der nicht überschritten werden darf. Es ist Aufgabe des Scrum-Masters auf die Einhaltung des Time-Boxing zu achten. Dadurch sollen endlose Diskussionen und Verstrickungen in Details vermieden werden.

Lesen Sie im folgenden dritten Teil, wie SCRUM bei Ferber-Software zum Einsatz kommt und was wir bisher für Erfahrungen damit gemacht haben.