Einleitung

Es sei unbestritten, daß die Aufgabe des Planens in einem (Software-) Projekt eine anspruchsvolle Aufgabe darstellt. Und je größer das abzuwickelnde Projekt ist, umso schwieriger und auch komplexer wird diese Aufgabe.

In einem klassischen ("Wasserfall"-) Projekt benötigt man per Definition einen vollständigen und korrekten Projekt-Plan für die gesamte Projektlaufzeit . Damit ist in der Regel ein signifikanter Aufwand zu leisten, bevor überhaupt die weiteren Arbeiten beginnen könne können.

Hat es der Planer erst einmal geschafft, einen Projektplan zu erzeugen, wird es meist schwierig diesen zu ändern: zu komplex sind ab einer gewissen Größe die gegenseitigen Abhängigkeiten von System-Teilen und auch den beteiligten Ressourcen. Eine Änderung wird in der Regel zu einem unangenehmen Domino-Effekt im Plan führen.

Man könnte sich aber auch überlegen, ob nicht Cäsar's Devise im Gallischen Krieg "teile und herrsche" (divide et impera) eine wirkungsvolle Alternative darstellt.

Im folgenden Artikel möchte ich zeigen, wie Agile Vorgehensweisen (z.B. Scrum oder auch eXtreme Programming) das Prinzip von "teile und herrsche" umsetzen und so Projekt-Planung vereinfachen helfen. Neben vereinfachter Planung kann man noch zusätzliche (positive) Seiteneffekte beobachten ...

Seitenanfang

Die Planungs-Falle

In jedem "Wasserfall"-Projekt (Analysieren - Designen - Ausführen - Abschließen) ist den Beteiligten klar, daß die Erstellung des Projekt-Plans eine sehr anspruchsvolle Aufgabe ist: sind alle Anforderungen bekannt und verstanden; sind alle Risiken identifiziert und entsprechend berücksichtigt; wo werden "Puffer" benötigt; sind die Abhängigkeiten zwischen den Aufgaben alle berücksichtigt; und vieles mehr.

Mit ansteigender Projektgröße nimmt auch Schwierigkeit und Komplexität dieser Aufgabe zu -- was jedem einleuchtet, der mit etwas Kombinatorik allein die möglichen Wechselbeziehungen zwischen den (Teil-) Arbeiten selbst plus denen zwischen den notwendigen Ressourcen überschlägt -- ganz zu schweigen von all den anderen Einflußfaktoren.

Abb. 1 zeigt ein stark vereinfachtes Bild von den Herausforderungen bei dieser Art von Vorab-Gesamt-Plan:

• "alle" Anforderungen müssen bekannt sein;
• ein detailierter Plan zeigt genau, wann was von wem erledigt werden wird;

Abb. 1: maximaler Plan -- "alles" wird bedacht und geplant;

Dazu ist natürlich noch folgendes zu bedenken:

• die Art und Weise, wie diese Anforderungen erfüllt werden, muß definiert sein;
• alle Ressourcen müssen bekannt und reserviert sein;
• Unklarheiten müssen vorab geklärt werden;

(die letzten Sätze klingen ganz nach dem Prinzip "Vor dem Ankommen wird gewarnt" aus dem sehr lehrreichen Büchlein 'Anleitung zum Unglücklichsein' von Paul Watzlawick [01]; und wenn man so manches Projekt ansieht, könnte Watzlawick durchaus recht haben ...)

Jeder wird verstehen und akzeptieren, daß eine solche Aufgabe Zeit, Mittel und wiederum Ressourcen benötigt -- und je größer das Projekt, desto mehr davon.

Das Problem: wer es endlich geschafft hat, die Planungs-Aufgabe auf der großen Fläche in Abb. 1 zu lösen, der wird wenig Begeisterung zeigen, falls der Plan geändert werden muß:

• solange mit der Ausführung noch nicht begonnen wurde, bedeutet eine Umplanung schlicht weg eine weitere Verzögerung des Projekt-Starts;
• wurden die Arbeiten allerdings schon begonnen, dann haben Änderungen in der Regel Auswirkungen auf den gesamten Restplan; das bedeutet weitreichende Absprachen und Entscheidungen auch zu weit in der Zukunft liegenden Konsequenzen;

Bei Planänderungen findet man sich oftmals wieder ganz am Anfang. Und je größer das Projekt ist, desto mehr Verständnis wird man für die umfangreichen und wiederholten Planungen finden. Manchmal fühlt man sich tatsächlich an Paul Watzlawick([01]) erinnert: "Es ist besser, hoffnungsfroh zu reisen, als anzukommen."

Aber was wäre die Alternative? Versuchen wir es doch einmal mit Cäsar's Vorschlag ...

Seitenanfang

Teilen ...

Als grobes Maß für die Komplexität der Planungs-Aufgabe soll die Fläche in Abb. 1 dienen: je mehr Anforderungen einbezogen werden müssen und je weiter damit das Planungs-Ziel in der Zukunft liegt, desto größer wird die (Planungs-) Fläche; d.h. es desto komplexer ist die Planungs-Aufgabe.

Das Bild ist natürlich stark vereinfacht: Risiken, wichtige Zwischentermine, Personal- und andere Ressourcen, usw. steigern die Komplexität weiter. Aber als Näherung sollte die obige Fläche ausreichen.

Bei der gewählten Darstellung gibt es zwei Dimensionen, in denen der Planungs-Aufwand reduziert werden kann:

• die Menge der Anforderungen, die in den Plan mit einbezogen werden;
• die Zeitachse, d.h. die Entfernung zum Planungs-Ziel;

Bevor man "teilen" kann, ist ein grobes Verständnis zum endgültigen Ziel bzgl. Umfang und Zeitrahmen notwendig: dazu ist eine Betrachtung "aus 10.000m Höhe" ausreichend. Damit sollte es Anwendern und Entwickler-Team möglich sein, die Größenordnung des Projekts gemeinsam abzustecken. Detail-Klärungen ("1.000m Höhe"), die den tatsächlichen Aufwand besser beschreiben, erfolgen zeitnah bei Bedarf (d.h. im jeweiligen Release).

Man konzentriert sich bei der ersten Teil-Planung darauf, welches aus der Sicht der Anwender die dringendsten Anforderungen sind; d.h. in der Regel: welche gewünschten Eigenschaften bringen dem Anwender am meisten Nutzen: Diese Eigenschaften werden mit dem Release Nr.1 ausgeliefert UND zum Einsatz gebracht (Abb. 1) .

Abb. 2: die dringendsten Anforderungen werden mit Release 1 geliefert;

Jedes Release hat eine fixe Dauer, die nicht verändert wird: ggf. werden in Absprache mit dem Kunden Anforderungen zusätzlich hineingenommen, oder aber in das nächste Release geschoben!

Dieses Vorgehen sorgt dafür, daß

• der Planungs-Aufwand vor dem Projekt-Start stark begrenzt wird;
• lauffähige Software sehr früh an den Kunden ausgeliefert wird;
• der Kunde zu einem bestimmten Zeitpunkt auch sicher lauffähige Software geliefert bekommt;
• Erfahrungswerte für die nächste Planung ermittelt werden; (welche tatsächlichen Schwierigkeiten beeinflussen das Projekt; tatsächliche Geschwindigkeit des Projekt-Fortschritts, etc.)

Gegen Ende des Release, wird basierend auf den konkreten Erfahrungen (bei Kunden und Entwicklern) das nächste Release geplant (sofern noch lohnende Anforderungen offen sind).

Seitenanfang

... und herrschen

Typische Zeitdauer für die Erstellung eines Release bei Agiler Vorgehensweise sind 1 bis 3 Monate, wobei der Zeitraum möglichst kurz gewählt werden soll. Durch ein solches Vorgehen kann ein wichtiges Element mit in den laufenden Planungs-Prozeß aufgenommen werden: die konkrete Erfahrung im eigenen(!) Projekt!

Der große Vorab-Gesamt-Plan in klassischen "Wasserfall"-Projekten basiert komplett auf Annahmen über das Benehmen des zukünftigen Projekts. Diese Annahmen sind bestenfalls aus den Erfahrungen in anderen(!) Projekten abgeleitet. Muß sich das Projekt auf Neuland bewegen (z.B. neues Fachgebiet oder neue Technologie), werden solche Annahmen immer schwieriger und riskanter. Viele Plan-Änderungen werden ausgelöst, weil man während des Projekts durch konkrete Erfahrung so manche Vorab-Annahme revidieren muß.

Wie in Abb. 3 skizziert, befassen sich die Releases nacheinander(d.h. Streng(!) sequentiell) mit Teil-Gruppen von Anforderungen: nach den "dringenden" Anforderungen werden die "wichtigen" geliefert, anschließend noch die "notwendigen", usw.; letztendlich entscheidet der Kunde, welche Eigenschaften noch "wertvoll" genug sind, um den weiteren Entwicklungs-Aufwand zu rechtfertigen!

Abb. 3: der Projekt-Plan ist eine Serie von Release-Plänen;

Bemerkenswert dabei ist:

• der Kunde erhält möglichst früh den bestmöglichen Geschäftsnutzen (siehe auch [02]);
• Rückmeldungen vom Kunden bzgl. eingesetzter Releases finden sofort Eingang in die laufende Planung und Arbeit;
• Erfahrungen der Software-Entwickler finden sofort Eingang in die laufende Planung;

Eines wird in Abb. 3 deutlich: zu Projekt-Beginn ist die Aussage über den tatsächliche "Ankunft" des Projekts (wann, wo/was) sehr vage! Nur über die Serie von Releases kann sich die Prognose mehr und mehr festigen.

Was auf den ersten Blick als großer Nachteil erscheint, ist in meinen Augen nichts anders als Aufrichtigkeit: ein Agiles Projekt versucht erst gar nicht, eine x-prozentige Sicherheit bzgl. der "Ankunft" vorzutäuschen. Vorab-Gesamt-Pläne vermitteln dem Kunden den Eindruck von "Planungs-Sicherheit", da die lange Liste der Annahmen und einschränkenden Aussagen im Kleingedruckten meist übersehen werden.

Die ehrliche Aussage im Agilen Projekt: "wir können es schaffen; wir wissen aber noch nicht, wie gut; aber wir werden sehr früh im Projekt messen(!), was wir tatsächlich erreichen können."

Diese Planungs-Un-Sicherheit klingt sehr negativ (insbesondere aus Sicht von 'Finance & Controling'). Lassen Sie mich deshalb noch einen kurzen Blick auf die positiven "Seiteneffekte" Agiler Planung eingehen.

Seitenanfang

Seiteneffekte

Abb. 4 soll bei der Beschreibung einiger "Seiteneffekte" helfen:

• im Beispiel sind die Kunden nach drei Releases mit dem erreichten Ergebnis zufrieden; anders ausgedrückt: die Arbeiten an weiteren Anforderungen haben einen zu schlechten "Return on Investment" (ROI, siehe dazu [02]));
• alles "notwendige" ist im System enthalten; man könnte auch sagen: alles "wertvolle" ist im System enthalten;
• es gibt ursprüngliche Anforderungen, die nicht mehr wichtig sind;
• durch Fokusierung hat man Zeit (und Geld) gespart und das Projekt endet früher;

Abb. 4: iteratives Vorgehen (Releases) bietet Einsparpotential;

Folgende positiven "Seiteneffekte" beobachte ich bei Agiler Vorgehensweise bzw. bei Agiler Planung:

• stark reduzierter Planungs-Aufwand:
  die einzelnen Release-Pläne befassen sich jeweils mit einem klaren Ausschnitt;
  dadurch reduziert sich zusätzlich die kombinatorische Komplexität;
  die sichtbare, rot schraffierte Fläche ist ein Hinweis auf die Einsparungen bei der Planungs-Arbeit gegenüber einem Vorab-Gesamt-Plan;
• Fokusierung auf notwendige Anforderungen:
  die Kunden wissen, daß das System in einer Serie von Releases erstellt wird und daß es damit stufenweise wächst;
  damit wird es ihnen leicht gemacht, sich von dem typischen Verhalten zu lösen: grundsätzlich wesentlich mehr anfordern, als letztendlich benötigt wird;
  die Kunden können sich schrittweise auf das jeweils wichtigste konzentrieren;
• Einsparung durch Weglassen überholter Anforderungen:
  werden die Kunden nur einmal zu Beginn des Projekts gefragt, was alles benötigt wird, dann werden sie wesentlich mehr Bedarf anmelden, als tatsächlich notwendig ist;
  meist wissen die Kunden einfach noch nicht, was sie in 6 Monaten oder in 1 Jahr genau benötigen; oder die Idee ist so neu, daß einfach noch keine Erfahrung vorhanden ist was notwendig bzw. möglich ist;
  erst gegen Ende des Projekts wird den Kunden/Anwendern klar, was sie tatsächlich benötigen; der Rest der ursprünglichen Ideen wird eben nicht umgesetzt;
• früher Nutzen für den Kunden:
  im strengen zeitlichen Rhythmus werden die Releases bearbeitet und ausgeliefert(!);
  jedes Release ist per Definition einsatzfähig, d.h. der Kunde kann bereits ab dem ersten Release den Nutzen realisieren, der mit den verfügbaren Eigenschaften des verbunden ist;
• Einsparungen für Prozeß zur Änderungs-Kontrolle:
  innerhalb der festen, kurzen Zeitraster der Releases sind die Chancen gering, daß sich die Ansichten und Ziele der Kunden ändern (falls doch, dann kann z.B. im 2-Wochen-Rhythmus der unterlagerten Iterationen leicht reagiert werden);
  bei jeder der regelmäßigen Release-Planungen können beide Seiten ihre konkreten Erfahrungen einbringen und den Projektkurs entsprechend korrigieren (u.a. Richtung und Geschwindigkeit);
• Investitionsschutz für den Kunden:
  jedes Release produziert einsatzfähige Software;
  sollte ein Projekt aus welchem Grund auch immer abgebrochen werden, dann bleibt dem Kunden in jedem Fall der Nutzen der gelieferten Releases erhalten;
  (in Wasserfall-Projekten ist oft alles Investierte verloren)
• Planungs-Sicherheit durch konkrete Erfahrung:
  das Projekt-Team (Entwickler UND Kunden) lernt den Charakter des Projekts mit jedem Release besser kennen;
  der Fortschritt wird ausschließlich durch laufende Software vor dem Kunden demonstriert;
  damit werden kontinuierlich Werte ermittelt, die die Fortschritts-Geschwindigkeit messen;
  diese Werte gehen in jede neue Release-Planung ein und verbessern so die Planungs-Aussage;
• keine Verschwendung durch "Lager-Haltung":
  bei Vorab-Gesamt-Plänen muß "alles" bedacht, definiert, geschätzt und geplant sein, was vielleicht einmal benötigt werden könnte;
  weiter ist ein solcher Plan in der Regel so gestaltet, daß die System-Teile erst gegen Ende integriert werden und damit ein einsatzfähiges System ergeben; meist funktioniert aus Kundensicht dann eben erst "alles zusammen";
  damit ergibt sich aber eine riesige "Lager-Haltung", die eine Menge Kapital (in Form von investierter Zeit) gebunden hat; in einem solchen "Lager" findet man z.B.: Detail-Beschreibungen aller Anforderungen, auch wenn sie erst in Monaten/Jahren gelesen werden; fertige Software-Teile des Systems, die aber alleine nicht einsatzfähig sind und damit auf die Fertigstellung anderer Teile warten müssen;

Seitenanfang

Zusammenfassung

Das Konzept "teile und herrsche" kann den Planungs-Aufwand in einem Projekt erheblich reduzieren. Agile bzw. Iterative Vorgehen sind sehr gut geeignet, dieses Konzept umzusetzen. Vor allem fördern diese Vorgehen das Prinzip des "Lernens über das eigene Projekt" (siehe auch [03]), was wiederum die Planung stark positiv beeinflußt.

Durch einen wohldefinierten Prozeß wird eine Serie von Teil-Plänen erstellt, die auf den konkreten Erfahrungen und Beobachtungen im eigenen Projekt aufbauen. Damit werden die Risiken unscharfer Annahmen stark reduziert: die Planung berücksichtigt immer den tatsächlichen "Charakter" des Projekts.

Früh im Projekt werden einsatzfähige Teil-Pakete produziert, die wertvolle Rückmeldungen zurück in das Projekt generieren: der Kunde bzw. die Anwender können früh dem Entwickler-Team signalisieren, wie weit Erwartungen erfüllt sind.

Alles in allem wird Agile Planung zu geringerer Projekt-Laufzeit, reduzierten Kosten und mehr Flexibilität im Projekt führen, obwohl auf Entwicklerseite der Planungs-Streß deutlich reduziert ist.

Seitenanfang

Verweise

Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und für weiterführende Informationen:

[01]	Paul Watzlawick: Anleitung zum Unglücklichsein; (Serie Piper)
[02]	Mark Denne, Jane Cleland-Huang: Software by Numbers; (Prentice Hall)
[03]	Mary Poppendieck: Lean Software Development, An Agile Toolkit; (Addison-Wesley)

Seitenanfang