Einleitung

"Zufällig", "nicht vorhersehbar", "planlos" ... "chaotisch" sind einige der Attribute, die ich immer wieder von Seiten die Skeptiker zum Thema "Agile Software Entwicklung" höre. Und schon der Begriff "eXtreme Programming"(XP)[01] ist doch bereits verdächtig, oder? Einen klassischen (und damit sehr detailierten) Projekt-Plan sucht machen in einem XP-Projekt vergeblich. Das heißt aber nicht, daß es keine Planung gibt -- es gibt eben eine Agile Planung.

Die wichtigsten Elemente einer solchen Agilen Planung in einem Software-Entwicklungs-Projekt möchte ich hier kurz vorstellen:

• beim Start wird sicher gestellt, daß alle Beteiligten das gleiche Ziel vor Augen haben und das gleiche Verständnis bzgl. des Projekt-Umfangs haben;
• ein Release stellt eine sinnvolle Teilmenge des Gesamt-Systems dar und ist als solche produktiv beim Kunden einsetzbar;
• eine Iteration ist die zeitlich kleinste Einheit eines Agilen Projekts und liefert bereits lauffähige Software für den Kunden;
• durch regelmäßige Messungen am laufenden Projekt werden die Planwerte für die wiederkehrenden Release- und Iterations-Planungen ermittelt;

Seitenanfang

Der Start

Am Beginn des Projekts wird gemeinsam erarbeitet, was das Ziel des Projekts ist.

"Gemeinsam" bedeutet: die Kundenseite ist mit Experten und zukünftigen Endanwendern vertreten; auf der Software-Seite werden die Entwickler selbst teilnehmen. Auf beiden Seiten verzichtet man auf "Stellvertretern".

Bzgl. einer Ziel-Definition wird das gesamte System in Form sog. User Stories beschrieben: [02]:

• die Kunden beschreiben in wenigen Sätzen selbst auf den Story-Cards, wie das System aus ihrer Sicht funktionieren soll;
• für jede Story sollen die Software-Entwickler ein grobes Verständnis erlangen;
• die Software-Entwickler schätzen sofort grob die Größe der Anforderung(en) in Form von "Funktions-Einheiten" (auch Story Points genannt);

Nun stellt sich sofort die Frage: wann hat man genug Story-Cards?

Ganz sicher ist es nicht Ziel einer solchen "Exploration" (= der Ausdruck in XP für diese erste Phase im Projekt), "alles" aufzuschreiben, was je einmal Thema im Projekt sein könnte. In der Literatur oder auch in Artikeln liest man oft die Zahl von "ca. 80 Stories", die ein System ausreichend beschreiben. Das hängt natürlich von Gesamtziel ab und muß relativiert werden.

Ich halte mich da schon lieber an eine Management-Regel der US-Marines [03]: "Aim for the 70% solution"; will heißen: es ist besser, mit einem 70-prozentigen Plan/Verständnis früh zu beginnen, als mit einem "perfekten" Plan zu spät.

Seitenanfang

Release

Die gesamte Projektlaufzeit ist in feste Zeiteinheiten unterteilt, die sog. Release-Timeboxes. Typischerweise dauert ein Release zwischen 4 und 8 Wochen, wobei 8 Wochen wirklich die Obergrenze darstellen sollte.

Zu Beginn eines jeden Release wird mit dem Kunden zusammen entschieden, was das System am Ende dieses konkreten Releases zusätzlich können soll. Die Regeln für eine Release-Planungssitzung sind einfach:

• die Entwickler geben bekannt, wieviele "Funktions-Einheiten" sie in diesem Release schaffen können;
• ggf. werden neue User Stories geschrieben und geschätzt;
• ggf. werden alte User Stories vom Kunden zurückgezogen;
• die Kunden "ziehen" solange User Stories (als Beschreibung für zusätzliche Funktionen) aus dem Stapel, bis die erklärte Release-Kapazität in "Funktions-Einheiten" erreicht ist;
• die Kunden müssen sicher stellen, daß die Kombination der ausgewählten User Stories produktiv einsetzbar ist;

Eine solche Planungssitzung dauert typischerweise ca. 2 Stunden.

Wie man erkennt, kommt es bei dieser Art der Planung nicht zu den typischen Diskussionen über Projektänderungen: der Kunde kann "jederzeit" seinen Plan an die eigene Erwartung anpassen. Ein schnelles Reagieren z.B. auf Marktänderungen ist immer möglich.

Seitenanfang

Iteration

Innerhalb eines Release wird die Zeit noch einmal in feste kleinere Zeiteinheiten unterteilt: jedes Release besteht aus N Iterationen; jede Iteration dauert 1-2 Wochen.

Zu Beginn einer jeden Iteration findet eine gemeinsame Iterations-Planungssitzung statt. Dabei geht es um eine weitere Stufe der Detaillierung in der Beschreibung von konkreten User Stories: die Software-Entwickler sollen jetzt die Details soweit verstehen, daß sie

• kleine Mini-Arbeitspläne je User Story schreiben können (sog. Task-Cards);
• jede Task-Card im Aufwand grob abschätzen können (in sog. Task-Points);

Wie schon bei der Release-Planungssitzung geben auch hier die Entwickler bekannt, wie groß die Kapazität der konkreten Iteration ist (in Task-Points);

Sobald die Kapazität der Iteration verplant ist, ist auch das Ziel der Planungssitzung erreicht, nämlich ausreichend viele Mini-Arbeitspläne für die Dauer der Iteration.

Die Dauer einer Iterations-Planungssitzung hängt vor allem davon ab, wieviel gemeinsames Verständnis die Beteiligten zum System haben; als Anhaltspunkt kann durchaus das Doppelte einer Release-Planungssitzung angenommen werden.

Seitenanfang

Messung

Bleibt jetzt zum Schluß "nur" noch die Frage: ja, und wie werden die Kapazitäten von Release und Iteration eigentlich festgelegt?

Auch auf diese Frage hat XP eine einfache Antwort: in der jeweils vorangegangenen Phase (Release oder Iteration) wird das Erreichte gemessen (in Story-Points bzw. Task-Points); und genau diese Werte sind das Limit für die nächste Phase. Allein im allerersten Zyklus muß auf Annahmen zurückgegriffen werden: entweder hat man bereits die Erfahrungswerte aus vergleichbaren Projekten, oder man startet mit den in der Literatur vorgeschlagenen Richtwerten [02].

Nach dem ersten Zyklus hat man in jedem Fall die eigenen(!) Richtwerte, die sich von Zyklus zu Zyklus verbessern werden. D.h. die Werte werden sich nach 2 (spätestens 3) Zyklen so stabilisiert haben, daß eine nahezu perfekte Hochrechnung für den Rest der Projektdauer ermöglicht wird.

Damit werden realistische Pläne für einen überschaubaren Zeitraum erreicht, die dennoch so flexibel sind, um ohne Aufwand an geänderte Projektziele angepaßt zu werden.

Seitenanfang

Zusammenfassung

Die agile Planungsmethode (hier am Beispiel von eXtreme Programming) versucht nicht den kompletten Projektzeitraum zu planen, sondern konzentriert sich jeweils auf den unmittelbar nächsten Zeitraum (Release bzw. Iteration).

"Jedes Projekt ist anders", heißt es allgemein. Ich sage immer: "jedes Projekt hat seinen eigenen Charakter". Dieser Charakter ist u.a. bestimmt durch die Aufgabenstellung, die beteiligten Personen, den Grad der Verfügbarkeit von wichtigen Personen, dem Niveau des sog. Domainen-Wissen der Beteiligten usw. Und es wird bei jedem Projekt Aspekte geben, die vergessen wurden.

Natürlich kann man durch entsprechenden Methoden (z.B. FMEA für das Projekt) "alle" möglichen Beeinflussungen vorab identifizieren. Und natürlich kann man für alle diese Aspekte im Vorfeld eines Projekts Annahmen treffen unter denen man dann den "perfekten" Projektplan erstellt.

Meine Erfahrung hat mir gezeigt, daß jeder Plan nur auf Annahmen basieren kann und daß die Wahrheit über ein Projekt sich erst im Verlauf des Projekts zeigen wird bzw. erst am Projektende bekannt ist.

Genau hier setzt die Agile Planung an: durch Beobachtung des Projekts selbst in definierten Zyklen lernen die Beteiligten den Charakter des Projekts kennen. Letztendlich ist nur wichtig, wieviele "Funktions-Einheiten" pro Zyklus fertiggestellt werden können. Die Antwort auf diese Frage berücksichtigt implizit alle(!) tatsächlich vorhandenen Einflußgrößen des Projekts, ganz ohne Annahmen bzw. Schätzungen; es wird "einfach" gemessen.

Damit werden realistische Pläne für einen überschaubaren Zeitraum erreicht. Selbst in sehr guten Projekten mit Vorab-Plänen wird wohl kaum die hohe Treffsicherheit erreicht, wie es mit der oben beschriebenen Vorgehensweise der Fall ist.

Seitenanfang

Verweise

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

[01]	Kent Beck: Extreme Programming -- Das Manifest; (Addsion-Wesley)
[02]	Ron Jeffries/Ann Anderson/Chet Hendrickson: Extreme Programming Installed; (Addsion-Wesley)
[03]	David H. Freedman: Corps Business; The 30 Management Principles of the US Marines; (Verlag Harper Business)

Seitenanfang