Wasserfall-Methode: Definition, Prozess & Beispiele
Wir leben in einer Welt, in der die Agile-Methodik allgegenwärtig ist. Von berühmten Technologiekonzernen bis hin zu kleinen Start-ups: Jeder nutzt sie zur Entwicklung seiner Produkte. Wenn Sie sich mit Agile beschäftigen, sind Sie vielleicht auf den Begriff „Wasserfall-Methodik“ gestoßen.
Die meisten Projektmanager, die Agile verwenden, betrachten Wasserfall als veraltete Methodik, die im Jahr 2023 keinen Zweck mehr erfüllt. Aber stimmt das wirklich?
Als Senior Product Manager habe ich viel Erfahrung mit beiden Methoden, sowohl Agile als auch Wasserfall. Zur Verteidigung der Wasserfall-Methodik lassen Sie uns im Detail betrachten, was sie ist, wie sie funktioniert und wann ihr Einsatz sinnvoll ist.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Worum geht es bei der Wasserfall-Projektmanagement-Methodik?
Wasserfall steht für ein Konzept, bei dem Entwicklungsprojekte in klar abgegrenzte Phasen unterteilt werden, die nacheinander abgearbeitet werden.
Obwohl das Zerlegen großer Arbeitsmengen in kleinere Teilaufgaben ein Konzept ist, das die Menschheit schon seit Urzeiten nutzt, fand die formale „Geburt“ der Wasserfall-Methodik viel später statt – nämlich 1970, als Dr. Winston W. Royce, ein bedeutender Computerwissenschaftler jener Zeit, sie in seinem Buch „Managing the Development of Large Software Systems“ beschrieb.
Seitdem war dies die Hauptmethode, mit der Softwareunternehmen ihre Projekte gemanagt haben, bis sich die Welt Anfang der 2000er Jahre zunehmend Agile zuwandte.
Wie sieht der Softwareentwicklungslebenszyklus (SDLC) nach der Wasserfall-Methode aus?
Im Gegensatz zu der iterativen und inkrementellen Struktur von Agile hat der SDLC bei Wasserfall sowohl einen klaren Anfang als auch ein klares Ende. Er unterteilt den gesamten Prozess der Softwareentwicklung in fünf verschiedene Phasen oder Meilensteine, wobei die Arbeit an einer Phase erst startet, wenn die vorherige abgeschlossen ist. Visuell sieht das folgendermaßen aus:
Die Arbeit fließt von einer Phase zur nächsten, bis sie am unteren Ende ankommt und das Projekt als „abgeschlossen“ gilt – was es optisch einem Wasserfall ähnelt (daher der Begriff).
Schauen wir uns nun jede Phase dieses linearen Ansatzes an und verstehen, was dahintersteckt.
Phase #1: Anforderungsaufnahme
Alles beginnt mit dem Sammeln der Anforderungen für das Projekt von allen Stakeholdern. Während der Anforderungsphase erstellen die Projektmanager ein umfassendes, sehr detailliertes Dokument, das jeden Aspekt des Projekts abdeckt, von funktionalen Anforderungen bis zu Budget- und Risikoplanung.
Phase #2: Lösungsdesign
Auf der Grundlage der vorher erfassten Anforderungen beginnt das Projektteam, die Lösung zu formulieren und zu entwerfen. Der Begriff „Design“ bezieht sich hierbei auf die technische Struktur des Produkts (Systemdesign), das visuelle und Interaktionsdesign des Produkts (UI/UX Design) sowie das physische Design (sofern es sich um ein physisches Produkt handelt).
Phase #3: Implementierung
In dieser Phase findet die eigentliche Programmierung statt. Ihre Softwareentwickler beginnen, das Produkt basierend auf den Ergebnissen zu bauen, die Sie in der Designphase erarbeitet haben.
Im Unterschied zu Agile, wo Sie den Projektumfang und das Design ständig anpassen können, geht die Wasserfall-Methodik davon aus, dass Sie sich an das Designdokument halten und Ihr Produkt während der Implementierungsphase nicht weiterentwickeln.
Phase #4: Testen
Sobald das Softwareentwicklungsteam das Produkt fertiggestellt hat, geht es in unserem Projektplan in die nächste Phase – das Testen. Ihr Team beginnt, das Produkt auf Fehler, Sicherheitslücken und Probleme mit der Benutzererfahrung zu überprüfen.
In der Testphase prüfen Sie außerdem, ob die Funktionalität und das Design des Endprodukts mit den in den ersten beiden Phasen erstellten Projektdokumenten übereinstimmen.
Phase #5: Deployment und Betreuung nach der Veröffentlichung
Angenommen, Ihr Team hat alle wesentlichen Probleme an Ihrem Produkt gefunden und behoben, ist es Zeit für den Rollout und Sie übergeben Ihre Lösung an Ihre Kunden und Endnutzer.
Ihre Entwickler gehen nun in die Wartungsphase über, indem sie laufend Kundenfeedback sammeln, notwendige Korrekturen vornehmen und neue Updates und Patches Ihres Produkts veröffentlichen.
Das war's – Ihr Projekt ist abgeschlossen und Sie können sich dem nächsten widmen!
Sollten Sie also die Wasserfall-Methode nutzen?
Falls Sie als Agile-orientierter PM (wovon ich jetzt ausgehe) denken, diese Methodik sei aus der Mode gekommen und man sollte sie nie mehr in Betracht ziehen, dann bin ich anderer Meinung und behaupte, dass der Wasserfall-Ansatz tatsächlich für bestimmte Projekttypen die bessere Wahl ist.
Lassen Sie mich Ihnen dazu ein paar Beispiele nennen, um meinen Standpunkt zu verdeutlichen.
Fallstudien: Die Wasserfall-Methode in der Praxis
Wie bei jedem komplexen Konzept können konkrete Beispiele hilfreich sein, um zu verstehen, wie die Methodik im wirklichen Leben funktioniert. Nachfolgend finden Sie einige Beispiele, die auf echten Projekten basieren (an denen ich möglicherweise selbst beteiligt war oder auch nicht), um Ihnen zu verdeutlichen, wie der Wasserfall-Ansatz in der Praxis abläuft.
Fall #1: Eine Zollabwicklungsplattform für die ägyptische Regierung
Stellen Sie sich vor, Sie sind Teil eines Unternehmens, das den Auftrag erhalten hat, die internationalen Handels- und Zollabwicklungssysteme eines relativ großen Landes, zum Beispiel Ägypten, zu modernisieren.
Die ägyptische Regierung möchte ein Hafensystem, das die Manifeste aller Schiffe verwaltet (ein Zolldokument, das Informationen über sämtliche Ladung und Passagiere eines Schiffes enthält), die die verschiedenen Häfen Ägyptens anlaufen.
Darüber hinaus soll dieses System direkt mit einem weiteren Produkt integriert werden, das Sie ebenfalls entwickeln sollen und das alle Zollanmeldungen (auch als SADs, Single Administrative Documents, bezeichnet) im Land abwickelt. Das Formular ist für normale Bürger ziemlich komplex auszufüllen, daher möchten sie, dass Sie diesen Prozess automatisieren.
Ägypten verfügt über ein komplexes Steuer- und Zollsystem, bei dem sich die Sätze je nach Art der importierten Waren, deren Menge und anderen Faktoren ändern. Da gewöhnliche Bürger keine Ahnung von diesen Sätzen haben, möchte die ägyptische Regierung, dass Ihre App alle Berechnungen automatisch auf Basis der angegebenen Informationen übernimmt und den Bürgern die Möglichkeit gibt, online mit ihrer Kreditkarte zu bezahlen.
Das klingt nach einem riesigen Unterfangen, richtig? Wenn es zur Ausarbeitung der Umsetzungsdetails kommt, werden sich Ihre Leitung (und vielleicht sogar die ägyptische Regierung) an Sie, den Projektleiter, wenden und fragen, wie Sie die Umsetzung dieses Projekts organisieren wollen.
Warum und wie Sie in diesem Szenario die Wasserfall-Methode einsetzen sollten:
Was auch immer Sie für eine nationale Regierung entwickeln, wird höchstwahrscheinlich auf einem Gesetz oder einer Entscheidung beruhen, das bzw. die das Parlament ratifiziert hat. Diese Entscheidungen umfassen alles – von den allgemeinen Eckdaten des Projekts (z.B. Kosten und Zeitplan) bis zu den kleinsten Details, wie alles funktionieren soll.
Das klingt und sieht aus wie ein Lastenheft aus der ersten Phase des Wasserfalls, oder? Tatsächlich ist dem so – und das bedeutet auch, dass Sie nicht einfach wie bei der agilen Softwareentwicklung laufend Implementierungsdetails, Design und Anforderungen ändern können.
Ich habe selbst einmal ein solches Produkt geleitet. Eines Tages haben wir festgestellt, dass wir das Nutzererlebnis durch ein paar kleine Änderungen in der Geschäftslogik deutlich verbessern könnten. Unsere Idee haben wir sofort mit dem zuständigen Vertreter der Zollbehörde geteilt, der mit uns zusammenarbeitete.
Tja, er sagte nein. Sie würden vielleicht denken, dass es ein Fehler war, ein solches Angebot abzulehnen, aber er hatte einen guten Grund dafür.
Unsere kleinen Änderungen hätten eine Änderung der Formel bedeutet, mit der die Regierung die Steuern für ein bestimmtes Produkt berechnet. Die Formel war jedoch gesetzlich festgelegt, und eine Änderung hätte bedeutet, dass das gesamte nationale Parlament zusammenkommen und darüber abstimmen muss.
Fall #2: Das Flugsteuerungssystem des Ingenuity-Helikopters
Ingenuity ist der Name des Hightech-Helikopters, den die NASA 2021 gebaut und zum Mars geschickt hat. So sieht der kleine Kerl aus.
Stellen Sie sich vor, Sie wären der glückliche Projektleiter, der für die Entwicklung der Software dieses unglaublichen Technikwunders verantwortlich ist. Insbesondere musste Ihr Team den Code schreiben, der den Flug des Helikopters steuern sollte.
Die Entwicklung eines Flugsteuerungssystems für ein Luftfahrzeug (insbesondere einen Helikopter) ist sehr schwierig. Sie müssen alle physikalischen Gesetze berücksichtigen, die während des Flugs auf Ihr Flugzeug einwirken, und die notwendige Drehgeschwindigkeit der Rotorblätter, den Winkel der Blätter und eine Million anderer Dinge berechnen.
Ihre Aufgabe ist allerdings noch komplexer: Ihr Helikopter soll über der Oberfläche eines anderen Planeten mit einer Atmosphäre fliegen, die hundertmal dünner ist als die der Erde.
Warum und wie Sie in diesem Szenario die Wasserfall-Methode einsetzen sollten:
Meiner Ansicht nach bleibt Ihnen hier nur die Wasserfall-Entwicklung. Im Gegensatz zum agilen Projektmanagement, bei dem Sie zunächst etwas Kleines (Ihr MVP) entwickeln, bereitstellen, im echten Einsatz testen, Feedback sammeln und darauf aufbauend Ihre Lösung schrittweise verbessern, sind bei einem Projekt wie diesem die Risiken einfach viel zu hoch.
Können Sie es sich wirklich leisten, eine fehlerhafte MVP-Version von Ingenuity zu bauen und sie 140 Millionen Meilen bis zum Mars zu schicken? Es gibt einfach keine Möglichkeit, dass dem irgendjemand zustimmen würde.
Sie müssen also die endgültige Version davon bauen und dann alle ihre Systeme gründlich testen, bevor Sie das notwendige Vertrauen haben, sie in eine Rakete zum roten Planeten zu schicken.
Das Wasserfallmodell ist lebendig und wohlauf!
Tatsächlich ist es viel populärer, als Sie erwartet hätten, denn die Hälfte aller Projekte weltweit nutzt immer noch diese Entwicklungsmethodik.
Obwohl das Aufkommen von Agile die Welt für viele Projektmanager verbessert hat, indem sie Produkte viel früher auf den Markt bringen und auf das Feedback ihrer Nutzer aufbauen konnten, ist das Wasserfallmodell nach wie vor eine äußerst wertvolle Methodik, die Sie für Projekte mit begrenzter Flexibilität und einer geringen Fehlertoleranz einsetzen können.
Ich hoffe, Ihnen hat unsere Darstellung der Wasserfallmethode gefallen. Wenn Sie auch etwas mehr über Agile lesen möchten, kann ich Folgendes empfehlen:
- Unser Leitfaden zu Agilem Produktmanagement.
- Die Sammlung der Best Practices für Agiles Portfolio-Management.
- Unsere kuratierte Liste der besten Tools für agiles Produktmanagement.
Dies sind nur drei der vielen Leitfäden und Artikel, die wir zu Produkt- und Projektmanagement haben. Für mehr, abonnieren Sie unseren Newsletter.
