Wie entwickelt man iterativ und inkrementell – und was bedeutet das eigentlich?
Diese Fragen beantwortete Lesmes López in einem Meetup am 5. April. Zu Beginn verglich er ein Projekt mit einem riesigen Elefanten – und machte deutlich, dass der klassische Impuls oft darin besteht, dieses große Vorhaben in seiner Gesamtheit „auf einmal zu bewältigen“.
Iterative Methodik: „Slicing the elephant“
Ein solches Vorhaben wirkt schnell überwältigend. Genau deshalb liegt der Schlüssel laut López im sogenannten „Slicing the elephant“: Das Projekt wird in kleine, wertstiftende Teile zerlegt.
Wichtig ist dabei nicht nur die Aufteilung, sondern dass jede gelieferte „Scheibe“ echten Nutzen für den Anwender erzeugt. Ziel ist ein Ansatz, der kontinuierlich Wert liefert und gleichzeitig die Produktivität des Entwicklungsprozesses optimiert.
Zusammenarbeit im Team
Das Erste und Fundamentale ist die Zusammenarbeit im Team. Jedes Teammitglied kann eine unterschiedliche Sicht darauf haben, wie das Projekt umgesetzt werden soll oder welche Phase wichtiger ist. Ohne ein engagiertes und abgestimmtes Team kann Pragmatismus und Agilität verloren gehen.
„Alle Teammitglieder sollten so früh wie möglich und so intensiv wie möglich in die Konzeption des Projekts eingebunden werden – von der Inception und Ausarbeitung bis hin zum Aufbau und Deployment“, erklärte López.
Um diese Vereinheitlichung zu erreichen, ist die Erstellung einer User Story entscheidend. Diese definierte er als etwas, das wir erklären können und das von allen Teammitgliedern einheitlich verstanden wird: eine gemeinsame Vision.
Die Kernpunkte dieser User Story sind Conversation, Confirmation und Card.
- Conversation ist der wichtigste Teil, in dem jeder seine individuelle Idee erklärt.
- Confirmation bedeutet, alle Versionen zusammenzuführen und zu einer einzigen Form zu gestalten.
- Card besteht darin, diese Idee festzuhalten, um sie als Referenz über das gesamte Projekt hinweg zu nutzen.
Unterschied zwischen Zerlegen und Slicing
Im iterativ-inkrementellen Ansatz ist ein zentrales Konzept der Unterschied zwischen „Zerlegen“ und „Slicing“.
Zerlegen bedeutet, Teile eines Projekts isoliert zu lösen. Ein möglicher Nachteil ist jedoch, dass beim späteren Zusammenfügen die Verbindung fehlt und die Usability nicht ausreichend unterstützt wird.
Deshalb ist es laut López sinnvoller, das Projekt in vertikalen Slices anzugehen. Das bedeutet, dass jede Lieferung alle Komponenten eines Services enthält, sodass ein echtes Produkt getestet werden kann und der Nutzer es bereits verwenden kann. Auf dieser Grundlage können in der nächsten Lieferung Funktionen ergänzt oder entfernt werden – basierend auf echter Interaktion zwischen Nutzern und Produkt.
User Story Mapping: die Projektreise definieren
Um eine präzisere Definition der iterativen und inkrementellen Entwicklung zu geben, beschrieb der ADM beide Konzepte getrennt:
„Inkrementell bedeutet, dass wir eine Funktionalität aus der Architektur nehmen, sie fertigstellen und ein Release machen. Danach erstellen wir ein weiteres Increment für eine andere Funktionalität und machen wieder ein Release – und so weiter, bis alle Funktionen einzeln aufgebaut wurden.“
Das iterative Konzept hingegen „geht davon aus, dass wir eine Basis aller Funktionalitäten erstellt haben und diese iterieren und verbessern“. Jede dieser Iterationen entspricht einem Release.
Beim iterativ-inkrementellen Ansatz „mischen wir beide Konzepte, sodass in jedem Release die Funktionalitäten in verschiedenen Bereichen weiterentwickelt werden – abhängig davon, was für den Nutzer echten Wert liefert“. Das bedeutet, dass Funktionen je nach realem Nutzerfeedback iterativ weiterentwickelt und inkrementell erweitert werden.
„Durch schnelle und kontinuierliche Lieferungen lernen wir wirklich, was der Nutzer braucht und wie wir es am besten liefern können, um in jeder Iteration Wert hinzuzufügen.“
Lesmes López - Agile Delivery Manager, Codurance
Sobald Zweck und Methodik klar sind, geht es weiter zu spezifischeren Werkzeugen. López stellte User Story Mapping (USM) vor, ein visuelles Tool, das Entwicklungsteams dabei hilft, die Reise des Projekts anhand der bestmöglichen User Experience zu definieren.
Er betonte, dass der wichtigste Teil des USM das Backbone ist, da es den narrativen Ablauf der User Journeys beschreibt.
„Sobald wir das Backbone identifiziert haben, also die Aufgaben, die definieren, was der Nutzer braucht, identifizieren wir darunter, wie diese Aufgabe umgesetzt wird“, erklärte er.
Das USM besteht somit aus dem Backbone, dem Working Skeleton – einer ersten Release, die alle minimal notwendigen Teile enthält, um den Nutzerfluss zu vervollständigen – und den darauffolgenden Releases, die auf den gewünschten Funktionen basieren. Dabei wird stets priorisiert, was echten Nutzerwert liefert.
Basierend auf einem Schema von Jocelyn Goldfein betonte López die Bedeutung, zu berücksichtigen, dass sich Release-Prozesse je nach Technologie und Geschäftsmodell unterscheiden.
Bei Web- oder Cloud-Services können Releases deutlich schneller erfolgen als bei On-Premise-Produkten.
Dieses Modell ermöglicht auch die Bewertung der Fehlerkosten. „Das Ausrollen einer neuen App-Version, die Nutzer herunterladen und die falsch ist, hat einen größeren Impact als ein Fehler auf einer Website, da wir diesen schnell korrigieren können, ohne große Auswirkungen auf die Nutzer“, erklärte er.
In solchen Szenarien – insbesondere in Organisationen mit komplexen Architekturen oder Legacy-Systemen – ist es entscheidend, Strategien zu nutzen, die eine schrittweise und kontrollierte Weiterentwicklung ermöglichen. Dies ist besonders relevant, wenn es darum geht, ein Legacy-System zu modernisieren, ohne den Wertfluss des Geschäfts zu gefährden.
Deployment-Strategien
Er beendete seinen Vortrag mit einer Reflexion über Deployment und Release und betonte, dass die Entkopplung dieser beiden Prozesse mehrere Vorteile bietet.
Dazu gehört die Möglichkeit zu überprüfen, ob die Pipeline korrekt funktioniert und keine Abhängigkeiten beeinflusst werden. Außerdem wird das Risiko negativer Auswirkungen auf den Kunden reduziert, da Releases erst erfolgen, wenn alles getestet wurde.
Er empfahl zwei zentrale Tools:
- Dark Launching, das es ermöglicht, Releases nur für einen Teil der Nutzer auszurollen
- Feature Flags, mit denen Funktionen gezielt aktiviert oder deaktiviert werden können
Nach der Präsentation folgte eine Kata-Übung zur praktischen Anwendung des Gelernten. Die Teilnehmenden arbeiteten in Gruppen von zwei bis drei Personen und entwickelten auf Basis eines hypothetischen Falls ein User Story Mapping. Anschließend präsentierten sie ihre Ideen und es entstand ein intensiver Wissensaustausch. Schließlich setzten sie das Modell in einer ersten Release um, die den anderen Gruppen vorgestellt wurde.
Bibliografie:
Fidelity - The Lost Dimensión of the Iron Triangle
User Story Mapping
