Agile Entwicklung Scrum für Embedded Systeme

Agile Entwicklung trägt dazu bei, schneller bessere Ergebnisse erzielen zu können. Der Prozess ist allerdings auch strikter, als Sie ihn heute wahrscheinlich leben. Scrum ist strikter gegenüber dem Management und erfordert einen funktionierenden Integrations- und Testprozess – vor allem in Embedded Systemen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Elektrobit Automotive GmbH

Der erste agile Wert lautet „Individuals and interactions over processes and tools“. Eben um im täglichen Arbeiten den Menschen und Interaktionen eine höhere Bedeutung einräumen zu können, ist es so wichtig, dass funktionierende Prozesse und Tools vorhanden sind, die ganz natürlich genutzt werden.

Agil klingt innovativ, ebenso wie Scrum mit seinen User Stories, dem Zusammenarbeiten.

Das agile Prinzip, Änderungen willkommen zu heißen, lässt Kunden und das höhere Management in Entwicklungsorganisationen in freudiger Schnappatmung erzittern. Verheißt dies doch die Möglichkeit, ohne sauer dreinblickende Projektmanager auch zwischendrin mal das Ruder herumzureißen, und das Ganze auch noch mit dem Segen des Agilen Manifests und mit einem Framework namens Scrum.

Echt jetzt? Wenn Ihre Organisation mit Scrum wirklich erfolgreich sein will, dann gilt es, etwas tiefer zu blicken. Der Prozess ist mit hoher Wahrscheinlichkeit deutlich strikter, als Sie ihn heute leben. Scrum ist außerhalb des Teams auch strikter gegenüber dem Management. Außerdem ist Scrum zu Beginn der Einführung anstrengender als Ihr heutiger Integrations- und Testprozess, vor allem für Embedded Systeme.

Scrum und die Bedürfnisse von Embedded Software Engineering

Über das agile Mindset wurde bereits viel geschrieben, etwa im Agilen Manifest [1]. Die Prinzipien hinter Scrum sind dieselben wie im agilen Manifest beschrieben:

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“[2]

Oft finden wir gute Ansätze und Motivation vor, dabei werden jedoch ebenso oft in der Rezeption in Teams nur die vier „mehr-als“-Prinzipien in den Mittelpunkt gerückt. Zusätzlich kann es bei der Einführung von Scrum zu Verwirrung, doppelter Arbeit und Unsicherheit kommen, vor allem während der Selbstfindung des Teams, oder bei der Zusammenarbeit mit Kunden, die selbst noch nicht „agil“ vorgehen, wie etwa in [3] nachzulesen.

Die Bedürfnisse von Embedded Software Engineering, eben die starke Bindung an Hardware, mit sehr preissensitiven elektronischen Komponenten und langen Vorlaufzeiten, sind teilweise anders.

Die Probleme beginnen, wenn Teams den Nachsatz „obwohl wir die Werte auf der rechten Seite wichtig finden“ übersehen. Denn die agilen Prinzipien bedeuten eben nicht, dass Prozesse, Werkzeuge und Dokumentation jetzt unwichtig sind. Die Präposition im englischen Original hilft weiter: „Individuals and interactions over processes and tools”. Over, also über.

Wenn Individuen und Interaktionen über Prozessen und Werkzeugen stehen, dann sind diese darunter und bilden somit die Basis. Individuen sind uns wichtiger, damit das aber Raum hat, brauchen wir hilfreiche Prozesse und Werkzeuge.

Wenn uns funktionierende Software wichtiger ist, dann brauchen wir darunter eben gerade genug Dokumentation, damit jeder weiß wie die bestehende Software und die Entwicklung laufen.

Wenn uns die Zusammenarbeit mit dem Kunden wichtiger ist, dann brauchen wir sinnvolle Vertragsverhandlungen, um eben diese Zusammenarbeit zu haben und gestalten zu können. Wer bei Embedded Software Engineering von automobilen Systemen allen Anforderungen funktionaler Sicherheit gerecht werden will, muss festhalten, bei wem die Zuständigkeiten liegen.

Gerade wenn wir schnell auf Veränderung reagieren wollen hilft als Grundlage ein Plan, in dem die ursprünglichen Idee und daraus folgenden Zielsetzungen festgehalten werden. In der Entwicklung von Embedded Systemen gibt es Rahmenbedingungen, die am besten Platz in einem Plan finden.

Planung ersetzt Zufall durch Irrtum. Und aus Irrtum kann das Team lernen.

Das agile Manifest wird oft als Waffe gegen jegliche klassische Methode benutzt. Das agile Manifest jedoch ist viel mehr: Zeigt es doch einen Weg auf, über all den klassischen Vorgehensweisen noch mehr Fokus auf das Gelingen zu legen, als Folge der Zusammenarbeit von Menschen in einer veränderlichen Welt.

Infrastruktur 1 – DevOps

Scrum besagt, das cross-funktionale Team soll quasi autark agieren und sich seine Prozesse und Methoden so definieren, wie es für das Projekt am besten ist. Und ja, mit absolut konstanten Teams kann das tatsächlich funktionieren.

In der Realität sehen sich Firmen jedoch einer Fluktuation gegenüber, so dass immer wieder neue Teammitglieder hinzukommen. Oft sind Projekte so groß, dass mehrere Teams daran arbeiten, was die Wahrscheinlichkeit neuer Teammitglieder zusätzlich erhöht.

Wenn das Team regelmäßig funktionierende Software liefern möchte, dann wird es nicht umhin kommen, die Funktionsfähigkeit der Software oft zu prüfen. So rücken „Continuous Integration“ und „Nightly Builds“ in den Fokus. Sie beziehen in einer entsprechenden Infrastruktur automatisch Code und andere Artefakte aus einem Versionierungssystem, bauen die Software und testen sie ausgiebig.

Obwohl sich nach Scrum jedes Team selbst organisieren und die Infrastruktur selbst bestimmen darf, sollte unbedingt sichergestellt sein, dass jedes Team eine funktionierende Build-Infrastruktur nutzt. Teams, die sich keine eigene Infrastruktur geben können oder möchten, sollte eine bestehende zur Verfügung stehen.

Das Erstellen einer Projekt- und Build-Infrastruktur ist nichts, was ein Entwickler eben mal an einem Nachmittag erreicht. Zusammen genommen ergibt die Build-Infrastruktur mit allem, was dazu gehört, die Development Operations, kurz DevOps [siehe auch [4]). Ohne Anspruch auf Vollständigkeit benötigt diese:

• 1. Versionskontrollsystem, z.B. Subversion[5], Git [6]

• 2. Ticket-System, z.B. Jira [7], Trello, Leankit, Kanbanize

• 3. Build-Server, z.B. Jenkins [8]

• 4. Deployment-Automatisierung, z.B. GoCD [9]

• 5. Tool für Statische Codeanalyse, z.B. Polyspace [10], Klocwork [11], die sowohl auf dem Build-Server als auch lokal für die Entwickler laufen.

• 6. Tool für Code Coverage, z.B. Bullseye [12]

• 7. Testautomatisierung, Framework je nach verwendeter Technologie

• 8. Branching-Strategie, damit neue Feature-Entwicklungen risikofrei entwickelt werden können. [siehe auch 13]

• 9. Vollautomatisiertes Reporting. Niemand sollte manuell Statistiken und Stati zusammentragen müssen.

• 10. Mehrstufiges Integrations- und Merge-Verfahren auf dem Build Server, um Branches zusammen zu führen [14].

• 11. Sandbox-System z.B. Docker [15], damit jeder reproduzierbar dieselbe Umgebung hat

• 12. Rollendefinition für Test Manager, Integration Manager, Release Manager, Build Manager.

Neben den funktionierenden Werkzeugen ist es wichtig, dass das Teammitglied mit dem Wissen über oben genannte Systeme und Verfahren im Projekt bleibt, um Änderungen angemessen adaptieren zu können. Hier wird die Scrum-Forderung nach cross-funktionalen Teams wichtig: Die betreffende Person muss Teil des Projekts sein und bleiben, sonst kommt es immer wieder zu Verzögerungen. Für große Projekte mit mehreren Teams kann ein DevOps-Team tatsächlich die hilfreichste Lösung sein. Um den Problemen der Fluktuation entgegen zu wirken wird so das notwendige Wissen durch ein ganzes Team „Wissender“ sichergestellt. Dieses Dev-Ops-Team muss aber direkt in die Entwicklungsteams eingebunden sein. Denn auch klar ist: Die Infrastruktur muss zuverlässig laufen, es dient als Produktivsystem.

Denn „in Scrum gilt: Es gibt keine Testphase. Es gibt nur eine Entwicklungsphase, die Testaktivitäten einschließt.“ Selbiges trifft auf Releases der Systemsoftware zu: „Releasing muss zu einem Standardprozess werden, der völlig geräuschlos abläuft.“ [3, p. 230].

(ID:45112558)