Agile Entwicklung in der Automobilindustrie

Erstellt von Thomas Arends | |   Automobil

Agile Entwicklung ist in aller Munde. Studien sagen: Für die Automobilindustrie taugt Sie nicht.

Ganz unabhängig davon ob es der Vorstand will.

Eine Streitschrift mit einer Lösung.

Ja ich weiß, es will Keiner hören, aber in der Automobilen Entwicklung taugt die Agile Entwicklung nicht.

Zunächst beginne ich mit einem  Zitat aus der Studie von Kuglermaag

Unanimous view of the respondents:
Following Agile methods and principles “blindly” as described “by the book” 
would have led to failure;therefore, respondents do “cherry picking” and implement agile practices which are useful for them

Nun zuerst muss man wissen dass hier 42 Projektleiter befragt wurden, 15 Life und 27 online.
(Ja man kann die Methode kritisieren und, und, und, aber hier sind erst mal ein paar Ergebnisse)

Die Erfahrung in der Befragten in der Agilen Entwicklung betrug 6 Monate bis 10 Jahre.

Nun, wenn die Projektleiter durchaus Erfahrung haben und es nicht anwenden, könnte es sein, dass diese keine Ahnung haben oder unfähig sind.

Das ist allerdings etwas, was ich definitiv nicht glaube.

Die Aussage: Man macht das was man brauchen kann um erfolgreich zu sein, das zeigt eher, ein gestandenes Maß an Erfahrung und Fähigkeit.

Die Aussage - following by the book would have lead to failure - zeigt eher das worum es geht.

Die Methode ist nicht (immer/vollständig) anwendbar.

Wenn Sie nur in Teilen anwendbar ist, ist Sie aber allgemein nicht anwendbar, oder fahren Sie ein Auto, dass nur Bergab fährt, oder nur abbiegeb kann.
Damit es ein vollständige Ganzes wird, muss es immer funktionieren und nicht nur zum Teil.
Warum dem so ist erkläre ich hier mal ganz kurz.

Wenn man auf ein basierendes System aufsetzt, ist die Agile Entwicklung oftmals gut anwendbar, allerdings ist es in der Automobilindustrie fast immer eine Neuentwicklung, das heißt, die Architektur des Systems und ebenso die Architektur der Software ist nicht vorhanden.

Ohne Architektur ist eine Entwicklung aber nicht möglich.

Funktionen welche unabhängig von der Architektur entwickelt werden sind Klasse, allerdings sind in komplexeren Entwicklungen viele Wechselwirkungen zwischen einzelnen Funktionen.

Ohne Requirements (ASPICE®) (SYS.1/SWE.1/HW.1,MEE.1) sowie Architektur und Schnittstellendefinition(SWE.2/HW.2/MEE.2), sind diese aber nicht bekannt.
Ja stimmt, das sind Prozesse einer anderen Norm, allerdings will die ISO 26262 diese Artefakte.
Wechselwirkungen zwischen einzelen FUSI (Funktionale Sicherheit) Funktionen (ISO 26262) setzten aber eine entsprechende Architektur welche Wechselwirkungen beschreibt und berücksichtigt, voraus.

Wenn Agil, dann ab SWE.3 / HW.3. (per SPICE)
Erst, wenn die Architektur und die Requirements vollständig sind, läßt sich Agil entwickeln. Vorher läuft es ins Leere.

Selbiges ist in der Studie beschrieben.
Rosinenpicken um schnell mal etwas im A / B Muster hin zu zimmern, okay, dafür benötige ich kein wirkliches Entwicklungsmodell.
Das Problem ist aber, dass Sie gemäß ISO26262 Ihr Produkt nach Prozess  entwickeln müssen. (Über alle OPhasen hinweg) Welcher ist es denn nun?

Und im C Muster - meistens klassisch - als V Modell.

Dann kann man auch direkt im V Modell bleiben!

Es gibt eine Lösung. Denn wenn man genau hinschaut widerspricht das V-Modell der Agilität nicht.
Die setzt tatsächlich das Agilitätsprinzip in die ISO 26262 um, setzt aber voraus, dass sich ganz viel in den Köpfen ändert.
Details dazu gerne in einem persönlichen Gespräch oder auf der Medconf

Zurück