Hellsehen für Fortgeschrittene – Releases berechnen

Von unserem Gastblogger Dr. Oliver Ciupke 

Das Release einer Softwareentwicklung liegt immer noch oft weit hinter dem geplantem Termin und weit über Budget. Dabei stehen heutzutage Mittel zur Verfügung, mit denen man Termin und Scope nahezu ausrechnen kann. Der Schlüssel dazu ist die Erkenntnis, dass ein Großteil der verbleibenden Arbeit noch gar nicht bekannt und nur vage oder gar nicht geschätzt ist.

Im Ergebnis erhalten wir prozentuelle Abweichungen statt Faktoren und vermeiden mühsame Diskussionen, da wir weite Teile durch Fakten und Berechnungen ersetzen können.

Viele Ansätze versuchen bereits zu beurteilen, ob ein laufendes Entwicklungsprojekt noch auf dem richtigen Weg ist. Im klassischen Projektmanagement berechnete man kritische Pfade und erstellte Gantt-Diagramme. Das finanzielle Projektcontrolling vergleicht Plan und Ist-Ausgaben. Im agilen Kontext werden Velocities berechnet und Burn-Down-Charts gezeichnet. Und doch sind Unternehmen auch heute noch kurz vor dem vermeintlichen Endtermin überrascht, dass das Projekt viel mehr Zeit und Budget benötigt und/oder nur einen Bruchteil des geplanten Scopes abschließen wird. Dieser Artikel erläutert einige Gründe dafür und stellt eine Methode vor, mit der sich all diese Unwägbarkeiten und Unbekannten quantitativ erfassen lassen. Für die Diskussion verwenden wir die gebräuchlichsten Begriffe und das Vokabular aus der heutigen agilen Softwareentwicklung. Diese können leicht in die Terminologie Ihres lokalen Prozesses (auch auf der skalierten Ebene z.B. SAFe, Nexus, Less oder Custom) übersetzt werden.

Verbleibende Arbeit insgesamt

Heutzutage wird die Projektarbeit in der Regel durch das Führen eines Backlogs von Work-Items in einem Tracker wie Jira, OpenProject, Redmine oder den entsprechenden Funktionen von GitHub, GitLab usw. verwaltet. Der Begriff Backlog wird mit zwei verschiedenen Definitionen verwendet. Manchmal steht er nur für den Teil nach dem aktuellen Sprint oder sogar Release. Wir verwenden hier die Definition als komplette Liste des gesamten Projektes. Ein Work-Item (oder Backlog Item oder Issue) kann dabei eine Anforderung unterschiedlicher Granularität (Epic, Feature, Story, Task etc.) ein Bug oder Sonstiges sein. Der folgende Screenshot zeigt einen kleinen Ausschnitt eines solchen Backlogs, wie Sie es wahrscheinlich aus Ihren Projekten kennen. Das komplette Projekt (Apache Spark) enthält zum Zeitpunkt der Erstellung dieses Artikels insgesamt 44.000 Work-Items, von denen 2.600 offen sind und jeden Monat 400 neue erstellt werden.

Zur Veranschaulichung der folgenden Ausführungen stellen wir das Product Backlog in Form eines Scrum- bzw. Kanban-Boards dar. In seiner üblichen Grundform enthält es bereits erledigte, in Arbeit befindliche und noch zu erledigende Work-Items.

Dieses Bild vernachlässigt jedoch einen großen Teil der gesamten verbleibenden Arbeit. Bei Projekten von signifikantem Umfang sind nicht alle Work-Items von Anfang an bekannt. Dies ist ja einer der Hauptgründe dafür, agil zu entwickeln, anstatt in sequentiellen Phasen (“Wasserfall”). (Seltsamerweise scheint es ein häufiger Fehler zu sein, so zu handeln und zu planen, als ob Agilität Veränderungen und Unwägbarkeiten verhindern würde, anstatt nur besser damit umzugehen.) Bislang deckt das dargestellte Scrum-Board nur Themen ab, die aktuell bereits bekannt sind. Um die vollständige Arbeit zu erhalten, müssen wir jedoch auch solche einbeziehen, die erst später im Projekt entdeckt werden. Noch unbekannte und die Vernachlässigung nicht geschätzter Arbeit ist in der Regel der Hauptgrund dafür, dass Vorhersagen zu kurz greifen und um Faktoren zu optimistisch sind. Selbst wenn ein Projekt neuere Methoden zur Fortschrittsverfolgung anwendet, wie z.B. Sprint-Velocity, werden unbekannte Work-Items oft außer Acht gelassen oder nur durch einen kleinen Puffer dargestellt. Bekannte, aber noch nicht geschätzte Work-Items werden ebenfalls leicht vernachlässigt. Dies hat zur Folge, dass der Großteil der Arbeit im Effekt ignoriert oder stark unterschätzt wird. Und selbst wenn auf der operativen Ebene noch Wissen darüber vorhanden ist, kann es auf dem Weg nach oben in der Berichtskette verloren gehen. In der folgenden Abbildung teilen wir die ToDo-Spalte in geschätzte und nicht geschätzte Work-Items auf und erweitern die Tafel um unbekannte:

Berechnung des verbleibenden Aufwands

Um ein realistisches Veröffentlichungsdatum (bzw. Scope bei Time-boxing) zu prognostizieren, benötigen wir zunächst einen prognostizierten Gesamtaufwand aller Work-Items – ob bereits bekannt oder nicht. Manche Berechnungen können auf unterschiedlichen Parametern und mit unterschiedlichem Detaillierungsgrad beruhen. Zunächst erstellen wir eine erste Basisberechnung, die schnell angewendet werden kann und bereits vernünftige Ergebnisse liefert. Diese kann später leicht in verschiedene Richtungen verfeinert und die Genauigkeit erhöht werden.

Erledigte:

Erledigte Work-Items erfordern per Definition keinen unmittelbaren Aufwand. Dennoch müssen ihre Aufwände und Schätzungen nachverfolgt werden, da diese in andere Berechnungen einfließen. (In späteren Sprints bzw. Iterationen gefundene Fehler ergeben typischerweise neue Work-Items.)

In Bearbeitung:

Vereinfachend können wir Work-Items, die sich in Bearbeitung befinden (z.B. für den laufenden Sprint geplant), unter die noch zu erledigenden subsumieren. Diese Vereinfachung spiegelt den Status direkt nach einem Sprint korrekt wider, z. B. wenn ein Schnappschuss des Backlogs nach dem Sprint-Review oder während der Sprint-Planung aus dem Tracker gezogen wird.

Geschätzte Work-Items:

Wenn Sie Story Points für die Schätzung verwenden, können diese einfach aufsummiert werden. Wenn das Team stattdessen in Manntagen schätzt, müssen Sie zwischen geschätzten (a-priori unangepassten) und tatsächlichen (a-posteriori angepassten) Manntagen unterscheiden und hier erstere verwenden. (Aus Gründen der Transparenz empfehle ich, im Vorfeld vorgenommene Schätzungen immer als Story Points zu bezeichnen, auch wenn die Schätzung in Manntagen erfolgte).

Noch nicht geschätzte Work-Items:

Berechnen Sie die durchschnittliche Größe aller bisher geschätzten Work-Items (sowohl erledigte als auch nicht erledigte). (Verwenden Sie die ursprüngliche Schätzung auch für erledigte Work-Items. Der inzwischen bekannte tatsächliche Aufwand der erledigten Work-Items wird stattdessen in der Velocity berücksichtigt.) Dies liefert eine Proxy-Schätzung für alle nicht geschätzten Work-Items.

Noch unbekannte Work-Items:

Jetzt kommt der interessante Teil – der Aufwand der Work-Items, die wir in Zukunft zu erwarten haben, aber noch gar nicht kennen. Zunächst simulieren wir diese rein statistisch basierend auf der Warteschlagentheorie [Queueing theory]. Es kann aber sehr einfach in beliebige Richtungen verfeinert werden. Aus den Daten des Trackers ermitteln wir dazu die durchschnittliche Ankunftsrate λ und die durchschnittliche Größe eines Work-Items W¯. Die neue Arbeit, berechnet sich dann zu t*λ*W¯. t ist dabei die Zeit z.B. in Sprints, Iterationen oder auch Tagen. Auf den ersten Blick scheint dies konservativ zu sein. Dennoch stellt es sich im Nachhinein sehr oft näher an den tatsächlichen Releases heraus zuvor diskutiert.

Die vorangegangenen Aufwandsberechnungen sind in der folgenden Abbildung zusammenfassend dargestellt:

Releasetermin

Wir haben nun erste Formeln für den verbleibenden Aufwand. Um die verbleibende Zeit zu berechnen, definieren wir den durchschnittlichen Fortschritt als Velocity (Summe des erledigten Aufwandes pro Zeiteinheit, üblicherweise Iteration bzw. Sprint [Project Velocity]) reduziert um den Erwartungswert zukünftig neu ankommender bzw. entdeckter Aufwände. Er misst, wie schnell der bekannte Umfang reduziert wird. Der Releasetermin (bzw. Scope zu diesem) ergibt sich natürlich aus dem aktuellen Gesamtaufwand und dem Fortschritt pro Zeiteinheit. Die Zeit (Sprints, Iterationen, Tage) ist natürlich die, bis der bekannte Umfang implementiert ist bzw. andere Releasekriterien erreicht sind. Ist der Releasetermin fest (Time-Boxing) berechnet sich der bis dahin fertiggestellte Umfang (Scope) mit denselben Formeln auf umgekehrte Weise. (Da die Dauer t in beide Seiten einfließt, beißt sich die entstehende Formel theoretisch in den Schwanz. Sie kann aber als geometrische Summe gelöst werden.)

Wollte man die Entwicklung bis zum Release graphisch darstellen, käme man auf etwas Ähnliches wie Burn-Down- oder Burn-Up-Charts. Diese müssen allerdings korrekt berechnet und die Ergebnisse müssen korrekt interpretiert werden, was leider selbst in Artikeln über agile Prozesse nicht selbstverständlich ist. Zum Beispiel ist die Darstellung neu hinzugekommener Arbeit eine häufige Quelle von Missverständnissen und kann zu einem falschen Gefühl der Sicherheit verleiten.

Es ist immer noch hilfreich, eine ergänzende Visualisierung hinzuzufügen, um Diskussionen zu erleichtern. Aus den genannten Gründen empfehle ich Burn Down Charts nur für Sprint Backlogs mit relativ festem Umfang. Die bessere Option für Release- Backlogs sind stattdessen Burn-Up-Diagramme, die auf den ersten Blick komplizierter aussehen, aber weniger anfällig für Fehlinterpretationen sind. Sie können automatisch aus den oben verwendeten Daten erstellt werden [Ken Schwaber, Jeff Sutherland: Scrum Guide, Version 1, February 2010] Das folgende Bild ist ein Burn-Up-Chart, das den Stand nach der Fertigstellung der Release zeigt:

Schätzen

Schätzen ist ein unbeliebtes Thema. Entwickler wollen nicht auf einmal abgegebene Zahlen festgelegt werden und Kollegen im Kundenkontakt oder entlang der Berichtslinie scheuen unangenehme Nachrichten. Ungeschätzte Work-Items dürfen jedoch nicht vergessen und müssen entsprechend berücksichtigt werden. Da wir nur einzelne Work-Items schätzen und diese dann zusammenzählen, entspannt sich die psychologische Situation deutlich. Falls sich eine Organisation mit dem Thema dennoch schwer tut, empfiehlt es sich, dies schrittweise anzugehen und stattdessen provisorisch mit Durchschnittswerten zu arbeiten. Wir haben bisher nicht nach der Art der Work-Items unterschieden (Epic, Story, Bug, sonstiges). Ein Epic erzeugt jedoch vermutlich mehr Aufwand als eine Story und Bugs unterscheiden sich oft nach ihrer Kritikalität. Wenn Sie keine oder nur sehr wenige Schätzungen haben, können Sie den Durchschnitt der bisherigen Werte als als Proxy- Schätzungen verwenden. Schätzen ist ein eigenes Thema, sowohl was die Methodik als auch die Psychologie bzw Kommunikation angeht. [OBJEKTspektrum 1/2006, Ciupke, Charles, Vorab schätzen trotz Scrum?! Gegensätze, die keine sind] Schätzungen bleiben natürlich immer vage. Da wir jedoch nur einzelne Work-Items schätzen und die Aufwände dann aufsummieren kommen wir für das Gesamtprojekt in den Bereich des Gesetzes großer Zahlen, wodurch die Vorhersagen für das Gesamtrelease recht genau werden.

Weitere Themen und Überlegungen

• Ein Projekt in einem Tracker erstreckt sich in der Regel über mehrere Versionen und oft auch über mehrere Produkte. Für welches davon ein bestimmtes Work-Item geplant ist, kann durch Labels, spezielle Spalten, Kommentare oder Notizen angezeigt werden. Manchmal wird es auch nur indirekt angedeutet, z.B. durch die Priorität. Das Identifizieren und Filtern von Work-Items, die sich auf ein zu berechnendes Release beziehen, ist einer der häufigsten Vorbereitungsschritte.
• Fehler können auf ähnliche Weise einem bestimmten Release zugeordnet werden, aber es kann auch ein abstraktes Akzeptanzkriterium wie eine maximale Kritikalität oder eine zulässige Anzahl von Fehlern pro Kritikalität geben. Dies muss im entsprechenden Teil der Restarbeit berücksichtigt werden.
• Um Durchschnittswerte zu berechnen, müssen Sie einen repräsentativen Zeitabschnitt auswählen. In der Regel ist es eine gute Idee, den Anfang des Projekts auszulassen, solange sich einige Parameter noch einpendeln.

Praktische Umsetzung

• Die Berichtsfunktionen der meisten Tracker sind in der Praxis begrenzt, insbesondere haben sie wenig Möglichkeiten für Berechnungen (viele sind aus reinen Fehlerverfolgungsprogrammen hervorgegangen, daher auch noch häufig die Bezeichnung “Issue-Tracker”). Für ein erstes schnelles Ergebnis können Sie natürlich den Backlog exportieren und einige Berechnungen in einer Tabellenkalkulation durchführen. Bei regelmäßigen Aktualisierungen oder größeren Projekten mit Tausenden von Work-Items wird dieser Ansatz jedoch unpraktikabel.
• Excel (oder ähnliche Programme) werden schnell träge, und die manuelle Bearbeitung ist sehr fehleranfällig. Datenexporte können zudem unerwartet kompliziert sein. Jira zum Beispiel hat eine feste Grenze für Exporte von 1000 Vorgängen, so dass mehrere Exportläufe korrekt kombiniert werden müssen. Außerdem können neue oder aktualisierte Vorgänge sogar die Spaltenmenge verändern. Bei fortgeschrittenen Berechnungen werden die Tabellen schnell unübersichtlich.
• In der Regel ist eine gewisse Datenbereinigung erforderlich. So können beispielsweise verschiedene Teams unterschiedliche Konventionen anwenden, Daten können fehlen oder müssen aus Labels, Notizen oder externen Quellen extrahiert werden. Die meisten dieser Schritte müssen bei jeder Aktualisierung wiederholt werden.
• Unsere Tools sind auf der Grundlage von Data-Science-Bibliotheken implementiert, die eine Verarbeitung großer Datensätze ermöglichen. Die Informationen werden direkt von den Issue-Trackern gesammelt, z.B. über deren APIs. Aktualisierungen erfordern dann nur einen erneuten Durchlauf. Tabellenkalkulationen können nach wie vor nützlich sein, um die berechneten Ergebnisse zu präsentieren und zu verteilen.

Zusammenfassung

Die vorgestellte Berechnung liefert für die meisten Softwareentwicklungsprojekte mit modernen Projektmanagementmitteln gute Ergebnisse. Sie basiert auf der Analyse des Backlogs mit Work-Items, die einzeln noch auf Schätzungen und Entscheidungen beruhen. Da wir aber über viele davon summieren und extrapolieren, kommen wir in den statistischen Bereich des Gesetzes der großen Zahlen. Die Berechnung ist sogar so angelegt, dass systematische Fehler und Fehleinschätzungen berücksichtigt werden, solange sich ihr Ausmaß nicht plötzlich ändert. Realistische Prognosen sind das Werkzeug, um die richtigen Entscheidungen zu treffen. Es liegt in der Natur der Sache, dass dies schlechte Nachrichten bedeuten kann. Aber bedenken Sie, dass es immer einfacher ist, unangenehme Folgen so früh wie möglich zu bewältigen. Andernfalls werden Entscheidungen auf einen späteren Zeitpunkt verschoben, wenn die notwendigen Maßnahmen viel teurer werden. Die verbleibenden Unwägbarkeiten werden auf einen Bereich begrenzt, der kaum Eskalationen nach sich zieht und auf operativer Ebene gehandhabt werden kann, was ihn zu einem echten “Game Changer” macht. Die automatische Implementierung liefert Daten zu geringen Aktualisierungskosten in Echtzeit. Erforderliche Maßnahmen können viel früher besprochen und umgesetzt werden, wodurch unnötige Anstrengungen und Kosten vermieden werden. Bei Fragen können Sie mich gerne über oliver.ciupke@gmail.com oder LinkedIn kontaktieren. Bitte nennen Sie dabei das Thema.