Inkrementeller vs. iterativer Task-Breakdown

Oftmals ist ein Task zu groß, um an einem Stück erledigt zu werden. In Things wird man in so einem Fall ein Projekt anlegen.

Das Projekt muss jetzt in mehrere Teiltasks herunter gebrochen werden. Bei der Definition der Teilaufgaben kann man nun verschiedene Strategien anwenden.

Zwei gängige Strategien sind die inkrementelle und die iterative Vorgehensweise.

Im ersten Fall bauen die Teilaufgaben Schritt für Schritt aufeinander auf. Mit Erledigung der letzten Teilaufgabe ist auch das Projekt erfolgreich abgeschlossen.

Vorteil der inkrementellen Methode ist die leichte Planbarkeit.

Nachteil ist, dass im Falle von Änderungen in den Projektzielen oder -anforderungen Teile der bereits getanen Arbeit obsolet werden können und schwer kalkulierbare Mehraufwände entstehen. Außerdem hat das Projekt erst nach dem letzten Teilschritt einen Nutzwert. Das bedeutet auch, dass möglicherweise erst sehr spät erkannt wird, dass das Ergebnis nicht den Erwartungen entspricht.

Die iterative Variante strebt an, nach jedem Teilschritt ein Ergebnis zu haben, mit dem das Projekt als abgeschlossen betrachtet werden kann. Mit jedem weiteren Teilschritt, wird der Projektumfang runder und vollständiger.

Die iterative Methode hat den Vorteil, dass nach jeder Iteration (also jedem Teilschritt) ein Ergebnis vorliegt, das benutzt werden kann. Damit wird auch sehr schnell sichtbar, ob das Ergebnis den Erwartungen entspricht. Falls nicht, kann leicht korrigiert werden. Ähnlich verhält es sich mit Änderungen bei den Anforderungen oder des Liefertermins.

Natürlich hat auch der iterative Ansatz Schattenseiten, so ist es nicht ungewöhnlich, dass bestehende Ergebnisse in späteren Iterationen wieder angefasst werden müssen.

Wie wir gesehen haben, haben beide Ansätze Vor- und Nachteile. Für die Auswahl der geeigneteren Methode ist es also wichtig, die Rahmenbedingungen eines Projekts zu kennen.

Inkrementelles Vorgehen dürfte speziell bei Projekten empfehlenswert sein, die keine großen Überraschungen erwarten lassen, weil z. B. bereits Erfahrungen mit ähnlichen Projekten vorliegen.

Iteratives Vorgehen bietet sich an, wenn Neuland beschritten werden soll. Dies ermöglicht frühzeitig Feedback zu erhalten und wenn nötig die Richtung korrigieren zu können, ohne bereits viel Aufwand getrieben zu haben.

Auch wenn Budget und Zieltermin hart limitiert sind, ist eine iterative Strategie vorzuziehen. Sie garantiert, dass man bei Erreichung eines dieser Limits ein Ergebnis vorzuweisen hat. Es mag nicht in voller Schönheit  erstrahlen, aber es wird nutzbringend sein. Eine spätere Verbesserung wäre so auch problemlos möglich.

Im Falle eines inkrementellen Ansatzes hätte man in diesem Fall kein brauchbares Ergebnis vorliegen.

Im Fall von Projektmanagement entspricht das inkrementelle Vorgehen dem klassischen Ansatz; man plant alle Aufgaben und arbeitet sie dann Stück für Stück ab. Das ermöglicht eine gute Kosten- und Terminprognose – falls nichts schief geht.

Der inkrementelle Ansatz wird im agilen Projektmanagement genutzt. Dieses ist besonders im Bereich der Softwareentwicklung inzwischen recht verbreitet.

Natürlich lässt sich dieses Vorgehen auch im kleineren Rahmen sehr gut nutzen. Ein Beispiel kann das Schreiben eines Artikels sein. Ich gehe dabei üblicherweise iterativ vor: zuerst schreibe ich eine Version herunter, dann überarbeite ich diese. Die Überarbeitung kann sich nun so oft wiederholen, bis ich absolut nicht mehr weiß, was ich noch verbessern könnte, oder eben eine deadline erreicht ist.

Bei genauerem Hinsehen stellt man fest, dass wohl beide Ansätze nie „sortenrein“ angewendet werden. Im Beispiel des zu schreibenden Artikels wird man auch inkrementelle Tasks haben; das posten des Artikels geschieht eben idealerweise nur einmal am Ende des Prozesses.

Entsprechend hat man bei inkrementellem Vorgehen oft auch iterative Aspekte, etwa beim typischen Review-Zyklus (z.B. schreiben, reviewen, korrigieren, reviewen, …).

2 Responses to Inkrementeller vs. iterativer Task-Breakdown

  1. Peter Diefenbach sagt:

    Hallo Stefan,

    ich erinnere mich an Scrum-Foren in Linked-In, in denen der Unterschied zwischen iterativ und inkrementell heiß, aber mit wenig Sachverstand diskutiert wurde. Dein Beitrag (und die Links auf Wikipedia) bringt es gut auf den Punkt.

    Nur noch eine Anmerkung von mir zu Deinem letzten Absatz:

    Entsprechend hat man bei inkrementellem Vorgehen oft auch iterative Aspekte, etwa beim typischen Review-Zyklus (z.B. schreiben, reviewen, korrigieren, reviewen, …).

    Es kommt immer auf die Granularität an, die ich gerade betrachte. In Scrum werde ich für jedes Feature wieder inkrementell alle Schritte durchlaufen, die ich in der Softwareentwicklung nun mal brauche. (Und weil ich das so oft so ählich für immer neue Features mache, lerne ich für den Prozess dazu und werde iterativ den Prozess verbessern.) Je nachdem, wie stark ich in den Prozess zoome, sehe ich also wahlweise Inkremente oder Iterationen.

    Gruß
    Peter

    • sbraun58 sagt:

      Hallo Peter,
      danke für deine Anmerkung! Ich kann mich auch an viele Diskussionen zu diesem Thema erinnern. Ist so ähnlich wie mit effektiv und effizient🙂
      Mit der Granularität der Betrachtung triffst du die Sache gut. Da war ich zu unpräzise.
      Gruß,
      Stefan

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: