Der Formalisierungsgrad der Entwicklungsprozesse bildet seit Jahrzehnten einen Zankapfel in der Softwareindustrie. Wie viel Prozess braucht ein Softwareprojekt? Es zeigt sich, dass der optimale Formalisierungsgrad keine Konstante sein darf. In frühen Produktreleases ist ein eher agiler, in späteren Phasen ein eher formeller Prozess sinnvoll. Ein Entwicklungsprozess muss mit seinem Ergebnis wachsen.
Der Streit um das Dilemma der Formalisierung des Entwicklungsprozesses kommt in die Jahre. Seit gut einer Dekade hauen und stechen Anhänger der agilen Methoden und die CMMI/SPICE-Fraktion aufeinander ein. Mit dem Agilen Manifest haben US-Berater Kent Beck und seine Kollegen im Jahr 2001 absichtlich den Stein des Anstoßes gelegt. Das Beratungsgeschäft lebt – oft sehr zum Leidwesen der Kunden und ihrer seriösen Berater – wie andere Industriezweige von Trends und Modeerscheinungen. Diese werden werbewirksam promotet. Ähnlich wie die CMMI-Experten von SEI mit ihren Case Studies haben agile Berater die Werbetrommel gerührt und fleißig berichtet, dass der Einsatz von Scrum & Co. einfach, kostensparend und erfolgreich sei.
Nach Jahren heftiger Auseinandersetzungen erreicht die Diskussion allmählich ruhigere Gewässer: Die vergangene Krise hat den Druck auf alle Beteiligten erhöht, endlich pragmatische Lösungen zu präsentieren. Die Zeit für konstruktive Schlussfolgerungen ist gekommen.
CMMI- und SPICE-Berater sind an ihrer Misere selber schuld
Es lässt sich kaum bestreiten, dass die CMMI/SPICE-basierte Prozessverbesserung stark an Popularität eingebüßt hat. Vieles wurde versprochen, wenig davon gehalten. Deutlich wird das, wenn man sich die alten SEI-Präsentationen zum Thema CMMI anschaut. So wird in den Management Summaries General Motors als erfolgreicher „Early Adopter“ von CMMI vorgestellt. Nach Angaben des Instituts sollen sich Qualität und Effizienz der Entwicklungsprozesse durch den Einsatz des CMMI-Standards erheblich verbessert haben. Angesichts der dramatischen Insolvenz des Automobilherstellers wirkt die Darstellung heute unglaubwürdig. Da General Motors nicht das einzige Unternehmen ist, das in der Finanzkrise trotz Prozessverbesserungsmaßnahmen in teils erhebliche Schwierigkeiten geriet, verloren Prozessberater eines der wichtigsten Verkaufsargumente für den Einsatz der CMMI/SPICE-Standards: prestigeträchtige Referenzbeispiele.
Stattdessen sind zunehmend agile Prinzipien gefragt. Statt einer durchgängigen Prozessgestaltung wird eine einfache, auf wenigen Kernideen basierende Vorgehensweise bevorzugt. Dieser Meinungsumschwung ist nicht allein mit Spätfolgen der Finanzkrise zu erklären. Vielmehr haben CMMI/SPICE-Prozessberater den Niedergang ihres Geschäftsmodells zumindest teilweise selbst zu verantworten. Als ich Tom DeMarco auf den SPICE Days 2010 fragte, wie er die Zukunft von CMMI sieht, meinte er ohne zu zögern: „That’s the end of it.“ Grund dafür sei unter anderem, dass Prozessberater mit einer teils unerträglichen Arroganz agierten, die irgendwann zu einer flächendeckenden Verdrossenheit geführt haben müsse. Diesen Eindruck haben die Teilnehmer der Podiumsdiskussion, an der neben Tom DeMarco auch der C++-Erfinder Bjarne Stroustrup teilnahm, klar artikuliert.
In diesem Vorwurf steckt viel Wahres drin. Trotz ihres oft überlegenen Fachwissens und langer Berufserfahrung verfügen Berater über unterschiedlich ausgeprägte Kompetenzen. Zugleich wird von ihnen erwartet, dass sie als Veränderungsagenten in einer Organisation souverän Stellung beziehen und diese auch standhaft verteidigen. Dies geht nun einmal nicht immer gut, und jedes Scheitern richtet einen gern weitererzählten Schaden an.
Das Kompetenzdilemma ist heikel. Ein kurzer Blick auf den Beratermarkt verdeutlicht den Umstand, dass nur wenige Berater in allen Prozessbereichen – von Qualitätssicherung bis Projektmanagement, von Konfigurationsmanagement bis Softwarearchitektur – wirklich aus eigener, praktischer Erfahrung berichten können. Es gibt in Deutschland gerade eine Handvoll solcher Experten. Zugleich leben Beratungsfirmen von einem personellen Skalierungseffekt: Sie benötigen für ihr Wachstum immer mehr Mitarbeiter. Die natürliche Ressourcenknappheit muss zwangsläufig zu Qualitätsengpässen im Beratungstagesgeschäft führen.
Pssst! CMMI lebt!
Es wäre aus meiner Sicht falsch zu behaupten, CMMI (oder SPICE, die europäische Schwester) sei am Ende. CMMI ist eine äußerst nützliche, praktische Ansammlung von Erfahrungen aus der Softwareindustrie, die man zu einer systematischen Bewertung der Qualität von Entwicklungsorganisationen verwenden kann. Der SPICE-Standard geht einen Schritt weiter: Es werden Prozessreferenzmodelle vorgeschlagen, die recht klare Vorgaben für die Gestaltung qualitativ hochwertiger Entwicklungsprozesse liefern.
Diese Standards jedoch als einen Irrweg abzutun ist leichtfertig. Ein Modell wie CMMI zeigt auf, was alles getan werden kann – dies bedeutet aber noch nicht, dass man auch alles umsetzen müsste, was auf dem geduldigen Papier steht. Ein innovatives Projekt mit einem hohen Forschungsanteil muss zwangsläufig andere Regeln befolgen als ein eingefahrenes Infrastrukturprojekt im 17. Release. Im ersten Release – womöglich einem internen Alpha-Release – ist die Produktqualität oft zweitrangig. Dagegen bildet für „reife“ Projekte die Qualität das A und O – und sie lässt sich am besten mit einem fundierten Entwicklungsprozess sichern. CMMI (oder SPICE) ist für die Kontrolle der Prozessqualität in der Softwareentwicklung hervorragend geeignet und wird daher mit Sicherheit ihren Platz in der Softwareindustrie auf Dauer finden.
Nicht weit vom Stamm: Produkte und Projekte
Ein agil entwickeltes Flugsicherungssystem? CMMI Level 5 für Dreierteams? Da kann etwas nicht stimmen. „Wir wollen uns nicht totverwalten“ versus „So versinken wir im Chaos“ – solche Totschlagargumenten machen ein Gespräch in der firmeneigenen Kaffeeküche zwar unterhaltsam, aber nicht sonderlich produktiv. Dabei steckt darin auch ein Körnchen Wahrheit, aber diese Wahrheit ist definitiv kontextabhängig. Eine vorsichtige Betrachtung fördert nämlich folgende Feststellungen zutage:
- Nicht für alle Projekte eignet sich eine agile Vorgehensweise.
- Nicht alle Projekte müssen auf dem CMMI Level 3 oder höher sein.
- Release 0.1 eines Produkts sollte anders entwickelt werden als das Release 7.5.
Das Gespräch in der Kaffeeküche kann daher nicht ohne Zusammenhang bewertet werden. Auf die Frage: „Kann es überhaupt einen universellen Prozess geben?“ lautet die schlichte Antwort: nein.
Die Art des Produkts bestimmt den Formalisierungsgrad seines Entwicklungsprozesses, da jedes Release des Produkts typischerweise ein separates Projekt darstellt. Die Struktur dieser Projekte ist von der Art des zu erstellenden Produkts determiniert.
STRUKTUR(Projekt) = FUNKTION(ART(Produkt))
Die Projektstruktur, insbesondere der Formalisierungsgrad des Entwicklungsprozesses, ist eine Funktion der Produktart im Kontext der erforderlichen Projektaktivitäten.
Es kann demnach keinen singulären Prozess für alle Projekte geben – für jedes zu entwickelnde Produkt ist eine passende Abbildung auf die Projektlandschaft erforderlich.
Wachsen in Schritten
Der Sachverhalt verkompliziert sich zusätzlich durch die Beobachtung, dass Produkte in frühen Versionen anderen Anforderungen genügen müssen als ihre späteren Releases. Deutlich wird dieser Umstand am Beispiel des iPhones. Das allererste Release überzeugte keineswegs mit vollendeter Qualität. Die Kamera lieferte schlechte Bildqualität, die Batterie war kurzlebig, die Verbindungsgeschwindigkeit unzureichend etc. Das hat aber in der Anfangsphase nicht gestört – die „First Movers“ liebten die Designidee und kauften das Produkt blind. Doch drei Jahre später: Eine kleine Unzulänglichkeit des Antennendesigns des iPhones 4 produzierte einen Sturm im medialen Wasserglas, und das über Wochen hinweg. Dass der Empfang des neuen iPhones sich unter spezifischen Umständen etwas verschlechterte, war plötzlich zum beinahe skandalösen Qualitätsproblem geworden.
Was war passiert? Über die Jahre ist das Produkt „iPhone“ erwachsen geworden. Die Nutzer haben sich an das neue Konzept gewöhnt, und Millionen neuer Kunden erwarben Apples Smartphones. Statt sensationeller Neuerungen erwartet diese Käuferschicht schlicht Stabilität und Zuverlässigkeit.
Um die geforderte Qualität zu erreichen, ist in späteren Produktreleases eine risikoaverse Gestaltung des Herstellungsprozesses erforderlich. Ausgedehnte Tests, proaktive Qualitätskontrolle, und überhaupt: „Trust but verify“ (Vertrauen ist gut, Kontrolle ist besser) – das sind die hier gefragten Mittel. Produkte durchleben einen Zyklus, der mit ihrer Neuentwicklung beginnt und in Degeneration endet.
Vor dem Markteintritt ist bei komplexen IT-Produkten, speziell also bei Software, eine intensive Forschungsphase erforderlich. Das zarte Pflänzchen darf nicht von schweren Prozessen „erschlagen“ werden. Bei Prototypen oder gar bei einem ersten Release (gelegentlich einfach nur ein „Versuchsballon“) ist eine flexible – wenn man so will: agile – Vorgehensweise praktisch unverzichtbar. Bei späteren Produktreleases sinkt jedoch die Fehlerakzeptanz der Produktabnehmer: Die Risikobereitschaft des Herstellers muss daher entsprechend angepasst werden.
Bürokratische Agilität? Agile Bürokratie?
Die Perzeption des Produkts durch seine Anwender hängt mit seiner jeweiligen Lebensphase zusammen. Neue Produkte werden begeistert aufgenommen, später werden keine Fehler mehr verziehen. Ein erfolgreicher Entwicklungsprozess muss zusätzlich zur Art des zu entwickelnden Produkts auch dessen Reife berücksichtigen. Ähnlich wie das Produkt selbst muss der Entwicklungsprozess eine Evolution durchlaufen: von kreativem Chaos zur stabilen, risikoscheuen Bürokratie. So misstrauisch diese Begriffe stimmen mögen, in der späten Sättigungs- und Degenerationsphase eines Produkts stellt das die bessere Konstruktion dar. Schließlich geht es dann nicht mehr um Eroberung neuer Märkte, sondern vielmehr um den guten Ruf des Herstellers als Lieferanten von Qualitätsprodukten.
Wie soll man aber bei solch widersprüchlichen Anforderungen den Entwicklungsprozess so gestalten, dass er für den gesamten Produktlebenszyklus geeignet ist?
Die Antwort auf diese Frage muss zwangsläufig die zeitliche Komponente berücksichtigen. Eine schriftliche, formalisierte Prozessgestaltung zeichnet sich meist durch eine statische, unbewegliche Natur aus. Die Gratwanderung kann aber nur gelingen, wenn der Prozess mit seinem Produkt „mitwächst“: am Anfang agil, später konservativ. Dies impliziert natürlich wiederum, dass der Prozess intrinsisch flexibel ist. Bürokratische Agilität ist naturgemäß genauso unrealistisch wie eine agile Bürokratie.
Wie lässt sich dieser Widerspruch lösen?
Befürworter der agilen Softwareentwicklung mögen anführen, dass ein agiler Entwicklungsprozess skaliert werden kann und somit die Lösung für das Dilemma darstellt. Wenn jedoch in späteren Produktreleases all die häufig als unangenehm empfundenen Aktivitäten wie Code Reviews oder Systemtests im erforderlichen Umfang in den Projektalltag integriert werden, dann wirkt sich das zwangsläufig bürokratisierend aus. Zum Beispiel ist eine hohe Testabdeckung nur dann zu erreichen, wenn man sie planen kann. Dies wiederum geht nur, wenn eine genaue Spezifikation vorhanden ist, auf die sich die einzelnen Testfälle beziehen können („Traceability“). Das bedeutet eine Wasserfall-artige Vorgehensweise, denn ein „Anforderungs-Reverseengineering“ hat noch nie wirklich gute Ergebnisse erbracht; also müssen die Anforderungen VOR ihrer Umsetzung erfasst werden. Weitere Implikationen umfassen ein lückenloses Design (zur Sicherung von Schnittstellen und nichtfunktionalen Anforderungen), planbare Review-Prozesse, ausgedehntes Konfigurationsmanagement (für die Konsistenz von Dokumenten in verschiedenen Entwicklungsphasen) etc. Somit lässt sich der Prozess nicht mehr als „agil“ bezeichnen.
Wenn jedoch die Anhänger der analytischen Prozessreife nun vermelden sollten, sie hätten das „schon immer gewusst“, so muss nochmals daran erinnert werden, dass ein schwerer Prozess am Anfang eines Produktlebenszyklus nicht angebracht ist. Dem kann entgegengehalten werden, dass ein CMMI-konformer Prozess gar nicht schwer sein MUSS. Standards wie SPICE oder CMMI sehen Maßnahmen vor, die eine sinnvolle und marktgerechte Vorgehensweise bei der Findung der „richtigen“ Anforderungen sichern sollen. Außerdem gelten ab der dritten Reifestufe Regeln, die eine entsprechende Anpassung des Entwicklungsprozesses an Projekttypen erfordern. Doch, wie bereits erwähnt, zeigt sich in der Praxis, dass Prozessberater oft nicht über hinreichend breit gefächerte Kenntnisse aller Entwicklungsdisziplinen verfügen, so dass sie die richtigen „Tailoring Rules“ (Anpassungsregeln) für schriftlich definierte Prozesse nicht effektiv erstellen können. Hinzu kommt der Umstand, dass der Umfang der schriftlichen Prozessdokumentation mit der Zahl dieser Anpassungsregeln wächst, wenn möglicherweise nicht exponentiell, dann doch zumindest stark polynomisch. Man darf zumeist davon ausgehen, dass das Budget für ein Prozessverbesserungsprojekt den Aufwand für die Erstellung und Pflege solcher Anpassungsregeln nicht vorgesehen hat. Im Nachgang gestaltet sich eine Flexibilisierung eines formellen Prozessmodells jedoch teuer und selten erfolgreich.
Hybridprozesse ante portas
In seinem Paper „A View of 20th and 21st Century Software Engineering” aus dem Jahr 2006 sagt die Software-Koryphäe Barry Boehm eine Integration der Vorgehensmodelle voraus: Agile und planbare Ansätze würden verschmelzen. Doch leider fehlt in dieser (übrigens äußerst interessanten, kompakten und empfehlenswerten) Publikation jedweder Hinweis darauf, WIE diese Integration erfolgen kann.
Es wurde sehr viel theoretisiert. Wir brauchen endlich ein Referenzmodell, das nicht nur agile Komponenten toleriert und ein „agiles V-Modell“ zusammenfasst, sondern zudem integrativ, exemplarisch und systemisch verfährt. Ein Beispiel „zum Aufbohren“, das sich leicht verallgemeinern oder anpassen lässt. Innerhalb dieses Beispiels muss der Übergang von einem empirischen (agil) in einen rationalen (CMMI/SPICE) Prozess explizit erfolgen. Der minimale Overhead in der Anfangsphase des Produktlebenszyklus muss kurz und knapp gehalten werden, während die Prozessgestaltung in späteren Produktreleases naturgemäß umfangreicher dokumentiert und schwergewichtiger werden muss.
Eine triviale Lösung steht indes nicht in Aussicht. Zu erwarten, dass man mit irgendeiner einfachen Daumenregel die seit 50 Jahren anschwellende „Softwarekrise“ beseitigen könne, wäre schier naiv. Es muss außerdem endlich klar werden, dass ein Entwicklungsprozess NICHT das oft gehässig verspottete „Write-only-Buch“ sein darf, sondern eine fortschreitende organisatorische Herausforderung darstellt, die man nie endgültig bewältigt. Entwicklung erfolgt durch Menschen und nicht durch Prozesse. Es wird aber eine neue Art von Projektmanagern erforderlich sein, damit die Softwareindustrie die nächste Entwicklungsstufe erreichen kann. Im Projektmanagement müssen erfahrene Softwareingenieure mit fundierten Managementskills Einzug halten, die alle Prozessbereiche aus eigener Praxis kennen und sowohl agil als auch rational denken können.
Die Projektbesetzung ist und bleibt der Schlüssel zum Projekterfolg. Sie wird sich mit der Produktreife laufend verändern müssen, denn ab einer bestimmten Projektgröße wird es nicht möglich sein, vom ersten bis zum letzten Produktrelease dieselben Experten zu beauftragen. Die Bedeutung persönlicher Präferenzen – agil versus diszipliniert – darf nicht unterschätzt werden. Es muss eine stufenweise Projektübergabe von agilen Forschungsteams an durchorganisierte Pflegeteams erfolgen.
Auf zu neuen Ufern
Kenner der Materie, die sich mit dem ewigen Konflikt zwischen Empirismus und Rationalität auseinandergesetzt haben, werden skeptisch bleiben – zu Recht. Die Ansichten stehen sich so diametral gegenüber, dass ein Vorgehen, das alle zufriedenstellt, einer Quadratur des Kreises gleichkommt. Doch die Streiterei zwischen den Verkäufern von Beraterprodukten wie „Agilität“ oder „Prozessreife“ kostet die Wirtschaft astronomische Beträge. Wir sollten Dogmen mit Skepsis betrachten und uns auf der Arbeitsebene verständigen. Eine Vereinbarkeit von Agilität und planbaren Prozessen IST möglich. Der Widerspruch kann durch die evolutionäre Gestaltung des Entwicklungsprozesses aufgelöst werden, bei der das Verhältnis von Agilität und Planbarkeit eine Funktion der Zeit darstellt.
Um dem Kind einen Namen zu geben, haben wir in unserer Beratungspraxis den Kunstbegriff „SlimTrace“ erfunden. Es handelt sich um eine Ansammlung von Werkzeugen, welche die geschilderte Prozessgestaltung ermöglichen sollen. Die Idee lautet (wieder einmal), dass das Rad nicht stets neu erfunden werden muss.
Hinterlasse jetzt einen Kommentar