Ergebnisse der Interviews Leitfaden Fehlermanagement

Um einen agilen Fehlermanagementprozess für digitale Produkte zu entwerfen und die aktuellen Strukturen, Entwicklungen, Prozesse und Probleme zu verstehen, wurden im Rahmen dieser Arbeit drei anonyme qualitative Interviews (s. Anhang 14) mit Industrievertretern durchgeführt. Es konnten zwei Experten aus Qualitätssicherungs-abteilungen digitaler Produkte von zwei deutschen Automobilherstellern sowie ein Experte aus einem deutschen Telekommunikationsunternehmen befragt werden. Ziel der Experteninterviews war es, einen praktischen Bezug zur Problematik Fehler-management in agilen Umgebungen herzustellen. Dabei lag der Fokus darauf herauszufinden, welche Rolle agile Methoden und Softwaretests bei der Entwicklung von digitalen Produkten spielen, wie der Fehlermanagementprozess derzeit abläuft und vor welchen Problemen die Unternehmen bei der Behebung von Fehlern stehen. Außerdem sollte die Rolle von Lieferanten während der Entwicklung und des anschließenden Betriebes thematisiert werden. Da keine Verschwiegenheitserklärung unterschrieben wurde sowie die Befragung telefonisch erfolgte, muss an dieser Stelle darauf hingewiesen werden, dass die Interviews auf Wunsch der Interviewpartner weder aufgenommen wurden noch anonym veröffentlicht werden.

Im Anhang 14 befindet sich eine Liste von Beispielfragen, die in Vorbereitung auf das Interview erstellt und den Interviewpartnern vor den Interviews zugesandt wurden. Die Fragen sind als Leitfaden zu verstehen und wurden im Laufe des Gesprächs angepasst.

Im Folgenden werden die Kernaussagen aus den Interviews dargelegt. Dabei ist natürlich zu beachten, dass Antworten von Experten aus zwei deutschen OEMs nur einen kleinen Ausschnitt darstellen und nicht im wissenschaftlichen Sinne verallgemeinerbar sind. Inhaltlich lassen sich die Ergebnisse wie folgt zusammenfassen:

1) Ein Großteil der Entwicklung von digitalen Anwendungen findet gemeinsam mit externen Lieferanten bzw. mit eng angebundenen Tochterunternehmen statt, die nahezu komplett in die Unternehmensstruktur integriert sind. Schwierigkeiten in Bezug auf Kommunikation und/oder Abstimmungsprobleme während der Entwicklung bzw. des Betriebes, wie sie in der Regel mit externen Partnern auftreten, spielen eher keine Rolle.

2) JIRA, das Fehlermanagementtool für agile Projekte, war allen Interviewpartnern vertraut. (JIRA ist eine Webanwendung zur Fehlerverwaltung, Problembehandlung und operativem Projektmanagement, die von Atlassian entwickelt wurde.)

3) Agile Entwicklungsmethoden werden vor allem im Bereich der Frontendentwicklung angewendet, wobei keine Trennung von Entwicklung und Betrieb mehr erfolgt.

4) Je komplexer die Anwendungen bzw. digitalen Produkte sind und je mehr Backendsysteme miteinander kommunizieren, desto schwieriger sind agile Methoden im Bereich der Entwicklung und Fehlerbehebung anzuwenden.

5) Softwaretests sind eine zentrale Säule der Qualitätssicherung in der Entwicklungsphase, finden jedoch zu selten auf Gesamtsystemebene, sondern oft nur recht isoliert und produktspezifisch in den Abteilungen statt.

6) Die zentrale und wichtigste Aussage, die allen Interviews zu entnehmen war, ist,

dass die große Herausforderung darin besteht, eine Fehlerallokation und -zuordnung auf die Backendsysteme bzw. Schnittstellen zu erreichen, um

eindeutige Verantwortlichkeiten bzw. Zuständigkeiten zuweisen zu können.

Die Ergebnisse der Interviews wurden beim Entwurf des Fehlermanagementprozesses berücksichtigt. Sie haben gezeigt, dass in den betroffenen deutschen Autofirmen ein beträchtlicher Teil der Softwareentwicklung digitaler Anwendungen in agilen Umfeldern und unter Einsatz moderner agiler Methoden erfolgt. Dabei verwenden die Teams unterschiedliche Test- und Dokumentationssoftware und arbeiten im Sinne agiler Vorgehensmodelle in kleinen, unabhängigen und eigenverantwortlichen Teams. Bei digitalen Anwendungen, die auf wenige Backendsysteme zurückgreifen und damit relativ unabhängig von der Gesamtsysteminfrastruktur sind, funktioniert dieser Ansatz, auch mit Blick auf einen effektiven Fehlermanagementprozess, sehr gut. Das trifft auf Apps zu, die keine oder kaum Auswirkungen auf die Hardware im Fahrzeug haben und als reine Smartphoneanwendung funktionieren. In der Regel sind solche digitalen Produkte dem Marketing zugeordnet. Die Teams, die für diese Art von Anwendungen verantwortlich sind, können ihre eigene Infrastruktur aufbauen, müssen nicht auf historisch gewachsene IT-Architekturen und -Verantwortlichkeiten Rücksicht nehmen und Schnittstellen zu anderen Systemen und Backend-Bereichen nicht oder nur wenig beachten. Tritt ein Fehler auf, kann die Ursache in der Regel schnell gefunden und behoben werden. Sobald Apps bzw. digitale Anwendungen jedoch mit dem Fahrzeug und mit Server- und/oder Cloudsystemen interagieren („Embedded Apps“), findet eine Vielzahl von Kommunikationsprozessen zwischen den Backendsystemen statt. Der Kunde sieht die Anwendung im Frontend, alle Prozesse, die im Hintergrund ablaufen, werden als Backend bezeichnet. Diese Backendsysteme werden von unterschiedlichen Teams betreut und sind oft historisch gewachsen (Stichwort: Legacy System). Es sind demnach bei Entwicklung und Betrieb von „Embedded Apps“ viele Schnittstellen, Umgebungen und komplexe Systeme zu beachten.

In allen Experteninterviews wurde bemängelt, dass auftretende Fehler aufgrund der komplexen IT-Gesamtinfrastruktur während des Betriebes nicht bzw. nur unter großem Aufwand einzelnen Systemen, Komponenten und damit auch Zuständigkeiten zugeordnet werden können. Ohne eine entsprechende Fehlerallokation bzw. -zuordnung

ist eine Fehlerbehebung jedoch nicht möglich. Der Schlüssel für eine schnelle Fehlerzuordnung während des Betriebes liegt in der Entwicklungsphase, speziell im Bereich der automatisierten Softwaretests. Bei agilen Entwicklungsmethoden ist die Abstimmung und Gesamtorchestrierung der Softwaresysteme, Teams und Organisationsbereiche besonders wichtig. Dabei muss eine gute Kommunikation, crossfunktionale Zusammenarbeit und eine abgestimmte Herangehensweise gewährleistet sein, um schnittstellen- und bereichsübergreifende Prozesse und Kommunikation zu ermöglichen. DevOps liefert hier einige hilfreiche Ansätze, wobei die Verschmelzung von Entwicklung und Betrieb eine wichtige Voraussetzung ist. Sind die Entwickler selbst für die Überwachung und den Betrieb ihrer Systeme verantwortlich, führt dies von vornherein dazu, dass während der Entwicklung bzw. dem Schreiben von Code Methoden und Tools in Codeform implementiert werden, die ein Tracken der Performance und eine schnelle Fehlerallokation ermöglichen.

Wie bereits erwähnt, ist neben einer guten Gesamtorganisation der einzelnen agilen Entwicklerteams der Bereich der Softwaretests von zentraler Bedeutung. Jede Softwareanwendung, das heißt auch digitale Dienste und Apps, müssen getestet werden.

In den klassischen Vorgehensmodellen, wie Wasserfall- oder V-Modell, finden Tests meist nicht automatisiert und zu einem späten Zeitpunkt im Entwicklungsprozess statt.

Agile Entwicklungsmethoden ermöglichen das Testen parallel zur Entwicklung. Dabei handelt es sich jedoch häufig um Tests auf Modul- bzw. Codeebene, die den Entwicklern ein schnelles Feedback geben. Im Gesamtsystem werden Anwendungen jedoch auch in agilen Projekten erst spät implementiert und getestet. Hier treten oftmals Fehler auf, die schwer zu beheben sind, da eine Vielzahl komplexer Abhängigkeiten zwischen den einzelnen Servern und Backendsystemen besteht. Daher muss eine Möglichkeit geschaffen werden, einzelne Anwendungen und Funktionen früher im Gesamtsystem zu testen und auftretende Fehler so zu dokumentieren, dass sie später eine Grundlage bilden, um im Betrieb schnell Fehlerursachen ermitteln zu können. Das Zusammenführen von Entwicklung und Betrieb, IaC und ein höchstmöglicher Grad an automatisiert ablaufenden Prozessen können die Testautomation so weiterentwickeln, dass kleine Entwicklerteams am Ende ihrer Sprints die Inkremente im Gesamtsystem testen können. Hier steht nicht die Fehleranalyse des Codes an sich im Mittelpunkt, diese findet täglich statt, sondern die Anbindung an andere Backends.

Wenn die Anwendungen in einem virtualisierten Gesamtsystem getestet werden, sollten Fehlerbilder, -ursachen und -behebungsmaßnahmen gesammelt und verknüpft werden können. Diese Verknüpfung, eventuell allein das Aufzeigen von Backendsystemen, die bei einem Prozess wie „Tür-öffnen-per-Smartphone“ beteiligt sind, kann einen Mehrwert darstellen und später die Fehlerbehebung während des Betriebes erleichtern. Die Bedeutung einer entsprechenden Dokumentation nimmt in solchen komplexen Umgebungen aber nicht ab. Um dabei nicht in alte nicht-agile Methodiken zu verfallen und einen Großteil der Arbeitszeit an die Dokumentation zu verlieren, sollte die Fehlerdokumentation weitgehend automatisiert erfolgen, indem Logfiles, Fehlerbilder und Fehlerhistorie eines Prozesses zusammengefügt werden.