zurück zum Artikel

Die Automobilindustrie hadert noch mit der Adaption von agilen und Lean-Prinzipien in der Softwareentwicklung. Jedoch wird es dadurch zunehmend schwieriger, den derzeitigen Anforderungen an Automobilsoftware gerecht zu werden. Das Lean Development Model begegnet dem, indem es verschiedene Methoden der Lean-Entwicklung kombiniert.

Agile und Lean-Prinzipien sind in der Softwareentwicklung etabliert. Die Automobilindustrie jedoch, obwohl in der Fertigung zu den Lean-Pionieren gehörend, hadert noch mit deren Adaption in der Softwareentwicklung, wo die Lieferung definierter Pakete zu einem bestimmten Termin üblich ist. Mit dieser Vorgehensweise ist es aber zunehmend schwierig, den derzeitigen Anforderungen an Automobilsoftware gerecht zu werden. Das Lean Development Model begegnet dieser Herausforderung, indem es verschiedene Methoden der Lean-Entwicklung kombiniert.

Zu klassischen Werten der Entwicklung für die Automobilbranche wie Design, Antrieb, Fahrwerk und Sicherheit ist in den letzten Jahren ein weiteres Differenzierungsmerkmal hinzugekommen: Vom Infotainmentsystem erwartet der Endkunde zunehmend die gleichen Funktionen [1], die Smartphones und andere mobile Endgeräte bieten. Diese Techniken unterliegen jedoch einem viel schnelleren Entwicklungszyklus als die Musterphasen der Autoentwicklung [2]. Plant ein Hersteller ein Auto mit zwei bis drei Jahren Vorlauf, lässt sich zwar die Hardware definieren, doch die Anforderungen an die Software werden sich bis zum unwiderruflich feststehenden SOP (Start of Production) noch stark verändern.

Zusätzlich erwartet der Endkunde neue Funktionen und Unterstützung aktueller Techniken über den Autokauf hinaus. Damit ändern sich die Anforderungen an die Software nicht nur während der Planung, sondern auch über den gesamten Produktlebenszyklus. Gleichzeitig werden meist mehrere Funktionsumfänge sowie länderspezifische Varianten angeboten, die auf demselben System basieren. Lineare Planungsverfahren wie Wasserfall und V-Modell geraten da schnell an ihre Grenzen, da sich während des Entwicklungsprozesses nicht umfassend und schnell genug auf Veränderungen reagieren lässt.

Die kontinuierliche Aktualisierung der Software im Auto bedeutet aber auch, dass die Anforderungen an die Hardware zum Produktionsstart höher sind als zu Planungsbeginn. Daher ist statt großer generischer Frameworks eine genau auf die Anforderungen reduzierte Software zu erstellen, um die Rechenkapazität nicht unnötig zu belasten. Das erfordert ein Refactoring, um zum Beispiel Code für alte Anforderungen wieder herauszunehmen. Nur eine Software, die den KISS- ("Keep it simple and stupid") und Clean-Code-Prinzipien [3] folgt, bleibt langfristig wartbar und reduziert das Risiko für neue Fehler. Zur Vermeidung von Regressionen ist die Nutzung automatisierter Test-Frameworks essenziell.

All das sind Eigenschaften, die agile Entwicklungsmethoden mitbringen und sie daher für die Automobilindustrie interessant machen. Das sich von ihnen ableitende Lean Development Model ist eine speziell auf die Automobilsoftwareentwicklung zugeschnittene Herangehensweise, die diese Prinzipien kombiniert. Es vereint Prinzipien aus agilen Methoden und dem Lean Software Development. Aus Projektmanagement-Sicht kommen in erster Linie Scrum und Kanban (mit Fokus auf Projekt- und Teammanagement) zum Tragen. Zusätzliche Methoden aus Extreme Programming (XP) unterstützen die Softwareentwicklung (s. Abb. 1). Doch wie kam es zu seiner Entstehung?

Von Scrum und Kanban zum Lean Development Model

2008 wurde zur Organisation der Feature-Entwicklung für ein Infotainmentsystem bei Elektrobit Automotive Scrum eingeführt. Iteratives Vorgehen und feste Sprint-Längen brachten positive Erfahrungen, da sich der Kunde – ein amerikanischer Automobilhersteller – früh und regelmäßig einbeziehen ließ.

Nachdem die Feature-Entwicklung weitgehend abgeschlossen war, verlagerte sich der Schwerpunkt hin zur Stabilisierung und Verbesserung des integrierten Gesamtsystems. Neue Fehler und sich dadurch verändernde Prioritäten sowie unterschiedlich ausgelastete Experten erschwerten es allerdings, zu Beginn eines Scrum-Sprints eine stabile Planung aufzustellen. Daher stellte das Team auf Software-Kanban zur Organisation um, was deutlich besser zu den anfallenden Tätigkeiten passte.

In einer späteren Phase galt es wieder, neue Features zu entwickeln. Statt vom etablierten Kanban wieder zu Scrum zu wechseln, entschied sich das Team, die beiden Methoden zu kombinieren. Aufgaben werden in Form von Tickets zu Storys gebündelt, die ein Feature des Infotainmentsystems darstellen. In dieser Granularität lassen sich Storys mit dem Kunden im Backlog priorisieren. Das Team arbeitet die einzelnen Tickets ab, bis sich die Story an den Kunden ausliefern lässt.

Zunächst war diese Vorgehensweise eine lokale Angelegenheit, da das Team hauptsächlich in Deutschland saß und die Entwicklung auf einem schlichten Board koordinieren konnte. Mit dem Wachstum und der Verteilung des Teams kamen zusätzliche Tools wie JIRA zum Einsatz, die die Koordination des Gesamtprojekts standortübergreifend ermöglichten.

Im Wesentlichen folgt das Lean Development Model genannte Verfahren den sieben im Folgenden genannten Prinzipien.

LDM-Prinzipien

1. Liefere so schnell wie möglich

Beim Modell ersetzt die agile Priorisierung eines Backlogs die klassische, detaillierte Planung für alle Ressourcen. Die Aufgaben werden nicht im Voraus durch den Projektleiter zugewiesen, sondern durch das Team selbstständig in den nächsten Workflow-Schritt gezogen (Pull statt Push) (Abb. 2). Das Hauptaugenmerk liegt dabei auf der Maximierung des Durchsatzes.

Die Limitierung von Arbeitspaketen in den Workflow-Schritten verhindert, dass in frühen Schritten mehr Zwischenprodukte erzeugt werden, als sich in späteren verarbeiten lassen. Angefangene Aufgaben, die Tickets, sind erst fertigzustellen, bevor neue begonnen werden, und jedes Teammitglied ist dafür verantwortlich, dass die Bearbeitung nicht ins Stocken gerät. Für die zu optimierende Cycle Time gibt es keine Pause oder Unterbrechung. Wenn ein Ticket zum Beispiel durch Warten auf Kunden-Feedback blockiert ist, läuft die Zeit trotzdem weiter. Ändert ein Entwickler die Codebasis, ist er so lange für das Ticket verantwortlich, bis die Änderung erfolgreich durch die Continuous-Integration-Tool-Kette validiert wurde. Bis der Fehler behoben ist, dürfen keine weiteren Änderungen gemacht werden.

Diese Vorgehensweise erlaubt eine tägliche Lieferung an den Kunden früh im Entwicklungsprozess. Eine ausgewählte Version der Software wird durch einen Smoke-Test validiert und mit dem Testergebnis ausgeliefert. Der Zustand der Software ist für den Kunden so immer sowohl transparent als auch greifbar und ermöglicht es ihm, Feedback zu geben, um Spezifikationen und Implementierung kontinuierlich zu verbessern.

2. Qualität inklusive

Die Definition of Done (DoD) ist entscheidend für die Qualitätssicherung und wird vom Team zu Beginn des Entwicklungsprozesses festgelegt. Sie legt fest, welche Schritte zur Implementierung einer User Story gehören, beispielsweise bei der Einarbeitung von Änderungen. Letztere sind ganzheitlich durchzuführen, zu dokumentieren und durch Reviews abzusichern. Bei der Übergabe einer Änderung ans Testteam muss neu erstellter und geänderter Code eine Vielzahl von Unit-Tests absolviert haben, die der Entwickler zu erstellen hat. Die Erwartung dabei ist, dass eine Änderung bei Übergabe keine Fehler mehr aufweist.

Das soll sicherstellen, dass Fehler so früh wie möglich aufgedeckt werden. Je höher der Automatisierungsgrad, desto schneller sollten sich Fehler und Regressionen finden lassen. Die Tests werden je nach Phase des Projekts und Art der Lieferung skaliert:

• tägliche Smoke-Tests für die Tages-Lieferung,
• fokussiertes Testen für Engineering Drops,
• Integrationstests für wichtige Meilenstein-Lieferungen,
• langlaufende Validierungstests für den Produktionsstart und
• kontinuierliche Unit-Tests als Teil von Continuous Integration.

Die Automatisierung wird durch das Continuous-Integration-Tool Jenkins gesteuert. Angebundene Test-Frameworks erlauben es, Interaktionen zu simulieren und die Ergebnisse dem Tester und Entwickler aufzubereiten. Der Entwickler bekommt direkte Rückmeldung zu statischer Codeanalyse und Unit-Tests sowie Testabdeckung. Die Auswertung durch SonarQube [4] ist für den Architekten, Projektleiter und Testmanager eine wertvolle Unterstützung. Metriken zu Lint-Warnungen, Duplizierung und Komplexität sowie das SIG-Maintenance-Modell [5] helfen, den Gesamtüberblick zu bewahren.

Die Weichen für erfolgreiches Testen werden bereits am Anfang gestellt. Die Beachtung von Design For Testability (DFT) und Test Driven Devlopment (TDD) mit Refactoring führen zu besserem Design und stabiler Architektur.

3. Just-in-time-Entscheidungen

In jedem langlaufenden Softwareprojekt wird der anfängliche Plan durch veränderte Anforderungen und Rahmenbedingungen schnell obsolet. Er ist daher über die gesamte Laufzeit fortwährend anzupassen. Zu Anfang einer Iteration müssen alle Anforderungen für den Inhalt abgestimmt sein, damit die Story-Teams die Feinplanung vornehmen können. Details zu Anforderungen zukünftiger Iterationen können noch unscharf sein, um flexibel auf Änderungen reagieren zu können. Annahmen, speziell die zu Beginn des Projekts getroffenen, sind oft zu korrigieren. Festlegungen zu Architektur und Design sollten möglichst nur soweit getroffen werden, wie es für die nächsten Schritte notwendig ist. Ziel ist es, teure Sackgassen zu vermeiden und sich Möglichkeiten offen zu halten, um das System anzupassen, wenn gesicherte Informationen verfügbar sind. Optimierungen erfolgen so spät wie möglich. Die Softwarearchitektur und Testabdeckung müssen regelmäßiges Refactoring unterstützen.

Nicht alle Zulieferer arbeiten iterativ. Werden ihre aktualisierten Komponenten integriert, muss eine Stabilisierungsphase erfolgen. Hierfür werden alle Tickets priorisiert, aber nicht nach Stufen, sondern in einer eindeutigen Rangordnung – dem Ticket-Backlog. Die geplante Grenze zur nächsten Iteration, und damit die Anzahl der abzuarbeitenden Tickets, ermittelt man anhand von Metriken wie der Cycle Time und dem Inflow neuer Tickets. Ein Ticket höherer Priorität kann es erfordern, den Inhalt einer Iteration anzupassen.

4. Verschwendung eliminieren

Um die Ressourcen des Teams so sinnvoll wie möglich einzusetzen, konzentriert sich das Team stets auf das aktuell benötigte Feature-Set. Work-in-Progress-Limits (WiP) für jedes Teammitglied und die Workflow-Schritte verhindern, dass an zu vielen Dingen gleichzeitig gearbeitet wird. Wechselzeiten, Verluste durch Übergaben und die Fehlerquote werden reduziert. Auch halbfertige Funktionalitäten, die zum Zeitpunkt der Lieferung als Verschwendung anzusehen sind, werden so vermieden.

Ganz vermeiden lassen sich Fehler jedoch nie. Daher ist der Arbeitsprozess dahingehend angepasst, Fehler so früh wie möglich zu identifizieren, um die Entwicklung fehlerhafter Funktionen und die dabei verlorene Zeit zu minimieren. Ebenso wichtig ist es, sich von nicht mehr benötigten Features zu trennen. Over-Engineering und vorauseilende, auf Annahmen basierende Implementierung sind zu vermeiden. Das verkürzt nicht nur die Entwicklungszeit, sondern reduziert auch Wartungs- und Testaufwand.

5. Das Team stärken

Basis der Teamarbeit sind Selbstbestimmung, Motivation und Ausrichtung auf ein gemeinsames Ziel. Der Mensch mit seinen Fähigkeiten steht im Vordergrund, die Ressource Arbeitskraft tritt in den Hintergrund. Das Team gestaltet den Entwicklungsprozess durch gemeinsame Retrospektiven weitgehend selbst.

Die Teamkommunikation wird durch die Visualisierung des Workflows auf einem magnetischen Board an der Wand unterstützt (Abb. 5).

Um auch standortübergreifend arbeiten zu können, werden die lokalen Boards mit einer elektronischen Übersicht synchronisiert. Die Projektmanager stellen priorisierte Arbeitspakete in der To-do-Spalte zur Verfügung. Der nächste freie Mitarbeiter eines Story-Teams zieht sich das Ticket (Pull) und kennzeichnet es mit einem seiner zwei Magneten (persönliches WiP-Limit). Ist kein Magnet mehr frei, sind Tickets zuerst abzuschließen oder an einen Kollegen zu übergeben (Abb. 6).

Die lokalen Teams behalten die Übersicht am physikalischen Board. Bei offenen Fragen oder sogenannten Findings wird das Ticket eigenverantwortlich mit einem "Talk about me"-Magneten versehen. Während des Daily-Standup-Meetings spricht das Team die markierten Tickets an, detaillierte Besprechungen erfolgen im Anschluss in kleinerem Kreis.

In der Feature-Entwicklung formieren sich dynamisch die Story-Teams, die sich um die Abarbeitung aller Tasks zu einer User Story kümmern. Die aus dem Scrum entlehnten Stories helfen dem Team, auch in Kanban den Überblick zu behalten. Das Team ist interdisziplinär besetzt mit Softwarearchitekten, Testern und Entwicklern. Im Daily-Standup-Meeting berichtet abwechselnd eines der Teammitglieder über den aktuellen Stand der Story. Auf diese Weise werden alle Teammitglieder gleichermaßen eingebunden.

Fazit

6. Lernen fördern

Kaizen (dt. etwa "Veränderung zum Besseren") als Konzept zur kontinuierlichen Verbesserung ist ein zentraler Baustein des Lean Development. Probleme werden im Daily-Standup-Meeting angerissen sowie dann in kleineren Gruppen diskutiert und gemeinsam gelöst. Wenn nötig, werden die dokumentierten Regeln angepasst, um ein erneutes Auftreten zu verhindern. Zudem reflektiert das Team in regelmäßigen Retrospektiven den Projektverlauf und identifiziert Best Practices sowie Maßnahmen zur Verbesserung. Das stellt sicher, dass das Projekt stets stabil läuft und dennoch notwendige Änderungen inkrementell Einzug finden. Dabei sind Arbeitsprozesse und -grundlagen, wie die Definition of Done, stets für alle Teammitglieder sichtbar dokumentiert.

Paarprogrammierung und Reviews sowie ein firmeneigenes Wiki ermöglichen womöglich den regelmäßigen Austausch von Projekt- und Fachwissen. Bei Elektrobit wird weiterhin der Wissenstransfer durch die firmeneigene Akademie gefördert, bei der sich jeder als Teilnehmer und Trainer beteiligen kann.

7. Ganzheitliche Betrachtungsweise

Im betrachteten Projekt ist Elektrobit als Integrator verantwortlich für das Gesamtsystem. Aber auch in Projekten, in denen nur eine Teilverantwortung vorliegt, darf das Gesamtbild nie aus den Augen verloren werden. Das Zusammenspiel aller Komponenten bestimmt letztlich den Eindruck, den der Endkunde im Auto haben wird. Daher ist es wichtig, die Software nicht nur auf Entwicklungskomponenten, sondern auch im Auto zu testen, und zwar sowohl auf der Teststrecke als auch in Alltagssituationen. Hierdurch werden nicht nur Fehler gefunden, sondern auch für den Autohersteller wertvolles Verbesserungspotenzial bezüglich Bedienbarkeit identifiziert – eines der wichtigsten Merkmale für die Kundenzufriedenheit [6].

Fazit

Im Laufe des Projekts hat sich gezeigt, dass keine der Lean-Methoden allein adressiert, was für eine erfolgreiche Entwicklung von Embedded-Software notwendig ist. Aber durch die maßgeschneiderte Kombination der passenden Vorgehensweisen und der kontinuierlichen Anpassung an die Bedürfnisse des Projekts konnte das Team die Transparenz bei der Entwicklung erhöhen und Probleme früher identifizieren.

Der Autohersteller wurde durch den Einsatz des Lean Development Model wesentlich stärker in die Softwareentwicklung eingebunden. Statt zu bestimmten Terminen fertige Arbeitspakete zu erhalten, begleitete er die Entwicklung, konnte täglich den Fortschritt verfolgen und jederzeit mit Anpassungen oder neuen Ideen einwirken. Auf diese Weise ist ein Infotainmentsystem entstanden, das die Anforderungen der Unterhaltungselektronik erfüllt und nicht nur die, die zu Projektbeginn definiert wurden.

Christian Hausner
ist als Projekt-Manager für die Elektrobit Automotive GmbH tätig. In seiner Rolle als zertifizierter Scrum Master betreute er Projekte verschiedener Automobilhersteller. Er unterstützt internationale Projekte beim Einsatz agiler Methoden.

Martin Dusch
ist als Team Manager für die Elektrobit Automotive GmbH tätig. Seit 2002 ist er als Entwickler, Projektleiter und in den Bereichen Qualitäts- und Wissensmanagement aktiv. Als zertifizierter Scrum Master beschäftigt er sich seit mehr als fünf Jahren mit agiler Softwareentwicklung. (ane [7])

URL dieses Artikels:
https://www.heise.de/-2094692

Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Aktueller-Stand-der-App-Entwicklung-fuer-die-Automobilbranche-1566172.html
[2] http://www.sebastian-schneider.eu/cms/iso-15504/die-musterphasen-der-automobilbranche
[3] https://www.heise.de/hintergrund/Clean-Code-Developer-in-Brownfield-Projekten-855114.html
[4] https://www.heise.de/hintergrund/Einsatz-von-SonarQube-zur-Qualitaetssicherung-in-heterogenen-Projekten-1953460.html
[5] http://www.sig.eu/en/Research/690.html
[6] http://autos.jdpower.com/ratings/
[7] mailto:ane@heise.de

Copyright © 2014 Heise Medien