Case Study Das Ideal der agilen Softwareentwicklung, bei dem ein sich selbst organisierendes Team in 14-tägigen Sprints iterativ und weitgehend frei von äußeren Einflüssen wie Zeit, Budget und konkreten Spezifikationen die ideale Lösung für die Kundenanforderung erarbeitet, ist in der Realität der meisten Unternehmen - insbesondere wenn externe Dienstleister mit der Entwicklung beauftragt werden sollen - nicht zu halten. Es versteht sich von selbst, dass die Rahmenbedingungen für Zeit und Budget essenzieller Bestandteil der Vertragsgestaltung sein müssen und der völlige Verzicht auf detaillierte Spezifikationen führt spätestens bei der kontinuierlichen Weiterentwicklung bzw. Erweiterung von Software oft zu Inkonsistenzen innerhalb der Applikation. Wenn alles im steten Fluss ist und Lösungen für ähnliche oder gar gleiche Anforderungen in verschiedenen Teilen der Applikation zu verschiedenen Zeiten von verschiedenen Entwicklern iterativ umgesetzt werden, entsteht zwangsläufig ein weder für Entwickler noch für Anwender verständliches Gesamtsystem. Unser Kunde ist ein namhafter Automobilhersteller mit Hauptsitz in München. Seit vielen Jahren übernehmen wir für unseren Kunden das Projektmanagement in einem Entwicklungsprojekt für eine intern eingesetzte Applikation zur Planung und Steuerung der Systemintegration und Absicherung im Gesamtfahrzeug. Kunde: Großer Automobilhersteller in München (Hauptsitz), ca. 125.000 Mitarbeiter (weltweit) Projekt: Multi-Tier-Applikation (Server, Datenbank, Desktop-Client (.NET) und Web-Client (React)), mit 365000 Lines of Code Teamgröße: 11 Projektvorgehen: Agil (Scrum-ähnlich) Tracking-System: Atlassian Jira
Herausforderung Planbarkeit trotz Agilität Die ersten Arbeiten an der Software begannen bereits im Jahr 2008. Damals war ein Entwicklungsvorgehen nach dem Wasserfallmodell 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 traditionellem 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 ineinandergreifendes 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 belastbare 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.