Projektmanagement

Herausforderung

Planbarkeit trotz Agilität

Die ersten Arbeiten an der Software begannen bereits im Jahr 2008. Damals war ein Entwicklungsvorgehen nach dem Wasserfall­modell noch die Regel und das zugehörige Projektmanagement und -controlling war daher prinzipbedingt sehr geradlinig und einfach. Doch mit dem Siegeszug der agilen Methoden hielt auch in diesem Projekt ein Scrum-ähnliches Vorgehen Einzug und die Entwicklungsarbeit entzog sich damit in mancher Hinsicht den üblichen Methoden des Projektmanagements und vor allem auch des Projektcontrollings.

Zu Beginn des Projekts war das Projektvorgehen eine sehr undifferenzierte Mischung zwischen agilen Fragmenten und traditio­nellem Vorgehen. Es gab zwar Sprints, doch waren dieser eigentlich nur eine mehr oder minder willkürliche Unterteilung des nach traditionellen Mustern ablaufenden Entwicklungsflusses. Die umzusetzenden Umfänge waren eigentlich doch wie vorher von Anfang definiert und das zur Verfügung stehende Budget ebenso wie die Zeitschiene festgelegt. Dadurch konnten die Vorteile die der Ansatz eines agilen Vorgehens mit sich bringen sollte, nie wirklich ausgespielt werden und trotzdem litt bereits die Planbarkeit durch die - zumindest vordergründig vorhandene - Agilität. Es musste also ein Vorgehen im Projektmanagement und -controlling entwickelt werden, das die Vorteile des agilen Vorgehens zulässt und trotzdem ausreichende Planbarkeit gewährleistet.

Lösung

Agilität in der Makrosicht, aber stringente Planung der Nahziele

Um zeitliche und wirtschaftliche Planbarkeit trotz agilem Entwicklungsvorgehen zu erreichen, wurde ein exakt ineinander­greifendes Räderwerk auf Basis von atmenden 3-Wochen-Sprints entwickelt. Ausgangspunkt sind die Kundenanforderungen in genau der Clusterung (in Form von Jira-Epics), wie sie vom Kunden jeweils als eine Einheit angesehen werden. Diese Epics werden in eine zeitliche Reihenfolge gebracht und grob abgeschätzt (budgetiert). Relativ knapp vor der geplanten Umsetzung eines Epics wird der jeweils zu implementierende Umfang so spezifiziert, dass sowohl für die Entwickler, als auch für die Tester eine belast­bare Referenz vorliegt. Auf Basis der Spezifikation werden dann einzelne Umsetzungstickets erstellt (User Stories, Improvements, etc.) und diese dann konkret abgeschätzt (und zwar in Stunden und nicht in Storypoints). Diese Summe der Schätzungen in den Einzeltickets erweitert um Abschätzungen der zu erwartenden Zeiten für Meetings, Bugfixing, etc. ersetzt dann - nach Freigabe durch den Kunden - die ursprüngliche Grobschätzung.

Die entstandenen Tickets werden dann so in die 3-Wochen-Sprints eingeplant, dass am Ende eines Sprints eine neue Version der Software mit einem in sich geschlossenen, erweiterten Funktionsumfang bereitgestellt werden kann. Um Planungsunsicherheiten wirkungsvoll zu begegnen, wird bereits zu Sprintbeginn festgelegt, welche Tickets mindestens in der nächsten Version enthalten sein müssen und welche bei Bedarf verschoben werden können. Da die Entwickler in der Regel an mehreren, mehr oder weniger unabhängigen Code-Teilen arbeiten müssen, um sich nicht gegenseitig zu behindern, ist diese Festlegung des Mindestumfangs nicht immer einfach, aber ein wesentlicher Baustein für einen erfolgreichen Sprintablauf. In der Praxis steht in etwa 90% der Sprints rechtzeitig zum Sprintende eine neue Version zur Verfügung, die dann auch so an die Software-Tester übergeben werden kann. In Einzelfällen kommt es vor, dass zum Sprintende noch kein sinnvoll testbarer Funktionshub erreicht wurde. In diesem Fall wird die Fertigstellung der Version in den Beginn des Folgesprints verschoben. Das zeitliche Raster der Sprints ändert sich also nicht, lediglich die Fertigstellung einer Version verzögert sich um wenige Tage.

Die für die Entwicklungsarbeit benötigte Zeit wird vollständig auf die jeweiligen Tickets gebucht, bei signifikanten Überschreitungen der jeweils geschätzten Zeiten werden die Ursachen analysiert und — sofern nötig — entsprechende Maßnahmen eingeleitet. Durch Aufsummierung aller Zeiten auf Epic-Ebene inklusive einer Extrapolation der noch zu erwartenden Bugfixing-Aufwände für noch nicht abgeschätzte oder noch gar nicht erkannte Fehler ist sehr früh erkennbar, wie das Verhältnis des Gesamtbudgets zu den noch umzusetzenden Anforderungen ist.

Mehrwert

Planen und Messen UND agile Entwicklung

Die Anpassung des Projektmanagements an die Ideen und Konzepte der agilen Softwareentwicklung hat es ermöglicht, die Vorteile der Agilität zu nutzen, ohne völlig auf die Planbarkeit und Messbarkeit der Entwicklungsarbeiten zu verzichten. Nun ist es möglich, auf sich ändernde Anforderungen rasch zu reagieren und dabei trotzdem die Abläufe innerhalb der Sprintzyklen gut zu koordinieren. Die Budget, Meilenstein und Terminplanung ist jederzeit transparent, wenngleich natürlich nicht so statisch wie in klassischen Projekten.

Die angewandete Methodik eignet sich für alle Softwareprojekte mit Teams, die mindestens 2 Entwickler umfassen und/oder bei denen eine kontinuierliche Weiterentwicklung über einen längeren Zeitraum geplant ist. Wir bieten unsere Leistungen in diesem Bereich sowohl unabhängig von der eigentlichen Entwicklungsleistung, als auch in Kombination mit der agilen Software-Entwicklung an, um damit insbesondere mittelständische Unternehmen bei der Bereitstellung hochwertiger, individueller Software-Lösungen zu unterstützen.