Home > Entwicklung, Projektmanagement > Scrum (3) – der Entwicklungsprozess

Scrum (3) – der Entwicklungsprozess

Der Entwicklungsprozess in Scrum ist iterativ und läuft in sogenannten Sprints ab. Meist konzentriert man sich zunächst auf die Umsetzung eines Basisprodukts, das (nach jeweils aktuellem Kenntnisstand) die erfolgversprechendsten Features enthält und schnell auf dem Markt platziert werden kann.

Priorisierung

Grundlage der Produktentwicklung bei Scrum ist das sogenannte Backlog. Es handelt sich dabei um eine Liste (häufig Excel) in der alle Anforderungen gesammelt und vom Product Owner priorisiert werden.

Je höher die Priorität einer Anforderung, desto früher wird sie verfeinert und umgesetzt.

Im Gegensatz zu Wasserfall-Projekten wird durch diese Vorgehensweise Overhead vermieden. Denn in Wasserfall-Projekten wird häufig über einen langen Zeitraum geplant und sehr detailliert spezifiziert, um dann in der Entwicklungsphase die Spezifikation “nur” noch abzuarbeiten.

Bestimmte Anforderungen des Marktes oder auch Probleme tauchen aber häufig erst während der Entwicklung auf. Und dann wird es oft schwer bzw. teuer das vorhandene Konzept noch einmal anzupassen.

Styleguides und Architekturkonzepte

Bei einem Scrum-Projekt sollte man schon auch darauf achten, bekannte Anforderungen festzuhalten und zu beschreiben. Doch geht man hier eben nicht gleich ins Detail, sondern macht das soweit wie nötig, um zukunftssichere Software bzw. Produkte entwickeln zu können.

Informationen über mögliche weitere Anforderungen können bspw. in einem Architekturkonzept oder auch einem Design Styleguide münden, auf dem das Team aufbauen kann.

Sprints

Die Entwicklung in Scrum besteht aus sogenannten Sprints. Sprints sind typischerweise 1-4 Wochen lang. Traditionelle Tätigkeiten wie die Beschreibung von Anforderungen, Design, Programmierung, Integration und Test finden in jedem Sprint statt und nicht verteilt auf mehrere Monate.

Ablauf der Scrum-Entwicklung (Quelle: Wikipedia)

Ein Sprint besteht aus einer Sprint-Planungssitzung, in der ein sogenanntes “Sprint Backlog” erstellt wird, das die umzusetzenden Anforderungen und Tätigkeiten für den Sprint festlegt. Hinzu kommen tägliche Kurzmeetings (“Daily Scrum”), die eigentliche Arbeit :-) und schließlich ein Sprint Review und eine Sprint Retrospektive. Als Ergebnis jedes Sprints gibt es ein auslieferbares Produktinkrement.

Product Backlog

Das Product Backlog enthält alle Anforderungen, die im Laufe des Projektes umgesetzt werden sollen. Jede Anforderung muss vom Product Owner priorisiert werden. Somit ist für alle Projektbeteiligten klar, welche Anforderungen zum jeweiligen Zeitpunkt Vorfahrt genießen. Die Priorisierung kann im Laufe des Projektes geändert werden.

Sprint Backlog

Der Sprint Backlog wird in der Sprint-Planungssitzung zusammengestellt und stellt die Anforderungen und Aufgaben dar, die im jeweiligen Sprint umgesetzt werden sollen.

Sprint-Planungssitzung

Product Owner, ScrumMaster und Team nehmen an der Sprint-Planungssitzung teil. In dieser Sitzung werden die Ziele für den Sprint festgelegt und das Sprint Backlog erstellt.

Der Product Owner wählt im Vorfeld (ggf. zusammen mit dem ScrumMaster) die Anforderungen aus, die aus seiner Sicht im Sprint umgesetzt werden sollten. Die einzelnen Anforderungen und Aufgaben werden von den Teammitgliedern zeitlich abgeschätzt und für den Sprint aktzeptiert oder abgelehnt.

Um die Planungssitzung effizient zu gestalten, muss diese von Product Owner und ScrumMaster gut vorbereitet sein. Die Vorbereitung des folgenden Sprints sollte bereits zur Hälfte des laufenden Sprints beginnen.

Daily Scrum

Damit sich das Team täglich abstimmen kann, gibt es das Daily Scrum Meeting. Das Meeting dauert 15 Minuten, nicht länger (“Everything is in a timebox” lautet eine der Grundregeln von Scrum).
Jedes Teammitglied sollte kurz und knapp folgende Fragen beantworten:

  • Welche Aktivitäten habe ich seit dem letzten Daily Scrum abgeschlossen?
  • Woran arbeite ich gerade bzw. was werde ich bis zum nächsten Daily Scrum voraussichtlich beginnen?
  • Gibt es irgendwo Probleme oder Hindernisse? (z. B. “ich wurde abgezogen, um an einem anderen Projekt zu arbeiten, dadurch kann ich meine Zusagen nicht einhalten”)

Sprint Review

Das Sprint Review findet am Ende eines Sprints statt. In dieser Besprechung werden die Arbeitsergebnisse besprochen. Es nehmen Product Owner, Team und ScrumMaster teil. Der Product Owner überprüft, ob das Team alle zugesagten Anforderungen erfolgreich(!) umgesetzt hat.

Sprint Retrospektive

Die Sprint Retrospektive findet im Anschluss an das Sprint Review statt. Hier wird besprochen, was im vergangen Sprint gut und was schlecht lief. Auf dieser Basis werden Verbesserungsmaßnahmen für die zukünftige Entwicklung festgelegt.

blog comments powered by Disqus
  1. Bisher keine Kommentare
  1. Bisher keine Trackbacks
Du musst Dich anmelden um einen Kommentar zu schreiben

Switch to our mobile site