
Peter Scheiwiller
27.06.2013
- Anmelden oder Registieren, um Kommentare verfassen zu können
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird die Projektplanung in einem Burn-down-Chart visualisiert. Im ersten Teil der Artikelserie stellt Ihnen Steffen Thols nach einer Gegenüberstellung klassischer und agiler Projektplanung eine alternative Darstellungsform agiler Projektplanung – den Burn-up-Chart – vor. Und er erklärt, in welchem Kontext sich dieser besser einsetzen lässt.
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird die Projektplanung in einem Burn-down-Chart visualisiert. Im ersten Teil der Artikelserie stellt Ihnen Steffen Thols nach einer Gegenüberstellung klassischer und agiler Projektplanung eine alternative Darstellungsform agiler Projektplanung – den Burn-up-Chart – vor. Und er erklärt, in welchem Kontext sich dieser besser einsetzen lässt.
Ein wichtiges Merkmal von agil durchgeführten Projekten ist die iterative Entwicklung. Diese bietet die Möglichkeit, auf Änderungen schnell zu reagieren und notwendige Anpassungen zu einem frühen Zeitpunkt vorzunehmen. So vorteilhaft dieses Vorgehen in dieser Hinsicht ist, so anspruchsvoll macht dies die Planung des Projekts oder der Releases. Da es keinen vorausberechneten Projektplan als Netzdiagramm oder Gantt-Chart gibt, kann auch kein Soll-Ist-Vergleich vorgenommen werden, ob das Projekt im Plan ist. Stattdessen wird der Projektfortschritt aus den erreichten Ergebnissen der abgelaufenen Iterationen abgeleitet.
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird für die Planung ein Burn-down-Chart angeboten. In ersten Teil der Artikelserie lernen Sie eine alternative Darstellungsform – den Burn-up-Chart – kennen und in welchem Kontext diese besser geeignet ist als der allgemein gebräuchliche Burn-down-Chart. Im zweiten Teil der Artikelserie erhalten Sie eine Vorlage für einen Burn-up-Chart in Form eines Excel-Spreadsheet. Anhand einer detaillierten Beschreibung und eines konkreten Beispiels erfahren Sie auch, wie Sie diese Vorlage anwenden, um einen Burn-up-Chart zu erstellen, der Ihren Projektanforderungen entspricht.
Die Planung sog. "traditioneller" Projekte erfolgt häufig nach diesem Muster: Zunächst werden die Projektziele definiert. Dann werden das Projektumfeld und die Stakeholder analysiert. Daran schließt sich eine erste Risikoeinschätzung an und es werden Maßnahmen zur Verringerung der Risiken abgeleitet.
Nachdem eine für das Unternehmen passende Projektorganisation ausgewählt wurde, kommt es nun zur Planung des Projekts (Bild 1), die z.B. folgendermaßen abläuft:
Bild 1: Traditionelle sequentielle Projektplanung.
Der Vorteil eines derartigen Vorgehens liegt darin, dass es das Projekt stark strukturiert und ungeübte Projektmitarbeiter ziemlich genaue Anweisungen haben, wie sie vorgehen sollten.
Ein Nachteil liegt darin, dass der Auftraggeber bei perfekter Durchführung des Plans genau das bekommen wird, was zu Beginn des Projektes vereinbart wurde, und nicht das, was er mittlerweile tatsächlich benötigt. Mittlerweile deshalb, weil gerade bei langlaufenden Projekten neue Erkenntnisse im Projektverlauf zu neuen Anforderungen führen können. Eine Änderung an Anforderungen kann hier aber nur durch Change Requests dargestellt werden, was zur Folge hat, dass alle damit zusammenhängenden Pläne angepasst werden müssen.
Des Weiteren führen meiner Erfahrung nach häufig nicht diejenigen Mitarbeiter die Planung durch, die später an der Umsetzung beteiligt sind. Die Folge davon kann sein, dass die Festlegungen, die erfahrene Entwickler und/oder Architekten vorgenommen haben, nicht eingehalten werden können, da die Umsetzung durch weniger erfahrene Entwickler erfolgt.
Die Tätigkeiten im Rahmen der Planung verteilen sich auf einen großen Arbeitsaufwand vor bzw. zu Beginn des Projekts. Im laufenden Projekt ist der Projektleiter dann hauptsächlich damit beschäftigt, den Fertigstellungsgrad (Ist-Zustand) abzufragen, mit dem geplanten Fortschritt (Soll-Zustand) zu vergleichen und ggf. Maßnahmen einzuleiten, falls die Budget- und Terminhochrechnungen, z.B. mit Hilfe einer Earned-Value-Analyse, eine Abweichung vom Plan ergeben.
Bei Scrum, dem bekanntesten Vertreter agiler Vorgehensweisen, erfolgt kein derartiges "Big Planning Upfront". Auch wenn Scrum dies nicht explizit vorschreibt, sollten natürlich die ersten Schritte einer Projektinitiierung, also die Definition der Projektziele, eine erste Umfeld- und Stakeholder-Analyse sowie eine Risikoeinschätzung inklusive Maßnahmen zur Verringerung der Risiken ebenso vorgenommen werden.
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
27.06.2013
29.06.2013
29.06.2013
22.07.2013
29.07.2013
Wolfram Müller (Speed4Projects.Net)
26.06.2013