Wasserfall beziehungsweise Waterfall als Methode der Softwareentwicklung ist tot, ein Hoch auf agile Methoden wie Scrum - diese Meinung dürften viele Softwareentwickler teilen. Aber stimmt diese gängige Überzeugung auch? Die Antwort lautet Nein! Wenn man den Wasserfall richtig verwendet, kann man mit ihm ebenso effizient wie mit agilen Methoden arbeiten. Bei Applikationen mit zwingend notwendigen, kritischen Systemeigenschaften hat er sogar deutliche Vorzüge.
Um diese Position zu verdeutlichen, sollen hier zunächst die wichtigsten Vorurteile und Überzeugungen zu Waterfall kurz dargestellt und diskutiert werden. Grundsätzlich: Waterfall ist eine alte, man kann auch sagen bewährte Methode zur sequenziellen, schrittweisen Entwicklung von Software, die bereits in den 70er Jahren des vorigen Jahrhunderts formuliert wurde. Sie heißt Waterfall, da in einem mehrteiligen Prozess von Stufe zu Stufe vorgegangen wird, ähnlich wie manche Wasserfälle fallen. Die verschiedenen Phasen im Entwicklungsprozess werden entsprechend der Reihe nach abgearbeitet. So weit, so gut. Was sind nun aber die häufigsten Einwände gegenüber dieser doch plausibel klingenden Vorgehensweise?
Kritikpunkt Dokumentation
"Waterfall ist ineffektiv und veraltet - agile Methoden wie Scrum sind modern und produktiv", so eine typische Einschätzung oder Fehleinschätzung. Sie geht davon aus, dass jedes Projekt unter Waterfall überdokumentiert ist und jeder einzelne Schritt zur Behebung auftretender, unerwarteter Probleme Monate dauert.
Tatsächlich aber benötigen agile Methoden wie Scrum ebenso viele, den Entwicklungsprozess begleitende Dokumente wie Waterfall. Auf eine Spezifizierung der Anforderungen, die Dokumentation der Architektur oder die Festlegung von Testszenarien wird auch hier nicht verzichtet.
Der wesentliche Unterschied besteht darin, dass in agilen Projekten diese Dokumente parallel zum Entwicklungsprozess und typischerweise als eher informeller Text erstellt werden. Der so genannte End-User versteht diese informellen Texte besser und sieht Ergebnisse der Entwicklung unmittelbar, da der agile Ansatz auf eine schnelle Umsetzung aus ist.
Manchmal ist dies von Wert, manchmal auch nicht. Es führt aber kein Weg daran vorbei, egal in welchem Prozessmodell, eine solide Dokumentation zu erstellen. Niemand kann ungezählte Zeilen von undokumentiertem Code pflegen, warten, erweitern oder verbessern. Die Frage ist nur, an welcher Stelle im Prozess diese Dokumentation erstellt wird: Vorab wie bei Waterfall oder begleitend zur Entwicklung wie etwa bei Scrum.
- 1. Fokus auf Kernfunktionen
Konzentrieren Sie sich bei der Definition der Anforderungen auf die Kernfunktionen der umzusetzenden Anwendung. Das Pareto-Prinzip gilt in der Regel auch in der Softwareentwicklung. Demnach sollten 80 Prozent der Funktionalität einer Anwendung durch 20 Prozent des Funktionsumfangs erbracht werden. - 2. Defensiver Technikeinsatz
Vermeiden Sie technische Spielereien. Es muss nicht immer jedes neueste Feature genutzt werden. Wägen Sie den Einsatz neuer Techniken sorgfältig ab, auch wenn diese eine höhere Entwicklereffizienz und schnelle Ergebnisse versprechen. Grundsätzlich gilt: Je mehr Funktionen, desto komplexer und damit aufwändiger und teurer wird die Anwendungsentwicklung. - 3. Einsatz vorgefertigter Komponenten
Prüfen Sie, ob Sie verfügbare Komponenten, Plattformen und Produkte nutzen können. Wenn es sich um nicht allzu komplexe Teillösungen handelt, kann das viel Aufwand ersparen. Allerdings ist eine "Buy"-Entscheidung nicht in jedem Fall der richtige Weg. Wenn die Komponenten erst "hingebogen" werden müssen, bis sie allen Anforderungen gerecht werden, ist das aufwändig und birgt Folgerisiken - etwa den Verlust der Release-Fähigkeit. - 6. Nutzung von Erfahrungen
Frühe Fehler können sich zu einem späteren Zeitpunkt zu Kostentreibern entwickeln. Unerfahrene Mitarbeiter sind daher ein Projektrisiko. Zumindest an den neuralgischen Punkten eines Projektes - etwa dem Architekturdesign oder der Projektplanung - sollten Sie den Projektbeteiligten daher erfahrene Mitarbeiter oder externe Berater zur Seite stellen. - 7. Stabile Anforderungen und verbindliche Absprachen
Sorgen Sie für stabile Anforderungen und klare Erwartungen an das Softwaresystem sowie für verbindliche Absprachen zwischen den Projektbeteiligten und strukturierte Change-Request-Verfahren. Dieses Vorgehen wirkt auf den ersten Blick etwas bürokratisch, letztlich hilft es aber, häufige Kurswechsel im Projektverlauf und daraus resultierende arbeitsintensive Nacharbeiten zu vermeiden. - 8. Kalkulation interner Ressourcen
Bewerten Sie die Verfügbarkeiten und Kapazitäten der internen Projektbeteiligten realistisch. Mitarbeiter, die beispielsweise zusätzlich zu ihrem Tagesgeschäft "nebenbei" im Projekt mitarbeiten, verursachen oft versteckte Mehrkosten, Terminverschiebungen und vor allem Qualitätsprobleme. - 10. Realistische Aufwandsplanung
Planen Sie die Aufwände eher vorsichtig. Zu optimistische Einschätzungen - "das ist schnell gemacht", "das ist ja fast fertig" - verfälschen die Kalkulation. Hektisches Nacharbeiten und Terminverzüge verursachen letztlich meist mehr Kosten als sauber geplante Projekte.