Agiles Projektmanagement (eBook)

1.9 Ein Beispiel aus der Praxis

Das in diesem Kapitel dargestellte Beispiel führt Sie an die wesentlichen Zusammenhänge eines agilen Entwicklungsprozesses heran und macht es einfacher, die theoretischen Aspekte und Techniken des Agilen Projektmanagements gedanklich einzuordnen.

Das Beispiel ist bewusst sehr schlicht gehalten. Es geht dabei nicht um eine möglichst hohe Realitätsnähe, sondern um maximale Verständlichkeit.

1.9.1 Der Projektstart

Maria Müller leitet ein kleines Software-Unternehmen mit vier Entwicklern. Ein Kunde, Paul Schmidt, meldet sich. Er braucht eine Kalender-Applikation. Frau Müller trifft sich mit ihm, um zu verstehen, was genau hinter diesem Wunsch steckt. Dabei lässt sie sich alles beschreiben, was die Kalender-Applikation aus Sicht des Kunden braucht (Techniken »Anwendungsfälle«, »User Storys«).

Paul Schmidt sagt, dass er Termine eintragen und verschieben können will und zwischen einer Tages- und Wochenansicht wechseln möchte. Diese Anforderungen hält Maria Müller einzeln fest:

• Neuen Termin in den Kalender eintragen

• Vorhandenen Termin verschieben

• Zur Tagesansicht wechseln

• Zur Wochenansicht wechseln

1.9.2 Anforderungen aus Kundensicht

Der Kunde äußert einen weiteren Wunsch: Es soll möglich sein, in der Applikation Terminkategorien wie z. B. »beruflich« und »privat«, zu unterscheiden. Frau Müller will die Anforderungen ihres Kunden richtig verstehen. Dazu muss sie wissen, was genau der Kunde mit der fertigen Applikation an dieser Stelle machen will.

Also fragt sie nach und bekommt heraus, welche konkreten Vorstellungen Herr Schmidt hierzu im Kopf hat. Sie schreibt sie auf:

• Neue Terminkategorie anlegen (z. B. beruflich, privat, Urlaub)

• Einem neuen Termin eine bestimmte Kategorie zuweisen

• Die Kategorie für einen bestehenden Termin ändern

Herr Schmidt beschreibt das Produkt aus seiner Sicht. Er beantwortet Frau Müller die Frage, was er alles mit dem fertigen Produkt machen können will. Dies ist die Basis für eine agile Produktentwicklung, damit der Kunde im weiteren Projektverlauf wirklich mitreden kann. Am Ende des Gesprächs hat Maria Müller ein Verständnis dafür entwickelt, was ihr Kunde eigentlich braucht. Da sie sich in ihrem Geschäft auskennt, kann sie den Aufwand für die Produktentwicklung abschätzen. Sie nennt dem Kunden den Endtermin der Entwicklung, der in zwei Monaten sein wird. Gleichzeitig vereinbart sie mit ihm, alle zwei Wochen ein Teilprodukt zu präsentieren. Außerdem erklärt sich Herr Schmidt bereit, kurzfristig für Nachfragen zu den Anforderungen zur Verfügung zu stehen. Frau Müller hat nun also eine ganze Reihe von sog. Anwendungsfällen gesammelt und versteht auf diesem Beschreibungsniveau, was der Kunde möchte.

Die zu Beginn gesammelten Anwendungsfälle geben erst einmal nur die Richtung für die ersten Schritte der Entwicklung vor. Im weiteren Verlauf der Zusammenarbeit wird der Kunde noch besser verstehen, was er genau braucht. Er kommt dann vielleicht auf weitere oder neue Ideen. Außerdem werden sich mögliche Missverständnisse aufklären. Änderungen an den Anforderungen werden daher von Anfang an fest eingeplant.

Die Summe der gesammelten Anwendungsfälle bildet den Startpunkt für die Produktentwicklung.

1.9.3 Produktentwicklung: die erste Runde

Nun kann Maria Müller die Produktentwicklung starten. Dazu bespricht sie gemeinsam mit ihrem Team, welche Anwendungsfälle im ersten Schritt innerhalb der ersten zwei Wochen umgesetzt werden sollen. Folgende Entscheidungskriterien spielen dabei eine Rolle:

• Was ist dem Kunden besonders wichtig?

• Welche Abhängigkeiten gibt es? Was gehört zusammen?

• Was sollte z. B. aus technischen Gründen zuerst gemacht werden?

• Was kann während der zwei Wochen geschafft werden?

Jetzt hat Frau Müller eine To-do-Liste für die nächsten zwei Wochen, die sog. erste Iteration. Diese Liste hängt sie an einer Pinnwand für alle im Projektbüro sichtbar auf (Task Board).

In unserem Beispiel sind die Anwendungsfälle gleichzeitig auch die Arbeitspakete. In der Praxis werden die Anwendungsfälle erst noch auf konkrete Arbeitspakete handlicher Größe (1 bis 5 Tage) heruntergebrochen. Für diese wird dann der Begriff »Tasks« verwendet. Die Tasks werden auf Karten geschrieben und an das Task Board gehängt, und zwar in den Bereich »To-do«.

Nun startet die Entwicklung. Jeden Tag trifft Maria Müller sich kurz mit dem Team am Task Board. In diesem Daily Stand-up-Meeting bespricht sie, wer gerade welche Aufgaben hat, und stellt sicher, dass alle gut vorankommen. Wenn jemand ein Problem nicht lösen kann, klärt sie, wer ihn unterstützt.

Wenn ein Entwickler eine Aufgabe vom Task Board übernimmt, hängt er die entsprechende Karte von »To-do« nach »In Work«. Er ist fortan für diese Karte verantwortlich, insbesondere dafür, dass die Karte rechtzeitig nach »Done« kommt, was erst möglich ist, wenn er die Aufgabe erledigt hat. Mit der Zeit wandern die Karten so über das Task Board.

Zwischendurch kommt ein Entwickler zu Frau Müller, weil er nicht weiß, wie genau der Dialog bei »Termin anlegen« aussehen soll. Soll bei der Eingabe des konkreten Datums ein Textfeld erscheinen oder eine kleine Kalenderansicht zur Auswahl eines Datums? Frau Müller klärt die Frage kurzfristig mit dem Kunden, so dass der Entwickler keine Zeit verliert.

Wann immer ein Entwickler eine konkrete Frage zu Details eines Anwendungsfalles hat, sorgt die Chefin dafür, dass er schnell eine Antwort bekommt. Viele Fragen kann sie auch direkt beantworten, ohne Rücksprache mit dem Kunden.

1.9.4 Feedback zum Teilprodukt einholen

Nach zwei Wochen ist eine erste Version des Produktes fertig und vorführbereit (Inkrement). Dieses Teilprodukt bzw. Inkrement zeigt Frau Müller Herrn Schmidt. Er kann es nun selber ausprobieren. Er fügt neue Termine ein, verschiebt vorhandene etc. Dabei fällt ihm auf, dass er Termine gar nicht löschen kann. Diese Anforderung, die am Anfang des Projektes vergessen wurde, ist ihm sehr wichtig.

Daher nimmt Frau Müller jetzt also »Einen vorhandenen Termin löschen« als neuen Anwendungsfall auf. Was sie allerdings nicht tut, ist, ihn nun einfach dem Task Board hinzuzufügen! Denn dadurch würden sich Projektkosten und -dauer unkontrolliert verändern.

1.9.5 Die Planung anpassen

Gemeinsam mit ihrem Team schätzt Frau Müller daher erst einmal den Aufwand für den neuen Anwendungsfall. Es gibt grundsätzlich drei Möglichkeiten, wie dann weiter verfahren werden kann:

1. Der neue Anwendungsfall wird der Planung hinzugefügt. Gleichzeitig wird ein anderer Anwendungsfall mit gleichem Umfang, der dem Kunden aber weniger wichtig ist, aus der Planung gestrichen.

2. Der neue Anwendungsfall wird der Planung hinzugefügt und es wird vereinbart, dass das Projekt entsprechend länger läuft.

3. Der neue Anwendungsfall wird der Planung hinzugefügt und es wird vereinbart, dass der Kunde das Budget erhöht. Frau Müller kann dann vorübergehend einen weiteren Entwickler beschäftigen und das Projekt zum vereinbarten Termin abschließen.

Dem Kunden werden diese Optionen vorgestellt. Er entscheidet, wie die Planung angepasst werden soll. Da die Anforderungen aus seiner Sicht beschrieben sind, kann er auch die Konsequenzen von Streichungen und Verschiebungen einzelner Anforderungen besser abschätzen. In der Praxis verschieben sich dadurch häufig Anwendungsfälle, die dem Kunden nicht so wichtig sind, nach hinten in spätere Iterationen. Tendenziell bekommt der Kunde so in frühen Entwicklungsrunden die Produktmerkmale, die ihm besonders wichtig sind (Business Value).

1.9.6 Produktentwicklung: weitere Runden

Mit der angepassten Planung geht es jetzt weiter. Wie vor der ersten Runde legt Maria Müller nun fest, was in den kommenden zwei Wochen entwickelt werden soll. So startet die zweite Entwicklungsrunde. Während der Entwicklung stellen sie und ihr Team fest, dass sie nicht alle Anforderungen schaffen werden, die für diese Iteration geplant sind. Frau Müller kommuniziert ihr Problem rechtzeitig an Herrn Schmidt. Vielleicht bespricht sie dabei auch mit ihm, welche Anforderungen später realisiert werden könnten. Dann reduziert sie den Umfang so, dass sie die Iteration rechtzeitig abschließen können (auf die vertraglichen Aspekte dieser »agilen« Zusammenarbeit zwischen Auftraggeber und Auftragnehmer geht das Kapitel »Der agile Festpreis« näher ein).

Den Umfang zu reduzieren und damit termintreu zu bleiben, ist ein wichtiger Unterschied zur typischen klassischen Vorgehensweise. Im klassischen Projektmanagement werden Meilensteine verschoben, wenn es eng wird. Bei der iterativen Vorgehensweise werden dagegen die Iterationsenden eingehalten und dafür der Umfang reduziert. Das ist wichtig, um das Vertrauen der Stakeholder zu erhalten und immer wieder zeitnah Feedback von ihnen zu bekommen. Frau Müller gleicht damit das Ergebnis der Produktentwicklung immer wieder mit den Vorstellungen des Kunden ab. Runde für Runde (Iteration für Iteration) nähert sie sich so dem Produkt an, das der Kunde wirklich brauchen kann. Die folgende Abbildung zeigt diese Idee des schrittweisen Nachsteuerns.

Eine wesentliche Basis für das Agile Projektmanagement ist die Erkenntnis, dass Projektanforderungen ein bewegliches Ziel darstellen,...