Woran es hapert bei agiler Hardware-Entwicklung
🔧⚡ Teil 2 der Serie: Status Quo agile Hardware-Entwicklung 🗂️
Eine Blogserie über aktuelle Probleme und bewährte Lösungen in der agilen Hardware-Entwicklung
Stolpersteine beim agilen Entwickeln von Hardware
Schauen wir uns mal an, was wir (die Autoren, s. unten) während unserer Arbeit so erleben, wenn es um agile Hardware-Entwicklung geht. Spoiler-Alarm: Da ist noch viel Luft nach oben!
Problem 1: Jeder kocht sein eigenes Süppchen
Das kennen wir eigentlich alle: Hardware-Entwickler sitzen in ihrem Team, Software-Entwickler in ihrem. Kommunikation? Findet statt, wenn mal jemand Lust drauf hat oder wenn's brennt. Oft arbeiten die Teams sogar mit komplett verschiedenen Pflichtenheften und Verträgen.
Was dabei schiefgeht:
- Die Pflichtenheft-Autoren reden nicht miteinander (klassisch!)
- Software-Parameter werden erst spät festgelegt
- Für Hardware-Prototypen gibt's keine Test-Software → das SW-Team muss spontan welche basteln
- Die "echte" Software läuft erst kurz vor Serienfertigung auf echter Hardware → Hardwarefehler zu beheben wird richtig teuer
- Hardware-Tests bekommen nur Feedback von anderen Hardware-Nerds, nie von echten Endnutzern
- Software-Teams müssen erstmal ewig suchen, wo sie überhaupt Infos über die Hardware finden (Versorgungsspannungen, Datenbusse, wo ist nochmal diese LED?)
Problem 2: Hardware zuerst, Software später (oder: das Wasserfall-Drama)
Durch die Team-Trennung entsteht ein Teufelskreis: Alle machen alles schön der Reihe nach. Erst Hardware, dann Software. Klingt logisch? Ist es aber nicht!
Der typische Ablauf:
- Hardware wird bis zum letzten MCU-Pin durchgeplant
- Monatelange Realisierung und Inbetriebnahme der kompletten Hardware
- Tests laufen von Hand (zeitintensiv und lückenhaft)
- Software-Support kommt mit massiver Verspätung
- Hardware-Regressionen werden viel zu spät entdeckt
Das Hauptproblem: Hardware braucht Software zum Testen, Software braucht Hardware zum Experimentieren. Ein klassischer Deadlock!
Der Psycho-Effekt: Weil alle wissen, dass Hardware-Entwicklung ewig dauert, wollen alle ihre Wünsche SOFORT in das erste Release reinpacken. Niemand will zweimal so lange warten. Das Ergebnis? Noch mehr Arbeit, noch längere Wartezeiten.
Problem 3: Teure Tools schaffen teure Probleme
Altium Designer, Mentor Expedition u.a. sind mächtige Tools - aber auch ziemlich speziell. Insbesondere in agilen Projekten schaffen sie unter Umständen Probleme:
- Teure Lizenzen → führen zu hoher Auslastung und Expertentum → Bottlenecks garantiert!
- Proprietäre Dateiformate → nur das Original-Tool kann die Daten (fehlerfrei) lesen
- Keine Transparenz → Arbeitsergebnisse sind nur für Experten sichtbar
- Spätes Feedback → andere Teammitglieder können erst spät (oder gar nicht) mitreden
- Keine Automatisierung → grafische Oberflächen verhindern automatische Builds und Skripte
Problem 4: Der Experten-Kult
Wenn Tools teuer sind, entstehen Flaschenhals-Experten. Und diese Experten entwickeln mit der Zeit eine interessante Beziehung zu ihrem Spezialwissen und ihrem Status. Der eigene Wert wird am Expertenwissen gemessen. Der Teilschritt wird vom Mittel zum Zweck zum Selbstzweck.
Die Folgen:
- Besitzstandswahrung
- Ablehnung von Änderungen
- Hardware-Entwurf liegt bei einer Person
- Gefühl der Unersetzlichkeit (und die Angst, doch ersetzt zu werden)
Zan Lazarevic auf Unsplash
">
Problem 5: Wenn andere Abteilungen nicht mitspielen
Agile Entwicklung scheitert oft an den Schnittstellen zu anderen Unternehmensbereichen. Klassisches Beispiel: Der zentrale Einkauf.
Das Szenario: Entwicklung braucht schnell ein Bauteil für Tests. Einkauf wird aber daran gemessen, günstig einzukaufen - und schnell ist selten günstig. Ergebnis: Das ganze Team wartet tagelang auf ein 5€-Bauteil.
Das Grundproblem: Isolierte Anreizsysteme, die nicht auf die unterschiedlichen Bedürfnisse von agiler Entwicklung vs. Serienproduktion eingehen. Ausserdem: fehlende Kommunikation und Verständnis rund um Agilität?
Problem 6: Kosten über alles (auch über Flexibilität)
Zu oft, so finden wir, herrscht die Mentalität:
"Herstellungskosten müssen um jeden Preis minimal sein!"
In einer statischen Welt funktioniert das. Aber wir leben nicht in einer statischen Welt.
Was dabei verloren geht:
- Flexibilität für späteren erweiterten Funktionsumfang
- Kapazitätsreserven bei Mikrocontroller, Speicher oder Datenbus
- Möglichkeit, auf Marktveränderungen zu reagieren
Aber Vorsicht: Wir wollen auch nicht alles überdimensionieren und am Ende ein zu teures Produkt haben. Es geht um die richtige Balance!
Weiteres Beispiel: Statt lokale Lieferanten früh einzubinden und von ihrer Erfahrung zu profitieren, wird auf "austauschbare" Lieferanten gesetzt. Vertrauen und enge Zusammenarbeit? Fehlanzeige.
Problem 7: Der totalspezifizierte Anfang
Hardware- und Software-Projekte starten meist mit vollständigen Lasten- und Pflichtenheften. Klingt professionell, führt aber zu:
- wenig agilen, weil ewigen Planungsphasen vor dem ersten Prototyp
- Riesigen Arbeitslasten bevor überhaupt getestet werden kann
- Spätem Feedback von Endnutzern
- Teurem Wissen über Funktionen, die keiner braucht
Das waren die häufigsten Stolpersteine, die wir in der Praxis antreffen. Im nächsten Teil schauen wir uns an, wie es besser geht!
Dies ist Teil 2 unserer Serie über agile Hardware-Entwicklung. Hier findest du alle Artikel der Serie. In einer losen Serie wollen wir zeigen, wo wir aktuelle Probleme sehen und welche Lösungen wir schon gefunden haben. Die Inhalte sind aus einem Whitepaper abgeleitet, an dem wir mitgewirkt haben. Das Whitepaper ist fast fertig und ist eine Zusammenarbeit von: