Die Evolution der Prozessmodelle
Bei der Diskussion von Prozessmodellen bekommt man häufig den Eindruck, dass zwischen den Vertretern der Modelle eine Art Krieg herrscht und die Vertreter der Modelle eher wie Evangelisten agieren. Meine Meinung dazu ist, dass jedes Prozessmodell die Produktentwicklung weitergebracht hat, zumindest in einigen Aspekten. Einige Eigenschaften der Prozessmodelle bauen dabei gewissermaßen aufeinander auf und ergänzen sich.
Im diesem Artikel möchte ich daher die verschieden Modelle kurz vorstellen und dabei bewerten, welche Aspekte meines Erachtens zu einem modernen Ansatz integriert werden können.
Wasserfall
Winston Royce, 1970.
Eigenschaften: Projektvorgehen. Aktivitätsbasiert, einfacher Durchlauf. Produkt-Versionen werden innerhalb von Projekten erzeugt.
Beschreibung: Erstes simples Modell, führt Begriffe zur Unterteilung von Aktivitäten in der Entwicklung ein. Die Grundidee ist, dass jedes Artefakt einmal final erstellt wird.
Kommentar: Das Modell strukturiert den bis dahin nicht beschriebenen Prozess der Entwicklung. Es ist ein klares und simples Modell, relativ einfach zu verstehen aber sehr idealisiert. (Daher hat es sich wohl auch so weit verbreitet). Als Vorgehensmodell ist es ungeeignet und nicht zu leben. Selbst Winston Royce führte es in seiner Veröffentlichungsschrift, neben anderen Modellen, nur als Idealbild ein, mit dem Hinweis, dass es in realen Projekten nicht als Vorgehensmodell geeignet sei.
V-Modell
Barry Boehm, 1979. KBSt der Bundesregierung, 1991.
Eigenschaften: Projektvorgehen. Aktivitätsbasiert, einfacher Durchlauf. Produkt-Versionen werden innerhalb von Projekten erzeugt.
Beschreibung: Erweiterung des Wasserfalls um die Beziehungen, wie und auf welcher Ebene Artefakte verifiziert und validiert werden. Jedes Artefakt wird einmal final erstellt.
Kommentar: Als Vorgehensmodell immer noch unbrauchbar, da es sich im Kern noch um einen Wasserfall handelt. Der eigentliche Wert des Modells besteht in den Beziehungen, die eine Rückverfolgbarkeit (Tracability) erlauben, indem die Testaktivitäten auf den verschiedenen Ebenen auf die jeweiligen Spezifikationen verlinken. Dabei prüft die Summe der Tests auf der rechten Seite alle Spezifikationen auf der linken Seite, womit eine Vollständigkeitsprüfung möglich wird.
Stage-Gate ®
Cooper, 1996.
Eigenschaften: Projektvorgehen. Aktivitäts- oder reifegrad-basiert. Einfacher Durchlauf. Produkt-Versionen werden innerhalb von Projekten erzeugt.
Beschreibung: Erweiterung des Wasserfalls um Phasen, die mit einem Meilenstein (Gate) abgeschlossen werden und einen steigenden Reifegrad des Produkts erzeugen sollen. Jedes Artefakt wird in einer bestimmten Phase initial erstellt. Artefakte werden, wenn nötig, pro Phase durch ein explizites Change-Management geändert und durch das Gate-Review freigegeben.
Kommentar: Je nach Inhalt der jeweiligen Aktivitäten innerhalb der Phasen ist StageGate (immer noch) ein Wasserfall mit Meilensteinen oder der Anfang einer iterativen Vorgehensweise. Stage-Gate ® ist in der physischen Produktentwicklung heute weit verbreitet. Insbesondere das Konzept der Gates verspricht eine gute Steuerbarkeit von Projekten auf höheren Managementebenen. Da die Phasen (Stages) aber meist mehrere Monate dauern und darüber hinaus Gate-Reviews abhängig vom Vorliegen bestimmter Ergebnisse veranstaltet werden, ist die Steuerungsmöglichkeit stark eingeschränkt.
In den einzelnen Phasen sind vom Prozess her verschiedene Artefakte, wie z.B. Prototypen, vorgesehen, die geplant, gebaut und getestet werden. Das möglichst schnelle Erstellen der Prototypen wird somit zum obersten Ziel, das Lernen mit den geeigneten Prototypen tritt in den Hintergrund. Termindruck führt dazu, dass jeder Prototyp nur einmal eingeplant wird, also aus den Phasen kleine Wasserfälle entstehen und Iterationen innerhalb der Phasen nicht eingeplant werden.
Die Gate-Reviews werden aufwändig vorbereitet und werden daher meist nicht wiederholt, sondern Gates werden mit „Auflagen“ genommen. Dies führt dann leider häufig zu späten Überraschungen (false positives, false confidence) und benötigt zudem ein aufwändiges Change-Management. Speziell für hoch innovative Vorhaben ist Stage-Gate zu zäh und schwerfällig, meiner Meinung nach selbst für gut planbare Vorhaben.
Unified Process
Kruchten, 1999.
Eigenschaften: Projektvorgehen. Aktivitäts- und reifegrad-basiert. Produkt-Versionen werden innerhalb von Projekten erzeugt.
Beschreibung: Erweiterung des Stage-Gate-Modells um gleich lange Iterationen innerhalb der Phasen (Timeboxing). Nutzung von Use-Cases und der UML.
Kommentar: Die Einführung von Iterationen als festen zeitlichen Rhythmus, und insbesondere die Iterations-Reviews alle 2 bis 4 Wochen, erzeugt ein „Gefühl der Dringlichkeit“ (Sense-of-Urgency), jedes Mal etwas Zusätzliches zeigen zu können und damit auch den Zwang, kleine Schritte zu gehen. UP erzeugt damit ein echt iterativ-inkrementelles Vorgehen, wobei die Priorisierung der Arbeitspakete streng risiko-orientiert erfolgen soll. Durch die häufigen Integrationen und deren Tests, wird eine (zumindest teilweise) Automatisierung der Tests notwendig. Die Integration von Use-Cases und der UML als Standard-Werkzeuge gibt dem Prozessmodell eine klarere Struktur, macht es aber andererseits auch unflexibler.
Als Projektvorgehen fehlt UP das Element der Team-Stabilität, wenn dem nicht durch die Messung der Verfügbarkeit der Team-Mitglieder und des Fortschritts begegnet wird, sowie durch Betrachtung der Verfügbarkeit der Team-Mitglieder als explizites Risiko.
Agile/Scrum
Sutherland, Schwaber, 1995.
Eigenschaften: Projekt- und Team-Vorgehen: Ein Team beschreibt seine komplette Arbeit, ggf. auch an mehreren Produkten. Produkt-Versionen werden in Releases erzeugt.
Beschreibung der Erweiterungen: klare Teilung der Verantwortlichkeiten auf drei Rollen, klare Priorisierung über Backlogs, Iterationen (Timeboxing), Selbstorganisation & Pull.
Kommentar: Scrum als agiles Framework stellt nur die elementarsten Prozess-Elemente dar und lässt alles andere bewusst außen vor. Dadurch ist Scrum so universell einsetzbar, muss aber für eine vollständige Prozessbeschreibung um weitere Elemente ergänzt werden. Die unterliegenden Paradigmen und Prinzipien sind aber in der agilen Arbeitswelt völlig neu und anders:
- Vertrauen , Respekt und persönliche Sicherheit statt Befehl und Kontrolle
- Selbstorganisation und Pull-Prinzip statt zentraler Kontrolle
Für ein vollständiges Prozessmodell eignet sich eine Kombination aus Scrum und UP.
Scaled Agile/Scrum (Team-of-Teams)
SAFe: Dean Leffingwell, 2002. LeSS: Bas Vode. Scrum@Scale: Jeff Sutherland. Nexus: Ken Schwaber. P4-Dev: Oliver Schoenfeld, 2014.
Eigenschaften: Multi-Team-Vorgehen (langlebige, stabile Teams). Mehrere Teams arbeiten an einem (oder mehreren Produkten). „Projekte“ gehen über in Produkt-/Applikationsversionen. Diese fließen zu den stabilen Teams. Es existiert mindestens ein interdisziplinäres Produkt-Team, ggf. mehrere Feature-Teams. P4-Dev beschreibt darüber hinaus Modul- und Plattform-Teams und zuarbeitende Experte-/Service-Teams. Produkt-Versionen werden in Releases erzeugt. All das führt zu stabilen Teams und Gruppen, die durch Pull und Selbstorganisation eine vorhersagbare Arbeitsgeschwindigkeit (Velocity) erreichen.
Folgende Erweiterungen werden für die Skalierung der agilen Scrum-Events auf eine höhere Ebene (Program, Cluster) eingeführt:
- Gezielte Überlappung
- Gruppen auf der höheren Ebene, die aus Mitgliedern der Teams bestehen (z.B. die Gruppe der Team-Product-Owner stimmen sich gemeinsam über die Planung ab)
- Gruppenübergreifende Rollen, wie ein „Chief-Product-Owner“, „Program-Owner“ oder Cluster-Product-Owner
- Events, an denen die Personen aus Teams und Gruppen zusammenkommen (z.B. Scrum-of-Scrums, Cluster-Retrospektiven)
- Messung der Performance von Teams, Cluster und der ganzen Organisation, um zu wissen wie viele Produkt-Releases pro Zeitraum leistbar sind und versprochen werden können.
- Klare Priorisierung durch Bewertung des Nutzens und des Aufwands von Vorhaben bzw. Produkt-Releases. Unterordnung aller weiteren klassischen Aktivitäten, die Einfluss auf die Priorisierung haben, wie Budgetierung, Zielvorgaben, Portfolio-Planung!
Fazit
Welche Elemente können wir in einem modernen Vorgehensmodell für eine ganze Organisation integrieren:
- Benennung der Aktivitäten und Artefakte aus dem Wasserfall
- Rückverfolgbarkeit und Vollständigkeitsprüfung aus dem V-Modell
- Meilensteine und wachsenden Produktreifegrad aus dem StageGate
- Iteratives Vorgehen, risiko- und architekturgetriebenes Vorgehen, sowie Artefakte (wie z.B Use-Cases) aus dem UP
- Transparenz, konsequente Disziplin, Team-Stabilität, Selbst-organisation und Pull für eine vorhersagbare Leistung mit hoher Qualität aus Scrum
So ist es im P4-Framework integriert.
Stage-Gate ® ist ein geschütztes EU-Warenzeichen des Innovation Management U3 und Product Development Institute Inc.