Der größte Vorteil agiler Prozesse ist m.E., daß die Beteiligten
regelmäßig und häufig miteinander reden (Review, Planning) und so
alle über die wesentlichen Eckpunkte Bescheid wissen (können). Das
trifft auf konventionelle Prozesse wie Wasserfall oder V-Modell nur
zu, solange das Team sehr klein ist und mehr oder weniger jeder alles
macht oder machen könnte. Sobald aber Architekten und Untergruppen
ins Spiel kommen, geht bei konventionellen Prozessen zu viel Wissen
verloren - aus Unaufmerksamkeit oder unbewußt. Wenn logische oder
architektonische Details bedeutsam werden können, dann müssen diese
allen Beteiligten bekannt sein - wozu die Meetings agiler Prozesse
führen.
Und durch das Herunterbrechen der Aufgaben auf sprintbare Teile ist
der jeweilige Kontext und die Abstraktion im Gesamtprojekt beachtbar
- in jedem Level der Hirarchie.
Im V-Modell hingegen können Schlüsse, die von unterschiedlichen
Rollenträgern gezogen wurden leicht auf deren jeweiliges Umfeld
beschränkt bleiben. Z.B. wenn Testentwickler Schwachstellen in den
Anforderungen finden, dann gehen diese nur über Change Requests in
die Anforderungsliste ein und kommen erst nach Freigabe bei den
SW-Entwicklern an. Im agilen Projekt würde das bei daily standups
oder spätestens beim Reviewmeeting ankommen und könnte zeitnah
berücksichtigt werden.
Wir fahren mit einem SCRUM-ähnlichen Modell sehr gut.