Agiles Vorgehen bei der Erstellung eines Lastenheftes – Teil II

Hier könnt ihr den ersten Teil lesen!

Phasen II & III: Datensammlung und Erstellung des Lastenheftes

In der zweiten Phase geht es darum, Informationen zu sammeln, zu sichten und alles bereitzustellen. Bei B. Braun haben wir das am zweiten Workshop-Tag gemacht, das kann sich aber auch über ein paar Tage oder eine Woche hinziehen.

Fakten, Fakten, Fakten

Diese Daten können alte Lastenheftdokumentationen sein, alte Spezifikationen, Marketingunterlagen, One-Pager, etc. All das sollte über einen FTP-Server bereitgestellt werden, sodass es mir immer vorliegt.

Darauf basierend setze ich die ganzen Informationen in das System-Footprint-Template (eine Art Word-Struktur). Dies tue ich auf Basis der Visualisierungen aus dem Workshop, sie stellen sozusagen die einzelnen Teilüberschriften dar und stellen die wesentlichen Aspekte heraus.

Vereinfacht gesagt übertrage ich das alles ins Lastenheft. Danach arbeite ich das Ganze auf, prüfe die Requirements, die Grammatik und so weiter. Dann folgt die Klärung der Lücken.

Diese werden typischerweise unterschätzt. Häufig höre ich von den Projektleitern bei den Workshops, dass das Lastenheft schon weitestgehend vollständig ist. Doch beim Footprint-Workshop folgt dann der große Aha-Effekt.

Genau das funktioniert in den Footprint-Workshops unglaublich gut: Was fehlt, was ist noch nicht besprochen, nicht visualisiert, nicht dokumentiert. Diese Lücken schließe ich dann durch das Triggern der inhaltlich zuständigen Leute.

In der Regel stecke ich nicht im Detail in dem technischen System, sodass ich die Zuarbeit der jeweiligen Spezialisten benötige. Sie können aber alles so zusammenschreiben, wie sie möchten und wie es für sie am einfachsten ist. Ich übernehmen den Feinschliff.

Das Lastenheft

Und damit kommen wir zur dritten Phase: Das tatsächliche, kontinuierliche Erstellen des Lastenheftes. Dafür nutze ich die Release-Stände und die Inhalte, die von der Entwicklung kommen, und kümmere mich um die Pflege der verschiedenen Attribute.

Wenn wir über Engineering-Requirements-Management reden, meine ich nicht nur die Requirement-Statements, also die Aussagen, sondern auch weitere Attribute für die klare Definition. Zudem kümmere ich mich um die Peer-Reviews.

Als Requirements-Management-Werkzeug nutze ich Polarion und fülle all das dort ein, inkl. Release-Stände. Das können auch Zwischen-Stände sein, also z.B. 0.3-3, diese schicke ich dann wieder zurück zum Projekt, damit die Leute vor Ort sich darum kümmern können, die Peer-Reviews durchzuführen.

Polarion – es gibt aber auch andere Tools – bietet die „Word-Round-Trip“-Funktion an, das heißt die andere Seite muss nicht zwingend ein ALM-Tool haben. Sie kann in Word korrigieren und sobald ich das wieder in Polarion integriere, kümmert das Tool sich selbstständig um das Einpflegen.

Die Erstellung eines Lastenheftes ist also der dritte Schritt, die dritte Phase. Das zieht sich im Grunde genommen so lange, bis 0.8 erreicht ist.