Warum Agile Entwicklung in der Automobilindustrie nicht geht

Agile Entwicklung ist in aller Munde, für die Automobilindustrie taugt Sie jedoch nicht.

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 Umfrage 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 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 anwendbar.

Warum dem so ist erkläre ich hier mal ganz kurz.

Wenn man auf ein basierendes System aufsetzt, ist die Agile Entwicklung sicherlich 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 SW ist nicht vorhanden.

Ohne Architektur ist eine Agile 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 (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 ist die 26262 ein Ableitung aus der 15504.
Wechselwirkungen zwischen einzelen FUSI 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 im Endeffekt 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.

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

Dann kann man auch direkt im V Modell bleiben!

Es gibt eine Lösung.
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 einer Präsentation.