Jedes Mal, wenn ich über Spec-Driven Development spreche, sagt jemand dasselbe. „Das ist doch nur Wasserfall.“ Es ist als Killerargument gemeint. Das ist es nicht.
Hier passieren zwei Dinge. Erstens haben die meisten Leute nie gelesen, was Royce wirklich geschrieben hat. Zweitens ist auch der echte Wasserfall am richtigen Ort gut. Nehmen wir beides.
Man greift einen Strohmann an
Das Wasserfall-Modell stammt aus einem Aufsatz von Winston Royce aus dem Jahr 1970, „Managing the Development of Large Software Systems“ [1]. Die Leute erinnern sich an ein Bild aus diesem Aufsatz. Anforderungen fliessen in den Entwurf, der Entwurf fliesst in den Code, der Code fliesst in den Test, und alles bewegt sich in eine Richtung, von oben nach unten.
Hier ist der Teil, den sie vergessen. Royce zeichnete dieses Bild und sagte dann, es sei riskant und lade zum Scheitern ein. Es war sein Beispiel für den naiven Ansatz. Der Rest des Aufsatzes bestand darin, es zu reparieren.
Er fügte Rückkopplungsschleifen hinzu, vom Test zurück zum Entwurf und vom Entwurf zurück zu den Anforderungen. Er sagte, man solle die Arbeit zweimal machen, mit einem Pilot zuerst. Er sagte, man solle den Test planen und überwachen. Er sagte, man solle die Dokumentation aktuell halten. Er sagte, man solle den Kunden einbeziehen.
Das Modell, über das man sich lustig macht, ist also die Version, vor der Royce gewarnt hat. Sein eigentlicher Vorschlag wurde nie zum gängigen Bild. Die Leute behielten den Strohmann und warfen die Antwort weg.
Aber seien wir fair
Ich möchte einen ehrlichen Punkt hinzufügen, denn er macht die Sache stärker, nicht schwächer.
Die Geschichte „Royce wurde falsch verstanden“ wird manchmal so erzählt, als wäre sein verbessertes Modell schon Agile gewesen. Das war es nicht. Seine Rückkopplung lief zwischen benachbarten Phasen. Es war kein Satz kurzer Iterationen, die alle paar Wochen lauffähige Software liefern. Es blieb plangetrieben und dokumentenlastig. Echte iterative und inkrementelle Entwicklung hat ihre eigene lange Geschichte, und Larman und Basili haben sie bis Jahrzehnte vor dem Begriff Agile zurückverfolgt [2].
Und das ist in Ordnung. Das ist genau der Punkt.
Wasserfall ist gut, wenn es passt
Plangetriebene Entwicklung, das ist der ehrliche Name für Wasserfall, ist eine gute Wahl, wenn die Situation dazu passt.
Es passt, wenn die Anforderungen stabil sind. Es passt, wenn eine späte Änderung teuer ist. Es passt, wenn man Nachvollziehbarkeit und echte Dokumentation braucht. Es passt bei regulierter Arbeit und bei Verträgen mit festem Umfang. Es passt bei einer Domäne, die gut verstanden ist.
In diesen Fällen ist das Nachdenken im Voraus keine Bürokratie. Es ist Risikoreduktion. Man macht das schwere Denken, bevor man das Geld ausgibt.
Die Agile-Bewegung brauchte einen Bösewicht, um sich davon abzugrenzen [3]. Also brannte sie die Strohmann-Version in das Gedächtnis aller ein. Das war gutes Marketing. Es war schlechte Geschichtsschreibung.
Der wahre Schmerz war die Übergabe
Hier ist die zentrale Erkenntnis, und es ist die, die man übersieht.
Der Schmerz von Wasserfall war nie „Anforderungen zuerst“. Der Schmerz war die Übergabe. Die Spezifikation war ein eingefrorenes Dokument, das von einer Gruppe von Menschen an eine andere weitergereicht wurde. Die Schleife von diesem Dokument bis zu lauffähigem, getestetem Code dauerte Monate.
Barry Boehm beschrieb die Kostenkurve der Änderung [4]. Ein Fehler, der spät gefunden wird, kostet weit mehr als einer, der früh gefunden wird. Wasserfall schob den Test ganz ans Ende, also tauchten Fehler spät auf und kosteten ein Vermögen. Royces Korrekturen, mach es zweimal und füge Rückkopplungsschleifen hinzu, waren ein Versuch, diese Kosten nach links zu ziehen.
Er hatte recht mit dem Ziel. Die Werkzeuge von 1970 konnten es nicht liefern.
Spec-Driven Development ist Royce, günstig gemacht
Schauen wir uns nun Spec-Driven Development mit KI an.
Wir stellen immer noch die Anforderungen an den Anfang. Wir schreiben immer noch eine klare Spezifikation. Wir achten immer noch auf Nachvollziehbarkeit. Dieser Teil sieht wie Wasserfall aus, und das gebe ich gerne zu.
Aber die Übergabe ist weg. Die Spezifikation ist ausführbar. Wir können den Code daraus neu erzeugen. Die Schleife von der Spezifikation bis zur laufenden Software dauert Minuten, nicht Monate. Wenn wir etwas Neues lernen, ändern wir die Spezifikation und erzeugen neu. Die Kosten einer späten Änderung sinken gegen null.
Das ist das, was Wasserfall nie konnte. KI flacht die Kostenkurve der Änderung ab, die Boehm gezeichnet hat.
Wenn mir also jemand sagt, Spec-Driven Development sei nur Wasserfall, argumentiere ich nicht, dass es anders ist. Ich sage ihm etwas Besseres.
Spec-Driven Development ist das, worum Royce 1970 gebeten hat. Wir haben endlich die Werkzeuge, um es günstig zu machen.
Keep IT simple
Lies die Quelle, bevor du sie zitierst. Royce hat dir den Wasserfall nicht verkauft. Er hat dich davor gewarnt und dir dann gesagt, wie man es besser macht.
Wir holen seinen Rat erst jetzt ein.
Quellen
[1] Winston W. Royce, „Managing the Development of Large Software Systems“, Proceedings of IEEE WESCON, Los Angeles, August 1970, S. 1-9. Ein Nachdruck ist verfügbar unter https://www.praxisframework.org/files/royce1970.pdf
[2] Craig Larman und Victor R. Basili, „Iterative and Incremental Development: A Brief History“, IEEE Computer, Band 36, Nr. 6, Juni 2003, S. 47-56. https://doi.org/10.1109/MC.2003.1204375
[3] Kent Beck et al., „Manifesto for Agile Software Development“, 2001. https://agilemanifesto.org
[4] Barry W. Boehm, „Software Engineering Economics“, Prentice Hall, Englewood Cliffs, NJ, 1981. Siehe auch Barry W. Boehm, „Software Engineering“, IEEE Transactions on Computers, Band C-25, Nr. 12, Dezember 1976, S. 1226-1241.
[5] „Waterfall model“, Wikipedia. https://en.wikipedia.org/wiki/Waterfall_model Diagramm: „Waterfall model“ von Peter Kemp und Paul Smith, Wikimedia Commons, lizenziert unter CC BY 3.0. https://commons.wikimedia.org/wiki/File:Waterfall_model.svg
