Releaseplanung

Releaseplanung

Die Releaseplanung wird  von 3 Steuerungsgrößen bestimmt, so unterscheidet man bei der Softwareentwicklung:

1. Funktionsumfang
2. Ressourcen
3. und Zeit

Diese 3 Faktoren beeinflussen sich gegenseitig und bestimmte die Planung eines Releases.

Auch die Qualität kann als weitere, 4 Größe mit aufgenommen werden.

So müssen verschiedene Aktivitäten aufeinander abgestimmt werden, man spricht auch von einer Rendevouz-Planung. Vertrieb, Marketing, Schulungen etc. müssen auf den Termin und Veröffentlichung der Features des neuen Software-Releases abgestimmt werden.

Das Investitionsmanagement stellt das Budget für das Projekt bereit. Durch eine Releaseplanung kann ermittelt werden wie hoch dieses Budget ausfallen muss.

Zunächst kostet das Projekt, bis man die maximale Investition erreicht hat, von da an hat man den Selbstfinanzierungspunkt erreicht und das Projekt beginnt sich zu rechnen, sobald es den Breakeven-Punkt erreicht hat und so mehr abwirft, als es gekostet hat.

So wird der ROI, der Return of Investment kontinuierlich beobachtet.

Release-Container

Die Releaseplanung kann:

1. Scopebasiert sein und sich am Funktionsumfang orientieren
2. Zeitbasiert sein und sich nach einem Liefertermin orientieren und Timeboxen für die Planung nutzen
3. Abhängig von den verfügbaren Ressourcen sein

Dabei spielt die Entwicklungsgeschwindigkeit, velocity des Teams eine große Rolle. Diese kann man schätzen basierend auf Erfahrungswerten und ersten Sprints.

Nutzt man feste Release-Container so kann man die Risiken der Investionen begrenzen, die Planung vereinfachen, der Product Owner bringt die Aufgaben in die jeweiligen Release-Container unter, die bestimmte zeitliche Längen haben von einigen Monaten (3 oder 6 beispielsweise).

Release-Controlling

Release-Controlling hilft dabei den Fortschritt von geplanten Releases zu überwachen.

Ein Release Burndown Bar Chart zeigt grafisch wie groß der Restaufwand in Story Points nach jedem Sprint ist.

Die Trendlinie zeigt so den ungefähren Termin für das Release an. Bei Bedarf kann man so den Umfang aus dem Product Backlog kürzen, den Termin verschieben oder effektiver arbeiten.

Aufgrund von schwankenden Leistungen ist der Releasetermin hier nur ungefähr schätzbar. Auch ein Todesmarsch, death march, kann so rechtzeitig erkannt werden, wenn die Entwicklung stagniert bzw. immer mehr neu abgearbeitet werden soll, als abgearbeitet wird.

Ein Release Burnup Chart zeigt über den zeitliche Verlauf an in Story Points wie viele Features schon umgesetzt wurden und vermittelt so die gleichen Informationen wir der Release Burndown Bar Chart.

Parking-Lot-Diagramme zeigen nach Themenbereichen, Teilsystemen bei großen Projekten übersichtlich wie weit der Zustand voran geschritten ist. Durch Färbungen zeigt man welche Bereiche noch nicht angefangen sind und prozentuale Balken zeigen den aktuellen Fortschritt des Themengebietes an. Dabei umfasst jeder Themenbereich User Stories und Epics. Auch ein Termin der Fertigstellung kann mit angegeben werden als Datum.

Ein funktionierendes Release kann auf verschiedene Arten abgerechnet werden.