Entwicklung

Agiles V-Modell - ein Widerspruch?

01.09.2011
Von Ingo Kriescher und Josef Markgraf

Agile Development kontra V-Modell: die Unterschiede

Beide Ansätze zur Entwicklung von Software haben das Ziel, Projekte erfolgreich und kostengünstig umzusetzen, sie folgen dabei jedoch mitunter komplett unterschiedlichen Vorgehensweisen und Grundsätzen. Das V-Modell XT ist ziel- und ergebnisorientiert, im Mittelpunkt stehen die Produkte. Damit gemeint sind alle zu erstellenden Artefakte, die durch das Tailoring zu Projektbeginn vorgegeben wurden. Als Ergebnis erhält das Projekt einen Handlungsrahmen, der eindeutig definiert, in welcher Reihenfolge die Produkte erzeugt und abgesichert werden.

Dementgegen zeichnet sich ein agiles Vorgehensmodell durch Werte und Prinzipien aus. Die Handlungen der Projektbeteiligten werden durch dieses Wertesystem angeleitet, seinen Leitsätzen folgen auch die konkreten Praktiken. Unter anderem folgende Eigenschaften bilden den methodischen Kernansatz:

  • Iteratives und inkrementelles Vorgehen innerhalb fester "Time Boxes".

  • Steuerung durch den Kundennutzen: Die Umsetzung der fachlichen Anwendungsfälle steht im Vordergrund und stellt den Projektfortschritt dar.

  • Risikoorientierung: Das Vorgehen orientiert sich stets an den schwerwiegendsten Risiken und versucht diese frühzeitig zu beheben.

  • Ständiges Feedback der Kunden und Anwender ist die Basis einer erfolgreichen Benutzung der Lösung.

  • Adaptive (rolling-wave) Planung hält das Projekt auf Kurs.

Damit werden die weitreichenden Unterschiede der beiden Vorgehensweisen deutlich, vergleichbar etwa mit dem Paradigmenwechsel beim Übergang von der prozeduralen Programmierung zur Objektorientierung. Für konkrete Budget- beziehungsweise Projektplanungen ist es zudem wichtig, diese Unterschiede an Projektthemen zu spiegeln:

Weniger Risiko und Kosten

Um eine wirtschaftliche Entwicklung zu gewährleisten, versucht das V-Modell XT, das Problem der hohen Fehlerkosten zu lösen, indem durch Redundanz und Dokumentation Fehler vermieden werden. Hierzu werden Dokumente erzeugt und abgesichert, bevor die eigentliche Lösung entsteht.

Im Fall des agilen Vorgehens werden die Fehlerkosten reduziert, indem sowohl Risiken frühzeitig verringert und im Softwaresystem abgesichert werden als auch das System so erstellt wird, dass sich Fehler kostengünstig und frühzeitig beheben lassen. Qualität ist ein Designkriterium. Die ständige Steuerung der fachlichen und technischen Qualität durch frühzeitiges kontinuierliches Prüfen, Testen und Integrieren gewährleistet den Projekterfolg. Die Kernarchitektur des Systems wird schrittweise innerhalb des Regelkreises (Iteration/Feedback) erstellt, zu einem frühen Zeitpunkt geprüft, kontinuierlich getestet und reift im Kern mit der Zeit.