|
Einleitung
Dies ist Teil 3 der Artikel-Serie "Im Visier":
anhand einiger Beispiele aus meinem aktuellen Arbeitsumfeld möchte ich
Ihnen zeigen, welche Möglichkeiten Agile Projekt-Teams in den verschiedenen
Abschnitten ihrer Projekte nutzen, um das Ziel immer im Visier zu haben.
Bisher ist zum Thema erschienen:
- Teil 1:
Projekt-Start, Projekt-Plan,
Release-Plan;
wie Agile Teams gemeinsam(!) schlanke Pläne für ihr Projekt
erstellen und mit dem Kunden abstimmen;
- Teil 2:
Die Projekt-Wand;
die Projekt-Wand dient dem Team als zentrales Navigations-System:
sie zeigt ein überschaubares (=nahes) Zwischen-Ziel und den aktuellen
Bearbeitungs-Status;
Im Teil 3 geht es nun darum, neben der Bewegung im Projekt vor allem
den Fortschritt sichtbar zu machen: nach innen wie auch nach außen.
(für Ihre Rückmeldung zu diesem Artikel erreichen Sie mich immer per Email an
h.franzke@t-online.de)
Seitenanfang
Kurzer Rückblick
In Teil 1 und
Teil 2 wurden 3 wichtige Elemente beschrieben,
mit denen das Agile Team die Richtung im Projekt regelmäßig überprüft und
ggf. anpaßt (Release-Plan,
Iterations-Plan) und
wie der aktuelle Bearbeitungs-Status im Projekt-Team sichtbar
gemacht wird (Projekt-Wand).
Nun wollen wir uns einmal ansehen, wir das Team diese Elemente mit einfachen
Mitteln zu einem brauchbaren "Navigations-System" ausbaut, damit sie
das Ziel (= Projekt-Erfolg = zufriedener Kunde) fest im Visier behält.
Seitenanfang
Bewegung
Die Projekt-Wand hat uns
bereits gezeigt, daß im Projekt "etwas" erreicht wird: User-Story- und
Task-Karten wandern über die Wand und landen nacheinander im "Ziel-Bereich"
auf der Wand.
Ja, es bewegt sich etwas ... und diese Bewegung können wir sehr(!) einfach
auf dem Iterations-Plan festhalten, der ebenso gut sichtbar im Projekt-Raum
hängt (siehe Abbildung 1):
Abb. 1: Iterations-Plan mit Markierungen;
Aber aufgepaßt:
was wir hier als wachsende (grüne) Markierungen sehen, ist
genau genommen "nur" Bewegung!
Die Tasks wurden von den Entwicklern definiert und mittels Task-Punkten
geschätzt; sie stellen aber für sich nicht unbedingt etwas dar,
das einem Kunden/Anwender (direkten) Nutzen bringt;
nur bei wachsendem "Nutzen" wird ein Kunde auch von "Fortschritt"
sprechen.
Bitte nicht nervös werden: ein Projekt-Mitglied sagte einmal
"ohne Bewegung gibt es keinen Fortschritt".
Gut, Bewegung sehen wir nun schon, also weiter ...
Seitenanfang
Geschwindigkeit
Als nächstes wollen wir uns diese Bewegung unter dem Aspekt
"Geschwindigkeit" etwas genauer ansehen:
- wie viel Aufwand hat das Team denn in diese Bewegung investiert?
- liegen wir damit im Bereich unserer Schätzungen?
- oder kündigt sich gar ein Problem an?
In meinen agilen Teams verwenden wir sog. "Velocity-Charts", um Bewegung
und Aufwand in Relation zueinander zu setzen
(siehe Abbildung 2):
Abb. 2: Beispiel, Velocity-Chart;
Soviel zu "Bewegung" und Geschwindigkeit".
Aber wir wissen: nicht jede Bewegung bedeutet auch "Fortschritt" ...
Seitenanfang
Fortschritt im Release
So, nun werde ich wohl erst einmal "Fortschritt" definieren müssen,
bevor wir ihn beobachten.
"Fortschritt" in einem Software-Projekt kann letztendlich nur aus der
Perspektive eines Kunden/Anwenders beurteilt werden: "wie entwickeln
sich die Leistungs-Merkmale des Software-Systems, die ich
definiert habe?".
In Anlehnung an Ron Jeffries Idee der "Running Tested Features (RTF's)"
[01] können wir zum Thema "Fortschritt" die
Entwicklung der User Stories im Release-Plan verfolgen
(siehe Abbildung 3):
Abb. 3: Release-Plan mit Markierungen;
Die wachsenden Markierungen im Release-Plan
(Abbildung 3) könnte man als "Mikro"-Fortschritt
bezeichnen: sozusagen "Fortschritt auf einer Teilstrecke" im Projekt.
Wie man Fortschritt im gesamten Projekt einfach sichtbar machen kann,
soll der nächste Abschnitt zeigen.
Seitenanfang
Fortschritt im Projekt
Wie gesagt: tatsächlichen Fortschritt im Projekt kann man nur
nach den Regeln der Kunde/Anwender messen: "wie entwickeln sich die
geforderten Leistungs-Merkmale?"
Bei meinen Teams benutzen wir dazu wieder die (gewichteten) User Stories,
die insgesamt für das Projekt definiert sind.
Wir pflegen zu diesem Zweck ein kleines Chart, das wir "User Story Chart"
nennen
(siehe Abbildung 4):
Abb. 4: Beispiel, User Story Chart;
Diese "User Story Chart" wird als einziges der gezeigten Monitor- oder
Navigations-Elemente
(Release-Plan,
Iterations-Plan,
Projekt-Wand,
Velocity-Chart,
User-Story-Chart)
elektronisch gepflegt.
Der Grund dafür: es dient auch der offiziellen Status-Meldung an den
Kunden; zu diesem Zweck ist es immer über die Homepage zum jeweiligen
Projekt verfügbar.
(ein kleines Perl-Skript und eine einfache Text-Tabelle mit den
Beschriftungen und den Werten lassen den Aufwand dafür gegen Null
gehen)
Damit wäre ich eigentlich mit meiner kleinen Artikel-Serie "Im Visier"
am Ende, wenn da nicht noch diese mulmige Gefühl wäre ...
Seitenanfang
Warnung!
Ja, mein mulmiges Gefühl ... es hat damit zu tun, daß die beschriebenen
Elemente nicht zum Selbstzweck dienen: sind Mittel zum Zweck und
ein Projekt-Team wird sicher allein durch die Verwendung dieser
Elemente nicht(!) zu einem Agilen Team!
Dazu braucht es wohl vor allem ein entsprechendes Werte-System und
die dazugehörige Grund-Einstellung aller Team-Mitglieder; darauf
einzugehen würde aber diese Artikel-Serie sprengen.
Es gibt viele Diskussionen zu diesem Punkt und ich möchte
stellvertretend Ron Jeffries ([03]) aus einem
seiner Beiträge im Forum
"extremeprogramming"([04]) zitieren:
"I would suggest that "are we doing XP" is not a good question to ask
ourselves. A better question would be "are we successfully
delivering software to our customer every week, which is fully
integrated and tested, and are we producing that software at a stead
or increasing rate of speed?" If we aren't, we're not doing very
well, no matter what we call the process."([05]).
D.h.: unser oberstes Ziel muß immer sein, den Kunden mit regelmäßigen
Lieferungen zufrieden zu stellen. Falsch wäre es, sich nur auf bestimmte
Dinge oder Aktivitäten im Prozeß zu konzentrieren (wie z.B. das Führen
von Plänen und Charts).
Seitenanfang
Zusammenfassung
Anhand einiger Beispiele aus meinem aktuellen Arbeitsumfeld wollte ich
Ihnen zeigen, welche Möglichkeiten Agile Projekt-Teams in den verschiedenen
Abschnitten ihrer Projekte nutzen, um das Projekt-Ziel immer im Visier
zu behalten.
Wichtig dabei erscheint mir, daß alle Beteiligten aktiv eingebunden sind:
die Software-Entwickler (und damit fasse ich alle IT-Rollen im Projekt
zusammen), die Kunden und die Anwender.
Die gezeigten Elemente erfordern nach meiner Erfahrung einen sehr geringen
Aufwand für Erstellung, Pflege und Anwendung und sind daher gut geeignet
für schnelles Feedback zum Projekt. Gemeinsam ist allen
das Prinzip der "Big Visible Charts"([06]
und [07])
für unmittelbares Feedback an das Projekt-Team (vor allem die Entwickler).
Damit wird ein strenger Fokus von allen auf die wichtigen Aufgaben
unterstützt. Dieser Fokus hilft Verschwendung im Projekt stark
zu reduzieren.
Seitenanfang
Verweise
Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und
für weiterführende Informationen:
Seitenanfang
|
