|
Einleitung
Dies ist Teil 2 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:
Im Teil 2 geht es hauptsächlich um unsere sogenannte "Projekt-Wand":
das ist unsere Form eines visuellen Informations-Systems,
das uns bei der täglichen Projekt-Arbeit leitet.
(für Ihre Rückmeldung zu diesem Artikel erreichen Sie mich immer per Email an
h.franzke@t-online.de)
Seitenanfang
Iterations-Plan
Am Ende von "Teil 1" entstand der
Release-Plan: das Projekt-Team hat
gemeinsam die Aufgaben-Schwerpunkte für die nächsten 4 Wochen festgelegt:
ausgewählte User Stories beschreiben konkret die nächste Lieferung an
den Kunden.
Der 4-wöchige Release-Plan wird in unserem Fall in 2 Iterationen
zu jeweils 2 Wochen abgearbeitet. Für jede einzelne Iteration erstellt das
Projekt-Team (Kunde/Anwender plus Entwickler) direkt am Iterations-Anfang einen
Plan (siehe Abbildung 1).
Abb. 1: Beispiel, Iterations-Plan;
In der Iterations-Planungs-Sitzung (Dauer ca. 1,5 Stunden) werden die
gleichen Grundregeln angewendet, die Kunden und Entwickler bereits aus der
Release-Planung kennen:
- jede Iteration hat eine bestimmte Kapazität (in idealen Stunden);
diese Kapazität wird durch den Balken dargestellt bzw.
durch das sog. "Plan-Limit" (rot);
- für jede User-Story wird von den Software-Entwicklern eine Reihe
von Tasks auf einzelnen Karten notiert: was ist notwendig, um die Story
im Sinne des Kunden abzuschließen?
- der Aufwand für jede einzelne Task (-Karte) wird von den Entwicklern
sofort geschätzt (in idealen Stunden);
- der geschätzte Aufwand wird sofort auf dem Iterations-Plan notiert
(siehe Abbildung 1);
- sobald das eingetragene Plan-Limit erreicht ist, wird die Planung
beendet;
Dieser Iterations-Plan hängt als Wegweiser für das Team während der 2
Iterations-Wochen gut sichtbar im Projekt-Raum.
Seitenanfang
Vor Augen
Die Idee hat viele Namen: u.a.
- "Visual Controls" (Toyota Production System, [01])
- "Information Radiator" ([02])
- "Big Visible Chart" ([03], [04])
Jeder dieser Begriffe verfolgt das gleiche Ziel: alle an der Arbeit Beteiligten
sollen auf einen Blick erfassen können, welche Aufgaben unmittelbar geplant sind,
an was gerade gearbeitet wird und wie man vorankommt.
Diese Art der Information soll den Personen, die die eigentliche Arbeit
(im Projekt) leisten, helfen, selbstständig die richtigen Entscheidungen zu
treffen. "Richtige Entscheidungen" sind solche, die das Projekt seinem Ziel
auf direktem Weg näher bringen.
WICHTIG:
"Vor Augen" bzw. "Visuell" ist wörtlich zu nehmen und grenzt sich damit
deutlich von "Elektronisch" ab!
Ich kenne einige Projekte, die auf elektronischem Wege Informationen
über das Projekt sammeln, aufbereiten und verteilen.
Im Grunde ist das Ziel-Publikum in solchen Fällen immer außerhalb(!) des
Projekts zu finden.
Hier geht es aber um Informationen, die im Projekt-Inneren genutzt werden sollen.
Diese Informationen müssen hyper-aktuell und sofort sichtbar sein: diese beiden
Anforderungen erfüllt kein elektronisches Werkzeug, wenn man nicht den
Gesamt-Prozeß im Projekt extrem verlangsamt.
Also: wir haben erfolgreich allen Versuchungen widerstanden, elektronische
Werkzeuge (wie z.B. XPlanner, [05]) einzusetzen.
Unsere Projekt-Wand steht offen und gut sichtbar im jeweiligen Projekt-Raum.
Damit liefert sie jedem im Projekt-Team auf einen (!) Blick den aktuellen Status.
Und so sieht unsere Projekt-Wand aus ...
Seitenanfang
Die Projekt-Wand im Überblick
Rein "technisch" betrachtet handelt es sich um eine ganz normale Pinwand.
Abbildung 2 zeigt einen Schnappschuß einer solchen
(leeren) Projekt-Wand.
Abb. 2: Beispiel einer leeren Projekt-Wand;
Hauptziel ist es, den Bearbeitungs-Status jeder für
die Iteration ausgewählten User Story sichtbar zu machen:
- Iterations-Ziel: hier werden zu Beginn alle User Stories der
Iteration plaziert;
- In Bearbeitung: sobald eine User Story zur Bearbeitung ausgewählt
wird, wandert die entsprechende Karte in diesen Bereich;
- Ready for Acceptance: ist eine User Story aus Sicht der Entwickler
"erledigt", wandert die Story-Karte in diesen Bereich;
- Accepted Stories: nachdem das Ergebnis der User Story vor
dem Kunden/Anwender demonstriert wurde und diese zufrieden sind,
landet die dazugehörige Karte letztendlich im Bereich rechts/unten
auf der Projekt-Wand;
Was im Detail alles auf dieser Wand geschieht und wie sie zu lesen ist,
sehen wir in den folgenden Abschnitten ...
Seitenanfang
Das Iterations-Ziel
Unmittelbar im Anschluß an die Iterations-Planung werden alle für die
Iteration geplanten User-Story-Karten links/oben an die Projekt-Wand
gepinnt (siehe Abb. 3)
Abb. 3: Das Iterations-Ziel auf der Projekt-Wand;
Als nächstes kann die erste User Story zur Bearbeitung ausgewählt werden ...
Seitenanfang
In Bearbeitung
Eine zur Bearbeitung ausgewählte User-Story-Karte wandert in den Bereich
"In Bearbeitung" auf der Projekt-Wand (siehe Abb. 4):
Abb. 4: User Story mit Tasks-Karten in Bearbeitung;
Sind alle notwendigen Tasks für eine User Story erledigt (und von dem
Entwicklern abgehakt), dann werden alle Task-Karten wieder hinter
die Story-Karte gesteckt und die Story wandert auf der Projekt-Wand
eine Station weiter ...
Seitenanfang
Fertig ...
Fertig ... was bedeutet das?
Hier in unserem Fall heißt das: die Entwickler sind mit ihrer Arbeit fertig
und haben das erreicht, was nach ihrem Verständnis für die User Story
notwendig ist.
Sie hängen eine solche User-Story-Karte in den nächsten Bereich der
Projekt-Wand (siehe Abb. 5):
Abb. 5: Fertig und warten auf die Abnahme;
Wenn man konsequent jede einzelne User Story demonstriert und nicht
einen Stapel von 4, 5 oder 6 Stories, dann ist die Wahrscheinlichkeit sehr groß,
daß der Kunde sich ein wenig Zeit nimmt und gerne die neue Funktion
begutachtet; die Entwickler laufen dann auch nicht in Gefahr, daß
Mißverständnisse mit dem Kunden sich in ihre Arbeit einschleichen und sich
über Stories hinweg fortpflanzen.
Und aus meiner Erfahrung weiß ich: der nächste Schritt macht süchtig ...
Seitenanfang
Akzeptiert
Unser Ziel ist es, dem Kunden/Anwender ein System nach seinen Vorstellungen
zu liefern, das ihm hilft, seine eigenen Arbeiten besser zu erledigen.
Natürlich können immer nur sinnvolle Funktions-Pakete produktiv eingesetzt
werden (siehe Release-Plan im
Teil 1); d.h. wir können in der Regel nicht einzelne Stories ausliefern.
Was wir aber immer anstreben: der Kunde/Anwender soll uns nach jedem unserer
kleinen Schritte (=User Stories) Rückmeldung geben, ob wir noch in die
richtige Richtung gehen (oder ob wir korrigieren müssen).
D.h. das Ziel der Entwickler ist es, jede Story-Karte möglichst schnell
in den Bereich "Accepted Stories" der Projekt-Wand zu bringen
(siehe Abb. 6):
Abb. 6: der Kunde hat die Stories akzeptiert;
Vielleicht noch ein Wort: diese Projekt-Wand ist ein Hilfsmittel und nicht
Ziel; d.h. die Aufgabe des Teams ist nicht, die Stories so schnell wie
möglich von links/oben nach rechts/unten zu bewegen.
Wir verstehen diese Wand sehr wohl als Informations-Monitor auf unserem
Weg, den Kunden nachhaltig zufrieden zu stellen.
Bleibt noch zu klären, wie diese Wand bei meinen Teams immer
auf dem aktuellen Stand gehalten wird ...
Seitenanfang
Aktualisierung
Die Aktualisierung erfolgt tatsächlich durch die Software-Entwickler selbst.
Der Aufwand dafür ist praktisch nicht meßbar.
Seit wir diese Wand im Einsatz haben, zeigt sie jedem auf einen Blick, wo wir
stehen.
Aus Erfahrung weiß ich, daß die Entwickler manchmal daran erinnert werden
müssen, doch nicht zu viele User Stories im Bereich "Ready" hängen zu lassen
(siehe Abb. 5).
Aber mit größer werdender Erfahrung vermeiden sie dann doch selbst diesen
Stau (bzw. Lagerbestand) ... und holen sich ihre Haken von den Kunden.
Seitenanfang
Zusammenfassung
Die Projekt-Wand spielt eine zentrale Rolle bei meinen Agilen Software-Projekten:
sie zeigt den Entwicklern immer die aktuellsten Informationen zum
Projekt-Fortschritt und leitet sie bei ihren Entscheidungen und ihrer
täglichen Arbeit. Dazu muß niemand ein Dokument im File-System suchen, oder
im Intranet klicken, oder jemanden fragen, der es wissen könnte.
Es genügt den Kopf zu heben -- ein Blick genügt.
Und natürlich ist diese Wand auch gut für mich als Projekt-Coach:
ein Blick und ich bin im Bilde.
Und was noch viel wichtiger ist: ich muß niemanden mit lästigen Fragen zur
Arbeit stören; jeder kann in Ruhe für das Projekt (sprich Kunden!) arbeiten.
Die Projekt-Wand hilft den Überblick zu bewahren und das Ziel nicht aus den
Augen zu verlieren: Projekt-Vision >>> Release-Plan >>>
Iterations-Ziel. Diese Zusammenhänge werden klar und unser Navigations-System
hilft uns, daß wir auch bei der täglichen Arbeit immer auf Kurs bleiben,
immer den Fokus behalten und uns nie in Nebensächlichkeiten verlieren.
Sie kennen sicher den Spruch: "Frage: Wie konnte es zu dieser riesigen Verzögerung
im Projekt kommen? Antwort: Tag für Tag für Tag ..."!
Diese Wand leistet aber noch mehr: sie gibt den Entwicklern ein sicheres
Gefühl ...
- weil sie wirklich wissen, wie es um das Projekt steht;
- weil sie ihre eigene Verantwortung im Projekt spüren;
- weil sie ihre eigenen Leistungen im Projekt einordnen können;
- weil sie ihre Erfolge zeitnah zu sehen bekommen;
- weil die Wand ihnen zeigt, wann sie mit ihrer Arbeit fertig sind;
- weil die Wand ihnen zeigt, daß es vorwärts geht;
Die Projekt-Wand ist sicher eines der wichtigsten Elemente, damit wir unsere
Projekte optimal "Im Visier" haben.
Daneben verwenden wir noch einige kleinere Elemente, die neben dem
projektinternen Nutzen auch gut geeignet sind, den Informations-Hunger
außerhalb des Projekts zu stillen.
Das soll Thema des abschließenden Teil 3 dieser Artikel-Serie sein ...
Seitenanfang
Verweise
Folgende Quellen wurden zum Teil zitiert bzw. werden empfohlen zur Vertiefung und
für weiterführende Informationen:
Seitenanfang
|
