Wasserfall vs Agil: Was ist die richtige Methode für Ihr Softwareprojekt?

In den letzten Jahren wird immer häufiger das Wort agil im Zusammenhang mit Projektmanagement und Softwareentwicklung genannt. Die Geschäftswelt verändert sich schnell, und deshalb suchen Unternehmen nach Prozessen, Ansätzen und Methoden, die ihnen helfen können, sich ebenso schnell an die veränderten Bedingungen anzupassen.

Obwohl es Dutzende verschiedener Projektmanagementansätze gibt, sollte die endgültige Wahl unter Berücksichtigung der Art des Unternehmens und seiner Anforderungen getroffen werden. Bei der Entwicklungsmethodik für Softwareprojekte werden traditionelle (Wasserfall) und agile Methoden oft gegeneinander ausgespielt.

Wenn Sie wissen möchten, wie sich beide Ansätze voneinander unterscheiden und welchen Sie für Ihr nächstes Softwareprojekt wählen sollten, sind Sie hier genau richtig. Im Folgenden wird die detaillierte Differenzierung der beiden Projektmanagementansätze erläutert.

Die Methode des Wasserfallmodells ist ein linearer Ansatz zur Softwareentwicklung. Das klassische Modell ist dabei in einzelne Phasen unterteilt, die nacheinander in einer festgelegten Reihenfolge durchlaufen werden.

In einem Wasserfall-Entwicklungsprojekt stellt jede dieser Phasen den fortschreitenden Verlauf der Softwareentwicklung dar. Bevor eine neue Phase beginnt, endet jede Phase mit einem vorher definierten Zwischenergebnis (Meilenstein), um den Projektstand zu überprüfen. Dabei ist es wichtig, die Abhängigkeiten zwischen den Phasen und Aktivitäten zu kennen.

Das Projekt startet mit der Definition der Anforderungen durch den Auftraggeber. Diese werden in einem Lastenheft festgehalten. Der Softwareentwickler analysiert diese und entwirft ein Designkonzept, welches in einem Pflichtenheft festgehalten wird. Nach der Prüfung starten

Programmierung, Testing und Deployment. Dabei sind Rücksprünge zu der jeweiligen Phase davor möglich.

Da alle Phasen aufeinander aufbauen, ist es wichtig kritischen Aktivitäten nach einem Zeitplan fertigzustellen. Sollte es zu Verzögerungen kommen, müssen diese schnellstmöglich behoben werden, um eine verspätete Produktauslieferung zu verhindern.

Entwickler und Kunden einigen sich darauf, was früh im Entwicklungslebenszyklus geliefert wird. Das macht die Planung und Gestaltung einfacher. Die klare Hierarchiestruktur vereinfacht die Steuerung von Teams und Arbeitspaketen.

Der Fortschritt lässt sich leichter messen und überwachen, da der volle Umfang der Arbeit im Voraus bekannt ist. Damit wird eine optimale Ressourcenplanung und -nutzung erreicht.

Außer bei Reviews, Freigaben nach Erreichung von Meilensteinen, Statusmeetings etc. ist eine Kundenpräsenz nach der Anforderungsphase nicht zwingend erforderlich.

Ein Wasserfall-Projekt ist auch von einer umfangreichen Dokumentation gekennzeichnet, die für Rückfragen recht vorteilhaft sein kann.

Da das Design früh im Entwicklungslebenszyklus abgeschlossen wird, eignet sich dieser Ansatz für Projekte, bei denen mehrere Softwarekomponenten für die Integration mit externen Systemen entworfen werden müssen.

Schließlich kann die Software vollständig und sorgfältiger entworfen werden, basierend auf einem umfassenderen Verständnis aller Softwarebestandteile. Auch in sicherheitskritischen Projekten ist ein standardisierter und erprobter Ablauf notwendig, daher eignet sich das Wasserfall-Vorgehensmodell hierbei sehr gut.

Kunden und Anwender müssen bei der Wasserfall-Vorgehensweise bereits von Anfang an eine sehr konkrete Vorstellung vom finalen Softwareprodukt haben und diese früh im Projekt für die Softwareentwickler bereitstellen. Oft ist es Kunden nicht immer möglich, eine Anwendung aus einem Anforderungsdokument zu visualisieren. Wireframes und Mockups können helfen, aber es steht außer Frage, dass die meisten Anwender Schwierigkeiten haben, diese Elemente mit schriftlichen Anforderungen zusammenzubringen, um sich ein gutes Bild davon zu machen, was sie bekommen werden.

Darüber hinaus ergeben sich weitere Einschränkungen und Nachteile:

• Erst spät im Entwicklungszyklus wird eine funktionierende Software produziert. Das ist schlecht für die Fehlererkennung.
• Das Modell ist ungeeignet für Projekte mit unklaren Anforderungen oder Anforderungen mit mittlerem bis hohem Änderungsrisiko sowie für komplexe und objektorientierte Projekte.
• Es ist schwierig, den Entwicklungsfortschritt innerhalb von Phasen zu messen.
• Geänderte Anforderungen können nur schwer oder kostspielig berücksichtigt werden.
• Erfordert große zeitliche Puffer, da Verzögerungen nur schwer kompensiert werden können.
• Das Anpassen des Umfangs während des Lebenszyklus kann ein Projekt beenden.

Das Wasserfall-Modell in der Softwareentwicklung lässt nicht viel Reflexion oder Überarbeitung zu. Sobald sich eine Anwendung in der Testphase befindet, ist es sehr schwierig, zurückzugehen und etwas zu ändern, das in der Konzeptphase nicht gut dokumentiert oder durchdacht war.

Wer sich für eine agile Entwicklungsmethode entscheidet wählt einen iterativen, teambasierten Entwicklungsansatz. Dieser Ansatz betont die schnelle Bereitstellung einer Anwendung in vollständigen funktionalen Komponenten. Als Leitfaden dienen User Stories, die beschreiben, was der Auftraggeber möchte. Anstatt Aufgaben und Zeitpläne zu erstellen, wird das Softwareprojekt in kurze Entwicklungszyklen eingeteilt. Dabei werden die Arbeitspakete zeitgesteuert in sogenannten „Sprints“ umgesetzt.

Jeder Sprint hat eine definierte Dauer mit einer laufenden Liste von Ergebnissen, die zu Beginn des Sprints geplant sind. Liefergegenstände werden nach dem vom Kunden festgelegten Geschäftswert priorisiert. Wenn nicht alle geplanten Arbeiten für den Sprint abgeschlossen werden können, wird die Arbeit neu priorisiert und die Informationen werden für die zukünftige Sprintplanung verwendet.

Wenn die Arbeit abgeschlossen ist, kann sie vom Projektteam und dem Kunden durch tägliche Builds und End-of-Sprint-Demos überprüft und bewertet werden. Agiles Vorgehen setzt auf ein sehr hohes Maß an Kundenbeteiligung während des gesamten Projekts, insbesondere aber während dieser Überprüfungen. Scrum, Scaled Agile Framework (SAFe) und Kanban sind die bekanntesten Beispiele für agile Methoden bei der Softwareentwicklung.

Der Kunde hat häufig und früh Gelegenheit, die gelieferte Arbeit zu prüfen. Er kann während des gesamten Entwicklungsprozesses Entscheidungen und Änderungen zu treffen. Damit gewinnt der Kunde ein starkes Gefühl der Eigenverantwortung, indem er während des gesamten Projekts intensiv und direkt mit dem Projektteam zusammenarbeitet.

Wenn die Markteinführungszeit für eine bestimmte Anwendung wichtiger ist als die Veröffentlichung eines vollständigen Funktionsumfangs, kann die agile Methode schneller eine Basisversion einer funktionierenden Software erstellen, auf der in aufeinanderfolgenden Iterationen aufgebaut werden kann.

Die Entwicklung ist oft benutzerorientierter, da das Kundenfeedback immer wieder einfließen kann. Neue oder geänderte Backlog-Items können für die nächste Iteration geplant werden, was die Möglichkeit bietet, Änderungen innerhalb weniger Wochen einzuführen.

Durch die Aufteilung des Projekts in überschaubare Einheiten kann sich das Projektteam auf qualitativ hochwertige Entwicklung, Tests und Zusammenarbeit konzentrieren. Durch die Erstellung häufiger Builds und die Durchführung von Tests und Überprüfungen während jeder Iteration wird die Qualität verbessert, indem Fehler schnell gefunden und behoben und Abweichungen von den Erwartungen frühzeitig erkannt werden.

Das sehr hohe Maß an Kundenbeteiligung ist zwar großartig für das Projekt, kann jedoch für einige Kunden, die einfach nicht die Zeit oder das Interesse für diese Art der Beteiligung haben, Probleme bereiten.

Da eine agile Softwareentwicklung sich auf zeitgesteuerte Lieferung und häufige Neupriorisierung konzentriert, ist es möglich, dass einige zur Lieferung bestimmte Elemente nicht innerhalb des zugewiesenen Zeitrahmens fertiggestellt werden. Zusätzliche, ungeplante Sprints können erforderlich sein und die Projektkosten erhöhen. Darüber hinaus führt die Einbeziehung des Kunden häufig zu zusätzlichen Funktionen, die während des gesamten Projekts angefordert werden. Auch dadurch können sich Gesamtzeit und Gesamtkosten der Implementierung erhöhen.

Es gibt noch ein paar weitere Nachteile des agilen Modells:

• Nicht geeignet für den Umgang mit komplexen Abhängigkeiten.
• Geringere Vorhersehbarkeit des Endergebnisses.
• Ein Gesamtplan, eine agile Führungskraft und Erfahrung im agilen Projektmanagement sind ein Muss, ohne das es nicht geht.
• Es birgt ein hohes Maß an Abhängigkeit von der Kundeninteraktion. Wenn der Kunde also nicht klar ist, kann das Team in die falsche Richtung getrieben werden.
• Es besteht ein höherer Kommunikations- und Abstimmungsbedarf
• Der Technologietransfer an neue Teammitglieder kann aufgrund fehlender Dokumentation eine ziemliche Herausforderung darstellen.

Die iterative Natur der agilen Entwicklung kann zu häufigem Refactoring führen, wenn der volle Umfang des Systems nicht in der ursprünglichen Architektur und im Design berücksichtigt wird. Ohne dieses Refactoring kann das System an einer Verringerung der Gesamtqualität leiden. Dies wird bei Implementierungen in größerem Maßstab oder bei Systemen mit einem hohen Integrationsgrad noch ausgeprägter.

Auch eine Kombination von agiler Vorgehensweise und Wasserfall-Modell kommt bei der Softwareentwicklung recht häufig vor.

Beispielsweise Banken, Versicherungen oder auch Behörden, neigen dazu, im Voraus eine detaillierte Erfassung und Analyse der Anforderungen durchzuführen. Sie grenzen ihre Projekte gründlich ein, führen Budgetanalysen durch und lassen sich das Vorhaben von verschiedenen Interessenvertretern absegnen. Das ist entspricht einem Wasserfall-Vorgehen.

Wenn die Entwicklung beginnt, kommt dann ein agiles Framework wie Scrum oder Kanban zum Einsatz, um einen iterativen Prozess zu unterstützen. Planänderungen sind zulässig, da die Software kontinuierlich an den Kunden geliefert wird.

Ziel einer hybriden Methode ist es, sowohl die Anforderungen wie bei einem Wasserfall-Ansatz im Vorfeld definieren zu können, als auch in Bezug auf Design, Entwicklung und Test auf einen agilen Ansatz überzugehen. Die Vor- und Nachteile dieser beiden Methoden bleiben gleich.

Wenn bei Softwareprojekten die Anforderungen im Voraus klar definiert sind und eine minimale Wahrscheinlichkeit für Änderungen zwischen dem Zeitpunkt der Anforderung der Software und ihrer Lieferung besteht, dann ist die Wasserfallmethode sinnvoll. Auch für Projekte, wo Teams sich an strenge Vorschriften halten müssen oder ein hoher Dokumentationsbedarf besteht, ist diese Methode gut geeignet. Daher ist die Wasserfallmethode ein guter Ansatz, wenn Ihre Zielsetzung und Anforderungen klar definiert sind und Sie einen strukturierten Plan haben, von dem nicht abgewichen werden sollte.

Mit einer agilen Methode bei der Softwareentwicklung gibt es mehr Raum für Richtungsänderungen und zum Experimentieren, während sich das Produkt entwickelt. Das eignet sich besonders gut, wenn es keinen komplett detaillierten Anforderungskatalog gibt. Eine funktionierende Software steht im Mittelpunkt und nicht so sehr die Dokumentation. Der gesamte Prozess ist darauf ausgelegt dynamisch auf Veränderungen zu reagieren und nicht nur blind einem Plan zu folgen.

Sie wollen das Beste aus beiden Welten? Dann wäre ein hybrides Vorgehen evtl. die richtige Methode.

Die Wahl der richtigen Vorgehensmethode hängt immer vom Kontext ab. Wenn Sie sich nicht sicher sind, welche Methode für Sie die beste Option ist, können Sie sich auch an Ihren Softwareanbieter wenden. Auch wir beraten Sie gern und unterstützen Sie bei der Wahl des für Sie passenden Vorgehensmodells.

Kontaktieren Sie uns, wenn Sie ein neues Softwareprojekt starten wollen oder wir Sie beim agilen Projektmanagement unterstützen können.