Agile vs V-Modell: Wo Anforderungen jeweils leben

Das häufigste Missverständnis im Anforderungsmanagement ist, dass Agile „keine Anforderungen“ bedeute. Das tut es nicht. Es bedeutet, dass Anforderungen an einem anderen Ort leben und nach einem anderen Zeitplan entdeckt werden.

Das V-Modell legt sie vorab fest, geschrieben vor dem Bau. Agile verteilt sie als fortlaufendes Gespräch über das Projekt. Keines ist „richtiger“ — sie sind Antworten auf unterschiedliche Randbedingungen, und die meisten echten Projekte verbinden beide.

Das V-Modell: Anforderungen im Voraus

Das V-Modell ist nach seiner Form benannt: Links steigt man von den übergeordneten Anforderungen über den Entwurf zum Code hinab; rechts steigt man über das Testen wieder zur Abnahme hinauf. Jede Anforderung links hat eine passende Verifikation rechts, und das Ganze ist nachverfolgbar.

Anforderungen werden geschrieben, geprüft und vor Baubeginn eingefroren — das Lastenheft. Das ist das Modell der Wahl, wenn die Kosten eines Fehlers hoch und die Anforderungen erkennbar sind: regulierte Systeme, sicherheitskritische Hardware, Festpreisverträge.

Agile: Anforderungen als fortlaufendes Gespräch

Agile nimmt an, dass Anforderungen nicht vollständig im Voraus erkennbar sind, und tut deshalb nicht so, als würde es sie alle aufschreiben. Anforderungen leben im Backlog als User Stories, jede mit Abnahmekriterien, und werden gerade rechtzeitig für jeden Sprint verfeinert.

Die Spezifikation ist kein Dokument — sie ist die kontinuierlich gepflegte Menge von Stories und ihren Kriterien. Nachverfolgbarkeit existiert weiterhin, läuft aber von Story zu Code zu Test innerhalb jedes Inkrements statt durch ein monolithisches Dokument.

Wann welches gewinnt

• V-Modell: regulierte oder sicherheitskritische Arbeit, Hardware, die sich nicht billig neu ausliefern lässt, Festpreisverträge oder alles, wo „später entdecken“ inakzeptabel ist.
• Agile: sich entwickelnde Produkte, unsichere oder wechselnde Anforderungen, Software, die ausgeliefert und iteriert werden kann, oder ein Markt, der Geschwindigkeit über Vollständigkeit belohnt.

Die falsche Alternative

Die praktische Antwort für die meisten Systeme ist eine Mischung, und sie folgt meist der Stabilität des Artefakts. Was stabil ist — Architektur, Schnittstellen, Sicherheitsanforderungen — wird im Voraus spezifiziert, im Stil des V-Modells. Was sich ändert — Funktionen, Nutzerabläufe — wird als fortlaufendes Backlog behandelt, im Stil von Agile.

Ein Gerät, das zertifiziert und integriert werden muss, nutzt eine Vorab-Spezifikation für seine Schnittstellenverträge und Sicherheitsanforderungen, während die Anwendung darum herum in Sprints wächst. Die beiden stehen nicht im Konflikt; sie arbeiten auf verschiedenen Ebenen desselben Systems.

Der Teil, der sich nie ändert

Unabhängig vom Modell sind drei Dinge nicht verhandelbar: Anforderungen müssen geschrieben und vereinbart sein, nachverfolgbar zu dem, was sie erfüllt, und nur über einen kontrollierten Prozess geändert werden. Das V-Modell erledigt das in einem Dokument; Agile in einem Backlog. Die Disziplin ist identisch.