8 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
V-Modell oder agil: Diese Frage stellt sich, sobald man eine Software entwickeln lässt. Sie wird als Wahl zwischen zwei Methoden des Projektmanagements dargestellt. Die eigentliche Trennlinie verläuft woanders. Sie trennt zwei Arten, mit dem umzugehen, was man noch nicht weiß: es vorhersagen oder sich darauf einstellen.
Ein prädiktiver Ansatz legt im Voraus fest, was gebaut wird und wann. Ein adaptiver Ansatz entscheidet nach und nach, auf Grundlage dessen, was man dazulernt. Und viele Praktiken, die heute agil heißen, sagen weiterhin voraus, nur mit anderen Mitteln.
Das Wasserfallmodell und das V-Modell beruhen auf demselben Prinzip. Die Phasen folgen aufeinander, von den Anforderungen bis zum Betrieb, und jede baut auf dem Ergebnis der vorherigen auf. Der Plan wird zu Beginn festgelegt. Getestet wird nach der Umsetzung.
Dieses Modell hat eine Geschichte, und sie beginnt mit einer Warnung. 1970 veröffentlicht Winston Royce, Ingenieur bei TRW, einen Aufsatz, in dem er diese Abfolge von Phasen zeichnet. Direkt darunter schreibt er: „I believe in this concept, but the implementation described above is risky and invites failure.“ (Ich halte das Konzept für richtig, aber die oben beschriebene Umsetzung ist riskant und lädt zum Scheitern ein.)
Er erklärt auch, warum. Die Testphase am Ende ist der erste Zeitpunkt, an dem sich das tatsächliche Verhalten des Systems beobachten lässt. Erfüllt dieses Verhalten die Vorgaben nicht, muss der Entwurf überarbeitet werden. Die Entwicklung kehrt dann an ihren Ausgangspunkt zurück, und man muss, so schreibt er, mit einer Überschreitung von bis zu 100 % bei Zeitplan oder Kosten rechnen.
Dennoch hält Royce den Ansatz für tragfähig, unter einer Bedingung: dass man ihn um fünf Schritte ergänzt. Dazu gehört, die Arbeit zweimal zu machen, wobei die erste Version als Simulation der zweiten dient. Und den Kunden einzubinden, formell und fortlaufend.
Craig Larman und Victor Basili haben nachgezeichnet, wie es weiterging. Die Norm DOD-STD-2167 des US-Verteidigungsministeriums schrieb ein striktes, dokumentengetriebenes Wasserfallmodell in einem einzigen Durchlauf vor. Ende der 1980er-Jahre erlebt das Verteidigungsministerium erhebliche Fehlschläge bei der Beschaffung von Software. Fast zehn Jahre später sagt der Hauptautor der Norm, er bedauere, sie geschrieben zu haben: Iterative Entwicklung habe er damals nicht gekannt, sonst hätte er sie nachdrücklich empfohlen. Im Dezember 1994 ersetzt MIL-STD-498 die überarbeitete Fassung DOD-STD-2167A. Sie beschreibt eine Entwicklung in mehreren aufeinanderfolgenden Versionen, von denen jede einen Teil der geplanten Funktionen umsetzt.
Ein prädiktiver Ansatz eignet sich weiterhin für einen Bedarf, der sich nicht ändern wird. Arbeit, die sich immer gleich wiederholt, wird vorhersagbar. Software dagegen wird immer zum ersten Mal entwickelt.
Im Februar 2001 treffen sich siebzehn Fachleute für iterative Methoden in Utah. Daraus entsteht das Manifest für Agile Softwareentwicklung. Sein Titel sagt, worum es geht: um Softwareentwicklung, nicht um Projektmanagement.
Seine vier Werte passen in vier Zeilen. Einer davon: „Reagieren auf Veränderung mehr als das Befolgen eines Plans“. Zwei seiner Prinzipien gehen in dieselbe Richtung: „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen“ und „Funktionierende Software ist das wichtigste Fortschrittsmaß“.
In diesem Text ist Agilität keine Methode. Sie ist ein Ansatz: Software ausliefern, die funktioniert, sehen, was sie bewirkt, und die Richtung ändern, wenn das Gelernte es verlangt.
Vieles von dem, was heute unter diesem Namen praktiziert wird, bringt die Vorhersage zurück.
Story Points. Ron Jeffries, einer der Begründer von Extreme Programming, erzählt, wie sie entstanden sind. Sein Team schätzte in „idealen Tagen“, die die Stakeholder als Kalendertage lasen. Um das Missverständnis auszuräumen, benannte das Team sie in „Points“ um. 2019 schreibt er: „I like to say that I may have invented story points, and if I did, I’m sorry now.“ (Ich sage gern, dass ich Story Points vielleicht erfunden habe, und falls ja, tut es mir jetzt leid.)
Velocity. Viele Teams schätzen jedes Element in Story Points, messen, wie viele Punkte sie pro Iteration abschließen, und leiten daraus einen Termin ab. Vasco Duarte benennt die Schwäche dieses Mechanismus: Während das Team die Arbeit immer besser versteht, schätzt es den Rest neu, und der Durchschnitt, auf dem die Vorhersage beruht, verschiebt sich ständig.
Skalierungs-Frameworks. In SAFe kommen die Teams alle 8 bis 12 Wochen zusammen, um den nächsten Zeitraum gemeinsam zu planen. Zu den Ergebnissen dieser Planungsrunde zählt die SAFe-Dokumentation ein Board, auf dem die Liefertermine der Features und ihre Abhängigkeiten zu sehen sind.
Martin Fowler, einer der Unterzeichner des Manifests, hat diese Verschiebung 2018 benannt: „faux-agile: agile that’s just the name, but none of the practices and values in place“ (Schein-Agilität: agil nur dem Namen nach, ohne die Praktiken und Werte). Im selben Jahr spricht auch Jeffries von „Faux Agile“.
Manche Teams haben aufgehört zu schätzen. Duarte schlägt vor, die Arbeit in Elemente zu schneiden, die klein genug sind, um einander zu ähneln, zu zählen, wie viele pro Woche fertig werden, und dieses Tempo fortzuschreiben, um den Rest vorherzusagen. Allen Holub, der dieselbe Methode vertritt, spricht von Projektionen auf Grundlage echter Messungen. Das Wort gehört zu dieser Schule.
Das ist ehrlicher als Raten. Aber es bleibt eine Vorhersage. Eine Vermutung über die Zukunft wurde gegen eine Hochrechnung aus der Vergangenheit getauscht.
Die Frage ist dieselbe geblieben: In welchem Tempo kommen wir voran, und wann sind wir fertig?
Ein adaptiver Ansatz stellt diese Frage nicht. Er stellt eine andere: Was ist jetzt das Nützlichste? Und er beantwortet sie mit dem, was man in diesem Moment weiß. Nicht mit dem, was man sich am Tag des Angebots vorgestellt hat.
Dave Farley wird in seinem Video „How To Estimate Software Development Time“ deutlicher: Er glaubt nicht an Schätzungen und sagt, wir sollten es auch nicht tun.
Frédéric Leguédois widmet diesem Übergang ein Modul seiner Schulung „Un retour à l’essence de l’Agilité“ (auf Französisch): „Passer de Scrum à un fonctionnement sans projection“ (von Scrum zu einem Arbeiten ohne Projektion; eigene Übersetzung). Darin stellt er Modelle vor, die auf Flow, Anpassungsfähigkeit und dem Verzicht auf prädiktive Planung beruhen.
Adaptiv heißt nicht, dass nichts vorhergesagt wird. Der Ansatz sagt voraus, was vorhersehbar ist: das Monatsbudget und die Entwicklungstage pro Monat. Er versucht nicht, das Unvorhersehbare vorherzusagen: was Ihre Nutzer mit einer Funktion tun werden, bevor sie sie in der Hand haben.
Diese Grenze hat einen Grund. Wenn Microsoft die Wirkung seiner Ideen per kontrolliertem Experiment misst, verbessert nur eine von drei die Zielmetrik. Ein Drittel hat keine Wirkung, ein Drittel verschlechtert sie (Kohavi und Thomke, Harvard Business Review, 2017). Niemand weiß im Voraus, welche. Das zeigt erst die Nutzung. Eine Idee lässt sich übrigens testen, bevor überhaupt etwas gebaut wird: Dafür ist ein MVP da.
Bei einem prädiktiven Ansatz wird die Funktionsliste zu Beginn festgelegt, zusammen mit Preis und Termin. Diese Liste entsteht aber, bevor es die Software gibt, also dann, wenn man am wenigsten darüber weiß, wie Ihre Teams sie nutzen werden. Jede Entdeckung unterwegs wird zum Nachtrag. Jeder Nachtrag vergrößert die Abweichung vom Angebot. Dave Farley erklärt es in seinem Video „Fighting User Requirements That CONSTANTLY Change“: Software entwickeln heißt, nach und nach zu lernen, was sie können muss. Anforderungen besser aufzuschreiben, reicht dafür nicht.
Unser agiler Entwicklungsansatz setzt am anderen Ende an. Fest stehen das Budget und das zu lösende Problem. Flexibel bleibt der Funktionsumfang, also die Funktionen, die dieses Problem lösen.
Wir entwickeln Ihre individuelle Anwendung zu einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird. Sie ist innerhalb eines Monats nutzbar. Nutzbar heißt nicht fertig: Ihre Teams arbeiten ab dem ersten Monat damit, und diese Nutzung entscheidet, was wir im Folgemonat entwickeln.
Es ist ein Festpreis, aber keiner mit festem Leistungsumfang. Wer in welchem Modell das Risiko trägt, wenn sich der Bedarf ändert: Darum geht es in unserem Artikel über Festpreis und Abrechnung nach Aufwand. Und warum ein Preis aus addierten Schätzungen so oft überschritten wird: Darum geht es in unserem Artikel über Budgetüberschreitungen.
Unser Leitfaden zeichnet die Geschichte des Wasserfallmodells ausführlich nach und zeigt, was die Begründer der Agilität darüber sagen, was aus ihr geworden ist.
Möchten Sie eine Software entwickeln lassen, oder haben Sie ein Tool, das mit Ihrem Geschäft nicht mehr mithält? Sprechen wir darüber?
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.
App entwickeln lassen: Mit welchem Budget rechnen? Der Betrag allein reicht nicht: Setzen Sie auf ein Ziel statt auf eine Liste, mit Nutzern ab dem ersten Monat.
Was ist ein MVP in der Softwareentwicklung? Nicht die Version 1 einer Software, sondern der kleinste Test, der zeigt, ob sich die Entwicklung einer Idee lohnt. Und was danach kommt.