Eine nachvollziehbare Releaseplanung für komplexe Systeme
In komplexen Projekten benötigen Projektmanager und Kunden eine Übersicht, wie ein Projekt entwickelt werden soll. Die klassische Projektplanung greift an dieser Stelle zu kurz, da ein WBS (Work-Breakdown-Structur) nicht abbildet, wie sich die Reife des Systems entwickelt. Hinzu kommt, dass Kunden, z.B. in der Automobilentwicklung, zu gewissen Meilensteinen einfach relevante Funktionen eines Systems benötigen, egal ob sie in Software, Hardware oder Mechanik gelöst sind. Beispielsweise, wenn man in der Entwicklung mit dem Auto auf Wintertest geht. Dazu wird von den Systemingenieuren eine Releaseplanung benötig, die auch über einen Zeitraum von mehreren Releases oder Meilensteinen eine grobe Einschätzung gibt, wie reif einzelne Funktionen eines Systems sind. Dazu benötigen die Projektmanager eine Aussage, wieviel Entwicklungsbudget für das Projekt benötigt wird.
Diese Schnittstelle ist die größte und wichtigste Schnittstelle zwischen der Rolle des Systemingenieurs und der des Projektmanagers. Ich bin darauf in Episode #32 „Was ist der Unterschied zwischen einem Projektmanager und einem Systemingenieur?“ ausführlich eingegangen.
Wie kann eine sinnstiftende Releaseplanung aussehen?
Ich benötige eine Darstellung, wie sich der Reifegrad eines System über die Entwicklungsmeilensteine darstellt und mit den Aufgaben und Aufwänden verknüpft. Dies kann ich über die verschiedenen Funktionen des Systems darstellen.
Gruppierung der Funktionen
Ich gruppiere diese Funktionen zunächst in die verschiedenen Disziplinen Software, Hardware und Konstruktion. In dieses Gruppen verfeinere ich dann noch nach Basis-Funktionen und Zusatzfunktionen. Oder ich nehme komplexe Funktionen des Systems als eigenständige Gruppe hinzu.
Wie ihr diese Gruppen definiert, bzw. unterscheidet, ist abhängig von eurem System und den Funktionen. Typischerweise nutze ich den Systems Footprint als Eingangsinformationen. Den Systems Footprint habe ich in der Episode #04 „The System Footprint – Anforderungen strukturieren und visualisieren“ ausführlich erläutert.
Festlegung der Meilensteine
Als nächsten Schritt definiere ich die Meilensteine. Oft sind diese schon grob durch das Projekt oder den Entwicklungsprozess vorgeben. Meistens ergeben sich aber auch zusätzlich Zwischenreleases, die ich hier direkt mit berücksichtige. Jetzt definiere ich eine erste grobe Abschätzung, welche Funktion zu welchem Release in welchem Reifegrad vorhanden ist. Diese Abschätzung stelle ich prozentual dar. Dabei geht es nicht darum, die absolut genaue Zahl darzustellen, sondern im Verhältnis einen Reifegrad darzustellen. Ob es jetzt 68% oder 73 % sind ist völlig egal. Es geht um eine punktuelle Abschätzung, während die Schätzfehler bei der Betrachtung der Zukunft viel größer sind. Viel wichtiger ist der Überblick: Welche Funktionen sind im Augenblick zu wichtigen Meilensteinen vorhanden?
Ebenso ergibt sich daraus auch, wie der Reifegrad der Funktionen voneinander abhängt. Beispielsweise brauchen wir beim Wintertest einen Reifegrad von 100% der Basisfunktionen und 60% der Algorithmusfunktionen. Das bedeutet aber auch, dass die Hardware und die Konstruktion ebenfalls mindesten 80% Reifegrad haben. Diese Zusammenhänge sind viel wichtiger als auf Kommastellen-genaue Angaben.
Aus diesem Schritt ergibt sich folgende Darstellung:
Abschätzen der Tätigkeiten
Als nächsten Schritt definiere ich die Tätigkeiten, die in den jeweiligen Releases notwendig sind. Mein Vorgehen zur Aufwandsabschätzung habe ich ebenfalls online gestellt: Effektive Aufwandsschätzung für komplexe Projekte
Ich gehe von den generellen Tätigkeiten aus, die den Entwicklungsprozess definieren und ergänze systemspezifische Aufgaben. Nun nutze ich die im vorhergehenden Tutorial beschriebene Aufwandschätzung, um die Tätigkeiten für das jeweilige Release abzuschätzen. Einige Tätigkeiten sind typischerweise in mehreren Releases vorhanden. Dann schätze ich die Tätigkeiten jeweils für den entsprechenden Releasezyklus ab. In dem Template kennzeichne ich diese Situation, in dem ich ein „x“ vor die Abschätzung setze. Daraus ergibt sich folgende Darstellung:
(N= Nanoprozent-Wert in Stunden, E = Erwartungswert in Stunden, U = Unsicherheit, W = errechneter Worst-case Wert, % = Wahrscheinlichkeit, work = Aufwand in Stunden)
Das Ergebnis
Wenn ich diese Schritte nun für die gesamten Releasezyklen durchgeführt habe, erhalte ich insgesamt folgendes Ergebnis:
- Aufwand der Tätigkeiten für jedes Release über die verschiedenen Disziplinen
- Verhältnis der Reifegrade zueinander und zum Release
- Einen Gesamtaufwand für das Entwicklungsprojekt
Wenn ich nun noch einen internen Stundensatz mit hinzunehme, kann ich auch das Budget über die Zeit darstellen. Jetzt habe ich die Möglichkeit, mit den Wahrscheinlichkeiten zu spielen und den Aufwand auf meine Projektsituation oder für den Vertrieb anzupassen.
Ich habe mein Template zur Releaseplanung online gestellt. In diesem Template ist die Berechnung der Abschätzungen entsprechend der beschriebenen Vorgehensweise mit hinterlegt. Die grünen Felder sind editierbar. In den weißen Feldern sind Berechnungen hinterlegt. Insgesamt nutze ich den Entwicklungsprozess nach Automotiv-SPICE in der Darstellung der Tätigkeiten. Seid frei, den Releaseplan nach Euren Bedürfnissen anzupassen!