Was ist der Unterschied zwischen iterativer und inkrementeller Entwicklung?
In meinen Schulungen stelle ich häufig fest, dass die Teilnehmer iterative und inkrementelle Entwicklung (IID) verwechseln. Ziel dieses Artikels ist es, ein Verständnis für die Beziehung zwischen inkrementeller und iterativer Entwicklung zu vermitteln.
Ich beginne mit einem Vergleich von Wasserfall- und agilen Ansätzen, am Beispiel der Bereitstellung einer Zahlungs-App. Ein passendes Mini-Webinar zu diesen Vorgehensweisen ist ebenfalls enthalten. Im zweiten Teil dieses Artikels positioniere ich Wasserfall und Agile in einer Matrix, die das Zusammenspiel von inkrementeller und iterativer Entwicklung zeigt, und erkläre alle vier Quadranten dieser Matrix.
Agile vs. Wasserfall: Die Entwicklung einer Zahlungs-App
Der Wasserfall-Ansatz
Wird diese Beispiel-App nach dem traditionellen Wasserfallmodell entwickelt, sind in Abbildung 1 die folgenden Schritte zu beobachten.
Kostenlos freischalten
Erstellen Sie ein kostenloses Konto, um diesen Beitrag zu Ende zu lesen und Teil einer Community zukunftsorientierter Führungskräfte zu werden, die Tools, Leitfäden und Insights für den Erfolg im Zeitalter der KI freischaltet.
Have an account? Log In
Abbildung 1: Dieses Diagramm zeigt einen typischen Wasserfall-Lebenszyklus am Beispiel der Auslieferung einer App.
Projektinitiierung
Alles beginnt mit einem Projektsponsor aus der Marketingabteilung, der die nötigen Mittel für diese App bereitstellen konnte. Er ging davon aus, dass die App die Kundentreue und den Zufluss neuer Kunden verbessern wird. Er hatte drei Hauptfunktionsgruppen vor Augen.
Sobald das Projekt genehmigt ist, wird ein Projektmanager bestimmt und ein Projektteam gebildet. Nach vielen Diskussionen und Anforderungsworkshops einigt man sich darauf, eine Zahlungs-App mit 250 Funktionen zu liefern. Alle diese Features werden in einem umfangreichen und sehr detaillierten Lastenheft festgehalten und vom Projektsponsor und dem Kundenvertreter (sowie weiteren wichtigen Stakeholdern) unterzeichnet.
Projekt-Designphase
Im nächsten Schritt übersetzt das Projektteam die Anforderungen in ein Design für die App. Der Architekt prüft das Design anhand der Designprinzipien. Er kontrolliert, ob alle benötigten Datenattribute auch im Backend-System vorhanden sind.
Nun sind bereits zwei Monate vergangen und der Kunde hat noch nichts Funktionierendes gesehen, lediglich einige Fortschrittsberichte. Und diese Fortschrittsberichte beinhalten wahrscheinlich eine Art „Wassermelonen“-Berichte, sodass der Kunde eigentlich keinerlei Ahnung hat, ob das Projekt im Zeitplan liegt oder nicht.
Projektentwicklungsphase
Die Entwicklung der App dauert sechs Monate, und wenn das erledigt ist, wird der Kundenvertreter gebeten, Leute für den User Acceptance Test bereitzustellen. Beim Testen stellt sich heraus, dass mehrere Funktionen nicht funktionieren.
Das Projektteam versteht nicht warum. Es wurde genau das umgesetzt, was im Lastenheft stand. Dies führt zu vielen Diskussionen, Nacharbeiten und Verzögerungen und die Kunden sind mit den Ergebnissen unzufrieden. Betrachtet man das Endergebnis, fällt vielleicht außerdem auf, dass viele der entwickelten Anforderungen vom Kunden gar nicht oder kaum genutzt werden.
Es könnte sogar noch schlimmer kommen. Angenommen, die Entwicklung der App dauert 1,5 Jahre und eine andere Bank liefert eine Zahlungs-App, während ihr Projekt gerade zur Hälfte fertig ist. Was würden Sie in diesem Moment tun? Hätte ihr eigenes App-Projekt dann überhaupt noch eine tragfähige Business-Case-Grundlage?
Ein Blick auf Abbildung 1 zeigt, dass beim Wasserfall-Modell der Umfang und die zugrunde liegenden Qualitätskriterien mit einer einzigen Lieferung festgelegt werden. Alle Schritte werden einmalig für das gesamte Projekt durchlaufen, und das Management konzentriert sich auf Kosten und Zeit. Wert wird für den Kunden erst nach der Bereitstellung der kompletten App geliefert.
Der Agile Ansatz
Entwickeln wir die App mit einem agilen Projektmanagement-Ansatz, ergibt sich folgendes Muster:
- Das Entwicklungsteam erklärt, dass es bereits in der ersten Iteration die beiden vom Product Owner priorisierten Features liefern kann.
- Alle drei Wochen (Sprint, Iteration oder Timebox) liefert das Projektteam ein Produktinkrement aus.
- Nach den ersten Lieferungen beziehungsweise Inkrementen sieht man einen Kunden, der Vertrauen in das Projekt entwickelt. Er besitzt bereits eine funktionierende App und weiß, dass noch nicht alle Funktionen vorhanden sind, aber die verfügbaren Features funktionieren.
Nach Veröffentlichung der jüngsten Version und der verfügbaren Funktionen erwähnt der Kunde ein völlig neues Feature. Eines, das zu Beginn des Projekts noch niemand bedacht hatte, das dem Kunden aber einen echten Produktivitätsgewinn bringt.
Nach jedem weiteren Inkrement führen Kundenrückmeldungen zu neuen funktionalen Möglichkeiten (die vorher nicht auf der Liste standen) oder zur Anpassung potenzieller Features. Das Produkt wird immer ausgereifter. Mit jedem Inkrement erhält der Kunde eine neue Version und ist zufriedener.
Abbildung 2: Das Diagramm zeigt den Agile-Entwicklungszyklus am Beispiel der Auslieferung einer App.
Wenn wir uns Abbildung 2 ansehen, erkennen wir einen stetigen Lieferfluss innerhalb einer festen Dauer unter Verwendung eines festen agilen Teams (dies sind Fixkosten). Der Umfang und die zugrunde liegenden Qualitätskriterien sind flexibel (dynamisch) mit häufigen, kleinen Releases (den Inkrementen).
Alle Schritte, die zur Entwicklung eines Features oder User Story notwendig sind, werden wiederholt durchgeführt (was den Prozess iterativ macht), bis die geforderte Qualität erreicht ist. Das Management legt den Fokus auf die Lieferung von Kundenwert. Die Wertschöpfung für den Kunden findet nach jedem Deployment eines Inkrements statt.
Wasserfall vs. Agile: Lieferungsergebnisse
Wenn wir die beiden Produkte aus dem Wasserfall- und dem agilen Softwareentwicklungsansatz genauer betrachten, sehen wir ein Produkt mit 250 Features und einen nicht so zufriedenen Kunden sowie ein Produkt mit nur 150 Features und einen sehr zufriedenen Kunden (siehe Abbildung 3).
Abbildung 3: Das Diagramm vergleicht Unterschiede in Zeit, Anzahl der Funktionen und Kundenzufriedenheit zwischen Wasserfall- und agilen Ansätzen.
Und wenn wir noch detaillierter auf das durch den agilen Ansatz gelieferte Produkt schauen, sehen wir nur eine Teilmenge von 100 Funktionen aus der ursprünglichen Liste und 50 Funktionen, die neu oder angepasst sind. Das entspricht einigen wichtigen Prinzipien des Agilen Manifests, darunter:
- Einfachheit, also die Kunst, die Menge nicht erledigter Arbeit zu maximieren: nur 150 Features statt 250 Features
- Willkommen heißende, sich ändernde Anforderungen, auch in späteren Entwicklungsphasen: Anpassung an Kundenfeedback nach jeder Iteration und jedem Inkrement
Agile Entwicklungsprozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden (es wurden 50 neue oder angepasste Features geliefert). Dadurch ist der Kunde sehr zufrieden. Die höchste Priorität des Teams ist es, den Kunden durch frühe und kontinuierliche Lieferung wertvoller Softwaresysteme zufriedenzustellen.
Mini-Webinar: Wasserfall vs. Agile-Lieferung
Hier gibt es ein kurzes Webinar mit weiteren Informationen zu den Unterschieden zwischen Wasserfall- und agiler Lieferung.
Unterschiede zwischen iterativer und inkrementeller Entwicklung
Nachdem ich die Unterschiede zwischen einem Wasserfall- und einem agilen Ansatz am Beispiel der Erstellung einer Zahlungs-App erklärt habe, werde ich nun Wasserfall und Agile in einer Matrix einordnen, die iterative und inkrementelle Entwicklung vergleicht.
Als letzten Schritt erläutere ich das Minimum Viable Product (MVP) und das Minimum Marketable Product (MMP) und zeige, wo diese in die unterschiedlichen Ansätze und eine Story Map passen. Dazu gibt es noch ein Mini-Webinar.
Matrix für iterative und inkrementelle Entwicklung
Wie bereits erwähnt, fällt mir oft auf, dass Studierende iterative und inkrementelle Entwicklung verwechseln. In Abbildung 4 sind vier Quadranten dargestellt, die sich aus einer horizontalen Achse (inkrementell oder nicht) und einer vertikalen Achse (iterativ oder nicht) ergeben. Eine sehr einfache Version dieses Schaubilds finden Sie in diesem YouTube-Video.
Abbildung 4: Diese Matrix zeigt verschiedene Entwicklungsansätze und ob die Teammitglieder, die diesen Ansätzen folgen, iterieren und/oder in Inkrementen arbeiten müssen.
Linker unterer Quadrant
Im linken unteren Eck sehen wir den Ansatz ohne Iterationen und ohne Inkremente. Das ist der Wasserfall-Ansatz. Alle Tätigkeiten (Design, Analyse, Entwicklung, Test und Deployment) werden einmal für das Gesamtprojekt ausgeführt.
Hier gibt es eine einzige Lieferung des Endprodukts auf Basis eines festen Umfangs. Der Kundennutzen wird erst nach der Übergabe des Endprodukts realisiert. Eines der Hauptziele dieses Ansatzes ist das Kostenmanagement.
Rechter unterer Quadrant
Im unteren rechten Quadranten sehen wir einen inkrementellen Ansatz ohne Iterationen. Dies ist eine gestufte oder inkrementelle Auslieferung kleinerer Teile des Produkts. Alle Aktivitäten für eine bestimmte Stufe (Design, Analyse, Entwicklung, Test und Bereitstellung) werden einmalig durchgeführt.
Innerhalb einer bestimmten Stufe ist der Umfang festgelegt, aber das Gesamtprodukt basiert auf einem dynamischeren oder flexibleren Umfang. Kundennutzen kann nach jeder Lieferung des Produkts erreicht werden. Eines der Hauptziele dieses Ansatzes ist die Geschwindigkeit der Auslieferung.
Oberer linker Quadrant
Im oberen linken Quadranten sehen wir einen spiralförmigen oder iterativen Ansatz ohne Inkremente. Dies ist eine einmalige Lieferung, bei der das Endprodukt durch mehrere Iterationen erstellt wird. Ein gutes Beispiel für diesen Ansatz ist Design Thinking. In der Grafik sehen Sie eine Abfolge der Aktivitäten Rahmen, Analyse, Ideenfindung, Realisierung und Reflexion.
Diese Abfolge wird wiederholt oder iterativ durchgeführt, wobei man sich in jeder Iteration dem endgültigen, korrekten oder gewünschten Produkt nähert. In vielen Fällen ist dieses Endprodukt ein Prototyp oder Modell. Bei diesem spiralförmigen Ansatz haben wir einen dynamischen oder flexiblen Umfang. Kundennutzen kann erst nach der Auslieferung des Endprodukts realisiert werden. Ein zentrales Ziel dieses Ansatzes ist die Korrektheit der Lösung.
Oberer rechter Quadrant
Im oberen rechten Quadranten sehen wir den agilen Ansatz, der mit Inkrementen und einer iterativen Methode arbeitet. Scrum ist ein gutes Beispiel für diesen Ansatz.
Am Ende jedes Inkrements, oft Sprint oder Timebox genannt, wird ein Inkrement des Produkts geliefert. Dieses Inkrement ist das Ergebnis vieler Iterationen, um kleine, aber korrekte Teile des Produkts zu entwickeln, die oft als User Stories oder Backlog Items bezeichnet werden. Das gesamte iterative Projekt wird Stück für Stück ausgeliefert.
Bei diesem agilen Ansatz gibt es einen dynamischen oder flexiblen Umfang. Kundennutzen kann nach jeder Lieferung des Produkts erreicht werden. Ein zentrales Ziel dieses Ansatzes ist die Generierung von Kundennutzen durch häufige Auslieferungen und Nutzerfeedback.
MVP oder MMP?
In Abbildung 4 finden Sie auch die Akronyme MVP und MMP. MVP steht für Minimum Viable Product und ist eine Version eines neuen Produkts oder einer neuen Dienstleistung, mit der ein Team das maximale Maß an Erkenntnissen über Kunden gewinnen und die Validierung mit minimalem Aufwand erhalten kann. Das MVP für den Dropbox-Service war ein einfacher Film. Das bedeutet, dass das P in MVP ein komplett anderes Produkt sein kann als das, was schließlich als Endprodukt herauskommt.
Ein Beispiel zur Veranschaulichung von MVP und MMP
Ich benutze oft das folgende Beispiel für ein neues Finanzprodukt. Ein begeisterter Vertriebsleiter hat eine großartige Idee für ein neues Finanzprodukt. Er glaubt, dass sie mindestens 100.000 dieser Produkte verkaufen können.
Gemeinsam mit einigen Finanzexperten entwerfen sie das Produkt innerhalb weniger Monate. Ein Entwicklungsteam wird beauftragt, und es dauert 4 Monate, bis das Produkt entwickelt ist. Parallel dazu werden Werbebroschüren erstellt und das Produkt mit einem großen Event eingeführt.
Leider kaufen nur wenige Menschen das Produkt. Wenn wir dem MVP-Ansatz folgen, könnten wir die Annahme treffen, dass 10 % ihrer Webnutzer an diesem Produkt interessiert sind. Dann würden wir ein MVP entwickeln, um diese Hypothese zu testen.
In diesem Fall könnte das MVP ein einfacher Button auf der Startseite sein. Wenn Sie klicken, erhalten Sie einen Bildschirm mit einer Nachricht zu diesem neuen Produkt und der Möglichkeit, Ihre E-Mail-Adresse einzutragen, falls Sie interessiert sind. Angenommen, weniger als 1 % der Besucher klickten auf den Button — das Produkt würde nicht weiterentwickelt und das Unternehmen hätte viele knappe Ressourcen eingespart.
Wenn wir uns Abbildung 4 genauer ansehen, sehen wir die potenzielle Nutzung von MVPs in allen Quadranten. Beim Wasserfall-Ansatz könnten Sie ein MVP in der ersten Software-Design-Phase erstellen, um zu prüfen, ob das Projekt einen geschäftlichen Nutzen stiftet.
Das Gleiche kann in der ersten Phase des ersten Inkrements bei gestufter Auslieferung getan werden. In manchen Fällen könnte das Ergebnis Ihres Design-Thinking-Ansatzes ein MVP sein. Das MVP kann auch zu Beginn eines agilen Ansatzes hilfreich sein.
Viele sehen das erste fertiggestellte Produkt am Ende Ihrer gestuften Auslieferung als das MVP an. Das kann so sein, aber in den meisten Fällen handelt es sich dabei nicht um ein MVP, sondern um ein MMP. MMP oder Minimum Marketable Product ist das kleinste Produkt, das Ihrem Kunden einen Nutzen bringen kann.
Wie sieht agile Auslieferung aus?
Da nun klar ist, dass inkrementelle und iterative Modelle nicht dasselbe sind und wir den Einsatz von MVP und MMP verstehen, können wir im Detail betrachten, wie inkrementelle und iterative Auslieferung aussehen.
Sie haben wahrscheinlich schon Jeff Pattons berühmtes Beispiel der Mona Lisa gesehen, bei dem das Gemälde Stück für Stück erstellt wird (gestufte Auslieferung). Eine andere Möglichkeit ist, mit dem ersten Inkrement zu beginnen, in dem nur eine grobe Skizze erstellt wird, und mit jeder neuen Iteration kommen mehr Details zur Skizze hinzu, bis am Ende das fertige Gemälde entsteht (inkrementelle und iterative oder agile Auslieferung).
In der ersten Situation muss man bereits eine detaillierte Vorstellung vom Endprodukt haben, während man in der zweiten Situation nur einen groben Umriss benötigt, da Änderungen viel leichter vorzunehmen sind. Wenn wir uns Abbildung 5 ansehen, sehen wir eine Story Map für ein neues Produkt namens ABC.
Abbildung 5: Eine beispielhafte Story Map für ein bestimmtes Produkt.
Der Product Owner stellte sich sieben Funktionen für dieses Produkt vor. Die ersten vier Funktionen sind unverzichtbar. Funktion 5 und 6 sind Soll-Anforderungen und die letzte Funktion ist eine Kann-Anforderung. Viele würden dies als MoSCoW-Priorisierung bezeichnen (Must-haves, Should-haves, Could-haves und Won’t-haves).
Jede Funktion kann für sich genommen in kleinere Teile unterteilt werden. In der Abbildung sieht man Funktionen oder User Stories mit Muss-, Soll- und Kann-Anforderungen. Eine Funktion kann unverzichtbar sein, aber das bedeutet nicht, dass alle zugrundeliegenden User Stories ebenfalls Muss-Anforderungen sind. Oder eine Funktion ist eine Soll-Anforderung, aber wenn man diese Funktion implementiert, sind manche User Stories Muss-Anforderungen und andere wiederum Soll- oder Kann-Anforderungen.
Um dieses ABC-Produkt zu implementieren, sieht man fünf Inkremente oder Releases. Das erste ist das Minimum Marketable Product. Dieses MMP besteht aus den ersten beiden Muss-User-Stories von Funktion 1 sowie den ersten Muss-User-Stories von Funktion 2 und 3.
Release 2 enthält die nächsten beiden Muss-User-Stories von Funktion 1, 2 und 3 (iterative Entwicklung). Die Produktentwicklung setzt sich fort mit der Implementierung der nächsten Releases. Mit jedem Release steigt der Kundennutzen.
Nach Release 5 hört der Product Owner auf, weitere User Stories zu implementieren. Rückmeldungen des Kunden zeigten ihm, dass das ABC-Produkt „fit for purpose“ ist, und er berücksichtigt das Prinzip der Einfachheit des Agile Manifests und stellt die Entwicklung ein.
Mini-Webinar: Iterative und inkrementelle Entwicklung
Hier ist ein ausführliches Webinar zur iterativen und inkrementellen Softwareentwicklung.
Abschließende Gedanken
Ist sich Ihr Softwareentwicklungsteam über iterative und inkrementelle Entwicklung im Klaren? Wie wenden Sie sie auf Ihre agilen oder Wasserfall-Methoden an?
Teilen Sie uns Ihre Gedanken in den Kommentaren mit oder werden Sie Mitglied bei unserem DPM-Programm und diskutieren Sie mit anderen Mitgliedern in unserem exklusiven Forum!
