Projekte mit Scrum steuern

Ein Scrum-Projekt gliedert sich in Iterationen, die als Sprints bezeichnet werden. Alle Sprints sind gleich lang - üblicherweise zwei bis vier Wochen. Motor des Scrum-Ablaufs ist das "Product Backlog", eine Liste von priorisierten Anforderungen. Für einen bevorstehenden Sprint wird unter den hoch priorisierten Anforderungen des Product Backlog eine Auswahl getroffen. Sie wird von einem interdisziplinären Team in Tasks, das heißt in elementare Entwicklungsaufgaben, zerlegt, die dann im Sprint abgearbeitet werden.

In jedem Sprint wird ein potenziell lieferfähiges Produktinkrement entwickelt. Innerhalb einer geplanten Anzahl von Sprints entsteht ein Produkt-Release. Nicht zuletzt durch die Selbstorganisation des Teams bei der Bearbeitung der Tasks hat der Prozess einen geringen Overhead. Basis für die Qualität der Arbeit eines Scrum-Teams ist unter anderem die "Definition of Done", eine vom Team erstellte Liste der Kriterien, nach denen Anforderungen als realisiert gelten.

Beim Blick auf die Verteilung der Arbeit in den verschiedenen Entwicklungsdisziplinen im Scrum-Ablauf stellt man fest: Die Unterschiede zum V-Modell XT sind in dieser Hinsicht geringer, als man erwarten könnte. In einem typischen Scrum-Projekt wird frühzeitiger in größerem Umfang entwickelt und getestet (zumindest legt Scrum dies nahe - das V-Modell XT hätte allerdings auch nichts dagegen). Naturgemäß fließt auch bei Scrum zu Beginn eines Projekts ein größerer Teil der Arbeit in das Verstehen der Anforderungen. Zum Projektende hin wird immer weniger an den Grundfesten der Architektur geändert.

Lesen Sie auf der nächsten Seite, wo sich die Steuerungsebenen der beiden Vorgehensweisen integrieren lassen.