Agile Softwareentwicklung
Erfahrungen aus Sicht des IT-Dienstleisters DMC. Ein Projektbericht

Ausgangssituation

Die Gruppenfreistellungsverordnung (GVO) EG 1400/2002 soll in der Automobilbranche für mehr Wettbewerb im KFZ-Service und im Reparaturbereich sorgen, ihre Vorschriften Wettbewerbsnachteile freier Werkstätten mildern. Automobilhersteller sind in diesem Rahmen verpflichtet, technische Serviceunterlagen in einer nicht diskriminierenden und wirtschaftlich vertretbaren Form für Berechtigte Dritte (BD) bereitzustellen. In Nordamerika mussten diesen bisher, neben technischen Informationen, die Durchführung der Fahrzeugdiagnose und Fahrzeugprogrammierung angeboten werden. In der EU war letztere nicht erforderlich, was sich nun wegen einer entsprechenden Selbstverpflichtung der Fahrzeughersteller ändert. Angesichts dieser Rahmenbedingungen mussten die Automobilhersteller die webbasierten Softwaresysteme ausweiten, mit denen sie die bis dato notwendigen Serviceinformationen für die Berechtigten Dritten bereitgestellt hatten.

Lösungsansatz

Laut Vorgabe des Gesetzgebers müssen alle Werkstattanwendungen zur Fahrzeugdiagnose, Fahrzeugprogrammierung usf. ein halbes Jahr nach der Verfügbarkeit in den Vertragswerkstätten auch von den Berechtigten Dritten, also den freien Werkstätten in Europa, aber auch von Anbietern von Inspektions- und Testdienstleistungen, Behörden, Bildungseinrichtungen oder Verbänden, genutzt werden können, und zwar auf handelsüblichen PCs anstelle der herkömmlichen herstellerspezifischen IT-Ausstattung. Dies leistet der Auftraggeber mit einem IT-Service-System, das sämtliche Softwaresysteme an die individuelle Hardware und Architektur bei den BD und für deren webbasierten Zugriff anpasst. Beispielsweise kann am Standard-PC eines BD nur ein Fahrzeug behandelt werden, weder eine Geräteverwaltung noch die Unterstützung eines Werkstattverbunds der Geräte sind erforderlich. Wesentliche Managementaufgaben in der Vertragshändler-Werkstatt sind für Berechtigte Dritte vom IT-Service-System zu übernehmen (User-, Identity- und Session-Management).

• Die eigentliche Herausforderung des Projekts lag zum einen in der sehr heterogenen Technologie und Architektur der Anwendungslandschaft, die in den Werkstätten der Vertragshändler im Einsatz ist.
• Diese hatte zum anderen noch keinen ausreichend gesicherten Entwicklungsstand erreicht, zumal laufend Funktionen nachgeschoben werden.
• Schließlich bereitet auch der Server, auf dem die Anwendungen liegen, Probleme.
• Zu diesen Erkenntnissen der Ist-Analyse kommt noch der hohe Termindruck hinzu, Änderungen an den Werkstattanwendungen innerhalb von sechs Monaten im IT-Service-System für BD für den Echtbetrieb umzusetzen.

Herausforderung

Angesichts dieser Rahmenbedingungen mit ihren zahlreichen Unwägbarkeiten können, das war allen Beteiligten schnell klar, unmöglich alle Vorgaben der offiziellen Projektvorgehensweise des Automobilherstellers erfüllt werden. Es wurde ein Weg gesucht, der die unverzichtbare Offenheit für Änderungen und eine extrem hohe Flexibilität als notwendige Voraussetzung für ein erfolgreiches Projekt garantieren würde.
Der Projektverantwortliche beim Auftraggeber setzte auf die Devise Form Follows Function (FFF): Die Vorgaben der offiziellen Projektvorgehensweise werden eingehalten, soweit dies möglich ist. In der Praxis setzte das Projektteam auf das so genannte Agile Vorgehen.

„Wir mussten letztlich agil vorgehen, um mit dem IT-Service-System für BD beständig auf Entwicklungen und Änderungen im Bereich der Werkstattanwendungen reagieren zu können“, erläutert Gerhard Pfaffinger, Projektleiter auf DMC-Seite.

Solch ein Agiles Vorgehen in der Softwareentwicklung stellt gerade das Ziel einer funktionierenden Software für den Kunden und die erfolgreiche Integration wechselnder Anforderungen an diese in den Mittelpunkt, will dafür den gesamten Prozess verschlanken und lässt detaillierte Planung, vollständige Spezifikation, umfassende Dokumentation oder ausgereifte Architektur gegenüber der zielorientierten Kommunikation und einem dynamischen, flexiblen Prozess in den Hintergrund treten.

DMC-Aufgaben

Die DMC-Experten Gerhard Pfaffinger und Robert Hanka haben das Konzept für die Umsetzung der gesetzlichen Vorgaben für die nicht diskriminierende Bereitstellung der technischen Serviceunterlagen sowie der Anwendungen für die Fahrzeugdiagnose und die -programmierung bei den Berechtigten Dritten entwickelt. Sie haben die Schnittstellenvereinbarungen zu den Anpassungen der Werkstättenanwendungen für das IT-Service-System für BD verhandelt und geschlossen sowie das Grobkonzept für den Server dafür erstellt, den ein Entwicklungspartner realisierte. Schließlich übernahmen sie Integrations-, Test- und Qualitätssicherungsaufgaben.
DMC-Experte Dr. Dieter Maas entwickelte das Betriebskonzept und organisierte in enger Zusammenarbeit mit dem Auftraggeber den gesamten Rollout. Dazu gehörten vor allem die Bereitstellung und Konfiguration aller vom Gesamtsystem benutzten Hardware- und Softwarekomponenten sowie die Beschreibung und Verteilung von Betriebs-, Administrations- und Supportaufgaben für den Regelbetrieb.

Agiles Vorgehen

Bereits das Projektteam wurde in diesem Projekt vom Projektleiter bewusst unter dem Aspekt der effizienten Kommunikation zusammengestellt, denn gemäß den Agilen Werten sind Individuen und Interaktionen wichtiger als Prozesse und Tools.
Sehr erfolgreich wurden für die Kommunikation innerhalb des Projektteams wie gegenüber den Entwicklern auf Seiten der Werkstattanwendungen grafisch dargestellte Szenarien verwendet. Grundlage waren Anwendungsfälle, die für alle Rollen entwickelt wurden, also für den BD ebenso wie für die Systembetreiber des IT-Service-Systems für BD. Die Szenarien wurden nach jeder Anforderungsänderung akribisch aktualisiert.

Nach Erfahrung von Pfaffinger ist solch ein starkes Kommunikationsmedium unverzichtbar. Speziell ein visuelles Medium erleichtert allen Beteiligten die Transparenz über die Fülle von Detailinformationen und ein gemeinsames Verständnis ungemein, ebenso die Entscheidungsfindung.

Auf diese Weise wurde auch die Gefahr entschärft, Reviews zu überfrachten. Denn werden im Rahmen eines Reviews sehr umfangreiche Dokumente von einer Vielzahl von Personen (im beschriebenen Projekt bis zu 20) gelesen und begutachtet, entsteht immer wieder eine Situation, in der unterschiedlichste Einwendungen erhoben werden. Am Ende stehen Kompromisse, die wochenlange Nacharbeiten an den Dokumenten nach sich ziehen ohne wirkliche substanzielle Verbesserungen.

Erfolgreich mit Szenarien begleitet wurde bereits der Lösungsfindungsprozess am Anfang des Projekts, nachdem die Ist-Analyse sechs Umsetzungsalternativen ergeben hatte. Zur Lösungsfindung wurden sukzessive k.o.-Kriterien gesucht und formuliert, um immer wieder eine Alternative auszuschließen und die Vielfalt möglicher Lösungsansätze einzugrenzen. Gleichzeitig wurden die Lösungen mit der größeren Flexibilität gegenüber künftigen Änderungen und nur sie, näher auf ihre Realisierbarkeit untersucht.
Weckte eine angedeutete, aber nicht ausformulierte Lösung das Interesse des Teams, wurde sie im Team ausführlicher diskutiert und anschließend ggf. von einem Kollegen weiter ausgearbeitet. Auf diese Weise wurde in keinem Fall eine „akademische“ Lösung überflüssigerweise konkretisiert.
Das entspricht der Agilen Vorgehensweise, die Entwurfsphase zu reduzieren und möglichst früh zu ausführbarer Software zu kommen, bzw. einer durchgängigen Priorisierung der Projektschritte nach der Maxime „Konzentration auf das, was als nächstes benötigt wird“.

Pragmatismus

Durchgängig wurde gemäß Agilem Manifest der Formalismus dem Pragmatismus untergeordnet – es sei denn, er versprach praktischen Nutzen. Der Fall war dies während des gesamten Projekts bei den Schnittstellenverträgen (Übersicht und Spezifikation), die – zu Recht – allesamt formal ausgearbeitet und unterzeichnet wurden. Darin wurde detailliert der Anpassungsbedarf für die Übernahme von Komponenten und Änderungen der Werkstattanwendungen in das IT-Service-System für BD festgehalten.

Bei der Erarbeitung von Schnittstellenkontrakten wie von Szenarien wurde im Übrigen die Agile Methode des analogen Arbeitens auf konzeptueller Ebene erfolgreich umgesetzt. Ein Kollege bearbeitete beispielsweise im Fall der Szenarien die Grafiken, ein anderer schrieb dazu die Texte – und das immer wieder in wechselnden Rollen.

Dieses Vorgehen wurde bewusst durchgehalten, um sich gegenseitig zu korrigieren und auf diese Weise eine höhere Präzision zu erreichen.
Bewährt hat sich in diesem Projekt auch das Agile Prinzip KISS der Einfachheit, beispielsweise bei der Lösungsfindung. Stets wurde die einfachste Lösung gewählt. Aber nicht in jedem Fall konnte sie gegen Widerstand benachbarter Projekte durchgesetzt werden. Im Nachhinein zeigten sich dann allerdings in aller Regel Folgeprobleme bei der Weiterentwicklung, die bei Durchhalten des KISS-Prinzips vermieden worden wären.

Auch gegen Widerstand sollte also möglichst lange an der einfachen Lösung festgehalten und nicht zu schnell ein Kompromiss eingegangen werden, so das Resümee von Pfaffinger und Hanka.

Fazit

Das Projekt wurde im Mai 2009 abgeschlossen, entsprechend der agilen Methode wurde erst auf der Grundlage der funktionierenden Programme eine ausführliche Dokumentation erstellt. Das webbasierte IT-Service-System ging Anfang Mai 2009 in den Freien Werkstätten und bei anderen Berechtigten Dritten produktiv.

• Die wichtigste Herausforderung konnte bewältigt werden: Während des Projektverlaufs reagierte das Team immer wieder erfolgreich und schnell auf Veränderungen bei den Vorgaben. „Das Projektmanagement nach dem agilen Vorgehen hat sich bewährt.“
• Das bestätigte sich auch, als kurz nach Inbetriebnahme des IT-Service-Systems für BD erhebliche Änderungswünsche aufkamen.

Wegen Mängeln bei den integrierten Modulen für Fahrzeugdiagnose und Fahrzeugprogrammierung war für deren Betrieb ein erhöhtes Maß an Absicherung zu realisieren. Zudem hatte das System für die Vertragshändler erhebliche Mängel. Deshalb wurde das IT-Service-System in die Lage versetzt, als Fallback-System für die Vertragshändler zu fungieren. Dies erforderte u.a. ein zusätzliches Load Balancing und ein dynamischeres Server-Management im Server.

All dieser Änderungsbedarf konnte schnell überprüft und problemlos bereitgestellt werden. Das Team war „agil“ eingespielt, die eingeübten kurzen Kommunikationswege zahlten sich nun besonders aus. Beim Teilprojekt Server IT-Service-System bewährte sich zudem das realisierte Agile Prinzip des gemeinsamen Code-Besitzes, was zur hohen Flexibilität bei Änderungen beiträgt.

Gerhard Pfaffinger zieht nach Abschluss des Projekts das Fazit: „Wir gingen notgedrungen agil vor. Im Ergebnis hat sich das zugrunde liegende Agile Manifest als sehr praxistauglich und tragfähig erwiesen.“

In einigen Fällen ließ sich die Agile Vorgehensweise nicht durchhalten. Beispielsweise konnte die gewünschte Lösung nach dem agilen KISS-Prinzip – eine einheitliche Implementierungsweise für die Module für Fahrzeugdiagnose und -programmierung bei den Berechtigten Dritten – nicht durchgesetzt werden mit entsprechenden Unannehmlichkeiten für die Freien Werkstätten.
„Hier hätte uns sehr geholfen, wenn die Agile Vorgehensweise beim Auftraggeber offiziell anerkannt wäre.

In Projekten wie dem beschriebenen mit den zahlreichen Unwägbarkeiten und höchsten Anforderungen an flexibles Reagieren auf Änderungswünsche und Bedarfsanpassungen überzeugt die Agile Vorgehensweise.“