Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil IV

Hier könnt ihr den ersten, den zweiten und den dritten Teil lesen!

Phase V: Die Weiterentwicklung

Für die Erstellung eines Lastenheftes und für das Lastenheft selbst ist diese fünfte Phase – die Weiterentwicklung – eine besondere. Denn der Release von 1.0 bedeutet, dass wir das Lastenheft mit bestem Wissen und Gewissen und auf dem aktuellen Stand der Technik und allem, was wir kennen, erstellt haben.

Release 2.0 – Neues einplanen

Gleichzeitig bedeutet es aber auch: Die Welt dreht sich weiter, wir werden neue Erkenntnisse bekommen, wir werden verstehen, dass und warum Dinge nicht funktionieren, wir werden neue Ideen haben. All das wird kommen. Das heißt, 1.0 ist niemals das eine unveränderliche Lastenheft, das beim Abschluss des Projektes zwangsläufig noch immer genauso vorliegen wird.

In der Regel gibt es eine Weiterentwicklung. Und auch diese kann ich über eine Release-Planung durchaus begleiten. Denn immer wieder kann etwas passieren, das nicht eingeplant war:

Ein Fertigungsstandort wurde plötzlich gewechselt, es ist eine neue Technologie hinzugekommen, die bislang überhaupt nicht geplant war, irgendetwas funktioniert auf einmal doch nicht und muss herausgenommen werden und so weiter.

Das heißt, ich kann in dieser fünften Phase tatsächlich hingehen und sagen: „Wie und auf welchen Wegen wandern wir jetzt zum Release 2.0“?

Mit dem bestehenden Lastenheft und der gesamten Dokumentation kann man sich also weiter zum Release 2.0 iterieren. Das ist eigentlich die Idee dahinter: In vielen kleinen Schritten, in vielen kleinen Schleifen weiterkommen – gegebenenfalls auch noch zu einem 3.0.

Selbst das ist nicht ganz unüblich, allerdings handelt es sich hierbei meist nur noch um Änderungswünsche: 2.0 ist inhaltlich meistens schon relativ stabil, während bei 3.0 eher Änderungen über das Änderungsmanagement abgewickelt werden.

Das agile Vorgehen bei der Erstellung eines Lastenheftes im Überblick

Das waren also die fünf Phasen der Erstellung eines Lastenheftes. Da wir hier relativ stark ins Detail gegangen sind und die Veröffentlichung des ersten Teils schon ein wenig zurückliegt, möchte ich hier kurz alle Phasen zusammenfassen:

1. Phase: Die Nutzen-Klärung

Beim System-Footprint-Workshop werden das System und die Anforderungen definiert und visualisiert. Die Release-Strategien helfen, alle Zusammenhänge zu begreifen, ein gemeinsames Verständnis für das Vorgehen zu entwickeln und eine Roadmap zu erstellen.

2. Phase: Datensammlung

Alle Informationen werden im System-Footprint-Template gesammelt, zusammengestellt und geprüft. So entdecken wir noch bestehende Lücken und füllen sie auf.

3. Phase: Erstellung des Lastenheftes

Hier geht es um die kontinuierliche Erstellung eines Lastenheftes mit einem Requirements-Management-Werkzeug. Release-Stände, zusätzliche Inhalte und Pflege der diversen Attribute fallen in diese Phase.

4. Phase: Reviews & Freigabe

Alle Teammitglieder erhalten alle Daten, Dokumentationen und Teile des Lastenheftes, um 1.0 fertigstellen zu können. Durch die Reviews sind die meisten Inhalte bereits bekannt, sodass es nicht mehr um wirkliche Fehler geht, sondern um zu behebende Auffälligkeiten.

5. Phase: Die Weiterentwicklung

Das Lastenheft kann und wird ständig an die aktuellen Entwicklungen angepasst, 2.0- oder gar 3.0-Releases können die Folge sein.