Inkrementelles Modell

Das Inkrementelle Modell liefert ein Projekt nicht in einem einzigen Durchlauf und nicht in risikogetriebenen Zyklen wie das Spiralmodell, sondern in einer Folge funktional wachsender Ausbaustufen. Jedes Inkrement fügt dem bereits ausgelieferten, produktiv genutzten Stand eine weitere, in sich fertige Funktion hinzu. Das Produkt wächst damit sichtbar mit jeder Stufe, statt erst am Ende als Ganzes zu erscheinen.

Herkunft

Anders als bei anderen Modellen lässt sich das Inkrementelle Modell keiner einzelnen Person oder einem einzelnen Aufsatz zuordnen. Es entwickelte sich seit den späten 1970er-Jahren aus der praktischen Erfahrung großer Softwareprojekte, dass die vollständige Auslieferung eines Systems in einem einzigen Wasserfall-Durchlauf oft zu lange dauert, um frühzeitig echten Nutzen zu stiften. Wegweisend war unter anderem die Arbeit von Tom Gilb, der schrittweise, messbare Teilauslieferungen unter dem Begriff „Evolutionary Delivery“ systematisierte. In der Softwaretechnik-Lehrbuchliteratur der 1990er-Jahre etablierte sich das Inkrementelle Modell schließlich als eigenständiger Modelltyp neben Wasserfall, Spirale und Prototyping. In Teilen der Literatur wird derselbe Ansatz auch als „Evolutionäres Modell“ bezeichnet, mit demselben Kerngedanken: Jede neue Version baut auf der vorherigen auf und ist eine funktionsfähige Erweiterung von ihr.

Aufbau: wachsende Ausbaustufen

Die Planung findet einmalig und gemeinsam für das Gesamtsystem statt: Hier wird grob festgelegt, in welche funktionalen Blöcke, die Inkremente, sich das Vorhaben zerlegen lässt (meist nach Priorität oder technischer Abhängigkeit geordnet). Von dieser gemeinsamen Wurzel aus durchläuft jeder Build anschließend einen eigenen, in sich abgeschlossenen Durchlauf durch dieselben SDLC-Phasen, Analyse, Design, Entwicklung, Test und Bereitstellung – oft im Aufbau einem verkleinerten Wasserfallmodell ähnlich. Jeder ausgelieferte Build geht danach in die Wartung über, die so lange parallel zum nächsten Build weiterläuft, bis dieser den bestehenden Stand um seine eigene Funktionalität erweitert. Erst nach dem letzten geplanten Build bleibt reine, wachstumslose Wartung übrig. Anders als beim Spiralmodell wächst hier nicht der Kenntnisstand über Risiken in konzentrischen Zyklen, sondern der tatsächliche Funktionsumfang des ausgelieferten Produkts in klar abgegrenzten Schritten.

Abgrenzung zu Scrum und anderen agilen Modellen

Das Inkrementelle Modell beantwortet vor allem eine Frage: wie ausgeliefert wird, nämlich in Stücken statt auf einmal. Die Aufteilung in Inkremente steht dabei meist von Anfang an fest, häufig als Ergebnis einer vorab getroffenen Vertrags- oder Planungsentscheidung. Es definiert keine festen Rollen, keine Timeboxen und keine wiederkehrenden Formate wie Sprint-Reviews oder Retrospektiven.

Scrum und andere agile Modelle beantworten zusätzlich eine zweite Frage: wie geplant, entschieden und zusammengearbeitet wird. Rollen, Events und ein sich laufend neu priorisierendes Backlog sorgen dafür, dass sich nicht nur der ausgelieferte Umfang, sondern auch der Plan selbst durch Feedback aus jedem Zyklus verändern darf. Ein Team kann inkrementell liefern, ohne irgendeine agile Praxis anzuwenden, historisch war das sogar über viele Jahre der Normalfall in größeren Softwareprojekten.

Wann das Inkrementelle Modell passt

• Große Systeme mit langer Gesamtlaufzeit: Wenn eine vollständige Auslieferung am Ende des Projekts zu spät käme, um frühzeitig Nutzen zu stiften.
• Klar zerlegbare Funktionsumfänge: Wenn sich das Zielsystem sinnvoll in unabhängig auslieferbare Blöcke aufteilen lässt.
• Stabiles Gesamtverständnis, aber Wunsch nach früher Wertschöpfung: Wenn das große Ganze bereits feststeht, einzelne Funktionen aber so früh wie möglich im echten Betrieb ankommen sollen.

Grenzen

Das Modell steht und fällt mit einer belastbaren Vorab-Zerlegung des Gesamtsystems. Eine schlecht geschnittene Aufteilung erzeugt technische Abhängigkeiten zwischen den Inkrementen, die sich erst spät zeigen. Frühe Architekturentscheidungen sind zudem schwer revidierbar, sobald mehrere Inkremente bereits darauf aufbauen. Und weil dem Modell die institutionalisierten Feedback-Mechanismen agiler Ansätze fehlen, bleibt die Nähe zu Nutzerinnen und Nutzern zwischen den Auslieferungen oft geringer als etwa in Scrum.

Verwandte Modelle

Das Spiralmodell teilt mit dem Inkrementellen Modell den mehrfachen Durchlauf, wächst dabei aber primär im Verständnis von Risiken, nicht im ausgelieferten Funktionsumfang. Zum Wasserfallmodell besteht der größte Unterschied darin, dass ein Inkrement für sich genommen oft wie ein kleiner Wasserfall abläuft, das Gesamtprojekt aber aus mehreren solcher Durchläufe besteht statt aus nur einem.