Embedded meets IT

Automotive Embedded Software mit agilen Methoden und SAFe entwickeln

Der klassische Entwicklungsablauf im V-Modell hat lange gut funktioniert. Doch bei komplexen Softwaresystemen für das autonome, vernetzte Fahren stoßen Projekte mit diesem Ansatz an Grenzen. Ist plötzlich alles falsch? Die Antwort ist ein klares Jein.

Software für vernetzte, autonome Fahrzeuge ist nie fertig. Sie wird laufend „Over-the-Air“ aktualisiert. Das hat Konsequenzen in der Entwicklung: Es ist kaum möglich, im Vorfeld die Komplexität der Projekte abzuschätzen. In manchen Bereichen fällt es schwer, das Entwicklungsziel bis ins letzte Detail zu beschreiben. Entwicklerteams fahren quasi auf Sicht: Stoßen sie beim klassischen Vorgehen auf technische Schwierigkeiten oder neue Aspekte, müssen sie oft einige Prozessschritte zurück – und mit ihnen alle Kollegen und Partner auf Lieferantenseite.

Bei ähnlichen Problemlagen greift die IT-Welt zu agilen Methoden: In kurzen Sprints entstehen Prototypen, die sofort mit den Kunden abgestimmt werden. Das Scaled Agile Framework (SAFe) dient als Methodenbaukasten, um das agile Vorgehen auf allen Ebenen der Produktentwicklung zu skalieren. Die Frage ist nur: Funktioniert das auch bei den hohen Sicherheitsanforderungen im Automotive-Umfeld?

Bild 1: Die Stacey Matrix von Ralph Douglas Stacey teilt Problemstellungen entsprechend Komplexität der Anforderung und Bekanntheit der Technologie auf.

Das richtige Werkzeug

Einen methodischen Königsweg gibt es in der Software-Entwicklung nicht. Je weniger am Anfang eines Projekts über die Anforderung und Technologie bekannt ist, desto wichtiger sind flexible Werkzeuge. Wer würde zum Hammer greifen, wenn noch unklar ist, ob er es mit Nägeln oder Schrauben zu tun bekommt? Ähnlich verhält es sich mit Entwicklungsmethoden: Ihr Nutzen wird erst klar, wenn die Aufgabenstellung bekannt ist (Bild 1).

Dave Snowdens Cynefin Framework (Bild 2) verhilft zu einer ersten Einschätzung. Bei einfachen Aufgaben mit klarem Ursache-Wirkungs-Zusammenhang kann sich die Projektplanung an „Best Practices“ orientieren. Dagegen sind bei komplizierten Aufgaben Analysen der Ursache-Wirkungs-Prinzipien oder Rückgriffe auf Expertenwissen gefordert, um das Vorgehen an Good Practices ausrichten zu können. Bis jetzt ist dieser Good-Practice-Ansatz das gängige Vorgehen für Automotive-Entwicklungsprojekte gemäß V-Modell.

Bei komplexen Problemen klärt sich die Beziehung zwischen Ursache und Wirkung oft erst im Nachgang – und ist beim Projektstart nicht vollständig beschreibbar. Bei der Einführung neuer Technologien gehen Entwickler daher experimentell in kleinen Zyklen vor. Dieses inkrementelle Vorgehen mit agilen Arbeitsweisen und SAFe setzt sich in Entwicklungsprojekten für autonome, vernetzte Fahrzeuge durch. Als Steigerung nennt Snowden chaotische Problemstellungen. Wo ein erkennbarer Zusammenhang zwischen Ursache und Wirkung fehlt, müssen Entwickler per Trial and Error vorgehen und ihre Methoden ständig nachjustieren, um der Lage Herr zu werden. Dies ist das Vorgehen in Krisen.

Bild 2: Das Cynefin Framework – unterschiedliche Problemstellungen erfordern verschiedene Lösungsansätze.

Zwischenfazit: Welches Vorgehen auf schnellstem Weg zum Ziel führt, hängt in erster Linie von der Problemlage ab. Weil sich in der Realität Aufgaben ändern und technologische Erkenntnisse reifen, sollten Methoden flexibel genug sein, um zielgerichtet arbeiten zu können.

Ausrichtung auf das Ziel

Bei der Entwicklung komplexer Fahrzeugsysteme mit unbekannten Technologien ist es mit agilen Methoden möglich, inkrementell auf ein Entwicklungsziel hinzuarbeiten. Dabei gilt es, das Gesamtziel und die angestrebten Termine im Blick zu behalten. Die alles entscheidende Größe ist der Kundenmehrwert.

Das inkrementelle Vorgehen und die sofortige Abstimmung von Prototypen mit den Kunden ermöglichen es, bei Bedarf schnell umzusteuern. Alle Entscheidungen inklusive der Verteilung und Priorisierung aller Aufgaben fallen im Team. Um die Projekte dennoch effizient planen, die Aufgaben richtig priorisieren und letztlich die beste technische Lösung finden zu können, ist ein Höchstmaß an Transparenz und gegenseitigem Vertrauen gefragt.

Das Organisationsframework SAFe bündelt Organisations­und Workflow-Muster, die das agile Vorgehen unterstützen: Kanban, DevOps, Scrum und Customer/User Centricity sowie das Big Room oder Product Increment (PI) Planning. Letzteres bietet allen Beteiligten die Möglichkeit, Ideen und Visionen in einem (virtuellen) Raum zu sammeln, um die gemeinsame Marschroute daran abzustimmen – was der Verzahnung von Produktmanagement und Entwicklung dient.

Erfahrungen bei der Umsetzung

Seit knapp einem Jahrzehnt nutzt ETAS agile Methoden in der Software-Entwicklung. Dabei war deren stufenweise Einführung vom Umgang mit neuen Technologien getrieben. Nach einer initialen Heatmap-basierten Nutzen-Analyse starteten 2011 die ersten Teams. Sie fanden sich zügig in der agilen Methodik zurecht – Projekterfolge mehrten sich. 2014 stiegen im Bereich Embedded Systems und in der Hardware-Entwicklung weitere Teams auf agile Methoden um. Seit 2017 nutzt ETAS auch SAFe für die schrittweise Skalierung teamübergreifender Kollaboration und zur Arbeitssteuerung in der Entwicklung.

Zum Erfolg trug bei, dass die Gruppen- und Abteilungsleitung uneingeschränkt zu der neuen Methodik standen und diese forcierten. Doch gab es auch Herausforderungen. Früh erkannten die Pilotgruppen, dass es keine per se richtige oder falsche Vorgehensweise mehr gibt. Für jeden Einzelfall ist neu zu klären, welche Methode für die spezifische Problemlage am vielversprechendsten ist. Dabei sind die Stacey Matrix und das Cynefin Framework nützliche Hilfen. So konnten die Probleme leichter eingeordnet und ein gemeinsames Verständnis erzielt werden. Hitzige Diskussionen über die richtige Methode gehörten der Vergangenheit an.

Anfangs suchten die Teams individuelle Lösungs- und Optimierungswege, was zu Redundanzen im Portfolio führte: Komponenten mit ähnlicher Funktion wurden mehrfach entwickelt und auf den Markt gebracht, was bei Kunden Verwirrung stiftete, den Wartungsaufwand erhöhte und die Interoperabilität der Produkte behinderte. Dem wirkte ETAS 2014 mit dem Solutions-Prinzip entgegen. Solutions im ETAS Sinn sind Funktionalitäten, die auf dem Zusammenspiel mehrerer Produkte und Komponenten basieren. Jede Solution löst mindestens ein Kundenproblem. Die Interoperabilität der Einzelprodukte ist essenziell. Beim Umsetzen dieses Prinzips erwiesen sich die Meetings des PI Planning als unverzichtbar: Darin gelang die Ausrichtung an gemeinsamen Zielen – was spürbar veränderte Arbeitsweisen und regelrechte Motivationsschübe auslöste.

Bild 3: Die zwei Grundstrukturen in einer Organisation lassen sich mit Skelett und Muskeln vergleichen.

Weitere wichtige Erkenntnisse

Zur technischen Komplexität gesellte sich hoher Abstimmungsbedarf zwischen den Projekten, die im ETAS Portfolio eine Vielzahl von Abhängigkeiten und Wirkzusammenhängen zwischen den Produkten beachten müssen. Weil die Interoperabilität für Kunden ein zentraler Mehrwert der ETAS Lösungen ist, ging es darum, diese Abhängigkeiten besser handhab- und steuerbar zu machen. Das erfordert eine optimale organisatorische Einbettung der agilen Methodik. Hier kommt der Automatisierungsansatz DevOps ins Spiel: Er regt die Entwicklung (Development), IT-Administration (Operation) und Qualitätssicherung (QS) durch gemeinsame Anreize, Prozesse und Entwicklungswerkzeuge zur effektiveren Zusammenarbeit an.

Prozessoptimierung und Digitalisierung der Abläufe sind eng verzahnt. Wie die Muskeln und Knochen im menschlichen Bewegungsapparat, sind die operative, (Kunden-)wertschaffende Struktur und die Ablauforganisation untrennbar (Bild 3). Darum setzt die Einführung der agilen Methoden eine holistische Transformation in Gang (Bild 4). Diese läuft nicht von allein. Um Frustrationen und Zweifeln zu begegnen, hat es sich bewährt, gut vernetzte Mitarbeiterinnen und Mitarbeiter zur Moderation abzustellen. Auch ein klares Commitment der Leitungsebene und das Definieren klarer Verantwortlichkeiten sind eine wichtige Voraussetzung.

Bild 4: Viele Bereiche sind bei der Organisationsentwicklung beteiligt.

Fazit: Positive Bilanz

Zehn Jahre nach der Einführung agiler Arbeitsmethoden ist die Bilanz positiv. Die Verlässlichkeit der Planung und die Kundenzufriedenheit sind spürbar gestiegen. Auch im neuen Arbeitsmodell erfüllen wir unabdingbare Sicherheitsanforderungen gemäß ASPICE oder ISO 26262. Gestiegene Produktivität, zufriedenere Mitarbeiterinnen und Mitarbeiter und höhere Zuverlässigkeit bestätigen unseren Weg. Im Bosch-Konzern und in der SAFe-Welt gilt unser Vorgehen als richtungsweisend. Und ganz nebenbei erweist sich unsere gelebte agile Methodik als gutes Argument im hart umkämpften Fachkräftemarkt. Auch das hilft, Kurs zu halten: Agil in die vernetzte Zukunft.

Autoren

Richard Mutschler ist Chief Chapter Lead Agile Leadership und Head of Lean Agile Center of Competence & Solution Train Engineer bei der ETAS GmbH.

Oliver Trost ist Chief Chapter Lead im Bereich Produktmanagement bei der ETAS GmbH.

Jürgen Crepin ist Senior Marketing and Communications Manager bei der ETAS GmbH.

  • Embedded meets IT: Automotive Embedded Software mit agilen Methoden und SAFe entwickeln Download