itemis Blog

Releasemanagement

Geschrieben von itemis | 03.09.2015

Releases (Auslieferungen) sind Zeitpunkte, an denen ein neues oder geändertes System ausgeliefert wird und von Anwendern genutzt werden kann. Zu Beginn von Projekten werden erste Releasepläne erstellt, die darstellen, welche neuen oder geänderten Funktionen ab einem bestimmten Zeitpunkt zur Verfügung stehen sollen. Bei Scrum entsteht mit jedem Sprint ein potentiell auslieferbares Produkt-Inkrement. Die Restaufwände des verbleibenden Product Backlogs nach jedem Sprint ergeben Release Burndown Charts. Wir erklären, wie diese aussehen können und wie sie bewertet werden sollten.

Fortschrittskontrolle im Sprint

Die Abbildung zeigt, wie viel Aufwand nach einzelnen Sprints zur Realisierung von Produkt 1 übrig ist. Ist der Aufwand in Stunden angegeben, bedeutet dies, es sind zehn Sprints erforderlich, um 500 Stunden Aufwand abzuarbeiten.


Es existieren sicherlich Projekte, in denen sich Anforderungen oder Rahmenbedingungen so gering verändern, dass sich tatsächlich ein Burndown Chart ähnlich dem oben angezeigten ergibt. Bei der Entwicklung komplexer (Software-)Systeme verändern sich Anforderungen jedoch immer wieder:

  • Der Kunde ändert die Priorisierung.
  • Es wird mehr Aufwand in einzelne, besonders wichtige Funktionen investiert.
  • Der Einarbeitungsaufwand in eine neue Technologie ist höher als zunächst angenommen.
  • Es existieren Anforderungen, die nicht mehr benötigt werden.

Somit ist der folgende Burndown Chart realistischer:

 
Es wird deutlich, dass zu Beginn eher Einarbeitungsaufwände anfielen, die nicht berücksichtigt worden sind, denn der Aufwand ist nach dem ersten Sprint höher oder gleich dem Aufwand wie er zu Beginn geplant worden ist.
 

Die nächste Abbildung beschreibt zusätzlich zu den Restaufwänden noch die sogenannte Velocity (Geschwindigkeit), die den abgearbeiteten Aufwand eines Sprints angibt.

Zunächst muss klar festgehalten werden, in welchem Aufwandsumfang sich Änderungen an bestehenden Anforderungen ergeben haben. Ebenfalls ist festzuhalten, in welchem Umfang neue Anforderungen eingebracht worden oder bestehende Anforderungen entfallen sind. Aus diesen Daten können dann detailliert Aussagen getroffen werden.

Die folgende Grafik stellt ein erweitertes Product Burndown Chart (PBC) dar. Auf der y-Achse sind die Aufwände in Stunden eingetragen. Auf der x-Achse sind die einzelnen Sprints zu sehen. Dieses Burndown Chart stellt dar, zu welchem Zeitpunkt das Produkt ausgeliefert worden wäre, wenn keine Änderungen vorhanden gewesen wären.


Die Linie Burndown zeigt, welche initial geplanten Aufgaben realisiert worden sind. "Remaining" gibt den übrigen Gesamtaufwand aus, "Changes" ist die Summe der Änderungen während der Projektlaufzeit. Jeder Linie ist in diesem Diagramm ein Trend zugeordnet.

Der Trend der Linie "Remaining" sagt aus, zu welcher Zeit die Entwicklung abgeschlossen ist, wenn weiterhin wie bisher Änderungen berücksichtigt werden. Aus den gesammelten Daten können weitere wichtige Kennzahlen errechnet werden. Für den Projektmanager ist es nun wichtig herauszufinden, wie viel vom initial geplanten Aufwand in der aktuellen Situation realisiert werden kann.

Folgende Kennzahlen sind erforderlich für weitere Planungsaussagen:

  • Total Burndown: gibt Auskunft darüber, wie viel Aufwand aus dem initial geplanten Aufwand pro Sprint heruntergebrannt werden kann.
  • Added Work: gibt Auskunft darüber, wie viele Änderungen sich durchschnittlich pro Sprint ergeben haben.
  • Team Burndown: gibt Auskunft darüber, wie viel Aufwand das Team real heruntergebrannt hat, inkl. der Änderungen.

Für unser Beispiel ergeben sich für die ersten 10 Sprints folgende Kennzahlen:


In angegebenem Beispiel bedeutet dies, das Team kann pro Sprint 111,5 Stunden Aufwand abarbeiten, von diesem Aufwand sind im Durchschnitt 44,5 Stunden Änderungen und 67,0 Stunden initial geplante Aufwände.

Bewertung und Ausblick

Auch in agilen Projekten müssen Releases geplant werden. Pro Sprint sind Grobschätzungen der geplanten Funktionen erforderlich, die einen Gesamtaufwand ergeben.

Werden Veränderungen und deren Gründe am initialen Plan nicht nachvollzogen, kann kein Rückschluss auf Ursachen für einen Misserfolg gezogen werden.

Diese Variante konzentriert sich auf Änderungen von Anforderungen und auf zusätzliche Anforderungen. Wenn diese protokolliert werden, ist es für den Projektleiter ein Leichtes, vor dem Kunden den Stand des Projektes zu vertreten.

Es ist mit dieser Methode zu jeder Zeit möglich, Auskunft anhand von Trends zu Realisierungszeitpunkten zu geben und ebenfalls hat der Projektleiter genügend Wissen darüber was sich gegenüber dem initialen Plan geändert hat.

Requirements Engineering mit Scrum