Scrum für Embedded Systeme

Anbieter zum Thema

Axivion GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Elektrobit Automotive GmbH

Infrastruktur 2 – Embedded Hardware

Eine weitere Herausforderung bei der Erstellung der Infrastruktur wird durch die Frage deutlich, wie wir so schnell wie möglich auf die Zielplattform kommen. Denn „funktionierende Software“ im agilen Manifest muss im Kontext von Embedded Systems eigentlich heißen: „funktionierendes System.“

Embedded Hardware ist etwas spröde in der Handhabung, und das liegt nicht am Material der Platinen. Wer mechatronische Hardware entwickelt, denkt in Vorlaufzeiten für Platinen-Layouts, Lieferzeiten und Verfügbarkeit aktueller Prozessoren.

Ein funktionierendes System muss nicht unbedingt die real existierende Einheit aus Software, Hardware und Mechanik bedeuten. Das funktionierende System kann auch als Simulation aufgebaut sein, mit deren Hilfe sehr frühzeitig der tatsächliche Kundennutzen geprüft wird [16]. Gerade Frameworks wie AUTOSAR helfen dabei, Funktionalitäten im Rahmen einer Simulation zunächst von Hardware getrennt betrachten zu können [17]. Dabei gilt es, Vorsicht vor unüberlegter Modellierung und unbedachter Simulation walten zu lassen. Das Aufsetzen von Simulationen, die keine notwendigen Erkenntnisse bieten, kann viel Aufwand und Zeit verschlingen [18].

Sukzessive werden dann der reinen Simulation in Software Methoden Processor-in-the-Loop (PiL) und Hardware-in-the-Loop (HiL) zugefügt, um konkrete Effekte von Prozessorarchitektur, Steuergerätehardware und mechatronischer Umgebung mit in die automatisierten Tests einzubeziehen. Alle Erfordernisse der DevOps-Infrastruktur gelten auch weiterhin: Nur was automatisiert getestet werden kann, ermöglicht es dem Team, in einem festen Takt einen Stand eines Systems auszuliefern.

Die Architektur des Systems kann dabei ihr übriges tun. Sauber geschnittene Module – sei es als Microservices [19] oder AUTOSAR-Komponenten – erlauben es, diese für sich zu entwickeln, zu testen und auszuliefern.

All diese Frameworks und Verfahrensweisen schränken scheinbar die Freiheit der Teams ein, geben tatsächlich jedoch mehr Freiheit in der Lösung der eigentlichen Aufgabenstellung, vorausgesetzt die Rahmenbedingungen sind bekannt und bleiben relativ stabil.

Manager und Einführung von Scrum

Scrum betrifft nicht nur das oder die Entwicklungsteams. Scrum betrifft die ganze Organisation. Auch wenn nur Teile einer Organisation tatsächlich nach Scrum arbeiten, so sollten doch alle, die mit diesen Teams interagieren, verstehen, was Scrum bedeutet.

Dies gilt auch und vor allem für Führungskräfte. Scrum sieht explizit vor, dass in Sprints gearbeitet wird, also Entwicklungsabschnitten von wenigen Wochen Dauer, an deren Ende jeweils ein lauffähiges System an den Kunden geliefert wird.

Nach jedem abgeschlossenen Sprint werden dann die Anforderungen für den nächsten geplant. Wichtig ist: Während des Sprints bleiben die Anforderungen stabil. Es kommt also kein Manager herein und gibt den Entwicklern plötzlich etwas anderes zu tun. Gibt es während eines Sprints neue Anforderungen, werden diese in der Regel nicht in den laufenden integriert, sondern kommen ins Product Backlog. Häufen sich die Fälle, dass für den aktuellen Sprint geplante Anforderungen plötzlich obsolet werden, ist das ein impliziter Auftrag an Scrum Master und Product Owner, sich Gedanken über bessere Anforderungen und deren Abstimmung mit den Kunden zu machen.

Die vornehmliche Aufgabe des Scrum Masters wird damit, das Team von organisatorischen Interrupts von außen zu schützen. Die Führungsriege einer Organisation sollte diese Bemühungen tunlichst unterstützen, indem sie eben nicht ins laufende Getriebe eingreift, sondern den Sprint-Takt nutzt, um geänderte Situationen und Anforderungen einzuspeisen.

Die Einführung von Scrum allein über Team-Schulungen reicht damit nicht aus. Es bedarf explizit auch der Schulung der Führungskräfte in angrenzenden Organisationseinheiten.

Agil bedeutet, dass wir die gesamte Organisation verändern müssen, hin zu einer Struktur, die das Projektergebnis ermöglicht und auf Wertschöpfung ausgerichtet ist. Das bedeutet nicht, dass jede Abteilung agile Methoden verwenden muss, doch sollten sie verstehen, was ihre Rolle in der agilen Organisation ist [20].

Die Einführung von Scrum hat einen Anfang, aber durch das Wesen der Selbstorganisation kein Ende. Veränderte Rahmenbedingungen und Projektumfelder werden sich in veränderten Umsetzungen von Scrum niederschlagen. Ihr Manager wird sich daran gewöhnen müssen, dass er keinen statischen Entwicklungsprozess unter sich hat, den er einmal aufgezeichnet bekommt und der dann ewig so bleibt.

Zusammenfassung: Scrum für Embedded ist kein Selbstläufer

Agile Vorgehensweisen im Embedded Software Engineering sind kein Selbstläufer. Den Teams durch gute Infrastruktur ermöglichen, regelmäßig aufwandsarm zu liefern, und ihnen Methoden an die Hand geben, die Belange von Embedded Systems zu berücksichtigen, ist eine gute Basis. Wenn dann auch noch die Manager die Teams in Ruhe arbeiten lassen, garantiert das schon fast den Erfolg.

Agile Methoden

Warum eigentlich (immer) Scrum?

Die Autoren:

* Martin Hillbrand ist seit über 10 Jahren in Software Engineering und Prozessoptimierung in verschiedenen Industrien unterwegs, und unterstützt bei Elektrobit Kundenorganisationen in der Einführung agiler Methoden. Er studierte Software Engineering und Informations-Ingenieurwesen und –Management an der FH Oberösterreich. Martin Hillbrand ist zertifizierter Scrum Master, Product Owner und Scrum Professional.

* Dr. Joachim Schlosser führt bei Elektrobit Automotive in München Informatiker und Ingenieure, die Automobilhersteller und Zulieferer zu Agilen Entwicklungsmethoden, Funktionaler Sicherheit und Software Architektur beraten. Nach seiner Promotion in Informatik an der TU München war er unter anderem über 10 Jahre für MathWorks, dem Hersteller von MATLAB & Simulink tätig. Er bloggt auf www.schlosser.info.

Literaturverzeichnis

[1] J. Sutherland and J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, UK: Random House Business Books, 2014.

[2] W. Cunningham and others, "Manifest für Agile Softwareentwicklung," 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

[3] B. Gloger, Scrum: Produkte zuverlässig und schnell entwickeln, 5. Auflage Hrsg., München: Carl Hanser Verlag, 2016.

[4] G. Kim, J. Humble, P. Debois, J. Willis and T. Demmig, Das DevOps-Handbuch, Heidelberg: O'Reilly / dpunkt.verlag GmbH, 2017.

[5] B. Collins-Sussman, B. W. Fitzpatrick and C. M. Pilato, "Version Controll with Subversion," 2017. [Online]. Available: http://svnbook.red-bean.com/index.de.html.

[6] S. Chacon and B. Straub, Pro Git book, US: Apress, 2009.

[7] M. Doar, Practical JIRA Administration, UK: O'Reilly, 2011.

[8] "Jenkins Handbook," [Online]. Available: https://jenkins.io/doc/book/. [Accessed 11 10 2017].

[9] „GoCD: Open Source Continuous Delivery and Automation Server,“ [Online]. Available: https://www.gocd.org/. [Zugriff am 11 10 2017].

[10] „Polyspace. Making Critical Code Safe and Secure,“ MathWorks, [Online]. Available: https://de.mathworks.com/products/polyspace.html. [Zugriff am 11 10 2017].

[11] „Klocwork: Source Code Analysis Tools for Security & Reliability,“ [Online]. Available: https://www.klocwork.com/. [Zugriff am 11 10 2017].

[12] „BullseyeCoverage Code Coverage Analyzer,“ [Online]. Available: http://www.bullseye.com/. [Zugriff am 11 10 2017].

[13] P. Hodgson, „Feature Branching vs. Feature Flags: What’s the Right Tool for the Job?,“ 23 05 2017. [Online]. Available: https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/. [Zugriff am 11 10 2017].

[14] W. Buchwalter, „A Git Workflow for Continuous Delivery,“ 21 06 2016. [Online]. Available: https://blogs.technet.microsoft.com/devops/2016/06/21/a-git-workflow-for-continuous-delivery/. [Zugriff am 11 10 2017].

[15] "Docker - Build, Ship, and Run Any App, Anywhere," [Online]. Available: https://www.docker.com/. [Accessed 11 10 2017].

[16] J. Schlosser, „Frühe Verifikation von Regelungssystemen mit Model-Based Design,“ in Embedded Software Engineering Konress, Sindelfingen, 2011.

[17] J. Schlosser und G. Sandmann, „Keine Angst vor Autosar – Leitfaden und nutzenbetrachtung für Funktionsentwickler,“ ATZelektronik, Bd. 4, Nr. 2, pp. 66-72, 2009.

[18] J. Schlosser, Architektur¬simulation von verteilten Steuer¬geräte¬systemen, Berlin: Logos Verlag, 2006.

[19] T. Schneider, „Achieving Cloud Scalability with Microservices and DevOps in the Connected Car Domain,“ in Software Engineering (Workshops), Wien, 2016.

[20] M. Hillbrand, „Agile Methoden skalieren, aber bitte nicht dogmatisch! Erfolgreich skalieren!,“ OBJEKTspektrum, Nr. 2, 2017.

[21] W. Cunningham, „Manifest für Agile Softwareentwicklung,“ 2001. [Online]. Available: http://agilemanifesto.org/iso/de/manifesto.html.

(ID:45112558)