Noch mehr Tipps für agile Hardware-Entwicklung
Teil 4 der Serie: Status Quo agile Hardware-Entwicklung Ganze Serie
"Der Mann, der einen Berg versetzt, beginnt damit, kleine Steine wegzutragen." — Konfuzius (chinesischer Philosoph)
Am 29.10.2025 habe ich zusammen mit Dr. Tobias Kästner von inovex Gmbh einen Vortrag über Agile Hardware-Entwicklung: Status Quo auf der Konferenz Power of Electronics (hervorragend organisiert von Elektronik-Praxis) im wunderschönen Würzburg gehalten. Am 4.12.2025 habe ich einen ähnlichen Vortrag zusammen mit Christoph Schmiedinger von Die Umsetzer GmbH auf dem ESE-Kongreß für embedded software engineering in Sindelfingen gehalten (mit einer etwas anderen Präsentation).
Hier findet ihr Teile unserer Präsentation. Für die wunderschönen Ukiyoye-Bilder habe ich Gemini von Google physisch in einem Nebenzimmer manifestiert und ihn/sie/es dann gezwungen, mir diese Bildchen zu malen. Los geht's:
Nachdem wir in den ersten Teilen dieser Serie den Status Quo angeschaut haben und resümierten, woran es bei der Umsetzung agiler Hardware-Entwicklungen oft hapert, haben wir im dritten Teil einige Quick Wins vorgeschlagen. Die sollen euch helfen, damit es in euren Projekten gleich gut läuft. In diesem Teil folgen nun noch einige Hinweise aus der Praxis für die Praxis: noch mehr Tipps aus unseren Projekten, was besonders gut lief und dem Team viel brachte.
Wichtig ist, zu verstehen, dass agil vorzugehen in bestimmten Situationen besonders gut ist. Wir haben das mal in dieser Graphik dargestellt:
Wenn man nicht viel weiß, was mögliche Endanwender mögen oder wollen, und wenn man auch noch nicht viel über die zu verwendenden technologischen Lösungen weiß (weil die sich heutzutage so schnell entwickeln und ändern), dann passen agile Vorgehensweisen immer gut, um schnell durch den Raum der Lösungen zu iterieren. Ist beides bekannt, kann man agil vorgehen, muss aber nicht. Ist beides Neuland, ist agil u.U. auch nicht besonders gut geeignet, denn dort wohnt Chaos und Drachen und so Zeugs.
Continous Integration bei Hardware möglich?
Wir haben in gemischten Teams viel gelernt, von den Arbeitsweisen der anderen Fachleute. Welche Tools Software-Leute verwenden, und wie viele und was man alles mit Software-Tools automatisieren kann, das war schon beeindruckend für uns Hardware-Leute.
- Software-Praktiken übernehmen (und vorher mal schauen: für fast alles, was man denkt, gibt es bereits Tools)
- Fokus auf automatisieren (per CLI: Tests durchführen, täglich Doku erstellen, Versionierung)
- frühe Fehler-Erkennung durch frühes, am besten automatisiertes Testen
- Design-Artefakte für alle lesbar und aktuell (lesbar für Mensch und Maschine)
Konfigurationsmanagement
Früher haben wir unsere Versionen anders benannt und behandelt, gerne mit großen Buchstaben und so. Heute verlassen wir uns hauptsächlich auf Git:
- Manuelle Revisionsnummern sind Mist
- Lösung: Versionskontrolle à la Software (z.B. Git)
- Git-SHA1 im Kupfer auf Platine verlinkt direkt zum korrekten Schaltplan
Und dazu ein Hinweis: offene Text-Formate für Design-Dateien wie z.B. in KiCAD sind besser für textbasierte Versionierungstools wie git, als z.B. proprietäre Datenformate wie bei Altium.
Für mehr Verständnis: Style Guide für Stromlaufplan
Damit in einem gemischten, agilen Team auch alle z.B. den Stromlaufplan verstehen, haben sich Style Guides bewährt. Wir haben zum Beispiel einen für Stromlaufpläne entwickelt.
- Style Guides verbessern Verständnis UND Schönheit
- schon mal auf eigenen Stromlaufplan 3 Monate später geschaut und nix gerafft?
- z.B. lieber mehrere A4-Blätter für verschiedene Funktionalitäten
- z.B. Input von links, Output nach rechts
- z.B. Versorgung oben, GND unten
- Spannungsangabe: min, normal max (Vbatt = (3.0, 3.6, 4.1) V
- u.v.m. ABER das Team entscheidet!
Siehe dazu auch unseren Blogpost über Style Guide für Stromlaufplan.
Open Source ausprobieren
Viele proprietäre Werkzeuge sind sehr gut, logischerweise. Trotzdem erzeugen die damit verbundenen hohen Kosten oft Expertentum, was sofort zu Flaschenhälsen im Prozessablauf führt. Oder die Unternehmen wollen die teuren Lizenzen voll auslasten, was dann ebenfalls Flaschenhälse erzeugt. Daher vielleicht mal Open-Source ausprobieren, die oft kostenfrei ist, und für viele Anforderungen (wenn auch nicht immer alle) ausreicht.
- kommerzielle Werkzeuge ➜ oft unflexibel
- Vorteil von Open-Source (OS): anpassbar, erweiterbar und Daten interpretierbar
- Quelloffenheit und Community ➜ Lösungen oder Integrationen (z.B. KiCad)
- Niederschwelliger Zugang (und übrigends: umso älter, umso besser dokumentiert für KI-Nutzung)
- Praxisbeispiel: eigene Skripte fürs Einfügen von Git-SHA1 in Produktionsdaten
Vielleicht auch Teile oder ein ganzes Projekt selber als Open Source Hardware veröffentlichen? Wir haben den Eindruck, da lernt man so einiges, welche Anforderungen andere an Stromlaufpläne, Design, Dokumentation haben beispielsweise.
Reifegradmodelle hinterfragen
Auch das scheint uns wichtig: das Hinterfragen von Vorgehensweisen, wenn möglich. Nicht immer geht das, aber wenn, bringt es sicherlich was, so unsere Erfahrung:
- Klassische Reifegradmodelle (V-Modell) sind dokumentengetrieben und oft realitätsfern
- Idee: Reifegrad "funktionsgetrieben" aus Anwendersicht messen
- Standardisierte Reifegrade für einzelne, modulare Funktionen definieren und tracken
- erfordert modulares Design, bei dem Module Funktionen unabhängig voneinander realisieren können
Fazit
Unser Fazit lautet:
- agil ist nicht nice-to-have, sondern in unserer Welt überlebenswichtig
- Keine Zeit verlieren ➜ startet noch heute mit agiler Hardware-Entwicklung
Download des Whitepapers
Dies ist Teil 4 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 fertig und kann gedownloaded werden. Es ist eine Zusammenarbeit von: