5 Bewertungen

Nicht stur dem Handbuch folgen Wieso Scrum nach Lehrbuch in der Embedded-Entwicklung nicht funktioniert

MicroConsult Microelectronics Consulting & Training GmbH

Scrum sollte in der Entwicklung von Embedded-Systemen nicht dem Lehrbuch folgen.

Bild: iStock, miljko
01.10.2019

Um im Embedded-Umfeld erfolgreich agil zu entwickeln, müssen neben den Scrum-Grundlagen die Besonderheiten des komplexen Zusammenspiels von Hardware und Software von der Planung bis zum Test berücksichtigt werden. ScrumBedded verspricht hier als maßgeschneiderte Lösung Erfolg.

Sponsored Content

Bei Embedded-Projekten legt man für gewöhnlich im Vorfeld eine grobe Architektur fest. Entwickelt man für Single- oder Multicore-Prozessoren? Wie viele Cores werden dabei benötigt? Und wie hoch ist die ungefähre Leistungsfähigkeit des Ziel-Controllers? Geht es um ein Bare-Metal- oder um ein RTOS-basiertes Design? Kommt dabei eine generische Produkt-Plattform zum Einsatz? Entsteht ein Einzelprodukt oder entwickelt man ein Teil einer Produktfamilie? Erst wenn diese Fragen zufriedenstellend beantwortet und die zugehörigen Eckdaten festgelegt sind, ist es für das Expertenteam sinnvoll, mit den Entwicklungssprints und so mit der agilen Entwicklungsmethodik zu beginnen.

Agile Embedded-Rollen

Zu den klassischen Scrum-Rollen wie Product-Owner, Scrum-Master und Scrum-Team kommen in der Embedded-Entwicklung noch viele weitere Rollen hinzu, darunter Hardware-Entwickler, System-Architekt, Entwickler von Low-Level-Treibern, Gesamtsystem-Tester, Anwenderdoku für das Gesamtsystem, Gesamt-Projektleiter sowie Produktmanager. Zu jeder dieser einzelnen Rollen sollten Schnittstellen bestehen, die in der agilen Entwicklung angepasst werden müssen. Ohne diese Anpassungen entstehen zu große Reibungsverluste, und oft führt das zum Scheitern des kompletten agilen Ansatzes. Hier ist Überzeugungsarbeit zu leisten und gegenseitiges Vertrauen zu schaffen, um gemeinsam den Erfolg der agilen Entwicklung zu ernten.

Herausforderungen im agilen Test

Das agile Testen im Embedded-Umfeld ist eine besonders harte Nuss. Hier hilft nur eine Dual-Targeting-Strategie, die das Testen einerseits auf der Entwicklungsplattform (1) und andererseits in der Target-Umgebung (2) zum Ziel hat. Die zeitliche Synchronisierung der potentiell lieferbaren Produktinkremente am Ende der Sprints mit der Versionierung der Target-Plattform (inklusive Evaluierungsboards, Pilot-Hardware, Produktversion, Bugfixes in der Hardware, etc.) ist ebenso wichtig wie das Festlegen des Umfangs von hardware-abhängigen Tests. Ein kontinuierlicher Systemtest, in den inkrementell weitere Funktionalität einfließen kann, stellt die ideale Konstellation dar.

Bauen Sie sich Ihr agiles Entwicklungsframework nach Maß

Scrum-Entwicklung nach Lehrbuch funktioniert in den wenigsten Fällen. Doch das Rad neu zu erfinden ist auch keine Lösung. Übernehmen Sie aus bestehenden Frameworks so viel wie notwendig, doch gleichzeitig auch so wenig wie möglich. Das Sammeln von eigenen Erfahrungen ist in der Embedded-Entwicklung essentiell.

Test-Driven Development für Embedded-Systeme

Das Dual-Targeting ermöglicht Test-Driven Development für Embedded-Systeme auch, wenn sich die Target-Hardware noch in der Entwicklung befindet. Vom ersten Tag an wird die Software so designt, dass sie auf mindestens zwei Plattformen lauffähig ist. Auf der Entwicklungsplattform müssen dazu viele Hardwareabhängigkeiten der Target-Hardware simuliert werden; dafür lässt sich die entstehende Software kontinuierlich z.B. auf dem PC testen und später mit der echten Hardware verifizieren. Im TDD-Cycle wird der Test zuerst entworfen und geschrieben, dann wird Funktionalität implementiert und getestet, schließlich refaktorisiert, um der stückweise entstandenen Software eine bessere Architektur einzuhauchen, ohne die Funktionalität zu verändern. Um dies zu überprüfen, wird zum Abschluss des TDD-Cycles nochmals der Test ausgeführt, erst dann geht der Cycle in eine neue Runde. Nach Scrum lassen sich Backlog-Items bis auf Tasks der Größenordnung “ein Mann” oder “ein Tag” herunterbrechen. Das ist die Schnittstelle, an der TDD, obwohl unabhängig vom verwendeten Projektframework, wunderbar mit Scrum zusammenwirkt. Der TDD-Testplan bricht die zu erledigenden Tasks inklusive des dazugehörigen Tests auf kleine Schritte herunter. Die Umsetzung dieser Schritte setzt die Tasks in die Tat um und verifiziert ihre Qualität. Das Test-Driven Development für Embedded-Systeme nutzt dieses Verfahren intensiv und ermöglicht eine deutliche Qualitätssteigerung durch frühes kontinuierliches Testen.

Einführung in die agile Entwicklung: ScrumBedded

Um die Besonderheiten der agilen Entwicklung in der Embedded-Welt zu beschreiben, haben wir bei MicroConsult den Begriff „ScrumBedded“ eingeführt. Er umfasst mit einem Wort die Erweiterungen des Standard Scrum-Frameworks um die Erstellung der System-Grobarchitektur, System-Stories, Synchronisationspunkte zwischen Software- und Hardware-Entwicklung, die erweiterten Rollen wie den System-Architekten und den Umgang mit dem Hardware-Bottleneck, der durch die gleichzeitige Entstehung von Software und Hardware besonders beim Testen schwierig ist. ScrumBedded steht damit im Mittelpunkt der agilen MicroConsult-Seminare.

Bildergalerie

  • Besonderheiten agiler Entwicklung von Embedded-Systemen

    Besonderheiten agiler Entwicklung von Embedded-Systemen

    Bild: Microconsult

  • Agile Rollen in der Entwicklung von Embedded-Systemen

    Agile Rollen in der Entwicklung von Embedded-Systemen

    Bild: Microconsult

  • Embedded-Systemtest

    Embedded-Systemtest

    Bild: Microconsult

  • Der Test-Driven Development Cycle

    Der Test-Driven Development Cycle

    Bild: Microconsult

Verwandte Artikel