Projekt

Was ist eigentlich ... iteratives Arbeiten?

Haben Sie heute schon einen Kaffee getrunken? Dann haben Sie vermutlich ein iterativ entwickeltes Produkt benutzt, vielleicht eines der Nespresso-Modelle EN166, EN266, EN520 oder EN550 - je nachdem in welcher Iteration Sie Ihre Maschine gekauft haben. Ob Kaffeemaschine, Smartphone, Computer, Fotoapparat oder Software: Sehr viele Produkte werden iterativ entwickelt, d.h. es wird eine vorläufige Version vorgestellt, anschließend sofort hinterfragt und auf Basis des Feedbacks weiter verbessert, bis das gewünschte Ergebnis erreicht ist.


Oder wissenschaftlich ausgedrückt:
„Iteration (von lat. iterare ,wiederholen‘) beschreibt allgemein einen Prozess mehrfachen Wiederholens gleicher oder ähnlicher Handlungen zur Annäherung an eine Lösung oder ein bestimmtes Ziel.“ (Quelle: Wikipedia)

Spannend an der iterativen Herangehensweise ist, dass sich die Ergebnisdefinition (in unserem Beispiel "die perfekte Kapsel-Kaffeemaschine") im Projektverlauf jederzeit ändern kann und ändern darf!

Iterativ: vom Vorläufigen zum Perfekten

Auch in der agilen Softwareentwicklung ist iteratives Arbeiten eine Grundvoraussetzung. Alle Projektbeteiligten akzeptieren, dass es unwahrscheinlich ist, das Produkt gleich beim ersten Versuch perfekt abzuliefern. Stattdessen wird ein Prototyp entwickelt und Feedback eingeholt, das sofort in eine Nachfolgeversion einfließt. Diese Feedbackschleifen (Iterationen) werden so oft wiederholt, bis der Auftraggeber zufrieden ist.

Wichtig: Es wird nicht einfach willkürlich an irgendwelchen Ecken "herumverbessert", sondern jede Iteration geht zurück zum Start, d.h. hinterfragt in einer Analyse den aktuellen Status Quo, macht sich erneut Überlegungen zum Design und führt nach der Implementierung wieder Tests durch. Im klassischen Wasserfallmodell hingegen wird das komplette Projekt zuerst analysiert, dann designed, implementiert und erst zum Schluss getestet.

Der Nachteil: Ein isolierter iterativer Ansatz führt dazu, dass erst recht spät ein marktfähiges Produkt vorliegt. Also vielleicht doch lieber inkrementell?

Inkrementell: vom Kleinen zum Großen

In inkrementellen Prozessen wird nicht am Gesamtsystem gearbeitet, sondern festgelegte Teilbereiche („Inkremente“) peu à peu fertiggestellt. So erhält der Auftraggeber sehr früh einzelne voll funktionsfähige Bausteine, allerdings fehlt im Gegensatz zur iterativen Arbeitsweise der Blick für „das große Ganze“ - Sie sehen den Wald vor lauter Bäumen nicht mehr.

Beispiel Straßenbau: Stellen Sie sich vor, Sie erhalten den Auftrag, eine neue Straße durch unwegsames Gelände zu bauen. Arbeiten Sie iterativ, roden Sie zuerst einen schmalen Trampelpfad für Fußgänger frei und testen die Wegeführung. Vielleicht korrigieren Sie noch einzelne Wegabschnitte, bevor Sie anfangen die Straße zu verbreitern, zu teeren, Leitplanken anzubringen, eine Ampelanlage zu bauen usw. Jede Straßenversion ist ein Stück ausgereifter, aber grundsätzlich kommen Sie bereits ab der ersten Iteration von A nach B.

Entscheiden Sie sich hingegen für eine inkrementelle Arbeitsweise, bauen Sie die Straße abschnittsweise – Sie kennen das vom klassischen Autobahnbau. Zwar ist jeder Teilbereich für sich früh bis ins kleinste Detail perfekt und nutzbar, aber mit dem Auto von A nach B fahren können Sie erst, wenn alle Etappen fertig sind.

Iterativ-inkrementell: Veränderung als Vorteil

Sie ahnen es bereits: Erst in Kombination entfalten beide Arbeitsweisen ihr volles Potenzial, insbesondere wenn es sich um komplexe Projekte handelt. So gegensätzlich die beiden Ansätze auf den ersten Blick wirken – sie ergänzen sich wunderbar. Scrum beispielsweise ist ein typisches iterativ-inkrementelles Framework.

Vereinfacht dargestellt wird die Gesamtaufgabe in kleinere Einheiten eingeteilt, die wiederum iterativ realisiert werden, d.h. die Teilbereiche werden basierend auf dem Feedback des Auftraggebers überarbeitet, bis sie den gewünschten Reifegrad erreicht haben. Dabei werden nicht wahllos Inkremente herausgepickt oder in einer sturen Reihenfolge abgearbeitet, sondern eine sinnvolle Priorisierung führt zu früh voll funktionsfähigen Key-Features, die ggf. sogar als marktfähige Prototypen eingesetzt werden können.

Tipp: Falls Sie noch mehr über den Unterschied zwischen inkrementell und iterativ wissen möchten - eines der anschaulichsten und meistzitierten Beispiele ist der „Mona-Lisa-Vergleich“ von Jeff Patton.

Und was bringt iterativ-inkrementelle Softwareentwicklung?

  • Höhere Kundenzufriedenheit: Durch die kontinuierliche Einbeziehung des Auftraggebers erhält der Kunde exakt das, was er benötigt und wann er es benötigt. Er arbeitet von Stunde Null an intensiv mit und versteht so auch die Komplexität des Projekts und die Qualität des Produkts besser. Durch die Kombination erhält der Auftraggeber sehr schnell sowohl einen ersten Eindruck vom kompletten Ergebnis als auch einzelne fertig ausgearbeitete Teilbereiche, die genutzt (oder vermarktet) werden können. Anhand des Straßenbeispiels: Von Beginn an wird am gesamten Straßenverlauf gearbeitet, aber vielleicht wird eine von vier geplanten Fahrbahnspuren schon zu einem frühen Zeitpunkt so weit ausgebaut, dass sie von Autos befahren werden kann. Die Erkenntnisse aus der Nutzung dieser Spur fließen dann wiederum in die weitere Bauplanung ein.
  • Geringere Kosten: Der Weg zum Ziel ist direkter, es wird nur entwickelt, was wirklich benötigt wird. Anforderungen, die sich als überflüssig oder unbrauchbar herausstellen, werden früh entdeckt und ggf. durch wichtigere, wertvollere Ideen ersetzt. Auf das Straßenbaubeispiel übertragen: Vielleicht stellt der Auftraggeber bei der Nutzung der ersten Spur fest, dass der Verkehr weniger dicht ist als geplant und dass statt einer vierspurigen Straße zwei Spuren völlig ausreichen (und das gesparte Geld besser in ein Stauwarnsystem investiert wird.)
  • Kontinuierliches Lernen: Zwar wird in jeder Art von Prozess gelernt – egal ob Wasserfall oder iterativ. Beim iterativen Vorgehen kommt das Gelernte aber den noch anstehenden Entscheidungen zu Gute. Beim Wasserfall werden bereits zu Projektbeginn die Weichen gestellt, d.h. die im Projektverlauf gewonnenen Erkenntnisse können nicht mehr mit einfließen. Das verursacht nicht nur mehr Arbeit und Kosten, sondern auch Frust.
  • Bessere Planbarkeit: Grundsätzlich wird nur das geschätzt, was zum jeweiligen Zeitpunkt Sinn macht. Während des Projekts wird die Geschwindigkeit des Entwicklungsteams gemessen, so dass die Schätzungen für künftige Projektabschnitte immer zuverlässiger werden.

Auch Scrum betrachtet die Unsicherheiten zu Projektbeginn nicht als Nachteil, sondern nutzt Veränderlichkeit aus, um innovative, an den Kundenbedarf angepasste Produkte zu schaffen. Was der iterativ-inkrementelle Ansatz mit Scrum-Sprints zu tun hat, werden wir demnächst in einem eigenen Artikel ausführlich vorstellen.

So, und jetzt hole ich mir einen Kaffee aus meiner (fast) perfekten Kaffeemaschine ...

Bildnachweis: anyaivanova / 123RF

Weiterlesen
Markiert in:

Was ist eigentlich ... eine Retrospektive?

Menschen machen Fehler. Auch Softwareentwickler. Und je komplexer das Projekt, desto höher die Fehlerquote. Die gute Nachricht: Wir können aus Fehlern lernen. Klar, hinterher ist man immer schlauer. Aber der Anglizismus „Lessons Learned“ bringt es auf den Punkt - wir müssen dieselben Fehler nicht zweimal machen. Genau deshalb ist es auch pragmatisch, mit der Nabelschau eines Projekts nicht bis zum Ende zu warten, sondern bereits projektbegleitend zu lernen und sich kontinuierlich zu verbessern. In agilen Projekten sind die sogenannten Retrospektiven Pflichtbestandteil des Projektablaufs, um Qualität und Effizienz zu erhöhen und das Team zu stärken. Aber wie läuft das genau?

Weiterlesen

Gut geschätzt ist halb gewonnen | Aufwandsschätzung Teil 1

Programmierer sind die schlechtesten Schätzer der Welt. Behauptet zumindest Anders Abel in seinem Blog „Passion for Coding“. Der schwedische Software-Consultant geht noch weiter und präsentiert eine mathematische Formel, um die tatsächlich benötigte Zeit zu ermitteln: Man nehme die geschätzte Zeit des Entwicklers, multipliziere sie mit Pi und rechne sie in die nächsthöhere Zeiteinheit um. Schätzt der Entwickler also einen Manntag, wird er – nach Abel – 3,14 Wochen benötigen. Sicherlich eine provokant formulierte These, nichtsdestotrotz ist das Thema Aufwandsschätzung ein Dauerbrenner in der Softwareentwicklung.

Weiterlesen
Markiert in:

Was ist eigentlich ... ein Projekt?

Wir starten unsere Teamprove-Glossar-Reihe "Was ist eigentlich ...?" mit einer ganz grundlegenden Frage: Was ist ein Projekt genau? Rund 3.000 Mal täglich wird der Suchbegriff „Definition Projekt“ bei Google eingegeben - die Frage scheint also viele zu beschäftigen. Und das ist auch gut so, schließlich erfordert jedes Projekt ein Projektmanagement und bindet damit Ressourcen im Unternehmen. Zeit, Mitarbeiter und nicht zuletzt Geld. Es macht also durchaus Sinn, Aufgaben von echten Projekten zu unterscheiden, um nicht ständig mit Kanonen auf Spatzen zu schießen.

Weiterlesen
Markiert in: