Waterfall
Ein sequenzielles Entwicklungsmodell, bei dem jede Phase (Anforderungen, Design, Bau, Test, Deployment) abgeschlossen wird, bevor die nächste beginnt. Solide bei festem, gut verstandenem Umfang, schwach bei Produktdiscovery.
Waterfall führt ein Projekt als geordnete Folge von Phasen durch: alle Anforderungen sammeln, dann das ganze System designen, dann bauen, dann testen, dann ausliefern. Jede Phase produziert ein abgenommenes Dokument und wird abgeschlossen, bevor die nächste beginnt. Der Reiz ist offensichtlich: Ihr kennt Plan, Kosten und Termin im Voraus, und alle stimmen zu, bevor eine Zeile Code geschrieben ist.
Für manche Arbeit passt es weiterhin legitim. Wenn der Umfang wirklich fest und gut verstanden ist, wenn ein Regulator vorab Dokumentation und Nachvollziehbarkeit verlangt, oder wenn ihr Hardware baut, bei der ihr nach dem Schnitt des Metalls nicht billig iterieren könnt, sind sequenzielle Phasen das ehrliche Modell. So ein Projekt als “agil” auszugeben, versteckt nur den Plan, statt ihn zu entfernen.
Bei Produktdiscovery scheitert es schwer. Die fatale Annahme ist, dass ihr das richtige Produkt im Voraus spezifizieren könnt, bevor irgendein Nutzer es berührt hat. Das könnt ihr fast nie. Wenn die Bauphase endet, sind die Monate zuvor gesammelten Anforderungen teilweise falsch, und Waterfall hat keinen billigen Weg, das vor der Testphase herauszufinden, in der jede Änderung teuer ist. Ihr bekommt ein Produkt, das der Spezifikation entspricht und am Bedarf vorbeigeht.
Die ehrliche Abgrenzung zu Agile: Waterfall lädt alle Entscheidungen nach vorn und wettet, dass sie richtig sind. Agile verteilt Entscheidungen über die Arbeit und wettet, dass frühes Feedback die falschen abfängt. Bei allem, wo ihr noch nicht genau wisst, was ihr bauen sollt, begünstigt diese Wette Agile. Bei allem, wo die Antwort wirklich bekannt und fest ist, ist die Vorhersehbarkeit von Waterfall ein Vorteil, kein Mangel.