Einleitung

Der Ausdruck "Im Visier" ist so eigentlich noch nicht vollständig: es muß wohl eher heißen
     "jemand steht im Visier" oder
     "jemand hat etwas im Visier".

Bei einem Projekt-Team denkt man wohl meist an die erste Version: das Team steht im Visier von allen möglichen Personen, oft angefangen vom Projekt-Leiter selbst über Kunden bis hin zu Managern. Mir geht es jedenfalls so ... und gleichzeitig spüre ich auch so ein ungutes Gefühl im Bauch, das mich früher (in meiner Wasserfall-Zeit) oft beschlich: ich stehe mit meinem Team "im Visier", ich soll Auskunft über den Status/Fortschritt/Termine geben und kann eigentlich nur raten.

In einer kleinen Artikel-Serie möchte ich von meinem aktuellen Arbeitsumfeld erzählen ... und von der zweiten Version von "Im Visier":

"jemand hat etwas im Visier", nämlich "das Projekt-Team hat das Ziel im Visier".

Und das erzeugt ein gutes Gefühl! Die Agilen Software-Entwicklungs-Teams, die ich aktuell unterstütze, wissen sehr wohl, wohin sie müssen, wie weit sie bereits gekommen sind, wieviel Weg noch vor ihnen liegt, wann sie am Ziel ankommen werden und wo die wirklichen Problemfelder im aktuellen Projekt sind. Ein jeder kann jederzeit (faktische) Antworten geben -- ganz ohne Raten und damit ganz ohne mulmiges Gefühl im Bauch.

Anhand einiger Beispiele möchte ich Ihnen zeigen, welche Möglichkeiten diese Teams in den verschiedenen Abschnitten ihrer Projekte nutzen, um das Ziel immer im Visier zu haben.

In diesem Teil 1 möchte ich auf den Projekt-Start und den Projekt-Plan blicken.

(für Ihre Rückmeldung zu diesem Artikel erreichen Sie mich immer per Email an h.franzke@t-online.de)

Seitenanfang

Sichtweisen

Bei der Beobachtung eines Projekt-Teams unterscheide ich verschiedene Sichtweisen, die sich teilweise überlappen:

• die des Kunden/Anwenders:
  u.a. Termine, Geld, Funktionalität, Qualität;
• die des Entwickler-Teams (sie beobachten sich selbst):
  u.a. Anforderungen, Lieferfähigkeit, Fortschritts-Geschwindigkeit, Probleme, Termine, Geld, fertiggestellte Funktionalität, Anwender-Akzeptanz, Qualität;
• die des Management-Levels:
  vor allem Termine, Geld;

Als Bild stelle ich mir da zum Beispiel eine Busreise vor:
den Reisenden liegt etwas an einer angenehmen Fahrt, sie sind dankbar für Hinweise auf sehenswertes an der Strecke, aber im wesentlichen interessiert sie am meisten, daß sie pünktlich und ohne Schaden am Ziel ankommen.
der Busfahrer hat die Gesamtstrecke im Kopf, reagiert auf aktuelle Informationen zu Geschwindigkeit, zurückgelegter und verbleibender Strecke, Straßen-Verhältnissen, Stau-Warnungen, uvm. und weiß sehr genau, wie er im Vergleich zu seiner Reise-Planung unterwegs ist.
der Busunternehmer möchte wissen, ob sein Bus rechtzeitig zurückkehrt, um die nächste Fahrt wie geplant zu starten.

Dieses Bild soll zeigen: falls der Busfahrer ohne Informationen (oder nennen wir es gleich Feedback) unterwegs ist, dann bleibt den beiden anderen Parteien nur noch das Prinzip "Hoffnung"; und wenn man da nervös wird und den Busfahrer ständig mit Fragen überhäuft, dürfte das auch verständlich sein.

Wie versorgt sich nun ein Projekt-Team so mit Informationen, daß man selbst Herr der Lage ist und unliebsame Überraschungen vermeiden kann? (über spezielles Feedback siehe auch [01])

Beginnen wir doch am Anfang ... mit dem groben Überblick ... sozusagen der Übersichts-Karte ... dem Projekt-Plan ...

Seitenanfang

Orientierung: die Teil-Strecken

Hinweis: die Arbeitsweise der Teams, von denen hier berichtet wird, basiert auf einer Kombination aus Scrum[02] (Schwerpunkt Planung/Coaching) und XP[03] (Schwerpunkt Entwicklung/Freigabe/Lieferung).

Wenn man auf einer langen Strecke zum allerersten Mal unterwegs sein muß, dann ist es wohl kein Fehler, sich die zuerst Teilstrecken anzusehen und dann zu addieren.

Die Agilen Projekt-Teams verwenden dazu Exploration-Sitzungen, in denen die "Teilstrecken" grob beschrieben werden: anhand von User-Stories (Abb. 1) werden zusammen mit dem Kunden die Teile des Projekts skizziert.

Abb. 1: Beispiel einer User Story Card;

Am Ende einer Exploration-Phase liegt ein Stapel aus User Story Karten vor; der Aufwand für jede einzelne Karte ist von den Entwicklern in idealen Tagen (z.B.) geschätzt; aus den Einzel-Bewertungen wird die ideale Gesamt-Punktzahl für das Projekt berechnet (siehe Abb. 2);

Abb. 2: Summe der idealen Punkte als Balken;

Diese ideale Gesamt-Punktzahl gibt einen Hinweis auf die Größenordnung des Projekts -- mehr noch nicht. Die Umsetzung in einen Projekt-Plan erfolgt in den nächsten Schritten ...

Seitenanfang

Vergleichen mit bekannten Erfahrungen

Ein Hinweis: die Frage, wie aus den gewonnen idealen Punkten ein Angebot erstellt wird und wie der Vertrag aussehen könnte, soll hier ausgeklammert werden -- nicht, weil es nicht funktioniert, sondern weil es den Rahmen hier sprengen würde.

Es gibt nun grundsätzlich 2 Möglichkeiten, die gefundene Zahl idealer Punkt in erwarteten Aufwand umzurechnen: man bestimmt die Kennzahl "reale Stunden pro idealem Punkt" durch

1. Erfahrungs-Werte:
   einige/alle Team-Mitglieder haben bereits in (ähnlichen) agilen Projekten gearbeitet und kennen die tatsächliche Kennzahl dort; z.B. 13,3 Entwickler-Stunden pro idealem Punkt;
2. eine erste Annahme:
   falls keinerlei Erfahrung existiert, muß mit einer ersten Annahme gestartet werden;
   z.B. 16 Entwickler-Stunden pro idealem Punkt (was einer Geschwindigkeit von 0,5 entsprechen würde);

In jedem Fall wird diese Kennzahl im Team diskutiert und festgelegt. Anschließend wird die ermittelte ideale Punkt-Zahl in erwarteten Real-Aufwand für die Entwicklung umgerechnet:

erwarteter Real-Aufwand = ideale Punkt-Zahl * Kennzahl
Beispiel: erwarteter Real-Aufwand = 53 ideale Punkte * 13,3 Entwickler-Stunden pro idealem Punkt = 705 Entwickler-Stunden;

Dieser erwartete Real-Aufwand bezieht sich auf den reinen Aufwand der Entwickler. Als Vereinfachung hier möchte ich jetzt nicht auf die Aufwände für Projekt-Coach, Administration, ggf. spezielles Training, usw. eingehen (zur reinen Budgetierung des Projekts sollte das keine Schwierigkeit bereiten; bei Teams mit 4-6 Personen liegt mein Coaching- und Administrations-Aufwand bei ca. 16-20% des Entwickler-Aufwands, je kleiner das Team desto höher der Anteil).

So, wir haben jetzt den erwarteten realen Entwicklungs-Aufwand mit dem wir den Projekt-Plan aufstellen werden ...

Seitenanfang

Projekt-Plan

Ziel für das Team ist es, den erwarteten Aufwand über die Zeit zu verteilen. Die folgenden Grund-Regeln spielen dabei bei meinen Teams eine Rolle:

• unsere Projekt-Tage haben max. 8 Arbeits-Stunden;
• Entwicklungs-Arbeit ist bestimmt durch Pair-Programming[05];
• bekannte Zeiten für Abwesenheit (z.B. Urlaub) werden berücksichtigt;
• da in den aktuellen Fällen die Personen nicht zu 100% für ein Projekt zur Verfügung stehen, legt das Team bestimmte Wochentage (mindestens 2) als sog. Projekt-Tage fest (z.B. Dienstags + Donnerstags);
• Team-Mitglieder müssen zu mindestens 40% kontinuierlich zur Verfügung stehen (=mind. 2 Tage pro Woche gleichmäßig für die geplante Projekt-Laufzeit, abzgl. Urlaub!);
• wir arbeiten time-boxed in Releases (4 Wochen) und Iterationen (2 Wochen);
• die Anzahl der Team-Mitglieder wird über die Projekt-Dauer konstant gehalten;
• es hat sich bewährt, zwischen Ende-Release-1 und Start-Release-2 eine entwicklungs-freie Woche einzuplanen: die Auslieferung des ersten Releases verursacht doch einiges an Aufregung im Team und stört die Entwicklungs-Arbeit über die Maßen; später ist das erfahrungsgemäß kein Problem mehr;

Nehme ich die 705 Entwickler-Stunden aus dem obigen Beispiel, dann ergeben sich daraus 88 Entwickler-Tage (bei 8 Stunden pro Tag). Mit 4 Entwicklern und 2 Tagen pro Woche ergibt sich eine Dauer von 11 Wochen. Das ergibt drei 4-Wochen-Releases.

Meine (agilen) Projekt-Pläne erstelle ich als Tabelle (siehe Abb. 3):

Abb. 3: tabellarischer Projekt-Plan;

Explizit wird darauf verzichtet, in dieser Art von Projekt-Plan die einzelnen Aufgaben oder gar die Aufgaben der einzelnen Entwickler darzustellen. Das erspart mir mindestens zweimal Arbeit: einmal beim Erstellen und später bei jeder Änderung, die ich in einen detailierten Plan einarbeiten müßte (ganz zu schweigen von den Diskussionen mit "Zuschauern", die dadurch entstehen würden).

In Absprache mit dem Kunden/Anwender wird in der Regel je Release ein (vorläufiges) Schwerpunkt-Thema festgelegt. Der produktive Einsatz eines jeden Release ist unmittelbar nach Ende der Release-Timebox vorgesehen. Damit kann der Anwender die fertiggestellten Funktionen nutzen und das Entwickler-Team erhält wertvolle Rückmeldungen, die sofort bei den weiteren Arbeiten berücksichtigt werden.

Zum Thema "Projekt-Budget": da wir time-boxed arbeiten, d.h. auch keine Überstunden arbeiten, können wir mit den ermittelten Stunden auch das erforderliche Budget ermitteln.

Die Freigabe des Projekts auf der Basis des Zeit- und Budget-Plans vorausgesetzt beginnt das Projekt-Team mit dem ersten Release ...

Seitenanfang

Der erste Release-Plan

Bei der ersten Release-Planung (wie auch bei allen weiteren) ist das Ziel, gemeinsam mit dem Kunden/Anwender aus den vorhanden User Stories ein "sinnvolles" Release-Paket zusammenzustellen.

"Sinnvoll" bedeutet:

• die ausgewählten User Stories ergeben zusammen ein (Teil-) System, das der Kunde/Anwender produktiv nutzen kann und will;
• der Gesamt-Aufwand der ausgewählten User Stories (gerechnet in idealen Punkten) übersteigt nicht die fixe Entwickler-Kapazität im Release;

Mit unerfahrenen Kunden kann die Dauer der ersten Release-Planungs-Sitzung auf 2 Std. angesetzt werden. Meine Erfahrung zeigt aber, daß man auch dann spätestens nach 1,5 Stunden fertig ist und das inklusive einer ausführlichen Einführung zu den Spielregeln beim Planning-Game (siehe [04]).

So könnte ein fertiger Release-Plan aussehen:

Abb. 4: Beispiel, Release-Plan;

Damit kann das Projekt-Team (Entwickler, Anwender, Kunden und Coach) an die Arbeit gehen ...
... aber wie es weitergeht werde ich Ihnen bald im zweiten Teil meiner kleinen Artikel-Serie zeigen ...

Seitenanfang

Fazit nach Teil 1

Ziel dieser kleinen Artikel-Serie "Im Visier" ist es darzustellen, welche Mittel Agile Software-Entwicklungs-Teams benutzen, um das Ziel "Projekt-Erfolg" ständig im Auge zu haben.

Als wichtiger Punkt erscheint mir bereits die Tatsache, daß Agile Entwickler-Teams in die Vorbereitung und Planung einbezogen werden:

• anders als ihre "Wasserfall"-Kollegen kennen sie bereits die Idee, die Anforderungen und die (Zwischen-) Ziele des Projekts bevor es an die konkreten Arbeiten geht.
• noch wichtiger: sie haben aktiv(!) an der Planung teilgenommen und z.B. ihre eigenen Schätzungen für die geplanten Arbeiten eingebracht.
• der Projekt-Plan ist ihr Plan, sozusagen ihr Strecken-Plan für die Projekt-Reise.

Gute Fahrt!

Seitenanfang

Verweise

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

[01]	Feedback Loops; Don Wells auf der Website "Extreme Programming: A gentle introduction."
[02]	http://www.controlchaos.com/; die Original-Seite zu SCRUM;
[03]	http://www.extremeprogramming.org/; Extreme Programming: A gentle introduction.
[04]	http://c2.com/cgi/wiki?PlanningGame; Wiki: Planning Game;
[05]	Pair Programming; Don Wells auf der Website "Extreme Programming: A gentle introduction."

Seitenanfang