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.
No responses yet