21 Jahre ist es her, dass in Snowbird im US-Bundesstaat Utah die Prinzipien der agilen Entwicklung ausformuliert und schriftlich festgehalten wurden. Seither haben agile Entwicklungsmethoden breiten Anklang gefunden, da sie Entwicklerteams im Vergleich zu traditionellen Vorgehensweisen wie dem Wasserfallmodell deutlich mehr Flexibilität bieten und den Entwicklungsprozess oftmals beschleunigen. Mittlerweile sind agile Methoden nicht mehr nur in der Softwareentwicklung zu finden, sondern haben sich auch einen Weg in die Entwicklung von Hardware-Produkten gebahnt. Ihr Einsatz im Hardware-Bereich stellt Unternehmen jedoch vor Herausforderungen.
Während es bei Softwareprodukten in der Regel gut möglich ist, einzelne Systemkomponenten getrennt voneinander zu testen, ist es bei Hardware und insbesondere bei sehr komplexen Systemen oftmals schwierig, alle Wechselwirkungen vorab zu kennen, sodass zum Schluss nach wie vor das System als Ganzes getestet werden muss. Und das ist nur eine der Herausforderungen bei der agilen Entwicklung von Hardware-Produkten.
Wie kann es Unternehmen also gelingen, ihre Produkte erfolgreich agil zu entwickeln, obwohl diese nicht nur Softwarekomponenten, sondern auch mechanische und elektronische Bestandteile umfassen? Der modulare Aufbau der Produktarchitektur vereinfacht die Einführung agiler Entwicklungsmethoden deutlich und ist gewissermaßen eine Voraussetzung für diese. Ist ein Produkt modular aufgebaut, lassen sich die einzelnen Module voneinander unabhängig in agilen Teams entwickeln und testen und die Ausarbeitung eines Minimum Viable Products (MVP), der erste Schritt in der agilen Produktentwicklung, wird erheblich vereinfacht.
Wie genau Modularität Ihnen dabei hilft, agile Entwicklungsmethoden erfolgreich auf Ihre Hardware-Produkte anzuwenden, erklären wir Ihnen in diesem Blog-Artikel. Dazu werden wir uns zunächst im Detail ansehen, was agile Entwicklung überhaupt bedeutet und was sie von anderen Vorgehensweisen wie dem Wasserfallmodell unterscheidet.
Vom Wasserfallmodell zur agilen Entwicklung
Jahrhundertelang war das Wasserfallmodell gemeinsam mit seiner Erweiterung, dem V-Modell, die Vorgehensweise in der Produktentwicklung schlechthin. Das Wasserfallmodell beschreibt eine lineare Vorgehensweise bei der Entwicklung von Produkten und Systemen, die mehrere Projektphasen umfasst, von der Analyse der Anforderungen bis hin zu Einsatz und Wartung. Ursprünglich für Hardware konzipiert, hat das Modell in späteren Jahren auch starken Anklang in der Softwareentwicklung gefunden. Die nachfolgende Grafik zeigt die sechsstufige Version des Modells für die Entwicklung von Software.
Das ursprüngliche Modell, dessen erste Erwähnung aus dem Jahr 1956 stammt, wurde mehrfach überarbeitet, verbessert und erweitert, um es an die Softwareentwicklung anzupassen. 1980 wurde das Wasserfallmodell zum ebenfalls linear organisierten V-Modell ergänzt mit dem Ziel, die Testentwicklung parallel zur Phase des Systemdesigns abzuschließen und so einen Großteil des Testaufwands früh im Entwicklungsprozess abzudecken. Der schematische Aufbau des V-Modells ist in der folgenden Grafik dargestellt.
Auch wenn viele Projekte erfolgreich mit dem Wasserfallmodell durchgeführt wurden, so bringt die Vorgehensweise einige Nachteile mit sich. Zu Beginn eines Projektes wird viel Zeit und Aufwand in die Anforderungsanalyse investiert, dies verzögert den Projektstart. Ein weiterer Nachteil ist die mangelnde Flexibilität, um auf Anforderungsänderungen einzugehen, die sich im Laufe des Entwicklungsprozesses ergeben. Werden Änderungen trotzdem zugelassen, was häufig unvermeidbar ist, so kommt es zu Störungen im Projektablauf. Da der Großteil der Produkttests zudem erst ganz zum Schluss stattfindet, werden Fehler erst spät identifiziert, was zu hohen Kosten und Verzögerungen führt.
Diese Nachteile haben dazu geführt, dass das Wasserfallmodell durch das V-Modell ersetzt wurde, welches von Anfang an auf verschiedenen Abstraktionsebenen Lösungen und Anforderungen vergleicht, um so die Schwächen des Wasserfallmodells zu adressieren. Aber auch Entwicklung im V-Modell ist vergleichsweise langsam und eignet sich nicht für die schnelle Iteration von Prototypen und einzelnen Features, so dass das V-Modell immer mehr durch das Konzept der agilen Entwicklung ersetzt wird, dessen Grundprinzipien 2001 im sogenannten Manifest für Agile Softwareentwicklung festgehalten wurden.
In dem Manifest, das als Zusammenfassung der Ansätze verschiedener agiler Entwicklungsmethoden wie Scrum oder Extreme Programming gedacht ist, liest man:
“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.”
Vorurteile gegenüber der Agilen Entwicklung
Der Wortlaut des Manifests mag auf den ersten Blick etwas vage erscheinen, aber in der Praxis lässt sich agile Entwicklung wie folgt beschreiben:
- Präferenz von Interaktion und Austausch mit Stakeholdern und Kunden gegenüber Tabellenkalkulationen und digitalen Tools.
- Das Gespräch mit dem Kunden suchen statt Zeit mit zähen Verhandlungen zu verschwenden.
- Bereitschaft, auf sich im Prozess ergebende Änderungen einzugehen, was sich häufig in der Verwendung von Prototypen zeigt, die bereits in frühem Stadium Interessengruppen und Kunden zur Verfügung gestellt werden, um das Produkt darauf aufbauend weiterzuentwickeln und zu verbessern.
- Vereinfachte und effizientere Anforderungsanalyse zu Beginn der Entwicklung, da davon ausgegangen wird, dass sich die Anforderungen an das Produkt zum Großteil doch wieder ändern werden.
Noch besser können wir die Kerngedanken der agilen Entwicklungsmethodik verstehen, wenn wir uns einige Vorurteile und Missverständnisse anschauen, die häufig in Bezug auf diese Entwicklungsmethodik bestehen.
Agile Entwicklung ist unstrukturiert
Agile Softwareentwicklung gilt häufig (fälschlicherweise) als unstrukturiert, da nicht alle Produktanforderungen im Voraus definiert sind. In Wahrheit ist es jedoch so, dass ein agiler Ansatz in der Entwicklung häufig sehr viel Struktur erfordert. Zum Beispiel muss zu Beginn des Projekts ein nach Prioritäten geordnetes Backlog (Bestand) der zu entwickelnden Elemente erstellt werden, auf dessen Basis die Planung erfolgt und welches ständig aufgefüllt und neu priorisiert wird, um sicherzustellen, dass Veränderungen der am Markt gestellten Anforderungen im Entwicklungsprozess berücksichtigt werden.
Agile Entwicklung vernachlässigt Dokumentation
Auch die Annahme, dass agil weniger Verwaltung und Dokumentation und dafür mehr Coding bedeutet, ist so nicht korrekt. Verwaltung und Dokumentation stellen einen erheblichen Teil des agilen Frameworks dar. Der einzige Unterschied zu traditionellen Vorgehensweisen bei der Entwicklung besteht darin, dass die Dokumentation auf den Umfang der aktuellen Projektphase beschränkt ist, ohne dass dabei der gesamte Umfang des Produkts berücksichtigt wird. Auch das kontinuierliche Updaten des Backlogs, das zum Priorisieren der Aufgaben verwendet wird, bedeutet einen gewissen Verwaltungsaufwand. Das Gleiche gilt für die Koordination von teamübergreifenden Aufgaben.
Agile Entwicklung ist intransparent
Zu den häufigsten Vorurteilen, die viele gegenüber der agilen Entwicklung haben, gehört auch, dass diese weniger transparent sei als traditionelle Methoden wie das Wasserfallmodell. Tatsächlich ist jedoch genau das Gegenteil der Fall. Viele agile Entwicklungsmethoden arbeiten mit Kanban Boards (siehe Grafik oben), auf denen die in der jeweiligen Projektphase anfallenden Aufgaben und bereitstehenden Kapazitäten dokumentiert werden. Das bedeutet, dass während des gesamten Entwicklungsprozesses hindurch klar ersichtlich ist, welcher Fortschritt beim Projekt erreicht wurde und wie ausgelastet die einzelnen Teams sind. Bei einer agilen Vorgehensweise reicht es demnach in der Regel aus, einen Blick auf die Kanban-Tafel zu werfen, um zu sehen, welchen Status die aktuellen Aufgaben eines Teams haben und welche Aufgaben als nächstes priorisiert werden müssen.
Agile Entwicklung funktioniert nur für kleine Entwicklungsabteilungen
Anders als häufig angenommen wird, lassen sich agile Entwicklungsmethoden nicht nur in kleinen Teams, sondern auch in größeren Unternehmen umsetzen, die deutlich mehr Entwickler beschäftigen als die, die normalerweise in einem Scrum-Team arbeiten. Dafür gibt es mittlerweile spezielle agile Entwicklungsansätze wie zum Beispiel das Scaled Agile Framework (SAFe), welches eine Methodik liefert, agile Entwicklungsphilosophien zu skalieren, um großen Projekten wie der Entwicklung eines Autos gerecht zu werden. Das SAFe-Modell basiert auf einem sogenannten Agile Release Train (ART), der über ein priorisiertes Backlog mit Aufgaben verfügt und die Basis für die Zusammenarbeit verschiedener Entwicklerteams darstellt. Die Vorgehensweise ist im folgenden Schema dargestellt.
Bei komplexen Produkten wie Autos werden mehrere ARTs in einem Solution Train gebündelt. Bei manchen Automobilherstellern kann ein Solution Train 40 oder sogar mehr verschiedene ARTs umfassen. Der Einsatz des SAFE-Ansatzes in der Automobilbranche verdeutlicht darüber hinaus, dass agile Entwicklungsmethoden sich auch für die Entwicklung von Produkten eignen, die neben Software auch elektronische und mechanische Komponenten umfassen. Wie genau Hardware-Unternehmen erfolgreich agile Entwicklung umsetzen können, werden wir uns jetzt genauer ansehen.
Agile Entwicklung für Hardware-Produkte
Die Entwicklung von Hardware-Produkten ist in vielen Bereichen auch heute noch von den Prinzipien des linearen Wasserfallmodells geprägt. Das bedeutet allerdings nicht, dass Unternehmen, die Hardware-Produkte entwickeln, nicht auch von den Vorteilen eines agilen Ansatzes profitieren können. Eine agile Herangehensweise kann genutzt werden, um kürzere Feedbackschleifen für die konstruktive Umsetzung der Mechanik und Elektronik eines Produkts zu ermöglichen.
Zentral ist hierbei die Arbeit mit Prototypen, die in agilen Entwicklungsmethoden häufig zum Einsatz kommen und die heutzutage dank moderner Technologien wie Design Automation und Rapid Prototyping auch im Hardware-Bereich um einiges schneller entwickelt und gefertigt werden können. In der Konsequenz könnten in kurzen Abständen hintereinander mehrere Prototypen entwickelt werden, anhand derer die Elektronik und Mechanik des Produkts kontinuierlich verbessert und an das Feedback der Kunden und Stakeholder angepasst werden.
Leseempfehlung: Sie interessieren sich für Design Automation? In unserem Blog-Artikel “Design Automation in der Produktkonfiguration” erklären wir Ihnen die theoretischen Grundlagen und zeigen Ihnen an einem Beispiel, wie diese Automatisierung in der Praxis funktioniert.
Minimum Viable Product und Minimum Marketable Product für Hardware definieren
Bei der agilen Entwicklung muss zu Beginn ein Minimum Viable Product (MVP) konzipiert werden, d.h. eine erste, minimal funktionsfähige Produktvariante, die Kunden und Stakeholdern zum Testen gegeben werden kann, um Feedback einzuholen. Die Funktionen des MVP sind im Backlog entsprechend mit der höchsten Prioritätsstufe zu versehen, da diese zuallererst bearbeitet werden müssen. Aufbauend auf diesen ersten Rückmeldungen kann dann in einem zweiten Schritt ein Minimum Marketable Product (MMP) definiert werden. Das MMP ist die einfachste Produktausführung, die ein Minimum an Anforderungen erfüllt, um marktfähig zu sein und damit Geld zu verdienen.
Bei der Entwicklung von MMPs für Hardware-Produkte ergibt sich jedoch folgendes Problem: Softwareprodukte können auch nach Verkauf und Auslieferung noch beispielsweise über Over-the-Air-Updates (OTA) verbessert und weiterentwickelt werden. Das ist bei Hardware nicht der Fall. In der Konsequenz müssten an das MMP für ein Hardware-Produkt bereits von Anfang an höhere Anforderungen gestellt werden, was wiederum einen größeren Aufwand zu Beginn sowie längere Vorlaufzeiten in der Produktentwicklung nach sich zieht.
Es sei denn, das Unternehmen arbeitet mit einem modularen Baukastensystem, welches es erlaubt, zunächst eine Reihe von Basismodulen zu entwickeln, während zusätzliche Modulvarianten für Produktkonfigurationen mit größerem Funktionsumfang und höherer Leistung erst später entwickelt werden.
Um modulare Produktarchitekturen effizient zu entwickeln und zu verwalten, empfiehlt es sich auf Software-Tools zurückzugreifen, die ein durchgängiges und konsistentes Datenmodell bieten, in dem alle Aspekte eines modularen Systems von Kundenwünschen bis zu technischen Lösungen dokumentiert werden können. Ein solches Tool sollte alle Aspekte der Modularisierung, von der Definition über die Kostenplanung bis zur Verwaltung unterstützen.
Leseempfehlung: Erfahren Sie in diesem Blogartikel, wie ihnen PALMA als Software-Tool für Modularisierung helfen kann, schneller und besser zum modularen Baukasten.
Modularität als Voraussetzung für die Agile Entwicklung von Hardware-Produkten
Schauen wir uns dazu das Beispiel einer modularen elektrischen Winde an. Die Winde basiert auf einer modularen Produktplattform, die es erlaubt, durch die Kombination von unterschiedlichen Modulvarianten verschiedene Produktausführungen zu konfigurieren, die unterschiedliche Marktanforderungen bedienen.
Alle Produktkonfigurationen sind schematisch aus den gleichen (abstrakten) Modulen aufgebaut, unterscheiden sich aber jeweils durch die verbaute (physische) Modulvariante, wie die nachfolgende Grafik verdeutlicht.
Bei einer modularen Produktarchitektur würde es zur Definition des MVPs für die Winde ausreichen, die modulare Struktur des Produkts auszuarbeiten und für jedes Modul die einfachste Variante zu produzieren. Die einfachste Produktkonfiguration, die sich dabei ergibt, wäre demnach das MVP für die gesamte modulare Produktarchitektur. Für den agilen Entwicklungsprozess ergibt sich daraus, dass die Modulvarianten der ersten Produktkonfiguration zuerst entwickelt werden müssten, während alle weiteren Varianten später folgen.
Leseempfehlung: Einen detaillierten Überblick über modulare Methoden und Produktarchitekturen liefert Ihnen unser Blog-Artikel “Alles, was Sie zu Modularisierung wissen müssen".
Das Beispiel der Winde zeigt, dass eine modulare Produktarchitektur es ermöglicht, für ein variantenreiches Portfolio schnell ein MVP zu entwickeln, mit dem das Produkt als Ganzes mit den Stakeholdern validiert werden kann. Daraus lässt sich ableiten, dass Modularität eine zentrale Voraussetzung für erfolgreiche agile Entwicklung ist. Das gilt sowohl für Produkte im Bereich Elektronik und Mechanik als auch für Softwareprodukte und Produkte, die eine Kombination der drei Komponenten darstellen. Die Vorteile der Modularität für agile Entwicklung gehen jedoch über die Definition von MVP und MMP hinaus.
Leseempfehlung: Mehr zum Begriff der Modularität lesen Sie in diesem Beitrag. Detaillierte Ausführungen zum Thema Software-Modularität finden Sie hier.
Die Tatsache, dass in einem modularen Baukastensystem die einzelnen Module durch stabile, standardisierte Schnittstellen voneinander getrennt sind, macht es möglich, dass unterschiedliche Modulvarianten parallel von verschiedenen agilen Teams entwickelt und auch gleich getestet werden. Die Modulvarianten für die erste Produktkonfiguration müssen dabei zuerst entwickelt werden, da sie für die Erstellung des Minimum Viable Product notwendig sind. In welcher Reihenfolge die einzelnen Module des MVP entwickelt werden, können die Entwicklerteams dabei selbst entscheiden, um eine größtmögliche Effizienz zu gewährleisten.
Ausgehend vom Minimum Viable Product, also der ersten Konfiguration des modularen Produkts, können die Teams danach weitere Modulvarianten und Produktkonfigurationen entwickeln, die auf verschiedene Kundenbedürfnisse angepasst sind und unterschiedliche Marktsegmente bedienen. Das und die Tatsache, dass modulare Strategien auf die übergeordnete Unternehmensstrategie abgestimmt sind, sorgen dafür, dass das Unternehmen bestmöglich aufgestellt ist, um die Bedürfnisse und Anforderungen der Kunden sowohl in der Gegenwart als auch in der Zukunft optimal zu bedienen.
Mit Modularität und agilen Entwicklungsmethoden sind Unternehmen bestens auf die Zukunft vorbereitet
Agile Entwicklung ist auf dem Vormarsch, da sie mehr Flexibilität und eine höhere Entwicklungsgeschwindigkeit erlaubt als traditionelle Entwicklungsmethoden wie das Wasserfallmodell, welches sie längst abgelöst hat. In diesem Blog-Artikel haben wir uns die Ursprünge und Kernprinzipien agiler Entwicklungsmethoden angesehen und dabei auch verschiedene Vorurteile gegenüber agiler Entwicklung widerlegt. Darunter auch, dass agile Entwicklung keineswegs nur für kleine Teams geeignet ist, sondern dass sich die Prinzipien auch problemlos auf größere Unternehmen und die Entwicklung höchst komplexer Produkte übertragen lassen.
Ziel dieses Beitrags war es zu zeigen, dass agile Entwicklung trotz ihres ursprünglichen Fokus auf Software auch erfolgreich für Hardware-Produkte genutzt werden kann. In diesem Zusammenhang haben wir erläutert, dass die größte Herausforderung für das agile Entwickeln von Hardware in der Definition des Minimum Viable Product und des Minimum Marketable Product liegt. Ohne die Möglichkeit, das Produkt nach Verkauf und Lieferung aufzurüsten, wie es bei Software der Fall ist, ist das Erarbeiten eines MMP um einiges aufwendiger, da dieses bereits “mehr können” muss.
Gelöst werden kann dieses Problem durch eine modulare Entwicklung der Produkte. Modularität vereinfacht zum einen die Konfiguration eines MVP und ermöglicht zum anderen, dass Module unabhängig voneinander entwickelt und getestet werden können, wodurch verschiedene agile Teams parallel an der Entwicklung des Produkts und seiner verschiedenen Varianten arbeiten können.
In unserem Webinar "Entwicklung von Produktbaukästen mit agilen Methoden" führt Sie Roger Kulläng durch die Themen dieses Artikels und geht im Detail auf verschiedene Beispiele und die Anwendung von agilen Entwicklungsmethoden für Hardwareprodukte ein.
