Wasserfall- versus agile Methode: Unterschiede und Beispiele

Was ist die Wasserfallmethode?

Die Wasserfallmethode ist ein Ansatz für Projektmanagement und Softwareentwicklung, der einer linearen Abfolge von Ereignissen folgt. Beim Wasserfallmodell ist jede Phase des Projekts in einzelne Abschnitte unterteilt. Teams können erst dann von einer Phase des Softwareentwicklungslebenszyklus zur nächsten übergehen, wenn die aktuelle Phase abgeschlossen ist. Jede Phase hat klar definierte Abschlusskriterien. Die Kriterien für das Projekt werden in der ersten Phase des Wasserfallmodells – der Anforderungsphase – festgelegt und in einer Dokumentation festgehalten. Die zu Beginn festgelegten Anforderungen sollten sich in diesem Modell im Laufe eines Entwicklungsprojekts idealerweise nicht ändern.

Das Wasserfallmodell eignet sich für Projekte, die einen hohen Dokumentationsaufwand erfordern und wiederholbare, vorhersehbare Prozesse haben. Es ist besonders effektiv für Projekte mit klar definierten Anforderungen und minimalen erwarteten Änderungen, da es Konsistenz und nachvollziehbare Kontrolle gewährleistet.

Was ist agile Softwareentwicklung?

Agile ist ein Ansatz für das Projektmanagement, insbesondere für Softwareentwicklungsprojekte, bei dem Zusammenarbeit, Continuous Delivery und Kundenfeedback im Vordergrund stehen. Agile unterteilt die Arbeit in iterative Schritte, also kleinere Aufgaben, die schnell erledigt werden können. Diese Iterationen werden in Sprints durchgeführt. Agile Teams schließen einen Sprint ab, bevor sie mit dem nächsten beginnen. Die Anforderungen können sich während des Projekts aufgrund sich ändernder Geschäftsanforderungen oder Kundenfeedbacks jederzeit ändern. Zukünftige Sprints basieren auf den Ergebnissen der vorherigen Sprints.

Es gibt mehrere Frameworks – beispielsweise Kanban, Scrum und Feature-Driven Development –, die Softwareteams dabei unterstützen, Agile in die Praxis umzusetzen und die 12 im Agilen Manifest beschriebenen Prinzipien zu implementieren. Agile Teams sind selbstorganisiert, und die Rollen innerhalb des Teams können sich im Laufe der Zeit ändern. Agile eignet sich am besten für Projekte mit flexiblen Prozessen, bei denen Kundenfeedback während des gesamten Prozesses einfließt.

Agile versus Wasserfallmethode

Die agile Softwareentwicklung legt Wert auf iterative Arbeit. Dies unterscheidet Agile von der Wasserfallentwicklung, bei der alle Arbeiten gruppiert werden und erst dann zur nächsten Phase des Softwareentwicklungslebenszyklus übergehen können, wenn sie alle denselben Fertigstellungsgrad erreicht haben.

Mit einem Ansatz, der auf kleinen Änderungen basiert, sind komplexe Softwareentwicklungsprozesse für alle Beteiligten nachvollziehbar und überschaubar. Wenn Entwicklungsteams versuchen, zu viel Code auf einmal zu ändern – wenn sie beispielsweise versuchen, mehrere neue Funktionen gleichzeitig zu entwickeln –, riskieren sie, auf unerwartete Probleme zu stoßen, die das Projekt verzögern. Diese Verzögerungen können Herausforderungen für andere Beteiligte mit sich bringen – beispielsweise für eine Geschäftsabteilung, die davon ausgeht, dass eine neue Funktion zum Starttermin eines Kundenprojekts verfügbar ist.

Agile begrenzt den Arbeitsumfang und konzentriert sich auf die Anpassung an sich ändernde Umstände. Diese Eigenschaften machen Agile vorteilhaft für komplexe Projekte, bei denen unerwartete Probleme auftreten können und die Entwicklungsteams zu schnellen Reaktionen zwingen.

Die Tendenz von Wasserfallprojekten, die vorgesehenen Fristen und den vorgesehenen Umfang zu überschreiten, bedeutet, dass Wasserfall heute nur noch selten verwendet wird. Im Allgemeinen bevorzugen die meisten Teams Agile.

Durch die Entscheidung für einen agilen Ansatz können Entwickler eine Reihe von Vorteilen erzielen, darunter die folgenden:

• Höhere Effizienz. Durch isolierte Änderungen verbringen Entwickler weniger Zeit mit der Implementierung überflüssiger Funktionen oder der Suche nach Fehlerquellen.
• Schnellere Software-Releases. Agile unterstützt Entwickler, Verzögerungen im Softwareentwicklungslebenszyklus zu vermeiden. Entwickler können schneller zu anderen Aufgaben übergehen, wenn sie nicht auf einen großen Release warten müssen. Davon profitieren auch die Benutzer, die neue Funktionen schneller erhalten.
• Höhere Anpassungsfähigkeit. Mit Agile können Teams Pläne ändern, wenn sie sich gegen eine bestimmte Funktion entscheiden. Bei der Wasserfallmethode verpflichtet sich ein Team zu vielen voneinander abhängigen Änderungen, die gleichzeitig implementiert werden. Wenn mehrere Projekte in der Wasserfallentwicklung zusammenlaufen, wirkt sich die Stornierung oder Änderung einiger Änderungen auf andere aus.
• Verbesserte Zusammenarbeit mit Stakeholdern. Durch die Einhaltung von Zeitplänen und Aufgaben stellt Agile sicher, dass Entwickler effektiv mit Stakeholdern zusammenarbeiten können. Zu den Stakeholdern können Geschäftsanwender gehören, die eine neue Funktion bis zu einem bestimmten Termin erwarten, oder IT-Teams, die die Infrastruktur für die Bereitstellung einer neuen Anwendungsversion bereitstellen müssen.
• Geringere Komplexität für Benutzer. Softwarebenutzer profitieren von Agile, da Änderungen in kleinen Schritten erfolgen. Sie müssen sich nicht an eine völlig neue Version einer Anwendung anpassen, die auf einmal grundlegend überarbeitet wurde, wie dies bei einem Wasserfallansatz der Fall wäre.

Dennoch kann die Wasserfallmethode für Softwareentwicklungsprojekte geeignet sein, bei denen Folgendes zutrifft:

• Die Anforderungen an das Projekt sind klar definiert, sodass keine detaillierten Planungs-, Analyse- und Designprozesse erforderlich sind.
• Der Gesamtumfang der zur Erfüllung der Anforderungen erforderlichen Arbeiten ist gering.
• Es gibt nur wenige Entwickler, die auch ohne ein Agile-Framework effizient zusammenarbeiten können.
• Die Deadline für das Projekt ist flexibel.

Unter diesen Bedingungen kann Wasserfall vorzuziehen sein, da es weniger Planung und Koordination erfordert.

Beispiele für agile und Wasserfallansätze

Agile und Wasserfall bieten allgemeine Leitlinien für die Strukturierung des Softwareentwicklungslebenszyklus. Es liegt an den Entwicklern, genau zu entscheiden, wie sie das Projekt innerhalb einer dieser Methoden durchführen.

Ein Ansatz zur Integration von Agile in jede der sieben Phasen des Softwareentwicklungslebenszyklus könnte wie folgt aussehen:

• Planung. In der Planungsphase des Softwareentwicklungslebenszyklus legen die Entwickler einen angemessenen Umfang der Änderungen fest, die sie implementieren möchten. Sie können beispielsweise beschließen, eine einzige neue Anwendungsfunktion zu entwickeln.
• Analyse. Nachdem sie entschieden haben, was implementiert werden soll, führen die Entwickler eine Analyse durch, um zu bestimmen, wie sie vorgehen werden. Nach einem agilen Ansatz teilen sie die Arbeit in kleine, einzelne Aufgaben auf.
• Entwurf. Agile beeinflusst nicht unbedingt die Entwurfsphase, in der der Schwerpunkt auf der Definition von Softwarearchitekturen, Komponenten und Schnittstellen im Zusammenhang mit den geplanten Änderungen liegt. Eine agile Entwurfsphilosophie kann jedoch die Verwendung kleiner, modularer Einheiten innerhalb von Anwendungsarchitekturen und Schnittstellen fördern, da dies dem agilen Konzept entspricht, Aufgaben diskret und überschaubar zu halten.
• Implementierung. In der Implementierungsphase erstellen die Entwickler nur die spezifischen Funktionen, die sie entwickeln möchten. Selbst wenn weitere Anforderungen zu berücksichtigen sind – beispielsweise wenn bestimmte Teile des Anwendungscodes zur Leistungsverbesserung optimiert werden können –, ignorieren sie diese vorerst, um sich auf eine einzige vordefinierte Aufgabe zu konzentrieren.
• Testen. Bei einer agilen Teststrategie werden Softwaretests in kleine Einheiten aufgeteilt, die dann vom Team schrittweise durchgeführt werden. Durch kleine, schrittweise Tests lässt sich die Arbeitsbelastung des Testteams besser einschätzen und es kann flexibel auf Fehler im Test reagieren.
• Bereitstellung. Agile muss nicht unbedingt die Herangehensweise des IT-Teams an die Bereitstellung ändern, das heißt die Überführung einer neuen Anwendungsversion in die Produktion. Allerdings erfolgen Bereitstellungen bei Agile häufiger als beim Wasserfallansatz. Jede inkrementelle Änderung wird separat bereitgestellt. Bei Wasserfall werden mehrere Änderungen gleichzeitig bereitgestellt. Inkrementelle Bereitstellungsstrategien wie Canary Releases und Blue/Green Deployment ergänzen Agile.
• Wartung. Agile schreibt nichts für die Wartungsphase des Softwareentwicklungslebenszyklus vor, in der Entwickler und IT-Teams eine Anwendung in der Produktion überwachen. Teams können Feedback zu Problemen sammeln, die während der Produktion aufgetreten sind, und dieses für die nächste Runde von Updates nutzen.

Im Gegensatz dazu sieht ein Wasserfallansatz für den Softwareentwicklungslebenszyklus eher wie folgt aus:

• Planung. Während der Planung erstellen Entwickler eine Liste der Änderungen, die sie implementieren möchten. Einige fügen möglicherweise Anwendungsfunktionen hinzu, während andere bestehende Funktionen erweitern oder die Leistung verbessern.
• Analyse. Die Vielzahl der von den Entwicklern angestrebten Änderungen macht es schwierig, jede einzelne vollständig zu analysieren und spezifische, detaillierte Pläne zu erstellen. Infolgedessen erreichen Entwickler möglicherweise nur eine grundlegende Analyse dessen, was für das Design erforderlich ist. In diesem Szenario füllen die Entwickler die Details möglicherweise erst aus, wenn die Arbeit bereits begonnen hat.
• Entwurf. Ebenso bedeutet ein Wasserfallansatz für das Design in der Regel, dass nur eine grundlegende Vision für die Anwendungsarchitektur, die Komponenten und die Schnittstellen vorliegt und die Details erst später ausgearbeitet werden.
• Implementierung. Bei der Implementierung im Wasserfallmodell schreibt eine Reihe von Entwicklungsteams den Code, der für die Erstellung der Funktionen oder anderer Änderungen innerhalb des Projekts erforderlich ist. Dabei können sie sich entscheiden, zusätzliche Aufgaben zu übernehmen, die ursprünglich nicht geplant waren, damit diese Änderungen mit dem Projekt umgesetzt werden können und nicht bis zum Start eines neuen Projekts warten müssen.
• Testen. Alle Änderungen werden gemeinsam implementiert und getestet. Aufgrund der Vielzahl von Änderungen, die gleichzeitig innerhalb der Anwendung auftreten, kann es unklar sein, welche Updates welche Probleme beim Testen verursachen. Wenn Entwickler Probleme in einem Teil des Codes beheben, können sie anderen Code beschädigen, der von dem reparierten Code abhängt. Aus diesem Grund kehren die Entwickler zur Implementierungsphase zurück, um den Code zu überarbeiten und anschließend erneut zu testen. Wenn sie neue Fehler entdecken, die sie zur Implementierung von zusätzlichem Code zwingen, wiederholt sich dieser Prozess.
• Bereitstellung. Wie bei Agile schreibt auch der Wasserfallansatz keine bestimmte Bereitstellungsmethode vor. Die große Anzahl der während des Projekts implementierten Änderungen macht die Bereitstellung jedoch in der Regel komplex. Bei der agilen Bereitstellung werden in der Regel weniger Komponenten geändert.
• Wartung. Ebenso ist bei einer Anwendung, die nach dem Wasserfallmodell entwickelt wurde, mit einem komplizierten Änderungsmanagement zu rechnen. Da die Release-Zyklen bei der Wasserfallmethode zudem sehr lang sind, kann die Behebung von Fehlern, die während der Wartungsphase entdeckt werden, viel Zeit in Anspruch nehmen.

Diese Beispiele zeigen, warum viele Entwicklungsteams von der Wasserfallmethodik abgekommen sind. Das Entwicklungsteam, das Wasserfall einsetzte, war nicht auf Fehler in Tests vorbereitet, was zu Ineffizienzen führte. Die Roadmap, zu der sich die Entwicklungsteams, die Wasserfall einsetzten, verpflichtet hatten, wurde verworfen, da die Entwickler wiederholt Fehler beheben mussten. Letztendlich konnte es viele Monate oder sogar Jahre länger dauern als ursprünglich erwartet, bis die geplanten Updates veröffentlicht werden konnten. Das agile Team konnte sich an Fehler in Tests anpassen, indem es die Arbeitslasten besser verwaltbar machte. Das agile Team hielt den Zeitplan ein, indem es den Bedarf an Flexibilität im Softwareentwicklungslebenszyklus vorhersah.

Die Tabelle enthält eine kurze Zusammenfassung der Auswirkungen der einzelnen Methoden auf die Phasen des Softwareentwicklungslebenszyklus: