AutorInnen: Silke Hertel, Richard Leitner
In der einschlägigen Fachliteratur sind die Gegebenheiten der betrachteten Softwareentwicklungsprojekte immer klar umrissen: Stakeholder wünschen sich Funktionalitäten, Entwickler sollen diese über Prozesse, Tools und Infrastruktur umsetzen. Es wird von „einer Gesamtorganisation“, „einer Infrastruktur“, „einer Mentalität“ ausgegangen. In der automotiven Realität treffen aber verschiedene Entwicklungsprozesse aufeinander und neue Wege der Zusammenarbeit und Integration sind notwendig.
Klassische Entwicklungsprozesse
Der „klassische Entwicklungsprozess“ geht davon aus, dass Fachleute Anforderungen präzise und konsistent beschreiben. Jede Leistungsstufe wird durch eine Teststufe überprüft, die sicherstellt, dass alles vollumfänglich implementiert wurde. Ergebnis dieses
strikt prozeduralen Vorgehens ist ein funktionierendes Gesamtsystem, das deployed werden kann. Im V-Modell werden zusätzliche funktionale Änderungen auf die nächste Version verschoben und sind nur mit sehr hohem Aufwand (Rückrufe, Softwareupdates etc.) möglich. Der Erfolg hängt maßgeblich von der Qualität der ursprünglichen Konzepte ab.
Agile Entwicklungsprozesse
Agile Entwicklungsprozesse gehen davon aus, dass es vorteilhaft ist, regelmäßig die Umsetzung gegen die Anforderungen zu prüfen möglichst mit produktiver Software. Daraus ergibt sich ein iteratives Vorgehen, das in regelmäßigen Abständen einen Softwarestand ins Zielsystem deployed. Prominentester Vertreter der agilen Entwicklungsprozesse ist SCRUM, das absichtlich mit einigen klassischen Denk- und Vorgehensweisen des Projektgeschäfts bricht. Agile Vorgehen erzielen nachweislich häufiger erfolgreiche Projekte, die Zeit- und Budgetziele einhalten. [1]
INFRASTRUKTUR EINER CAR2X-SYSTEMLANDSCHAFT [2]
Eine moderne Telematik-Landschaft führender Premiumanbieter besteht aus vielen Komponenten:
- Fahrzeuge mit unterschiedlichen Hard- und Softwareständen, u.a. aus verschiedenen Connected Services-Generationen
- Netzwerkverwaltung (Zugang zum Mobilfunknetz, Roaming etc.)
- Hersteller-Backbone (z.T. mit eigenen Diensten, teilweise als Proxy)
- Drittsysteme (Zahlungsdienstleister, Online-Plattformen und -Services)
In naher Zukunft wird der „Car to X“- Begriff auch im Feld zur Realität und die beteiligten Kommunikationspartner werden ergänzt um:
- andere Fahrzeuge
- Verkehrsleitsysteme
- Drittanbieter (Tankstellen, Werkstätten etc.)
Die verschiedenen Systeme folgen unterschiedlichen Entwicklungsprozessen und -geschwindigkeiten. Das Auto selbst ist Teil einer Modellreihe und kann eine fest verbaute SIM-Karte haben, wodurch die dazugehörige Schnittstelle nicht verändert werden kann. Andererseits nehmen Drittanbieter wie große Social-Media-Plattformen keinerlei Rücksicht auf derart veraltete Zugriffsmethoden und wollen die Freiheit besitzen, die von ihnen angebotenen Services regelmäßig zu ändern und veraltete Schnittstellen zeitnah abzuschalten, um eine bessere Wartbarkeit ihrer Software zu gewährleisten.
Unterschiedliche Entwicklungsgeschwindigkeiten
Damit ergibt sich das entscheidende Problem in der Weiterentwicklung der komplexen C2X-Landschaften: die beteiligten Komponenten unterliegen sehr unterschiedlichen Entwicklungsprozessen. Ein zehn Jahre altes Automodell möchte aktuelle Kraftstoffpreise für die Tankstellen der Umgebung abrufen, welche dem Automobilhersteller von einem externen Datendienstleister zur Verfügung gestellt werden. Der Automobilhersteller kümmert sich inzwischen um eine Vielzahl verschiedener Schnittstellen, die jeweils den Wartungs- und Weiterentwicklungsaufwand exponentiell erhöhen, auch weil Interferenzen getestet werden müssen. Der Datendienstleister drängt darauf, alte Methoden zu blockieren, um sich handlungsfähig für den sich schnell entwickelnden Mobilitätsmarkt zu machen. Auch in der Entwicklung treten diese Timing-Probleme auf. Während das HMI (Human Machine Interface) bereits in einer frühen Phase der Fahrzeugentwicklung fest definiert sein muss, werden die Backbone-Dienste parallel höchst agil entwickelt. Stellen
die Entwickler nun fest, dass im Fahrzeug, aufgrund (agil) geänderter Anforderungen, weitere Daten abzufragen sind oder eine andere Verschlüsselung verwendet werden muss, so ist das im Normalfall nicht möglich. Der Aufwand und die Kosten (weitere
Testläufe, Zertifizierungen etc.) übersteigen jeglichen Nutzen der Online Dienste für den Endkunden. Ergebnis sind stark verlängerte Entwicklungslaufzeiten der Telematik Dienste oder funktionale Einschränkungen und ein damit verbundener Imageverlust.
Lösungsansätze
Der erste und wichtigste Schritt: alle beteiligten Parteien müssen sich der Problematik bewusst sein. Insbesondere das Verständnis, dass die große Herausforderung in der Ausgangssituation liegt, um dadurch Enttäuschungen der Beteiligten zu vermeiden. Die Handlungsfähigkeit des Teams sollte nicht durch zu harsche Kritik an der Performance des beteiligten Personals gefährdet werden. Vergleiche mit rein server- oder cloudbasierter Softwareentwicklung, wie z.B. bei Amazon oder Google, sollen vermieden werden. Weiterhin ist ein sehr erfahrenes Managementpersonal nötig, um alle beschlossenen Maßnahmen konsequent durchführen zu können und die Zusammenarbeitsmodelle, so komplex sie auch sein mögen, nachhaltig zu leben. Im Folgenden werden Werkzeuge vorgestellt, die die Zusammenarbeit in hybriden Systemen in den Punkten Agilitätslevel, Prozesse, Reporting und Kommunikation erleichtern können.
Agilitätslevel für Systeme
Für jedes beteiligte System wird ein Steckbrief definiert, der wichtige Charakteristika hinsichtlich der Agilität enthält. Dazu zählen Deploymenthäufigkeit, Anforderungsaktualität, Meetingstruktur, etc. Aus diesen Werten werden Agilitätslevel errechnet, mit deren Hilfe sich die Landschaft in agile und weniger agile Teilsysteme aufteilen lässt. Sie bieten die Möglichkeit, Anforderungen der weniger agilen Systeme höher zu priorisieren und so
stabiler zu halten. Auf Basis dieser unterschiedlichen Systemarchitekturen achtet ein erfahrener Projektmanager u.a. auf folgende Risikosituationen:
- Schnittstellen zwischen Systemen mit sehr unterschiedlicher Agilität
- Unzureichende Testumgebungen für Systeme mit hoher Agilität
- Ungenaue Anforderungen bei Systemen mit niedriger Agilität
Die Liste lässt sich je nach konkretem Anwendungsfall noch erweitern, bietet aber grundsätzlich Werkzeuge, um Risiken und Deadlocks präventiv zu erkennen und zu vermeiden.
AGILITÄTSLEVEL FÜR ERGEBNISSE
Analog der Systeme werden die Ergebnisse der Entwicklung mit einem Agilitätslevel versehen, der bestimmt, wie sehr die Artefakte (Code, Oberflächen, etc.) von der ursprünglichen Planung abweichen dürfen. Dabei werden alle Aspekte beleuchtet, bei einer Webanwendung etwa die Oberfläche, Performance, etc. In Verbindung mit dem System-Agilitätslevel stellen sich einige Fragen, wie:
- Muss ein Ergebnis in einem hochagilen System fix sein?
- Werden Schnittstellen-Logiken auf beiden Seiten des Interfaces mit dem gleichen Level bewertet?
- Berücksichtigt der Projektplan eventuelle Nachtests bei hochagilen Ergebnissen?
PROZESSMISCHUNGEN
Zu Beginn des Gesamtprojekts ist es wichtig, sich über den Ausgangszustand (inkl. Agilitätslevel), Zeithorizont und zu erwartende Ergebnisse klar zu werden. Damit lässt sich ein passender Mischprozess erarbeiten, der aus klassischen und agilen Komponenten besteht. Benötigt eine bestimmte Projektphase ein fixes Artefakt (z.B. eine Schnittstelle zum HMI), so ist dies im Projektplan vorzusehen. Die Agilität der Umsetzung beschränkt sich darauf, wann das Artefakt vor dem Abgabetermin erstellt wird (z.B. drei Wochen vorher oder „Just in time“). Wichtigstes Ergebnis der Mischplanung ist ein übergreifender Projektplan, der Termine für alle Teilprojekte, Sprints und Deployments festlegt und
ausreichende Testzeiträume einplant. Ebenso enthält der Projektplan Synchronisationspunkte zwischen den unterschiedlichen Systemen. Für jede Phase werden zusätzlich Eingangskriterien festgelegt, um eventuelle Blocker rechtzeitig erkennen zu können.
REPORTING UND KOMMUNIKATION
Ein aussagekräftiges Reporting hilft den Beteiligten tagesaktuell zu sehen, wo das Gesamtprojekt steht und welche Herausforderungen zu meistern sind. Es wird offen über Team- und Abteilungsgrenzen hinweg der reale Status kommuniziert, in dem festen Vertrauen, dass Impediments als Aufgabe des Gesamtprojekts verstanden werden. Wichtig ist aber auf die Art der Kommunikation zu achten. Zulieferer der Hard- und Software arbeiten in verschiedenen Ländern, sodass Kenntnisse der anderen Mentalität, ein respektvoller Umgang miteinander und eine gemeinsame Sprache, sowohl fremdsprachlicher als auch fachlicher Natur, essentiell für den Projekterfolg sind.
FAZIT
Die beschriebenen Ansätze helfen die agile Softwareentwicklung von Connected Cars in einem hybriden Umfeld in ihrer Komplexität zu verstehen und erfolgreich zu steuern. Komplexität in der Projektplanung und -steuerung zu berücksichtigen ist Kernbotschaft
dieses Artikels. Dass dabei Aspekte klassischer Projektplanung zum Zuge kommen, ist kein Zufall. Nicht zu unterschätzen ist, dass kulturelle Unterschiede, Remote-Teams und sprachliche Barrieren es erschweren, diese Komplexität teamübergreifend zu bewältigen. Somit ist die Beherrschung der Komplexität und eine fokussierte Kommunikation inkl. Vermeidung von Kommunikationshürden der richtige Ansatz.
[1] Bitkom-Research: „Scrum-König unter den agilen Methoden“ (21.09.2018). https://www.bitkom-research.de/de/pressemitteilung/scrum-koenig-unter-den-agilen-methoden
[2] Urbach, Jörg Peter: „Car2X: Wenn Autos mit der Umwelt kommunizieren“ (10.08.2018). https://www.adac.de/rund-ums-fahrzeug/autonomes-fahren/technik-vernetzung/car2x-kommunikation
