Das agile Arbeiten: Softwareentwickler vs. Konstrukteure

Software-Entwicklung und Fahrzeugtechnik: Sprints und Integration

  |   CX Consulting ,

Wie funktioniert die Kommunikation zwischen einem Ingenieur und einem Softwareentwickler? Für das Internet der Dinge verschmelzen oft Welten. So treffen Abteilungen aufeinander, die vorher nur wenig Schnittstellen hatten. Agilität in 2- oder 10-wöchigen Sprints ist nicht vergleichbar mit den Konstruktionsprozessen eines maschinellen Produkts – könnte man meinen. Erfahren Sie, wie sich Spannungen zwischen Fachbereichen zu Innovationen entwickeln können.

 

Die Schnelllebigkeit und hohen Innovationsraten in der IT steht den Herausforderungen der Automobilbranche gegenüber und macht Unterschiede in Vorgehensweisen, aber auch im Tempo sichtbar. So gibt es im klassischen Fahrzeugbau momentan die Phase der Serien-Entwicklung mit 36 bis 48 Monate bis zur Serien-Produktion. Sei es bei einer kompletten Neuentwicklung oder einem Derivat, davor müssen auch verschiedene Stufen der Vorentwicklung durchschritten werden, bis das erste Fahrzeugkonzept steht. Die Integrationsstufen der Serien-Entwicklung für die Integration der Teil- und Vollaufbauten sind als genereller Zeitplan für alle Beteiligten klar spezifiziert. Der lange Takt der Automobilentwicklung trifft auf kurz getaktete Software-Entwicklungsgruppen.

Automobilbranche – Erste Prototypen aus Lehm

Längst arbeiten die Ingenieure mit virtuellen Werkstücken, die ständig ins virtuelle Fahrzeug integriert werden. Was früher in akribischer Spezifikationsarbeit aufgeschrieben und vertraglich festgehalten werden musste, wird heute vorab bereits virtuell erlebbar. So entscheidet der Ingenieur die nächsten Produktionsschritte nicht mehr vorab aufgrund seiner Vorstellungskraft, sondern erlebt das gemeinsame virtuelle Werkstück. Software-Entwickler sind gerade dabei, Continuous Integration als Stand der Technik in ihre Prozesse zu integrieren. Wer ist hier eigentlicher agiler?

 

Die Software-Entwicklung stellt sich unterschiedlichsten zeitlichen Vorgaben. Software für Steuergeräte und die Mensch-Maschine-Schnittstelle (vulgo: Navigations-System) sind fest im Fahrzeug verbaut und müssen mit den zeitlichen Vorgaben der Steuergeräte und damit der maschinellen Konstruktion einhergehen. Und immer mehr Komponenten werden mit software-gesteuerten Geräten versehen. Selbst Scheinwerfer wurden als „adaptive Scheinwerfer“ neu erfunden. Um das vorausfahrende Fahrzeuge zu erkennen, dessen Konturen zu verarbeiten und im Anschluss den Lichtkegel anzupassen, werden Daten benötigt. Auf Basis der Auswertung mit Hilfe von Software können Scheinwerfer entsprechend des Lichteinfalls oder -ausfalls gesteuert werden.

 

Der aktuelle Evolutionsschritt hier wird der Remote-Update sein, um sich aus diesem Korsett befreien zu können und neue Formen der Flexibilität zu finden. Die Smartphone-Industrie hat es vorgemacht. Die Software außerhalb des Fahrzeugs wurde längst an Internet basierte Prozesse angepaßt, Aktualisierungen sind hier selbstverständlich.

 

Beide Entwicklungswelten befinden sich in ihren eigenen Change-und Innovationsprozessen und haben oft Schwierigkeiten zu erkennen, wer sich jetzt wem anpassen sollte: Software-Entwickler gehen oft davon aus, daß gerade sie die neuesten Entwicklungs-Prozesse am Start haben. Automobil-Entwickler sind nicht bereit, ihre bereits auf Erlebbarkeit getrimmten Prozesse und den festen Takt der Serien-Produktion aufzugeben, da sie um den Qualitätsverlust fürchten und ein Kommunikations-Chaos vermeiden wollen. Tatsächlich ist die Skalierung von agilen Software-Entwicklungs-Prozessen ein oft unterschätztes, oder vernachlässigtes Thema. Nun, es gibt Gründe, daß beide Seiten aufeinander zugehen und Best Practices voneinander lernen.

Ständige Erlebbarkeit

 

Eine wichtige Gemeinsamkeit gibt es in der Arbeitsweise von Konstrukteuren und Softwareentwicklern: Der Fokus auf die ständige Erlebbarkeit des Produkts. Die einen arbeiten am virtuellen Werkstück, dessen Eigenschaften man jeden Tag aktuell simulieren kann. Bei der Software wird mit Continuous Integration ebenfalls täglich integriert, so dass sämtliche Weiterentwicklungen von Programmierern und Dienstleistern erlebbar sind.  Auf beiden Ebenen gibt es das Ziel, dass Entwickler nicht mehr einfach eine Spezifikation runter-entwickeln, sondern täglich den Fortschritt und die Änderungen der anderen Teams sehen können. Und das Wichtigste dabei: Sie können darauf reagieren.

Release Train, SAFe und SCRUM

 

Früher gab es große Prozessmodelle mit klaren Richtlinien zur Entwicklung einer Software. Dabei lag der Gestaltungsspielraum hauptsächlich beim Software Architekten. Die Freiheitsgrade eines Entwicklers waren stark eingeschränkt. Diese klaren Strukturen erzeugen wenig Spielraum für Innovationen. Bei einer gleichmäßigeren Verteilung der Freiheitsgrade dagegen entstehen neue Wege und Entwicklungen, aus denen Ideen entstehen. Der Fokus auf Gruppenarbeit und eine damit verbundene vereinfachte Kommunikation bilden dabei die Basis von agilen Methoden. Eine dieser agilen Methoden des Projektmanagements ist der sogenannte SCRUM-Ansatz. Um die Effizienz bei den SCRUM-Teams zu steigern, wurde das Scaled Agile Framework (SAFe) entwickelt. Schwerpunkt des Konzeptes ist hierbei, die verschiedenen Beiträge in die Teamarbeit zu integrieren.

Quelle: https://www.scaledagileframework.com/agile-release-train/

Mit Hilfe von SAFe wird Software ständig beobachtbar für alle Mitwirkenden. So kann an bereits entwickelten Teilbereichen weiterentwickelt werden oder Problemstellungen lösen sich automatisch.

Fazit

 

Momentan ist es noch nicht Stand der Technik, daß die Welt der Software mit der virtuellen Welt der Fahrzeug-Entwicklung ständig integriert wird. Dafür spannt die Software den Bogen zu anderen technischen Devices und Plattformen und erhöht den Vernetzungsgrad immer weiter. Dadurch entstehen noch ganz andere Nutzungsmöglichkeiten, die entkoppelt vom Fahrzeug und den Produktlinien selbst sind:

  • Der Kunde erlebt die Software auch im Portal oder in der App
  • Die Konzernzentrale dagegen erlebt die Software im Backend
  • Der Mechaniker erlebt die Software in seiner Garage

 

Dennoch gilt: Auch diese  Form der Software muss unabhängig vom Alter des Fahrzeugs zu jeder Zeit funktionieren, jede Software-Aktualisierung soll mit den verkauften Fahrzeugen weiter funktionieren. Die Herausforderung liegt darin, die Software weiter zu entwickeln und dabei alle Sachzwänge der unterschiedlichen Modelle über die Jahre mit zu berücksichtigen. Testautomatisierung und Continuous Testing kann die Erlebbarkeit der verschiedenen Modelle simulieren. Sie liefert Antworten auf die Frage „funktioniert unsere neue App-Version auch noch in einem 4 Jahre alten Auto? In aller Welt?“.

Lesen Sie mehr in unserem nächsten Blogbeitrag zum Thema Testautomatisierung.

Wie funktioniert die Kommunikation zwischen einem Ingenieur und einem Softwareentwickler? Für das Internet der Dinge verschmelzen oft Welten.