Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014.

Transkript

1 Christian Kühnel, BMW Group AGILE ENTWICKLUNG VON FAHRERASSISTENZSOFTWARE. AGILE CARS 2014.

2 PROJEKT ÜBERBLICK Entwicklung von Fahrerassistenz-Software zur Vorverarbeitung und Fusion von Sensordaten aus mehreren Kamera-, Ultraschall- und Radarsensoren. Teamgröße: 25 interne Mitarbeiter Programmiersprache: C/C++ Integration auf zwei verschiedene AUTOSAR Steuergeräte. Projektstart 2012, Serieneinsatz 2015 Jira & Greenhopper als Tool für die Aufgabenplanung Page 2

3 MOTIVATION FÜR DIE SCRUM EINFÜHRUNG. Bisher eigenes Vorgehensmodel mit agilen Anteilen. Schwierigkeiten: Getrennte Rollen für Funktions- und SW-Entwickler. Details zu den Aufgaben nicht im Ticket dokumentiert. Abhängigkeiten zwischen Tickets nicht dokumentiert. Relative Prioritäten der einzelnen Tickets nicht klar, alles ist wichtig. Bei einer Sprintlänge von 6 Wochen: viele Änderungen während des Sprints. Zuordnung von Sprints zu Releases schwierig. Planung für 20 Personen und 6 Wochen nicht überschaubar. Page 3

4 TRANSITIONSSTRATEGIE. Bei der Einführung von Scrum helfen übliche Methoden aus dem Change Management: Zeigen, dass Scrum ein bestimmtes akutes Problem lösen kann. Am Anfang erst Änderungen im eigenen Verantwortungsbereich. Pragmatische Lösungen für scheinbar unlösbare Probleme finden. Nicht dogmatisch Scrum folgen. Probleme identifizieren und lösen oder auf später vertagen. Inkrementellen Verbesserungsprozess auch bei der Einführung nutzen. Ideen mit den Kollegen diskutieren, deren Wissen nutzen. Hindernisse und Bedenken aktiv identifizieren und beseitigen. Page 4

5 AGILES SETUP. Start mit Plain Vanilla Scrum, Änderungen nur wo unbedingt erforderlich. 4 Feature Teams mit 5-9 Entwicklern. 4 Product Owner, ein Chief Product Owner. 4 Scrum Master. 2 Wochen Sprints. Entwicklungsreleases mit jedem Sprint. Serien-Releases nach 3-8 Sprints. Keine Trennung der Rollen Funktions- und SW-Entwickler. Page 5

6 ERFOLGSFAKTOREN FÜR DIE SCRUM EINFÜHRUNG. Entwickler überzeugen. Grünes Licht vom Management holen. Rahmenbedingungen schaffen, die ein agiles Arbeiten ermöglichen: Gezielte Entkopplung des eigenen Projekts von wasserfallartigen Prozesspartnern. Know-How Aufbau im Team. Continuous Integration. Plattform für schnelle Validierung der Sprintergebnisse. Product Owner dürfen entscheiden. Erfahrene Mitarbeiter als Scrum Master. Es muss beim ersten Versuch nicht perfekt sein, aber wir müssen daraus lernen. Erfahrungsaustausch mit anderen agilen Projekten im Unternehmen. Page 6

7 NICHT-AGILE PROZESSPARTNER Wir haben zwei wesentliche Kategorien von Schnittstellenpartner, die nicht agil arbeiten: Architekturänderungen. SW-Integration beim Lieferanten. Architekturprozess Antrag Abstimmung Umsetzung Sprints Integrationsprozesse Festschreibung Architektur Integrationsrahmen Softwareabgabe Integration Page 7

8 SW-INTEGRATION BEIM LIEFERANTEN. Architekturprozess Antrag Abstimmung Umsetzung Rahmenbedingungen: Vordefinierte Integrationsstufen. Sprints Integrationsprozesse Festschreibung Architektur Abstand zwischen den Integrationsstufen: 2-6 Monate Integrationsrahmen Integration Softwareabgabe SW-Lieferungen werden nur zu diesen Integrationsstufen integriert. Architekturänderungen nur 1x pro Integrationsstufe mit ca. 12 Wochen Vorlauf möglich. Integrationsplattform ist bei BMW verfügbar. Erstellung und Validierung von eigenen Entwicklungsständen möglich. Umstieg auf agiles Vorgehen in laufenden Projekten auf Grund von Widerständen beim Lieferanten meist nicht umsetzbar. Dies muss in zukünftigen Projekten vertraglich vereinbart werden. Page 8

9 ARCHITEKTURÄNDERUNGEN. Rahmenbedingungen: Architekturänderungen innerhalb einer AUTOSAR SW Component sind mit jeder SW-Änderung möglich. Architekturänderungen im Steuergerät und 1x pro Integrationsstufe möglich, Vorlaufzeit mehrere Wochen. Architekturänderungen zwischen Steuergeräten 2x im Jahr möglich, Vorlaufzeit mehrere Monate. Steuergerät SWC SWC SWC RTE Basis-SW Page 9

10 UMGANG MIT NICHT-AGILEN SCHNITTSTELLENPARTNERN. Auswahl eines Sprints pro Integrationsstufe in dem alle Architekturänderungen umgesetzt werden. Architekturänderungen im AUTOSAR XML und im Code gleichzeitig: Entwickler soll sich nur einmal mit der Änderung beschäftigen. Konsistenz zwischen AUTOSAR XML und Code sicherstellen Änderungen zwischen Steuergeräten: Beantragung gemäß vorgegebener Vorlaufzeit. Umsetzung im AUTOSAR XML und im Code erst mit den jeweiligen Integrationsstufen. Parallel: Diskussionen um den Architektur- und Integrationsprozess agiler zu gestalten (Intern und mit Lieferanten). Page 10

11 UMGANG MIT AUTOSAR. Entkopplung von Architektur und Integration über die Generierung einer eigenen RTE: Laufend auf dem Continuous Integration Server generiert SW jederzeit kompilieren können Für Prototyping und Validierung Sofort Rückmeldung bei Inkonsistenzen zwischen AUTOSAR XML und Code Sicherstellen, dass alle Informationen für die RTE-Generierung im AUTOSAR XML vorhanden sind. Know-How im Team um mit dem Lieferanten technische und organisatorische Themen diskutieren zu können A? = C Page 11

12 FAZIT NACH DEM UMSTIEG. Wo ein Wille da auch ein Weg. Man muss ihn nur finden. Projekt deutlich besser steuerbar über (Chief-) Product Owner. Zuverlässigkeit der Planung ist deutlich besser geworden. Zusammenarbeit und Austausch im Feature-Team ist intensiver geworden. Abhängigkeiten zwischen den Feature-Teams geringer als anfangs erwartet. Schwierigkeiten treten vor allem an nicht-agilen Schnittstellen auf. Page 12

13 NÄCHSTE SCHRITTE. Innerhalb unseres Projekts: Verbesserung der Mittel- und Langfristigen Planung (> 1 Sprint). Umstieg bei der Schätzung von Stunden auf Story Points. Schrittweise Detaillierung und Ausweitung der Definition of Done. Einheitliches Verständnis von SW-Qualität und deren Einhaltung. Außerhalb unseres Projekts: Agile Ideen in den Köpfen unserer Schnittstellenpartner verankern. Know-How Transfer in andere Projekte. Für zukünftige Steuergeräte Projekte: agiles Vorgehen im Vertrag verankern und konsequent einfordern. (Bordnetz-) Architekturprozesse agiler gestalten. Page 13