Automotive SPICE & Scrum: Einführung

Um was geht es?

Vor 9 Jahren habe ich hier zum ersten Mal über Automotive SPICE und Scrum geblogged. Da ich aktuell im Rahmen eines neuen Trainingskonzepts meine Gedanken zu dem Thema zu Papier bringe, möchte ich hier etwas zur Diskussion in der Community beisteuern und eine kleine Reihe in meinem Blog beginnen. Diese Gedanken in den nächsten Folgen zu einzelnen Prozessen sind keine Musterlösung, sondern sollen eine Gesprächsgrundlage darstellen um gemeinsam in weitere Details einzutauchen.

In dieser ersten Folge soll es um die Grundlagen gehen, auch wenn der eine oder die andere schon weiß, was Automotive SPICE ist. In dem Fall, folgt mir bei LinkedIn um die nächste Folge mit “MAN.3 Project Management” nicht zu verpassen.

Was ist Automotive SPICE?

Um die Jahrtausendwende haben die Softwareanteile in Fahrzeugen bis dahin ungeahnte Ausmaße angenommen. Die Entwicklung komplexer Software-Systeme hat sowohl die Automobilhersteller (OEMs), wie auch die Lieferanten vor neue Herausforderungen gestellt. Überspitzt formuliert: Es fand an vielen Orten eine Transformation von der mechanischen oder elektromechanischen Fabrik zum IT-Konzern statt. Dementsprechend hatten die OEMs auch immer wieder Probleme mit der Softwarequalität, die es teilweise auch in die Medien schafften und die OEMs hatten ein großes Interesse daran, aktiv auf die Lieferanten (die den Löwenanteil der Softwareentwicklung trugen) einzuwirken um die Softwarequalität in den Fahrzeugen zu verbessern. Wären jedoch verschiedene OEMs mit verschiedenen Vorstellungen zu Entwicklungsabläufen bei einem TIER-1-Lieferanten aufgeschlagen, wäre der arme Lieferant in Besprechungen, Assessments und Widersprüchen versunken. So haben sich Anfang der 2000er Jahre ein paar deutsche OEMs zusammengetan und ein Konzept entwickelt, wie sie die Reife in der Produktentwicklung bei ihren Zulieferern bewerten können, Das Ganze sollte so einheitlich, dass jeder OEM die Ergebnisse des anderen akzeptiert. Die Basis dazu war die ISO-Norm 15504, die ein Rahmenwerk zur Reifegradbewertung von Softwareentwicklungsorganisationen bietet (Hinweis: inzwischen wurde die ISO-15504 durch ISO-33000 Reihe abgelöst.)

Diese „SPICE-Norm“ (SPICE = Software Process Improvement and Capability dEtermination) legt fest, welche Reifegrade es gibt und wie diese bewertet werden. Dieser Rahmen ist Branchenneutral, da es nur um die Bewertung geht. „Automotive SPICE“ stellt nun innerhalb dieses Bewertungsrahmens ein sogenanntes Prozess-Referenzmodell (PRM) auf (Welche Prozesse wollen wir bewerten? wie benennen wir diese? Was für Ziele und Ergebnisse sollen diese Prozesse haben?) und ein Prozess-Assessmentmodell (PAM), welches detailliert die Erwartungshaltung an die gelebten Prozesse der Organisation beschreibt. Das aktuelle PRM/PAM gibt es hier in der Version 3.1 zum Download.

Die Reife wird in Assessments ermittelt, in denen (zumeist) externe Assessoren durch Interviews und Einsicht in Dokumente ermitteln, wie die Organisation arbeitet, dieses mit dem Prozess-Assessmentmodell (PAM) vergleichen und dementsprechend pro asseriertem Prozess ein Reifegrad („Capability Level“, umgangssprachlich auch “SPICE Level”) vergeben. Der Umfang eines Assessments wird im Vorfeld festgelegt, nicht alle im PRM enthaltenen Prozesse werden bewertet, der VDA hat einen “Standardumfang” mit den wichtigsten Prozessen festgelegt (“VDA Scope”). Die Reifegrade aus der Norm, die auch im Assessment verwendet werden, sind wie folgt:

• 0: unvollständig
• 1: durchgeführt
• 2: gesteuert
• 3: etabliert
• 4: vorhersagbar
• 5: optimierend

Relevant für die Praxis sind insbesondere die Reifegrade 1 (die erwarteten Ergebnisse kommen irgendwie zustande) und 2 (das Erarbeiten der Ergebnisse wird geplant und nachverfolgt). Schon bei Reifegrad 3 (einheitliche Vorgehensweise) darf die Frage gestellt werden, wie viel Aufwand dieser Schritt verursacht und wieviel Verbesserung bei der Produktqualität dabei herausspringt.

Bei Reifegrad 1 geht es um die Basics im Engineering, im Projektmanagement und bei den unterstützenden Prozessen. Die Anforderungen sind in sogenannten Base Practices (BPs) im PAM pro Prozess festgehalten. Bei Reifegrad 2 geht es um generische Dinge, wie Dokumentenlenkung, sowie Planung und Nachverfolgung von Tätigkeiten. Dementsprechend sind die Anforderungen hier nicht mehr pro Prozess festgelegt, sondern übergreifend in sogenannten Generic Practices (GPs).

Zu beachten: Während Level 1 (grob gesagt) mit 50% Zielerreichung bei den BPs erreicht werden kann, also indem man halbwegs gut arbeitet, müssen die Level 1 Abläufe nahezu perfekt sein um einen Level 2 darauf aufbauen zu können. Beim Schritt zu Level 2 ist also der Hauptaufwand nicht, die entsprechenden GPs umzusetzen, sondern die darunterliegenden BPs wirklich gut hinzubekommen.

Wie passt ASPICE zu Agil?

Aufgrund der historischen, eher wasserfallartig organisierten Entwicklungsprozesse, herrschte beim Aufkommen agiler Ansätze die Annahme vor, dass das neue Arbeiten nicht so recht zu Automotive SPICE passt. Viele Anforderungen werden jedoch von agilen Ansätzen schon abgedeckt andere müssen so oder so mit etwas Aufwand erfüllt werden und nur ganz wenige Aspekte bergen wirklich einen Konflikt zwischen Automotive SPICE und Scrum. So lassen sich die Prozesse (ich verwende hier das PRM 3.1 mit dem VDA Scope + SYS.1) in etwa wie folgt clustern:

• Prozesse, bei denen etwas Aufwand nötig ist, um die Anforderungen von Automotive SPICE darstellen oder argumentieren zu können. Die wichtigsten Fragen:
  • MAN.3 Projektmanagement: Was ist ein Projekt bei agilen Ansätzen?
  • SYS.1 Anforderungserhebung: Wie wird das agile Backlog eingesetzt?
  • SYS.2: System-Anforderungsanalyse: Sind Anforderungen Backlog Items oder etwas anderes?
  • SWE.1 Software-Anforderungsanalyse: Sind Anforderungen Backlog Items oder etwas anderes?
  • SUP.1 Qualitätssicherung: Wie, wann, wo läuft die Qualitätssicherung?
  • ACQ.4 Lieferanten-Monitoring: Wie läuft die agile Zusammenarbeit mit Lieferanten?
• Prozesse, bei denen die Inhalte wie bekannt sind, aber in einem agilen Kontext definiert werden muss, wer wann diese Inhalte erstellt:
  • SYS.3 System Architektur
  • SYS.4 Systemintegration- und integrationstest
  • SYS.5 Systemtest
  • SWE.2 Software Architektur
  • SWE.3 Software detailliertes Design
  • SWE.4 Softwware-Unittest
  • SWE.5 Softwareintegration- und integrationstest
  • SWE.6 Softwaretest
  • SUP.9 Problemlösungsmanagement
  • SUP.10 Änderungsmanagement
• Prozesse, die sich kaum von agil zu klassisch unterscheiden:
  • SWE.4 Software Unit Test
  • SUP.8 Konfigurationsmanagement

Mit Blick auf Reifegrad (Level) 2 lässt sich sagen, dass der Hauptaufwand auf Level 1 liegt um all die Details zu definieren. Level 2 hingegen ist mit Scrum der einfachere Teil, denn die hier geforderte Planung und Nachverfolgung wird von Scrum gut abgebildet. Und der zweite Aspekt von Level 2 sollte ohnehin vorhanden sein: eine funktionierende Dokumentenlenkung.

Ausblick

Jetzt haben wir hoffentlich in etwa den gleichen Stand zu Automotive SPICE. In den nächsten Folgen werde ich einzelne Prozesse aus dem PRM/PAM 3.1 diskutieren. Die Version 4.0 steht vor der Türe und wird ein paar Erleichterungen bringen, wie z.B. das Tracen auf Cluster von Requirements oder das Verschieben von Strategien auf Level 2. In meinem Workbook zu meinem neuen Training, das im Frühjahr 2024 erscheinen wird, werde ich mich dann auf PRM/PAM 4.0 beziehen.

EDIT 2023-12-16: Inzwischen ist das PRM/PAM in der Version 4.0 erschienen. Daher werde ich die folgenden Artikel auch auf die aktuelle Version beziehen.