Wer gewinnt? Wasserfall oder Iterationen - Eine Praxiserfahrung
Oft stehen sich die beiden Lösungsansätze gegenüber und in der Debatte wird versucht die eine Methode mit der anderen zu vergleichen. Vor- und Nachteile in der Anwendung werden aufgeführt, Stärken und Schwächen diskutiert. Oftmals dreht sich der Vergleich um die sequenzielle Wasserfall-Methode, die in der traditionellen Entwicklung eine wichtige Rolle spielte und Scrum einer iterativen und inkrementellen Projektmanagement-Methode.
Was ist SCRUM - in aller Kürze
Scrum ist ein Vorgehensmodell. In kurzen Zyklen, den sogenannten Sprints, wird ein lauffähiges Stück Software programmiert - das Inkrement. Die Dauer der Sprints, in welchen ein Inkrement entwickelt wird als Teil eines Gesamtprojekts, ist unterschiedlich. Sprints können eine Woche, zwei oder auch länger dauern. Selten wird länger als ein Monat an einem Inkrement gearbeitet. An dieser Stelle gilt es zu erwähnen, dass Scrum nicht nur in der Software-Entwicklung, sondern oft auch im Projekt-Management eingesetzt wird.
Begleitet von regelmässigen Feedbackschleifen (Daily Scrum, Sprint Review, Refinement und Retrospektive), entwickelt das Scrum-Team, bestehend aus einem Scrum Master, Product Owner und den Entwicklern, das Produkt von einem Inkrement zum nächsten weiter, bis die Softwareentwicklung abgeschlossen ist. Nach jedem Sprint haben Anwender die Möglichkeit das Inkrement, also den Zwischenschritt, zu testen und Verbesserungen zu liefern. Das Feedback ist im Vergleich zur Wasserfall-Methoden zentral, da während des Projekts auf Änderungen eingegangen werden kann.
Die Wasserfall-Methode – in aller Kürze
Ein nach Wasserfall geführtes Projekt wird linear geleitet und unterteilt sich in klar definierte Phasen. Nacheinander werden diese abgearbeitet. Von der Anforderungsanalyse über das Design zur Implementierung, dem Testen, der Bereitstellung und der Wartung. Jede Phase zeichnet sich durch umfangreiche Dokumentationen aus, was für klare Anforderungen und Spezifikationen sorgt. Die Anforderungen werden zu Beginn des Projekts vollständig definiert und während des Entwicklungsprozesses nicht mehr verändert. Bevor die nächste Phase beginnt, muss die vorherige abgeschlossen sein und die Führung des Projekts orientiert sich an strikten Meilensteinen sowie Deadlines. Erst nach der Fertigstellung kriegt der Kunde die Lösung zu Gesicht und kann diese testen.
Wo liegen die Schwächen der Methoden?
Um zur Frage zurückzukehren, wer bei der Entwicklung das Rennen macht. Ein berechtigter Kritikpunkt bei der traditionellen Wasserfall-Methode ist, dass der Kunde erst nach Abschluss des Projektes die Möglichkeit hat, die Software auf seine Anforderungen zu testen. Die Anforderungen des Kunden können sich in der Entwicklungsphase ändern, doch wird dies erst nach Abschluss des Projektes sichtbar.
Scrum wiederum wird angelastet, dass die Dokumentation während der Entwicklung viel zu kurz kommt und die Nachvollziehbarkeit somit fehlt. Müssen neue Team-Mitglieder in das Projekt eingearbeitet werden, fehlen oftmals die Unterlagen, um die Mitarbeitenden zu schulen.
Unsere Erfahrungen mit den Methoden
Der Vergleich der beiden Methoden erscheint naheliegend, befinden sie sich ja im selben Einsatzgebiet. Dennoch kommen die Ansätze bei unterschiedlichen Projekten zur Anwendung. Sie können nicht einfach gegeneinander ausgespielt werden. Auch wenn bei der Wasserfall-Methode von einer traditionellen Methode die Rede ist, wäre es falsch, diese als überholt zu bezeichnen. In bestimmten Situationen macht es Sinn, einen sequenziellen Ansatz zu wählen.
Sind detaillierte Vorgaben vorhanden, die vertraglich festgehalten werden und sind Anforderungsspezifikationen im Vorfeld umfassend geklärt, kann der Wasserfall-Ansatz zielführend sein.
Wenn jedoch ein Produkt entwickelt werden soll, welches die Bedürfnisse des Marktes abbilden muss, ist ein streng sequenzielles Vorgehen kaum geeignet. Gerade in Projekten mit hoher Komplexität, die sich durch dynamische Anforderungen auszeichnen, spielt der iterative Ansatz seine Vorteile aus.
Unsere Erkenntnis ist, dass oft eine Mischung aus beiden Ansätzen zum Erfolg führt. So kann es Sinn machen, die Phase der Anforderungsanalyse zu Beginn strukturiert aufzuarbeiten und eine Dokumentation der Lasten aufzusetzen. Geht das Projekt in die Design- und Entwicklungsphase über, folgt der Wechsel in eine iterative Vorgehensweise. Der Vorteil besteht darin, dass eine erste Dokumentation dem Projekt ein Gerüst gibt und eine fundierte Grundlage der Anforderungen besteht.
Ein Praxisbeispiel
Wir erhielten den Auftrag in einem Projekt das Anforderungsmanagement zu übernehmen. Die neue Softwarelösung sollte einen Teil der Funktionen des im Einsatz befindlichen ERP bereitstellen. Die Funktionen waren somit klar definiert, genauso wie die Erwartung, dass die neue Lösung nah am bestehenden ERP sein soll. Diese klaren Gegebenheiten führten dazu, dass wir ein Lastenheft erarbeiteten, welches sich an einer Wasserfall-Struktur orientierte.
Bei der Entwicklung wiederum, entschied sich das Team einen iterativen Ansatz zu verfolgen, um einerseits bei Anforderungsänderungen die Lösung nicht an den Anwendern «vorbeizuprogrammieren». Ein weiterer Grund war die Komplexität des Projekts. Da zu Beginn noch nicht alle technischen Details definiert waren, integrierten die Entwickler die Anforderungen agil in die Lösung. Auch wenn die Vorgaben eigentlich durch das ERP und die Anforderungen zu Beginn besprochen wurden, konnten die Entwickler nicht ausschliessen, dass sich die Bedürfnisse der Anwender mit der Zeit verändern.
Die Quintessenz
Wie so oft zeigt dieses Beispiel, dass es die Kombination aus zwei bewährten Ansätzen ist, die am Schluss das Rennen macht.
Autor:
Dominik Lischer, Professional Business Analyst
Quellen:
https://www.scrum.org/resources/what-scrum-module
https://seibert.group/blog/2010/05/12/agile-software-entwicklung-vs-wasserfall-modell-was-die-forschung-sagt/
https://asana.com/de/resources/waterfall-project-management-methodology
https://www.digicomp.ch/blog/2023/12/17/devops-vs-klassische-entwicklung-versiegt-der-wasserfall