Agile vs. Wasserfall: Wie agile Vorgehensmodelle die Probleme der traditionellen Softwareentwicklungsprozesse lösen

In den letzten Jahren stellen zunehmend auch sehr konservativ aufgestellte Unternehmen ihre Softwareentwicklung von traditionellen Vorgehensmodellen auf agile Softwareentwicklung um. Die Motivation ist klar: Die Softwareentwicklung soll bei besserer Qualität schneller und kostengünstiger werden. Mit agilen Methoden können diese Ziele in der Praxis auch tatsächlich erreicht werden. Die Hintergründe, warum agile Methoden für Softwareentwicklungsprojekte besser geeignet sind als traditionelle Modelle, wie z.B. Wasserfall, V-Modell oder RUP, sind jedoch nur wenigen Entscheidungsträgern bewusst.
Ken Schwaber und Jeff Sutherland haben in Ihrem Buch “Software in 30 Days” diese Zusammenhänge sehr anschaulich beschrieben. Dieser Beitrag greift die von Ken und Jeff beschriebenen Mechanismen auf und beschreibt kurz und knapp, wie mit der richtigen Anwendung agiler Methoden die in den meisten traditionell organisierten Softwareprojekten auftretenden Probleme gelöst werden können.

Traditionelle Softwareentwicklungsprozesse

… basieren auf der Genauigkeit der Planung und der genauen Ausführung dieser. Bei solchen Prozessen geht man von folgenden Annahmen aus:

• Alle Anforderungen sind bekannt und bleiben über die gesamte Projektlaufzeit unverändert
• Alle Anforderungen wurden bis in Detail verstanden
• Die Technologien zur Umsetzung der Anforderungen funktionieren wie vorgesehen und deren Verwendung verursacht keine Probleme

In einer Umgebung in der diese Annahmen erfüllt sind funktionieren traditionelle Prozesse recht gut. Solche Umgebungen findet man zum Beispiel im Bereich der industriellen Fertigung mit Maschinen. Da wir es im Bereich der Softwareentwicklung aber nicht mit deterministischen, wiederkehrenden Problemen zu tun haben sind die oben genannten Annahmen in der Realität nicht erfüllt. Mit zunehmender Projektlaufzeit führt das meist zu folgenden Problemen:

• Releases dauern immer länger
  Mit jedem weiteren Release der Software wird immer mehr Zeit für die Realisierung einzelner Anforderungen benötigt. Das hat zur Folge, dass immer seltener Released wird und der Kunde länger auf neue Funktionen warten muss. Die zusätzliche Zeit kann jedoch nicht vollständig für die Implementierung neuer Funktionen genutzt werden, da sie für eine noch detailliertere Planung, Regressionstests und Fehlerbehebung aufgewendet wird. Dadurch steigen die Entwicklungskosten und die Kundenzufriedenheit sinkt.
  
• Release Termine müssen verschoben werden oder es wird nicht der gesamte Funktionsumfang geliefert
  Unsere Kunden sind darauf angewiesen, dass unsere Versprechungen bzgl. Umfang und Zeitpunkt eines neuen Release gehalten werden. Wir informieren Sie erst kurz vor dem vereinbarten Termin, dass nicht alle Funktionen im Release enthalten sind oder der Termin verschoben werden muss.
  
• Die Integration und Stabilisierung am Ende eines Release dauert immer länger
  In der Testphase zum Ende eines Release stellt sich heraus, dass die gelieferten Funktionen nicht nutzbar sind oder nicht den eigentlich gewünschten Zweck erfüllen. Die einzelnen Komponenten eines Gesamtsystems arbeiten nicht wie gewünscht zusammen. Es wird zusätzliche Zeit für die Integration und Fehlerbehebung benötigt.
  
• Die Planungsphase für ein Release nimmt immer mehr Zeit in Anspruch
  Eine ungenaue Planung führt zu vielen Änderungen während der Entwicklung. Die vielen Änderungen machen eine genaue Aussage über Kosten und Zeit unmöglich. Daraus wird der Rückschluss gezogen, dass eine genauere und vermeintlich bessere Planung benötigt wird. Die Planungsphasen werden immer intensiver, länger und kostspieliger. Der gewünschte Effekt von weniger Änderungen, genaueren Schätzungen und weniger Überraschungen während der Entwicklung tritt jedoch leider nicht ein.
  
• Änderungen während der Entwicklung eines Releases lassen sich nur schwer und mit sehr hohem Aufwand umsetzen
  Durch die lange Planungsphase am Anfang liegt eine sehr detaillierte Spezifikation der Release Features mit allen Abhängigkeiten vor. Änderungen an den Anforderungen bedingen eine Anpassung der gesamten Anforderungsdokumente. Schafft es eine neue Anforderung aufgrund des hohen Aufwands für Änderungen nicht in das aktuelle Release muss der Kunde jedoch aufgrund der langen Release Zyklen sehr lange auf eine unter Umständen sehr wichtige Änderung warten.
  
• Die Qualität sinkt kontinuierlich
  Durch den starken Termindruck stehen alle am Projekt beteiligten ständig unter einer hohen Arbeitsbelastung. Auf der anderen Seite gibt es lange Phasen der Inaktivität. Am Anfang eines Release, wenn die Anforderungen geklärt werden, haben Tester und Entwickler wenig zu tun. Die Analysten jedoch stehen unter hohem Zeitdruck, da die Anforderungen bis zu einem bestimmten Meilenstein feststehen müssen. Stehen die Anforderungen fest haben Tester und Analysten nichts zu tun und die Entwickler stehen unter hohem Zeitdruck. Am Ende eines Releasezyklus müssen die Tester die in den vorangegangenen Phasen zu viel benötigte Zeit wieder raus holen. Die Code Qualität ist durch die schlechten, unter Zeitdruck entstandenen Anforderungen und den unter Druck erstellten Programmcode meist schlecht. Entwickler und Tester versuchen so gut es geht einen auslieferbaren Stand des Produkts zu erzeugen.
  
• Die Moral der Mitarbeiter sinkt
  Die am Projekt beteiligten Personen werden über alle Maßen beansprucht. Der Termin steht vor der Gesundheit der Mitarbeiter. Die Motivation, Leistungsfähigkeit und Moral der Mitarbeiter sinkt dadurch rapide. In „Agile for Business“ beschreibt Bob Gover diesen in klassischen Projekten auftretenden Zyklus sehr passend:
  „In software organizations, a common vicious cycle looks like this: buggy technology leads to unhappy customers, which leads to unhappy managers who then pressure workers, who become unhappy and disengaged only to produce more buggy software.„
  

Empirische Softwareentwicklungsprozesse

… unterscheiden sich von traditionellen Prozessen dadurch, dass Informationen durch Beobachtung und nicht durch Vorhersage gewonnen werden. Empirische Prozesse finden bei komplexen Problemstellungen Anwendung, bei denen es mehr unbekannte Faktoren gibt, als bekannte. Die Voraussetzungen für den Erfolg empirischer Prozesse sind eine ständige Beobachtung der aktuellen Situation und eine auf den Beobachtungen basierende Anpassung der Planung. Je mehr unbekannte Faktoren es gibt, desto höher sollte die Frequenz des Zyklus der Beobachtung und Anpassung gewählt werden. Je geringer die Frequenz, desto höher wird das Risiko das Ziel nicht zu erreichen.
Transparenz über die zu beobachtenden Dinge ist eine Grundvoraussetzung für das funktionieren empirischer Prozesse. Der Gegenstand der Beobachtung hängt immer vom Ziel des Prozesses ab. Wenn ein Softwaresystem mit neuen Funktionen entwickelt werden soll, dann müssen die Funktionen beobachtet werden. Dazu muss Transparenz über die Funktionen hergestellt werden.

Wie löst ein empirischer Prozess, wie z.B. Scrum, die oben genannten Probleme?

• Releases dauern immer länger
  Releases bestehen aus einem Set von vollständig fertig gestellten und integrierten Inkrementen. Es kann im Prinzip ständig released werden. Wenn sich in Absprache mit dem Kunden herausstellt, dass der gelieferte Funktionsumfang bereits ausreichend ist, kann sogar früher als geplant released werden. Der für eine Arbeit mit kurzen Iterationen notwendige hohe Automatisierungsgrad bei Regressionstests und Deployment sorgt für eine ständige Kontrolle, durch die Fehler so früh wie möglich gefunden und im Idealfall noch in der laufenden Iteration behoben werden.
  
• Release Termine müssen verschoben werden oder es wird nicht der gesamte Funktionsumfang geliefert
  Der Release Termin kann nicht verschoben werden, weil Iterationen eine feste Länge von maximal 30 Tagen haben. Dieser Zeitraum kann nicht verlängert werden. Ein Release besteht aus einer festen Anzahl von Iterationen, also aus einem fest definierten Zeitraum, der ebenfalls nicht veränderbar ist. Die variable Größe eines Release ist der Umfang der gelieferten Funktionen. Dabei wird durch die Reihenfolge der Anforderungen im Product Backlog sichergestellt, dass immer an den wichtigsten Dingen zuerst gearbeitet wird und keine unnützen Dinge in den Iterationen realisiert werden. Nach dem aktuellen „Chaos Manifesto 2011“ werden in bestehenden Softwaresystemen mehr als 50% des Funktionsumfangs nicht oder nur selten genutzt. Agile Methoden stellen sicher, dass diese unwichtigen Funktionen zuletzt oder gar nicht erstellt werden.
  
• Die Integration und Stabilisierung am Ende eines Release dauert immer länger
  Jede Iteration liefert als Ergebnis ein komplett getestetes und integriertes Inkrement. Die Software ist also bereits voll nutzbar. Eine Stabilisierungsphase am Ende eines Release wird nicht benötigt, da die gesamte Integrationsarbeit bereits als Teil der Iteration erledigt wurde. Durch die bereits in der Iteration durchgeführten Tests und eine Automatisierung von Regressionstests wird sicher gestellt, dass keine Fehlerbehebungs-Phase am Ende eines Release benötigt wird.
  
• Es wird immer mehr Zeit für die Planung benötigt
  Die initiale Planung wird auf eine grobe Zielsetzung und die Definition einiger Features, die zum Erreichen dieses Ziels notwendig sind, beschränkt. Die detaillierte Planung für jede Iteration wird erst unmittelbar vor Beginn der Iteration durchgeführt (just in time planning). Dadurch wird sichergestellt, dass die Planung immer auf Grundlage der aktuellsten Informationen durchgeführt wird und alle Erfahrungen aus vorangegangenen Iterationen berücksichtigt. Es wird keine Zeit in die Planung von Dingen investiert die später nicht realisiert werden.
  
• Änderungen während der Entwicklung eines Releases lassen sich nur schwer und mit sehr hohem Aufwand umsetzen
  Da es keine festgelegte Planung für das gesamte Release gibt, können Änderungen jederzeit und ohne Mehraufwand in das Projekt einfließen. Die Anforderungen sind emergent (Emergenz ist die spontane Herausbildung von neuen Eigenschaften oder Strukturen eines Systems). Das heißt neue Anforderungen können sich jederzeit ergeben und bestehende können sich verändern oder überflüssig werden.
  
• Die Qualität sinkt kontinuierlich
  Jedes Inkrement ist vollständig umgesetzt, getestet und nutzbar. Es gibt keine Test und Stabilisierungsphase am Ende eines Release. Qualitätsprobleme werden bereits während der Iteration erkannt und müssen dort gelöst werden. Über die Definition of Done kann zusätzlich sichergestellt werden, dass die Einhaltung nichtfunktionaler Anforderungen zum Ende jeder Iteration überprüft wird. So können Probleme die nicht direkt in Bezug zu der Umsetzung von fachlichen Anforderungen stehen ebenfalls frühzeitig erkannt werden.
  
• Die Moral der Mitarbeiter sinkt
  Der oben beschrieben Zyklus aus Unzufriedenheit wird durchbrochen. Durch kontinuierliches liefern guter Qualität mit wenig Fehlern sind sowohl Kunden als auch Manager mit den Ergebnissen zufrieden. Dadurch sinkt der Druck auf das Entwicklungsteam. Frustrierende Integrations- und Stabilisierungssphasen am Ende eines Release entfallen, da die gelieferte Software sich kontinuierlich in einem auslieferbaren Zustand befindet. Selbstorganisation der Teammitglieder, die eigenständig über den Umfang der Iterationen entscheiden, ständige Kommunikation innerhalb des Teams und
  frühes Feedback im Rahmen der Review Meetings sind weitere Faktoren, die zu einer besseren Motivation der Teammitglieder führen.

Agile Methoden adressieren mit Hilfe der ihnen zugrunde liegenden empirischen Herangehensweise viele der Probleme, die in der Vergangenheit immer wieder in klassisch organisierten Projekten beobachtet werden konnten. Eine Prozess-Umstellung allein reicht jedoch nicht aus, um die oben beschriebenen Lösungen tatsächlich in einem Projekt zu realisieren. Der agile Prozess bildet lediglich eine Basis, mit der durch Transparenz eine Analyse der aktuellen Situation ermöglicht wird. Dadurch können auftretenden Problemstellungen frühzeitig erkannt und durch entsprechenden Maßnahmen adressiert werden. Die Maßnahmen zur Lösung der Probleme findet man oft in agilen Praktiken, deren Beherrschung für ein agiles Team mindestens genauso wichtig ist wie die Beherrschung der eingesetzten agilen Methode.