Agiles Projektmanagement mit Erfolg einsetzen (02) – Kundenanforderungen

CJeske — Sat, 31 Aug 2013 09:49:13 +0000

Der Kunde weiß aus seiner Erfahrung, wie unwahrscheinlich es ist, dass das Team ein System liefert, das den Kundenwünschen entspricht. Das Team hat wiederum die Erfahrung gemacht, dass der Kunde nicht weiß, was er will, und in dem Moment, in dem das Team glaubt, die Kundenwünsche zu kennen, seine Meinung erneut ändert.[…]

– Ken Schwaber: Agiles Projektmanagement mit Scrum. Washington 2007, S. 56 –

Mit meinem ersten Beitrag zum agilen Projektmanagement bin ich mittendrin eingestiegen, ohne jedoch den ersten Schritt anzugeben: Aber am Anfang eines Projektes steht immer die Kundenanforderung. Das obere Zitat von Ken Schwaber, der mit Jeff Sutherland zusammen Scrum entwickelte, trifft oft die Problematik der Anfangssituation.

Aber wie kommt es dazu?

In den meisten Softwarefirmen wird das Wasserfall-Modell oder das V-Modell eingesetzt. Sie beschreiben einen Fluss von mehreren Punkten. Meistens Analyse- und Definition, Entwurf, Implementierung und Test. Nach jedem Punkt wird den Stakeholdern, also allen am Projekt Interessierten, die Ergebnisse präsentiert und überprüft, ob sich das Projekt in die richtige Richtung bewegt. Je tiefer im Projekt oder „Wasserfall“, desto schwerer oder kostenintensiver ist es, frühere unbeachtete Fehler zu korrigieren. Die Vorstellung, man fällt wirklich einen Wasserfall herunter zeigt deutlich: Es ist unmöglich wieder hoch zu schwimmen. Es sei denn, man bestelle einen Kran, der einen wieder hochzieht. Somit ist auch der Kunde daran interessiert, spät entdeckte Fehler oder Fehlinterpretationen zu ignorieren, damit seine Projektkosten nicht explodieren. Das Ergebnis ist ein Produkt, welches nur zum Teil oder im schlimmsten Fall gar nicht den Kundenanforderungen entspricht. Die Bezeichnung Wasserfall Modell passt somit wie die Faust aufs Auge. Viele Projekte ertrinken unterwegs.

Aber was macht Agiles Projektmanagement besser und wo liegen seine Vorteile? Es beruft sich auf kurze Iterationen und Inspektionszyklen. Am Anfang steht bei Scrum eine Kundenvision. Sie enthält den erwarteten ROI, die Releases und Meilensteine. Daraus entwickelt der Kunde zusammen mit dem Product Owner den sogenannten Product Backlog mit allen sich abzeichnenden Anforderungen. Das Team wählt nun aus diesem Product Backlog in dem sogenannten Sprint Planning Meeting Funktionen aus, welche sie innerhalb des nächsten Sprints (30 Tage) zu einem demonstrierbaren Prototyp entwickeln können. Mit diesem Sprint Backlog fängt das Team an zu entwickeln und überprüft alle 24 Stunden im Daily Scrum den Fortschritt. Am Ende jedes Sprints können der Product Owner und die Stakeholder das Projekt im Sprint Review Meeting anpassen.

Der Unterschied ist enorm. Dadurch, dass der Kunde alle 30 Tage Funktionen sieht, kann er Wünsche und Korrekturen kostengünstig äußern und umsetzten. Er sieht, was möglich ist und bekommt genau das, was er wünscht. Durch diese persönliche Einbindung des Kunden wird das Projekt qualitativ hochwertiger und der Softwareentwicklungsprozess schneller. Die Kundenvision, welche am Anfang stand, kann der Kunde durch Sehen des Machbaren immer neu ausrichten und diese folglich von Sprint zu Sprint immer realer erscheinen lassen.

Durch diese einfachen Methoden der kurzen Iteration kann man dem Fluch der Lasten- und Pflichtenhefte entkommen und den Kunden und das Entwicklungsteam wieder näher zusammenbringen.

Das Problempotenzial wird drastisch verringert und beide Seiten können Missverständnisse schneller korrigieren. Dadurch sind alle Beteiligten positiver gestimmt und bekommen ein zufriedenstellendes Ergebnis.

Agiles Projektmanagement mit Erfolg einsetzten (01) – Meetings

CJeske — Mon, 17 Jun 2013 09:01:16 +0000

Seit je her bin ich im Projektgeschäft tätig. Schon in meiner Ausbildung habe ich individuelle Lösungen für Kunden programmiert, wobei Kundenorientierung immer im Vordergrund stand. Frühzeitig habe ich erkannt, dass Pflichten- oder Lastenhefte Vor- und Nachteile haben. Wenn ich zurückblicke sind die besseren Projekte durch klar definierte Ziele aus Anwendersicht geprägt worden und kamen ohne solche Anforderungslisten aus. Mit diesem ersten Beitrag möchte ich eine Serie starten, mit der ich meine Erfahrungen mit agiler Softwareentwicklung und agilem Projektmanagement berichte.

Mit agilem Projektmanagement können Projekte rapide und effizient zum Erfolg geführt werden. Schnelles Feedback und kurze Entwicklungszyklen fördern deutlich die Qualität und bewahren vor Fehlentwicklung. Leider gibt es auch viele Stolpersteine, wodurch die anfänglichen Ziele weit verfehlt werden können.

Ein großes Problem in der Softwareentwicklung ist das „Vorbeiprogrammieren am Kunden“. Ziele müssen klar aus Anwendungssicht formuliert sein. Ist das endgültige Produkt falsch beschrieben, können nachträgliche Änderungen ziemlich teuer werden.

Richtig eingesetzt kann agiles Projektmanagement verhindern, dass ein Produkt entwickelt wird, welches den Anforderungen der Benutzer nur zum Teil oder gar nicht entspricht. Eine essentielle Voraussetzung besteht in der stetigen Kommunikation zwischen allen Projektbetroffenen. Durch wöchentliche Meetings mit den Stakeholdern (Interessenten) und täglichen Meetings des Projektteams kann ein effizientes Exceptionmanagement (Abweichungsmanagement) aufgebaut werden. In der Praxis können so schwammig definierte Projektpunkte konkretisiert und schnell korrigiert werden, falls die Entwicklung sich in die falsche Richtung bewegt.

Allerdings stellen genau diese Meetings gleichzeitig die ersten Stolpersteine dar und dies in mehreren Aspekten.

Aspekt 1: Die Meetings müssen zeitlich begrenzt sein. Sie dürfen nicht zu lange dauern. Die täglichen Meetings sollten sich an einem Zeitfenster zwischen fünf und zehn Minuten halten und die wöchentlichen Meeting nicht über eine Stunde hinausgehen. Zu schnell wird sonst dazu geneigt, Themen zu zerreden und das Projekt unnötig in die Länge zu ziehen. Natürlich sollten bestimmte Problemstellungen zwischen den Verantwortlichen länger besprochen werden. Es ist stets bei den Meetings zu beachten, das es um das weitere Vorgehen im Projekt als Ganzes geht und Teilaufgaben nur als „in Arbeit“, „nicht gestartet“ oder „fertig gestellt“ besprochen werden mit der Angabe, wann noch offene Punkte abgearbeitet sein sollen. Dadurch haben alle Teammitglieder eine Übersicht über den Projektfortschritt.

Das wöchentliche Meeting hat zum Ziel den Stakeholdern eine Übersicht über die schon fertig gestellten Projektschritte zu geben und wie man im geplanten Zeitrahmen steht. Fragen, die beantwortet werden sollten, sind zum Beispiel: „Bewegt sich das Projekt in die richtige Richtung?“, „Werden in den schon fertig gestellten Teilaufgaben alle definierten Punkte richtig umgesetzt?“ oder „Befindet sich das Projekt im vereinbarten Zeit- und Kostenrahmen?“. Bei Meilensteinen sollte das Produkt auch immer zumindest als Prototyp mit den definierten Punkten präsentiert werden. Dadurch haben die Stakeholder auch konkrete Berührungspunkte zum Projekt und Missverständnisse können schneller erkannt und geklärt werden. Hier sollten auch Änderungen von Projektpunkten besprochen werden.

Die Umsetzung dieses Konzeptes mit Beachtung seiner einzelnen Aspekte erfordert ein hohes Maß an Disziplin. Helfen können genaue Rollenverteilungen. Beim Einsatz des Scrum-Vorgehensmodells für agiles Projektmanagement von Jeff Sutherland und Ken Schwaber werden zum Beispiel sechs verschiedene Rollen verteilt. Dabei ist der Scrum-Master für die korrekte Einhaltung der Prozesse zuständig. (Die anderen Rollen: Entwicklungsteam, Product Owner Management, Customer und User werde ich in weiteren Einträgen dieser Serie genauer erklären)

Durch ein erfolgreiches agiles Projektmanagement kann ein Produkt schnell, kostengünstig und qualitativ hochwertig fertig gestellt werden. Jedoch erfordert dies die Disziplin aller Beteiligten und das Umdenken weg vom klassischen Pflicht- und Lastenheft, hin zu einer klar aus Anwendungssicht formulierten Zielsetzung.

Scrum – Chris' IT Guide to The Galaxy

Agiles Projektmanagement mit Erfolg einsetzen (02) – Kundenanforderungen

Agiles Projektmanagement mit Erfolg einsetzten (01) – Meetings