Als agiler Protagonist in der Automobilindustrie bin ich immer wieder Bestandteil von Diskussionen über die Vereinbarkeit von agilen Ansätzen mit Automotive SPICE und ISO 26262. Dabei habe ich gelernt dass die Diskussionen oft auf verschiedenen Ebenen geführt werden. Die agile Seite argumentiert auf einer hohen Abstraktionsebene, dass es doch prinzipiell keine Probleme geben kann und alles vereinbar ist, die Gegner der Agilität hingegen bringen viele konkrete und valide Beispiele für potentielle Konflikte und Fragestellungen, auf welche die agile Seite oft spontan keine Lösung hat.
Also sammle ich in diesem Beitrag mal ein paar Gedankenfetzen zum Projektmanagement (MAN.3) die sich in meinem Kopf, auf meinem Rechner und in meinen Schubladen rumtreiben. Ein fiktives Pilotprojekt im Hinterkopf, rede ich im Folgenden nicht von Prozessbeschreibungen, sondern schreibe alles ins Projekthandbuch, damit Änderungen am Prozess leicht von der Hand gehen. Agil eben.
Allgemeines
Aus SPICE-Sicht ist das Projektmanagement neben dem Konfigurationsmanagement einer der beiden wichtigen Querschnittsprozesse für Capability Level 2. Schwächen im Projektmanagement schlagen sich meistens in allen anderen Prozessgebieten beim Prozessattribut 2.1 nieder und erschweren oder verhindern so das Erreichen von Level 2 oder höherenLevels.
Für die folgenden Ausführungen gehe ich von einem mechatronischen Produkt aus, die Softwareanteile sollen mit Scrum entwickelt werden.
Definition des Arbeitsumfangs (BP1)
Hier erwartet SPICE, dass sich alle Beteiligten über den Umfang des Projekts bewusst sind und dass das Projekt mit den vorhandenen Ressourcen auch durchführbar ist. Zum Beispiel wird dazu das Projekt mit einer Work-Breakdown-Structure (WBS) strukturiert um eine handhabbare Größe für Grobschätzungen zu bekommen.
Die erste Möglichkeit besteht darin, alle Blattobjekte in der WBS klassisch mit Expertenschätzungen in Personentagen zu schätzen. Alternativ können die Scrum-Teams mit ihnen vertrauten Schätzungen arbeiten, also in Story-Points schätzen, falls mit Stories gearbeitet wird. Die Herausforderung beim initialen Schätzen besteht darin, dass die Schätzungen in Points nicht von Team zu Team übertragen werden können. Jedes Team hat seinen eigenen Maßstab für Schätzungen und eine dementsprechend eine eigene Velocity. Später im Projekt ist das problemlos, weil jedes Team die eigenen Aufgaben schätzen muss. Jetzt, in der Vor-Projektphase besteht aber noch keine Zuordnung von Features zu Teams. Hier wäre es möglich, die Teams parallel schätzen zu lassen und die Schätzungen mit den jeweiligen Velocities zu normieren, also in Personentage umzurechnen, und miteinander zu vergleichen. Egal wie die Schätzungen stattfinden, wir müssen sicherstellen, dass dokumentiert ist, wie die Zahlen zustande gekommen sind (Datum, Teilnehmer, Schätzverfahren).
Definition des Projektlebenszyklus (BP2)
Ein klassisches Thema für das Projekthandbuch das wir hier ebenso klassisch abhandeln können, da es keine Konflikte mit unseren Scrum Teams gibt. Hier benötigen wir auch nur wenig Kreativität, denn der grobe Rahmen des Lebenszyklus wird vom OEM vorgegeben. Der SOP (Start of Production) wird kundgetan (und ist in Stein gemeißelt), davor werden Übergabepunkte für A-, B-, und C-Muster evtl. auch mit Unterlieferungen (B0, B1, ..) definiert.
In einer Top-Down-Betrachtung kommen wir so von der Projektlaufzeit auf die Musterphasen, dann auf die Unterphasen innerhalb der Muster. Das sind die Phasen und Meilensteine die von außen vorgegeben werden und nach außen sichtbar sind. Unsere Aufgabe ist es nun die internen Tätigkeiten in dieses Raster einzupassen. Der nächste Schritt dazu ist, weitere, interne Meilensteine festzulegen, im Normalfall interne Releases. Die Scrum-Teams liefern ohnehin in kurzem Takt Releases, sie sind die atomare Ebene in der Planung. Doch auch für Mechanik und Elektronik-Hardware bietet es sich an interne Releases in einer gleichmäßigen Taktung (Herzschlag der Organisation) anzusetzen. Je effizienter die Prozesse und die Werkzeugketten in diesen Bereichen sind, desto mehr können sie sich mit der Release-Taktung an die agilen Elemente annähern. Denn die Motivation für kurze Zyklen in Scrum – bessere Fortschrittskontrolle und Risikominimierung – gelten für die „klassischen“ Disziplinen ebenso wie für die Software.
Eine Phase, die der OEM nicht vorgibt, dürfen wir hier nicht vergessen: Die Projektvorphase. In dieser wird der Aufwand geschätzt und die Machbarkeit analysiert (siehe BP1) oft auch in Verbindung mit Vorentwicklungen. Ziel der Projektvorphase ist es, eine Entscheidungsgrundlage dafür zu liefern ob das Projekt durchgeführt werden soll. Falls die Entscheidung positiv ausfällt, endet die Vorphase mit dem Kickoff-Meeting.
Definition und Pflege von Schätzungen für Projektattribute (BP3)
Die Schätzverfahren haben wir schon weiter oben definiert. Diese Basispraktik sollte mehrfach im Projekt vorkommen um die Schätzungen zu verfeinern und Vorgaben zu aktualiseren. Zusätzlich sollten wir neben Aufwand und Kosten weitere Attribute wie z.B. Qualitätsmetriken definieren und für diese auch Vorgaben machen. Dieser Aspekt, der explizit in der Basispraktik enthalten ist, wird oft vernachlässigt, weil es zu Beginn des Projekts schwierig ist diesbezüglich Aussagen zu treffen. Da wir uns jedoch wie jedes Projekt fest vornehmen die Zahlen regelmäßig zu aktualisieren :), können wir am Anfang auch mit ersten Vorgaben auf Basis von Erfahrungswerten ins Rennen gehen.
Definition von Projektaktivitäten (BP4)
Was ist im Projekt alles zu tun? Diese Frage sollten wir uns unabhängig vom angestrebten SPICE Level stellen. Dieser Punkt führt oft zu Diskussionen im Assessement. Selbstverständlich kann jedes Projekt nachweisen, dass es sich in irgend einer Form Gedanken über die Aktivitäten gemacht hat. Die Granularität dieser Arbeitspakete, die im Hinblick auf Pflegeaufwand bei Änderungen meistens pragmatisch grob festgelegt werden entsprechen nicht immer den Vorstellungen der Assessoren. Hier sollten wir uns den Ansatz aus der agilen Welt zu Nutze machen und die Granularität der Planung in Abhängigkeit der zeitlichen Entfernung vom Planungszeitpunkt festlegen. Eine Detailplanung für Monate im Voraus (was macht Entwickler XY am 17.10. vormittags?) wird in der konventionellen Projektplanung zwar manchmal angestrebt, funktioniert aber nicht. In der agilen Welt ist eine solche detaillierte Planung auf lange Zeithorizonte ohnehin nicht vorgesehen.
Wie gehen wir das Thema also an, um zum einen klassische und agile Welt zusammenzubringen, einen pflegbaren pragmatischen Ansatz zu haben und gleichzeitig den SPICE Assessor zufrieden zu stellen? Die Argumentation der Assessoren geht meist dahin, dass eine feine Granularität essentiell für das Tracking des Arbeitsfortschrittes ist, dieses Bedürfnis wird in Scrum durch die regelmäßig (wenn auch teilweise nur intern) ausgelieferten Inkremente befriedigt.
Noch ein Wort zu den Schnittstellen im Projektplan: In der Praxis werden meist verschiedene Teilprojektpläne zu einem Gesamtprojektplan aggregiert und über Meilensteine synchronisiert. Das bietet uns z.B. die Möglichkeit, den Teilprojektplan „Software“ agil zu gestalten und so die Scrum Sprints im Gesamtprojektplan zu integrieren. Wir legen zunächst fest, wie die einzelnen Projektpläne zusammenarbeiten und wie die unterstützenden Tätigkeiten wie Qualitätssicherung, Änderungsmanagement usw. verteilt werden und geben Vorgaben für die Granularität der Arbeitspakte.
Im nächsten Schritt stellen wir den Teilprojektplan für die Softwareentwicklung auf. Die Sprints sind relativ einfach einzuplanen, die unterstützenden Tätigkeiten und Meilensteine fügen wir hinzu. Statt einer separaten Liste mit Arbeitspaketen zu pflegen, erfassen wir diese gleich in einem Projektplanungswerkzeug, mit dem wir später auch den Projektzeitplan pflegen.
Definition des Qualifikationsbedarfs (BP5)
Für unser Beispiel gehen wir davon aus, dass im der Organisation bereits Rollen definiert sind in denen die erforderlichen Qualifikationen beschrieben sind. Damit reicht es aus, im Projekthandbuch auf diese Rollen zu verweisen und die Mitarbeiter im Projekt diesen Rollen zuzuordnen. Für die Generische Praktik 2.1.4 aller Prozessgebiete müssen wir nachweisen, dass die gewählten Mitarbeiter auch die erforderliche Qualifikation mitbringen.
Vorsicht: Die quasi öffentliche Begründung der Qualifikation in Projektdokumenten verursacht in vielen Betrieben Konflikte mit dem Betriebsrat. Dies ist vorher abzuklären. Gegebenenfalls kann im Assessment argumentiert werden, dass die Zuordnung samt Begründung durch die Vorgesetzten der Mitarbeiter geschieht, die ohnehin durch die Jahresgespräche Einblick in die Qualifikationen der Mitarbeiter haben.
Definition und Pflege eines Projektzeitplans (BP6)
Nachdem wir in BP5 schon unser Projektplanungswerkzeug mit Arbeitspaketen gefüttert haben können wir mit eben diesem die Aktivitäten schätzen (die Methodik dazu haben wir ja schon definiert) und den Aktivitäten Ressourcen zuweisen. Aus den zugewiesenen Ressourcen ergibt sich die Bearbeitungszeit der Ressourcen. Zumindest eine erste Näherung der Zeit, denn man ist geneigt den Werkzeugen zu glauben, dass die Bearbeitungszeiten linear zu den bereitgestellten Ressourcen skalieren, was durch Reibungseffekte und Kommunikation nicht so ist. Das sollten wir aber in einem separaten Beitrag einmal diskutieren.;)
In unserem Kontext ist es wichtig ein Konzept für die Planung der Scrum-Teams zu haben. Die Teams schätzen zwar langfristig die Dauer für bestimmte Arbeitspakete, drehen dies aber in der kurzfristigen Planung (Sprintplanung) um und schätzen wie viele Arbeitspakete innerhalb einer bestimmten Dauer zu schaffen sind. Dieses Vorgehen scheint für traditionelle Projektmanager weniger planbar als der konventionelle tayloristische Ansatz, in der Praxis kommt die Differenz meiner Meinung nach jedoch eher aus der Illusion der Planbarkeit beim klassischen Ansatz. Nichtsdestotrotz benötigen wir ein Konzept, wie wir mit Scrum zu einem bestimmten Termin planbar einen bestimmten Software-Stand abliefern. Hierzu ist es interessant sich den Ansatz „Reliable Scrum“ von Wolfram Müller anzusehen, der explizites Puffer-Management aus dem Critical-Chain-Projektmanagement für Releasplanungen mit Scrum verwendet.
Für uns und den lieben SPICE Assessor müssen wir nun also festlegen, wie der Software-Projektplan mit den Sprintplanungen zusammenhängt. Dazu übernehmen wir die Sprints als immer gleiche Balken in das Projektplanungswerkzeug, nummerieren die Sprints aber mit einer aufsteigenden Zahl durch. Damit schaffen wir die Referenz zu den Sprintplanungen im Backlog. Apropos Backlog: Dieses dient sowohl dem Requirements-Engineering wie auch der Planung. Also müssen wir den planerischen Umgang damit auch im Projekthandbuch beschreiben, ebenso sollten wir festlegen in welchen Intervallen die Planung aktualisiert wird. Es bietet sich für den Software-Teilprojektplan an, die Planung im Takt der Sprints zu aktualisieren.
Ein Konflikt kann im Assessment durch die Zuordnung von Aktivitäten zu Teams entstehen. Manche Assessoren erwarten eine Zuordnung zu einzelnen Personen um die Auslastung der Ressourcen überwachen zu können. Da Scrum jedoch ein Pull-System darstellt können die Ressourcen in den Scrum-Teams nicht überlastet werden. Theoretisch :)
Ermittlung und Überwachung von Projektschnittstellen (BP7)
Hier sollen wir aufzeigen mit wem das Projekt wie kommuniziert. Das machen wir ganz unagil in einer Kommunikationsmatrix im Projekthandbuch. :)
Erstellen des Projektplans (BP8)
Der Projektplan (nicht zu verwechseln mit dem Projektzeitplan) ist im Projekthandbuch definiert. Wa wir nun schon seit einigen Abschnitten fleißig am Projekthandbuch basteln und dies auch weiterhin tun werden, müssen wir für BP8 gar nicht viel unternehmen, außer festzulegen wann das Projekthandbuch aktualisiert werden soll (Intervall und Verantwortung).
Umsetzung des Projektplans (BP9)
Alles ist geplant, jetzt muss es „nur“ noch umgesetzt werden. Für die Umsetzung selbst benötigen wir nicht viele Vorgaben, wir definieren nur, wie die Aufgaben kommuniziert werden (Meetings, Dokumente, Verantwortungen).
Überwachung von Projektattributen (BP10)
Zu den wichtigen Projektattributen zählen Umfang, Zeit, Kosten und Qualität. Die Überwachung erfolgt mit Soll/Ist-Vergleichen. Die Aufgabe des Projektmanagements ist es, diese Zahlen „einzusammeln“, denn sie fallen in den verschiedenen Prozessgebieten an. Der Umfang kann über die Anzahl der Anforderungen und Zahlen zu Freigabestati und Änderungen überwacht werden. Die Einhaltung der Zeit bedeutet im starren Muster-Rahmen in der Automobilindustrie die Überwachung des Entwicklungs-Fortschritts, dieser muss aus den Teilprojektplänen ersichtlich sein. Die Qualität wird über die üblichen Metriken gemessen und von dem entsprechenden Prozessgebiet bereitgestellt. Einzig die Kosten in unserer obigen Aufzählung müssen vom Projektmanagement erfasst werden und den Budgets gegenübergestellt werden. Auch hier bietet es sich an, Kostenfortschritt mit Projektfortschritt gegenüber zu stellen und so eine „Kosten-Fieberkurve“ aufzustellen. Agilerweise tauschen wir hier nicht Reports aus, sondern berufen eine Besprechung ein, die wir für die Überwachung der Projektattribute und zur Abstimmung anderer Themen benutzen können. Wir nennen diese Besprechung das „Projekt-Meeting“. Und natürlich dokumentieren wir alles fein, für den Assessor.
Prüfung und Berichterstattung bezüglich des Projektfortschritts (BP11)
Die Überwachung des Projekts haben wir soeben in BP10 definiert. Hier geht es mehr um die Berichterstattung „nach oben“, an das Management, und die Überwachung des Projektes durch eben dieses. Dazu definieren wir ein Reporting-Intervall und Review-Meetings mit der Projektleitung in einem Lenkungsausschuss. Dieser kann Eskalationen entgegenehmen und Unterstützung aus den Linienfunktionen bieten. Scrum bietet mit Sprint-Burndowns, Release-Burndowns, Backlog und Impediment Log hinreichend viele Artefakte die in einen solchen Report einfließen können.
Maßnahmen zur Abweichungskorrektur (BP12)
Gedacht ist hier, dass wir ein Gremium haben, das Maßnahmen beschließt und die Umsetzung dieser Maßnahmen verfolgt. Auch hier halten wir für unser Pilotprojekt die allgemeinen Dinge etwas schlank und fokussieren uns auf die agilen Aspekte, also der Korrektur von Abweichungen in unseren Scrum Teams. Die „klassische“ Methode bei Problemen mehr Ressourcen in das Projekt zu schieben wird bei Scrum Teams schwierig. Eine Vergrößerung der Teams durch weitere Mitglieder verlangsamt zunächst einmal die Teams (das ist in der unagilen Welt genauso, nur wird es dort manchmal ignoriert), eine Skalierung erfolgt bevorzugt über weitere Teams. Dies setzt aber wiederrum voraus, dass die Organisation in der Lage ist bei Problemen im Projekt auch ein „lauffähiges“ Scrum Team bereitzustellen (also an anderer Stelle zu entbehren). Der agile Ansatz bei Problemen mit Scope-Änderungen zu reagieren, ist in der Automobilbranche schwer durchsetzbar. In der Praxis wird dies jedoch teilweise auch bei konventionellen Projekten gemacht, denn der SOP ist unverrückbar. So ist manchmal die letzte möglich Maßnahme des OEMs, doch den Funktionsumfang der zugelieferten Komponenten für den SOP zu reduzieren.