Agil und Wasserfall – Klar zu trennen oder doch kombinierbar?

Bei der Frage, wie man am besten bei dem managen und ausarbeiten eines Projektes vorgeht, hört man zumeist von zwei Entwicklungsmodellen, die auf den ersten Blick wohl unterschiedlicher nicht sein könnten. Auf der einen Seite das klassische Wasserfallmodell, das als strukturiert, übersichtlich und vorhersehbar gepriesen wird, und auf der anderen Seite das Agile Modell, welches durch seinen schnellen, iterativen und flexiblen Ansatz hervorsticht. Doch sind es wirklich zwei Vorgehensweisen, die sich schlicht ausschließen, oder handelt es sich nicht eher um zwei etablierte Modelle, die nicht nur voneinander profitieren sondern auch kombiniert werden können?

Fließend ans Ziel

Das sogenannte Wasserfallmodell ist der traditionelle Projektmanagementansatz, welcher aufgrund seiner linearen Vorgehensweise dazu genutzt wurde, um Struktur und Disziplin in die oftmals chaotische Softwareentwicklung zu bringen. Zurückgeführt wird das Modell auf den Computerwissenschaftler Dr. Winston W. Royce, der 1970 in seiner Publikation Managing the Development of Large Software Systems darauf verwies, dass das gängige 2-Stufen-Entwicklungskonzept aus Analyse und Coding vor allem bei größeren Projekten nicht zielführend ist.

Royce warb dafür, große Projekte lieber in mehrere Stufen zu unterteilen, die aufeinander aufbauen und in einer festgelegten Reihenfolge verlaufen. Er selbst verwendete in seiner Publikation in keinem Satz das Wort Wasserfall, jedoch etablierte sich die Bezeichnung recht schnell, da die linear abfallende Stufenabfolge - die in ihrer Grundform kein Weg zurück kennt - schlichtweg an fallendes Wasser erinnert.

Sein Modell könnte man auch als ‚think first, code later’ beschreiben, da bevor die Analyse überhaupt startet zunächst alle notwendigen Anforderungen geklärt sein sollten und dem Coding eine Designphase vorhergeht. Dieses vorausschauende Planen kombiniert mit den ineinandergreifenden Arbeitsschritten sollte dafür sorgen, dass Projekte einfacher betriebsbereit, pünktlich und innerhalb der Kosten vollendet werden können.

Klar definierte Struktur und Phasen

Heutzutage besteht der sequentielle Prozess der Wasserfallmethodik je nach digitalem Projekt aus 5 bis 7 typischen Phasen, die sich beispielhaft wie folgt anordnen:

1. Initialisierung: Festlegen der Projektziele und aller geschäftsrelevanten Aspekte wie Kosten, Ressourcen und Verfügbarkeit.
2. Analyse: Ausarbeiten der Nutzungsanforderungen und Erstellen eines Grobkozepts über die Funktionen und Eigenschaften des Produktes.
3. Konzeption: Die Anforderungen werden spezifiziert, sodass eine klare to-do-Liste für Design und Programmierung erstellt werden kann.
4. Design: Konkrete Lösungskonzepte für das visuelle als auch technische Design. (UI, System- sowie Informationsarchitektur)
5. Programmierung: Realisierung der in der Design-Phase konzipierten Architektur. Die Komponenten werden seperat entwickelt, integriert und Modultests unterzogen.
6. Testen: Nach der abgeschlossenen Implementierunge wird das System überprüft und auftretende Fehler behoben.
7. Betrieb: Das fertige Produkt wird ausgeliefert. Je nach Bedarf können hierauf weitere Tests, Wartungen oder Optimierungen folgen.

Die optimale Umsetzung des Wasserfallmodells sieht vor, dass jede Phase konsequent abgearbeitet und als Meilenstein abgeschlossen wird. Dies bedeutet, dass eine neue Phase nur dann begonnen werden kann, wenn die vorherige Phase mit einem klaren Ergebnis für beendet erklärt wurde. Damit in diesem Kontext die Nutzer nicht auf der Strecke bleiben, begleitet seit Anfang der 90er der Prozess des Human-Centered-Design (HCD) die Entwicklung von Beginn an. Hier legen die Entwicklerteams einen großen Wert auf Usability und greifen hauptsächlich auf Standards und Styleguides zurück, die sich in der Mensch-Maschine-Interaktion (HCI) bewährt haben.

Das Wasserfallmodell in Kombination mit HCD hilft durch die übersichtliche Organisationsstruktur mit klar definierten Phasen und Leistungsparametern dem Projektteam und –manager Unklarheiten früh zu beseitigen und den Fokus auf das aktuelle Arbeitsfeld zu legen. Außerdem liegt der Schwerpunkt der Methode auf der gesamten Projektdokumentation, da jede Phase ausführlich erfasst wird und mit einem Meilenstein endet.

Dies stellt aber auch gleichzeitig einen der Nachteile des Modells dar. Die Dokumentation hat einen solch übergreifende Stellenwert, dass sie u.U. wichtiger als das eigentliche System genommen wird. Die starren, linearen Prozesse erforden zudem eine hohe Vorhersehbarkeit des Projektverlaufs. Das Ergebnis und somit auch der Return on Investment sind erst nach Abschluss des Gesamtprojekts wirklich sichtbar. Wenn also der notwendige wie zeitfressende Konzeptions- und Anforderungsanalyse-Aufwand fehlerbehaftet ist, verläuft die Planungen in eine falsche Richtung und die Methode versagt.

Agiles Arbeiten dank hoher Flexibilität

Um den straffen und ohne Rückkopplungen versehenen Ablauf des Wasserfallmodells zu durchbrechen, wurden in den vergangenen Jahren eine Vierlzahl an agilen Methoden entwickelt, die sich durch eine hohe Flexibilität auszeichnen. Allen gemein sind 4 wesentliche Werte, die 2001 von einer Reihe namhafter Entwickler während des sogenannten Snowbird-Meeting im Agile Manifesto formuliert wurden:

• Individuen/Interaktionen wichtiger als Prozesse/Werkzeuge
• Funktionierende Software wichtiger als umfassender Dokumentation
• Kunden-Zusammenarbeit wichtiger als Verhandlungsführung
• Reagieren auf Veränderung wichtiger als das Befolgen eines Plans

In diesen Werten sieht man bereits einige Unterschiede zum klassischen Modell. Statt einem eher bürokratisch daherkommenden Prozess zu folgen, bricht man das Projekt auf und konzentriert sich auf schnelle Iteration. Die Themenbereiche werden in kurzen Zyklen - besser bekannt als Sprints - bearbeitet, getestet und abgeschlossen. Dies erlaubt den Entwicklern auf jegliche Änderung sowie auf Kundenfeedback schnell zu reagieren.