Projektvorgehen nach Scrum
Rollen bei Scrum
Die verschiedenen Rollen in Scrum und ihre Aufgaben:- Der Product Owner ist verantwortlich für das Produkt. Er trägt alle Anforderungen des Projektes zusammen und priorisiert sie so, dass sie in der Reihenfolge ihrer Wichtigkeit entwickelt werden. Er steht dem Team als ständiger Ansprechpartner zur Verfügung.
- Das Team ist verantwortlich für das Liefern produktionsreifer und getesteter Ergebnisse.
- Der Scrum Master ist verantwortlich für den Prozess. Er unterstützt das Team bei der Selbstorganisation und der Optimierung seiner Arbeit.
Projektablauf
Im ersten Schritt wird gemeinsam mit dem Product Owner ein Product Backlog erstellt, welches in verschiedenen Detailgraden das zu erreichende Ziel beschreibt. Inhaltlich wird dabei in der Sprache des Product Owners formuliert: z.B. „Ich möchte eine Website im Branding meines Unternehmens, mit dem ich meine Kunden besser informieren, und darüber hinaus in meine Produktentwicklung einbinden möchte. Dafür brauche ich eine Community mit Forum, News/Blog und eine Möglichkeit die Inhalte (Texte/Bilder) auf der Website zu strukturieren und leicht zu pflegen. Um mehr über meine Kunden zu erfahren, möchte ich, dass nur registrierte Benutzer Texte im Forum verfassen können.“Aus dieser sprachlichen Beschreibung werden Aufgaben im Backlog formuliert, die vom Umsetzungsteam verstanden werden: „Wir brauchen eine Portalsoftware mit Content Management und Modulen für Forum, Blog, News und Benutzerregistrierung. Auswahl der Software. Aufsetzen von Test und Entwicklungssystemen usw.“
Nachdem das erste grobe Bild im Product Backlog vermittelt wurde, wird im 1. Sprint Planning ermittelt, welche Teilaufgaben zuerst umgesetzt werden müssen und mit wie viel Aufwand diese verbunden sein werden. Diese Abschätzung wird – moderiert von der Person mit der Rolle des Scrum Masters – vom Umsetzungsteam vorgenommen. Die Abschätzung selber erfolgt nicht in Zeiteinheiten (z.B. Tagen), sondern in Relation der Aufgaben zueinander. Meist werden dafür abstrakte Einheiten wie z.B. Komplexitätspunkte verwendet. Der Hintergedanke dieses Vorgehens ist, dass viele Entwickler ein Problem mit der genauen Schätzung in Zeiteinheiten haben, aber meist ein sehr genaues Verständnis von der Komplexität einer Aufgabe. Mit Hilfe der Komplexitätspunkte kann genau erfasst werden, dass Aufgabe A dreimal so lange dauern wird wie Teilaufgabe B.
Schematischer Ablauf der agilen Entwicklung nach SCRUM.
Nachdem das Team sich darauf festgelegt hat, wie viele Teilaufgaben es bis zum Ende des nächsten Entwicklungszyklus (Sprint) abgearbeitet haben will, beginnt der Sprint.
Um Transparenz darüber zu schaffen, wie viele Teilaufgaben bereits bearbeitet wurden bzw. gerade in Arbeit sind, werden die Teilaufgaben plastisch mit Zetteln an eine Wand geheftet: „offen“, „in Arbeit“, „Erledigt“.
In täglichen, kurzen (max. 15 Minuten) Meetings, dem sogenannten Daily Scrum, beantworten alle Teammitglieder die Fragen, was sie erreicht haben, was sie behindert, und was sie vorhaben. Das schafft tägliche Transparenz über Erreichtes und über Verzögerungen.
Ziel ist es am Ende eines Sprints eine lauffähige Version des zu erstellenden Systems zu haben, welches zwar noch nicht alle Funktionen enthält, aber was fertig ist, funktioniert.
Am Ende eines Sprints wird in einem „Sprint Review“ ermittelt, ob alle gesteckten Ziele erreicht wurden, und wenn nein warum nicht. Im Anschluss werden vom Product Owner die Einträge des Product Backlog überarbeitet (neue hinzugefügt, existierende verändert etc.). Auf dieser Basis wird der nächste Sprint geplant. Dadurch nähert sich das Entwicklungsteam iterativ dem Ziel, welches sich durchaus im Laufe des Projektes ändern kann (was nach gängiger Erfahrung in der Anwendungsentwicklung häufig vorkommt).
In jedem Sprint werden die „klassischen“ Phasen des „Wasserfallmodells“ durchgeführt:
- Konzeption: Überarbeitung des Product Backlog
- Design: Sprint Planning
- Entwicklung, Test: Umsetzung im Sprint mit dem Ziel am Ende des Sprints über lauffähige Funktionalität zu verfügen
- Abnahme: Sprint Review mit dem Auftraggeber, dem Product Owner
