Autoren: Dr. Joachim Schlosser, Martin Hillbrand, Elektrobit Automotive GmbH<\/p>\n
Agil, was ist das eigentlich? Agile Entwicklung, das hat was von Leichtigkeit. Tats\u00e4chlich tr\u00e4gt agile Entwicklung dazu bei, schneller bessere Ergebnisse erzielen zu k\u00f6nnen. Es gilt aber auch: der Prozess ist strikter, als Sie ihn heute wahrscheinlich leben. Scrum ist strikter gegen\u00fcber dem Management und erfordert einen funktionierenden Integrations- und Testprozess, vor allem in Embedded Systemen.<\/strong><\/p>\n Der erste agile Wert lautet „Individuals and interactions over processes and tools“. Eben um im t\u00e4glichen Arbeiten den Menschen und Interaktionen eine h\u00f6here Bedeutung einr\u00e4umen zu k\u00f6nnen, ist es so wichtig, dass funktionierende Prozesse und Tools vorhanden sind, die ganz nat\u00fcrlich genutzt werden.<\/p>\n Agil klingt innovativ, ebenso wie Scrum mit seinen User Stories, dem Zusammenarbeiten.<\/p>\n Das agile Prinzip, \u00c4nderungen willkommen zu hei\u00dfen, l\u00e4sst Kunden und das h\u00f6here Management in Entwicklungsorganisationen in freudiger Schnappatmung erzittern. Verhei\u00dft dies doch die M\u00f6glichkeit, ohne sauer dreinblickende Projektmanager auch zwischendrin mal das Ruder rumzurei\u00dfen, 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. \u00a0Der Prozess ist mit hoher Wahrscheinlichkeit deutlich strikter, als Sie ihn heute leben. Scrum ist au\u00dferhalb des Teams auch strikter gegen\u00fcber dem Management. Au\u00dferdem ist Scrum zu Beginn der Einf\u00fchrung anstrengender als Ihr heutiger Integrations- und Testprozess, vor allem f\u00fcr Embedded Systeme.<\/p>\n \u00dcber das agile Mindset wurde bereits viel geschrieben, etwa im Agilen Manifest [1]. Die Prinzipien hinter Scrum sind dieselben wie im agilen Manifest beschrieben:<\/p>\n „Wir erschlie\u00dfen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese T\u00e4tigkeit haben wir diese Werte zu sch\u00e4tzen gelernt:<\/p>\n Das hei\u00dft, obwohl wir die Werte auf der rechten Seite wichtig finden, sch\u00e4tzen wir die Werte auf der linken Seite h\u00f6her ein.“ [2]<\/p>\n Oft finden wir gute Ans\u00e4tze und Motivation vor, dabei werden jedoch ebenso oft in der Rezeption in Teams nur die vier „mehr-als“-Prinzipien in den Mittelpunkt ger\u00fcckt. Zus\u00e4tzlich kann es bei der Einf\u00fchrung von Scrum zu Verwirrung, doppelter Arbeit und Unsicherheit kommen, vor allem w\u00e4hrend der Selbstfindung des Teams, oder bei der Zusammenarbeit mit Kunden, die selbst noch nicht „agil“ vorgehen, wie in [3] zu lesen.<\/p>\n Die Bed\u00fcrfnisse von Embedded Software Engineering, eben die starke Bindung an Hardware mit sehr preissensitiven elektronischen Komponenten und langen Vorlaufzeiten sind teilweise anders.<\/p>\n Die Probleme beginnen, wenn Teams den Nachsatz „obwohl wir die Werte auf der rechten Seite wichtig finden“ \u00fcbersehen. Denn die agilen Prinzipien bedeuten eben\u00a0nicht<\/em>, dass Prozesse, Werkzeuge und Dokumentation jetzt unwichtig sind. Die Pr\u00e4position im englischen Original hilft weiter: „Individuals and interactions\u00a0over<\/em>\u00a0processes and tools“.\u00a0Over<\/em>, also\u00a0\u00fcber<\/em>.<\/p>\n Wenn Individuen und Interaktionen\u00a0\u00fcber<\/em>\u00a0Prozessen und Werkzeugen stehen, dann sind diese\u00a0darunter<\/em>\u00a0und bilden somit\u00a0die Basis<\/em>. Individuen sind uns wichtiger, damit das aber Raum hat, brauchen wir hilfreiche Prozesse und Werkzeuge.<\/p>\n Wenn uns funktionierende Software wichtiger ist, dann brauchen wir\u00a0darunter<\/em>\u00a0eben gerade genug Dokumentation, damit jeder wei\u00df wie die bestehende Software und die Entwicklung laufen.<\/p>\n Wenn uns die Zusammenarbeit mit dem Kunden wichtiger ist, dann brauchen wir sinnvolle Vertragsverhandlungen, um eben diese Zusammenarbeit zu haben und gestalten zu k\u00f6nnen. Wer bei Embedded Software Engineering von automobilen Systemen allen Anforderungen funktionaler Sicherheit gerecht werden will, muss festhalten, bei wem die Zust\u00e4ndigkeiten liegen.<\/p>\n Gerade wenn wir schnell auf Ver\u00e4nderung reagieren wollen hilft als Grundlage ein Plan, in dem die urspr\u00fcnglichen Idee und daraus folgenden Zielsetzungen festgehalten werden. In der Entwicklung von Embedded Systemen gibt es Rahmenbedingungen, die am besten Platz in einem Plan finden.<\/p>\n Planung ersetzt Zufall durch Irrtum. Und aus Irrtum kann das Team lernen\u00a0[1]<\/em>.<\/p>\n 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, \u00fcber all den klassischen Vorgehensweisen noch mehr Fokus auf das Gelingen zu legen, als Folge der Zusammenarbeit von Menschen in einer ver\u00e4nderlichen Welt.<\/p>\n Scrum besagt, das cross-funktionale Team soll quasi autark agieren und sich seine Prozesse und Methoden so definieren, wie es f\u00fcr das Projekt am besten ist. Und ja, mit absolut konstanten Teams kann das tats\u00e4chlich funktionieren. In der Realit\u00e4t sehen sich Firmen jedoch einer Fluktuation gegen\u00fcber, so dass immer wieder neue Teammitglieder hinzukommen. Oft sind Projekte so gro\u00df, dass mehrere Teams daran arbeiten, was die Wahrscheinlichkeit neuer Teammitglieder zus\u00e4tzlich erh\u00f6ht.<\/p>\n Wenn das Team regelm\u00e4\u00dfig funktionierende Software liefern m\u00f6chte, dann wird es nicht umhin kommen, die Funktionsf\u00e4higkeit der Software oft zu pr\u00fcfen. So r\u00fccken „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.<\/p>\n Obwohl sich nach Scrum jedes Team selbst organisieren und die Infrastruktur selbst bestimmen darf, sollte unbedingt sichergestellt sein,\u00a0dass<\/em>\u00a0jedes Team eine funktionierende Build-Infrastruktur nutzt. Teams, die sich keine eigene Infrastruktur geben k\u00f6nnen oder m\u00f6chten, sollte eine bestehende zur Verf\u00fcgung stehen.<\/p>\n 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\u00f6rt, die\u00a0Development Operations<\/em>, kurz DevOps\u00a0[4]. Ohne Anspruch auf Vollst\u00e4ndigkeit ben\u00f6tigt diese:<\/p>\n Neben den funktionierenden Werkzeugen ist es wichtig, dass das Teammitglied mit dem Wissen \u00fcber oben genannte Systeme und Verfahren im Projekt bleibt, um \u00c4nderungen angemessen adaptieren zu k\u00f6nnen. 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\u00f6gerungen. F\u00fcr gro\u00dfe Projekte mit mehreren Teams kann ein DevOps-Team tats\u00e4chlich die hilfreichste L\u00f6sung sein. Um den Problemen der Fluktuation entgegenzuwirken, 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\u00e4ssig laufen, es dient als Produktivsystem.<\/p>\n Denn in Scrum gilt: „Es gibt keine Testphase. Es gibt nur eine Entwicklungsphase, die Testaktivit\u00e4ten einschlie\u00dft.“ [3, p. 228] Selbiges trifft auf Releases der Systemsoftware zu: „Releasing muss zu einem Standardprozess werden, der v\u00f6llig ger\u00e4uschlos abl\u00e4uft.“ [3, p. 230]<\/p>\n Eine weitere Herausforderung bei der Erstellung der Infrastruktur wird durch die Frage deutlich, wie wir so schnell wie m\u00f6glich auf die Zielplattform kommen. Denn „funktionierende Software“ im agilen Manifest muss im Kontext von Embedded Systems eigentlich hei\u00dfen: \u201e“funktionierendes System.“<\/p>\n Embedded Hardware ist etwas spr\u00f6de in der Handhabung, und das liegt nicht am Material der Platinen. Wer mechatronische Hardware entwickelt, denkt in Vorlaufzeiten f\u00fcr Platinen-Layouts, Lieferzeiten und Verf\u00fcgbarkeit aktueller Prozessoren.<\/p>\n 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\u00fchzeitig der tats\u00e4chliche Kundennutzen gepr\u00fcft wird [16]. Gerade Frameworks wie AUTOSAR helfen dabei, Funktionalit\u00e4ten im Rahmen einer Simulation zun\u00e4chst von Hardware getrennt betrachten zu k\u00f6nnen\u00a0[17]. Dabei gilt es, Vorsicht\u00a0vor un\u00fcberlegter Modellierung und unbedachter Simulation walten zu lassen. Das Aufsetzen von Simulationen, die keine notwendigen Erkenntnisse bieten, kann viel Aufwand und Zeit verschlingen [18].<\/p>\n Sukzessive werden dann der reinen Simulation in Software Methoden Processor-in-the-Loop (PiL) und Hardware-in-the-Loop (HiL) zugef\u00fcgt, um konkrete Effekte von Prozessorarchitektur, Steuerger\u00e4tehardware und mechatronischer Umgebung mit in die automatisierten Tests einzubeziehen. Alle Erfordernisse der DevOps-Infrastruktur gelten auch weiterhin: Nur was automatisiert getestet werden kann, erm\u00f6glicht es dem Team, in einem festen Takt einen Stand eines Systems auszuliefern.<\/p>\n Die Architektur des Systems kann dabei ihr \u00fcbriges tun. Sauber geschnittene Module \u2013 sei es als Microservices\u00a0[19] oder AUTOSAR-Komponenten \u2013 erlauben es, diese f\u00fcr sich zu entwickeln, zu testen und auszuliefern.<\/p>\n All diese Frameworks und Verfahrensweisen schr\u00e4nken scheinbar die Freiheit der Teams ein, geben tats\u00e4chlich jedoch mehr Freiheit in der L\u00f6sung der eigentlichen Aufgabenstellung, vorausgesetzt die Rahmenbedingungen sind bekannt und bleiben relativ stabil.<\/p>\n Scrum betrifft nicht nur das oder die Entwicklungsteams. Scrum betrifft die ganze Organisation. Auch wenn nur Teile einer Organisation tats\u00e4chlich nach Scrum arbeiten, so sollten doch alle, die mit diesen Teams interagieren, verstehen, was Scrum bedeutet.<\/p>\n Dies gilt auch und vor allem f\u00fcr F\u00fchrungskr\u00e4fte. Scrum sieht explizit vor, dass in Sprints gearbeitet wird, also Entwicklungsabschnitten von wenigen Wochen Dauer, an deren Ende jeweils ein lauff\u00e4higes System an den Kunden geliefert wird.<\/p>\n Nach jedem abgeschlossenen Sprint werden dann die Anforderungen f\u00fcr den n\u00e4chsten geplant. Wichtig ist:\u00a0W\u00e4hrend<\/em>\u00a0des Sprints\u00a0bleiben die Anforderungen stabil<\/em>. Es kommt also kein Manager herein und gibt den Entwicklern pl\u00f6tzlich etwas anderes zu tun. Gibt es w\u00e4hrend eines Sprints neue Anforderungen, werden diese in der Regel nicht in den laufenden integriert, sondern kommen ins Product Backlog. \u00a0H\u00e4ufen sich die F\u00e4lle, dass f\u00fcr den aktuellen Sprint geplante Anforderungen pl\u00f6tzlich obsolet werden, ist das ein impliziter Auftrag an Scrum Master und Product Owner, sich Gedanken \u00fcber bessere Anforderungen und deren Abstimmung mit den Kunden zu machen.<\/p>\n Die vornehmliche Aufgabe des Scrum Masters wird damit, das Team von organisatorischen Interrupts von au\u00dfen zu sch\u00fctzen. Die F\u00fchrungsriege einer Organisation sollte diese Bem\u00fchungen tunlichst unterst\u00fctzen, indem sie eben\u00a0nicht<\/em>\u00a0ins laufende Getriebe eingreift, sondern den Sprint-Takt nutzt, um ge\u00e4nderte Situationen und Anforderungen einzuspeisen.<\/p>\n Die Einf\u00fchrung von Scrum allein \u00fcber Team-Schulungen reicht damit nicht aus. Es bedarf explizit auch der Schulung der F\u00fchrungskr\u00e4fte in angrenzenden Organisationseinheiten.<\/p>\n Agil bedeutet, dass wir die gesamte Organisation ver\u00e4ndern m\u00fcssen, hin zu einer Struktur, die das Projektergebnis erm\u00f6glicht und auf Wertsch\u00f6pfung 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].<\/p>\n Die Einf\u00fchrung von Scrum hat einen Anfang, aber durch das Wesen der Selbstorganisation kein Ende. Ver\u00e4nderte Rahmenbedingungen und Projektumfelder werden sich in ver\u00e4nderten Umsetzungen von Scrum niederschlagen. Ihr Manager wird sich daran gew\u00f6hnen m\u00fcssen, dass er keinen statischen Entwicklungsprozess unter sich hat, den er einmal aufgezeichnet bekommt und der dann ewig so bleibt.<\/p>\n Agile Vorgehensweisen im Embedded Software Engineering sind kein Selbstl\u00e4ufer.\u00a0 Den Teams durch gute Infrastruktur erm\u00f6glichen, regelm\u00e4\u00dfig aufwandsarm zu liefern und ihnen Methoden an die Hand geben, die Belange von Embedded Systems zu ber\u00fccksichtigen, ist eine gute Basis. Wenn dann auch noch die Manager die Teams in Ruhe arbeiten lassen, garantiert das schon fast den Erfolg.<\/p>\n Wir bei Elektrobit haben sowohl gro\u00dfe Teile unserer eigenen Entwicklungsorganisation, als auch namhafte Kundenorganisationen in Embedded Software Engineering erfolgreich durch die Transition auf Agile Vorgehensweisen begleitet und lernen immer noch st\u00e4ndig dazu. Sprechen Sie uns an.<\/p>\nMindset<\/h2>\n
\n
Infrastruktur 1 \u2013 DevOps<\/h2>\n
\n
Infrastruktur 2 \u2013 Embedded Hardware<\/h2>\n
Manager und Einf\u00fchrung von Scrum<\/h2>\n
Zusammenfassung<\/h2>\n
Literaturverzeichnis<\/h3>\n