Schlankes agiles PM: Anwendung agiler und schlanker Ansätze auf das Projektmanagement
von Steve Blais
Die Umsetzung von Veränderungen im Softwareentwicklungsprozess ist der Knackpunkt für alle Entwicklungsprojekte. Bei linearen Methoden besteht über die Umsetzung von Veränderungen ein genereller Konsens, die gesammelten Anforderungen zu einem bestimmten Zeitpunkt einzufrieren. Veränderungen werden nicht verhindert und neue Anforderungen werden nicht ausgeschlossen. Durch das Einfrieren wird der Veränderungsprozess nur langsamer, da alle Veränderungen dem Management begründet werden müssen, bevor sie eingeführt werden.
Der Vorteil der linearen Methode ist, dass notwendige und zweckmäßige Veränderungen mit Augenmaß angegangen und in einem geregelten Umfeld dokumentiert werden. Der Nachteil: Veränderungen brauchen Zeit. Der Kunde und das Entwicklungsteam finden den Prozess oft bürokratisch, zeitraubend, mit unnötigen Mehrkosten verbunden und unnötig.
Der Fokus des Projektmanagers ist darauf gerichtet, die Auswirkungen von Veränderungen auf das laufende Projekt zu minimieren, um den Zeitplan und die Ressourcenvorgaben einzuhalten. PM-Tools eignen sich hervorragend, um die Auswirkungen auf das Projekt während der Veränderung festzustellen: nehmen Sie neue Anforderungen auf, durch die sich eine Aufgabe um ein paar Tage verlängert, und schauen Sie sich die Konsequenzen für das restliche Projekt an! Ein PM-Tool zeigt Ihnen aber nicht die Auswirkungen von nicht umgesetzten Veränderungen: was sind die Folgen für das Unternehmen oder den letztendlichen Produkterfolg?
In der dynamischen Geschäftswelt von heute müssen wir unseren Projektplanungsfokus von einem umfassenden Kontrollveränderungsprozess zu einem adaptiven Prozess, der Veränderungen aktiv aufnimmt, verlagern: ein Prozess, der Unternehmenserfordernissen egal wann Rechnung trägt – ein Prozess, der flexibel genug ist, selbst den Prozess zu verändern. Mit einem Wort: wir brauchen einen agilen Entwicklungsprozess.
Durch agile Methoden der Softwareentwicklung wurden eine Reihe von Ansätzen eingeführt, die zur Flexibilität und Reaktivität eines Softwareentwicklungsprojekts beitragen können. Diese Ansätze sind nicht auf Scrum, Extreme Programming (XP), Feature Driven Development (FDD), Microsoft® Solutions Framework (MSF) und sonstige als Marke geschützte agile Methoden und Prozesse beschränkt. Alle Entwicklungsprozesse profitieren von der Implementierung der agilen Basisansätze solcher Methoden. Inkrementale Iteration
Der Vorteil eines Agile-Ansatzes, des iterativen, besteht darin, dass Veränderungen in einem laufenden Projekt ohne Auswirkungen auf das Projekt eingeführt werden können. Dieser Ansatz bricht das Gesamtprodukt in kleinere Teile herunter. Beispiele: ein Stapel Indexkarten mit Anwenderberichten, die die gewünschte Funktionalität definieren; eine Liste der Features, die in einer Gruppe zusammengefasst werden; eine Auswahl der Anforderungen einer Auftragsbestandsliste der erforderlichen Lösungselemente.
Jede Iteration des Lebenszyklus der Softwareentwicklung (Definition von Anforderungen, Analyse, Design, Code und Test) wiederholt oft dieselben Phasen und führt zu mehreren Teilergebnissen. Jede sukzessive Iteration
- durchläuft denselben Entwicklungsprozess wie die erste;
- bringt vor Beginn der nächsten Iteration mehr Wert für den Kunden, damit er den Zwischenstatus prüfen und freigeben kann;
- ermöglicht die Einführung von Veränderungen am Ende jeder Iteration;
- kann eine separate Aufgabe im Rahmen des Gesamt- oder Einzelprojekts sein.
Der Kunde und das Entwicklungsteam kooperieren bei der Auswahl der spezifischen Ziele jeder Iteration. Die Gesamtfunktionalität, die jede Sollgröße erbringt, wird mit einem anderen Agile- Ansatz ermittelt: der Timebox.
Mit Timeboxing fragt der Projektmanager: “Wie viel dieser Lösung kann in diesem Zeitrahmen erreicht werden” (wie viele Anwenderberichte, Features, Anforderungen)? Zeitrahmen sind i.d.R. kurz – zwei bis vier Wochen. In der Summe erlauben sie eine realistischere Abschätzung für die Gesamtlösung.
Der Kunde legt Prioritäten fest, die Entwickler geben Abschätzungen ab. Dann wird ein kleiner Teil der Gesamtlösung entwickelt. In einigen Wochen sieht der Kunde die Ergebnisse. So kann er die Arbeiten besser nachvollziehen und zeitnah darauf reagieren. Das gesamte Produkt wird also nicht in einem Leistungsverzeichnis, das Monate zuvor genehmigt wurde, definiert.
Jede inkrementale Iteration bringt das Produkt der Fertigstellung einen Schritt näher. Und der Kunde hat am Ende jeder Iteration die Option, den eingeschlagenen Kurs fortzusetzen, Änderungen vorzunehmen oder das Projekt sogar zu stoppen. Jede Option ist ein positives Ergebnis für das Projekt.
Alle an einen Tisch
Bei einem anderen Agile-Basisansatz, der frühzeitigen und häufigen Einbindung des Kunden in den Softwareentwicklungsprozess, ist der Kunde im Entwicklungsteam vertreten. Der Vertreter wird je nach Agile-Marke als “On-Site-Kunde,” “Domain-Experte” oder “Produkteigentümer” bezeichnet.
Egal ob der Vertreter als Anwender oder als kleines Anwenderteam mit dem Entwicklungsteam kooperiert und zur Beantwortung von Fragen und Erteilung von Anweisungen zur Verfügung stet, wissen das Entwicklungsteam und der Kunde, dass sie im selben Boot mit demselben Ziel sitzen: das Unternehmensproblem zu lösen.
Dazu gehört auch, dass der Kunde Widerstände gegen Agile-Ansätze hat. Organisationen sind i.d.R. nicht geneigt, Ressourcen in ein Vollzeit-Entwicklungsteam zu stecken. Der Agile-Standpunkt ist der, dass der Kunde begreifen muss, dass die Qualität der erbrachten Lösung proportional zu der Zeit, die er mit dem Lösungsteam verbringt, steigt..
Durch häufigere Kontakte mit dem Kunden lernt das Entwicklungsteam die Sprache und Fragen hinter dem zu lösenden Problem kennen und ist besser in der Lage, die richtige Lösung zu finden. Der Kunde lernt die Schwierigkeiten und Kompromisse, die zur Softwareentwicklung gehören, kennen. Beide Seiten lernen mehr über den Problembereich und die resultierende Lösung. Selbst wenn nur gegenseitiges Verständnis besteht, wird die Kooperation intensiver und die Lösung agiler und flexibler.
Einfach halten
Der Basisansatz, der dem gesamten Agile-Prozess zugrundeliegt, ist “alles so einfach wie möglich machen.” Bei agilen Prozessen wird nur so viel Software geschrieben, damit das Unternehmensproblem gelöst wird, und was sofort verwendet werden kann. Das bedeutet: nur so viele Anforderungen, nur so viel Design und nur so viele Tests, wie nötig: ein schlankes Konzept, bei dem alles just in time ist.
Agile Methoden unterstützen auch das Refactoring: durch Einplanen von Zeit zur Vereinfachung von Code und Design werden unnötige oder redundante Elemente ausgeschlossen.
Durch ein einfacheres Produkt und einen einfacheren Prozess werden auch Änderungen daran einfacher. Wenn Produkt und Prozess schlank gehalten werden, kann der Projektmanager Veränderungen aktiv angehen, statt sie zu fürchten.
Fazit
Die schnellste und qualitativ hochwertigste Lösung ist eine Lösung, die einfach das Unternehmensproblem löst. Bei agilen Ansätzen geht es immer darum, den Fokus der Softwareentwicklung unter Einsatz von IT-Technologie auf die Lösung von Unternehmensproblemen auszurichten. Durch möglichst einfache Fokussierung des Unternehmensproblems wird der Prozess reaktiv, flexibel und letztendlich agil.
Das Projektmanagement muss sich ständig fragen: “Bringt uns diese Aktivität bei der Problemlösung weiter?” Durch Ausschluss von Aktivitäten, die zu negativen oder auch nur fraglichen Antworten führen, und Konzentration auf Aktivitäten, die das Projekt in die richtige Richtung lenken, wird das Gesamtprojekt agiler.
|