Agile (Hardware-)Entwicklung

Vor einiger Zeit bin ich gefragt worden, ob ich mich mit agiler Hardware-Entwicklung auskenne, oder ob wir sogar agile Hardware-Entwicklung betreiben und entsprechende Tools und Prozesse kennen. Wie jeder weiß, der in der Entwicklung tätig ist, ist „agil“ zurzeit in Mode und möglichst jede Entwicklungsabteilung und jedes Entwicklungsprojekt soll agil sein oder werden.

Was sind die Hoffnungen hinter dem Trend zur Agilität?

Wikipedia hat einen Artikel zur agilen Software-Entwicklung (https://de.wikipedia.org/wiki/Agile_Softwareentwicklung). Darin heißt es:

Das Ziel agiler Softwareentwicklung ist es, den Entwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen […].

Indem man ein Produkt agil entwickelt, hofft man den Entwicklungsprozess flexibler und schlanker zu machen, und damit also folgendes zu erreichen :

• wertvollere Produkte
• kürzere Entwicklungszyklen
• frühe und kontinuierliche Wertschöpfung
• lernende Organisationen
• begeisterte Kunden und Mitarbeiter

aus https://www.it-agile.de/wissen/einstieg-und-ueberblick/was-ist-agile-produktentwicklung/, einer der ersten Treffer bei Google zu agiler Entwicklung

Diese Punkte können als Optimierung der drei Faktoren Kosten, Zeiteffizienz und Qualität betrachtet werden. Natürlich wünscht man sich eine Optimierung aller drei Faktoren, was nicht selten zu Widersprüchen führt.

Weiterhin besteht der  Wunsch, die Planung und die Spezifikation nicht schon zu Projektbeginn zu verfassen, sondern Planung- und Entwicklungsphase parallel verlaufen zu lassen. Besonders zu Beginn des Projektes gibt es offene Punkte, deren Bearbeitung erst während der Entwicklung des Projektes möglich wird. Manche Spezifikation erweist sich auch erst nach den Tests als unhaltbar und mit zunehmender Projektlaufzeit treten  umso mehr Änderungswünsche und Ideen treten auf. Beispielsweise kann man von ungefähr 5% Änderung der Anforderungen pro Monat ausgehen.  Der Wunsch, dass die Spezifikationen erst später definiert werden, ist also nachvollziehbar.

Schließlich zeichnet sich  agile Entwicklung durch frühere und häufigere Lieferung im Vergleich zur klassischen Entwicklung aus, was entsprechend frühere Untersuchungen und Rückmeldungen ermöglicht. Dies klingt erstmal sinnvoll. Das Problem bei vielen Projekten, die nicht perfekt laufen, ist aber nicht fehlende Rückmeldung oder späte Lieferung, sondern dass kritische und warnende Stimmen nicht gehört werden. Erfahrene Entwickler liefern wertvolle Meinungen, Vorschläge und Feedback zu den Produkten, aber sie müssen auch gehört werden. Werden die falschen Parameter gemessen oder wird den Entwicklern kein Gehör geschenkt, dann verpasst man das Feedback. Das erfordert viel Feingefühl und Aufmerksamkeit bei den Projektverantwortlichen.

Besonders interessant finde ich, wie die „agile“ Bewegung entstand. Daraus kann man dann auch auf die Anwendung in der Hardware und den eigenen Projekten schließen.

Das agile Manifest

Der Begriff “agil” kommt aus der Software-Entwicklung und wurde bei einem Treffen von Software-Entwicklern in Utah im Jahr 2001 geprägt. Davor war der Begriff „lightweight“ für diese Prozesse und Methoden üblich, da klingt “agile” natürlich besser. Wer möchte schon als  „Leichtgewicht“ bezeichnet werden? :). Agil klingt besser und diese Entscheidung hat sicher auch zur Verbreitung beigetragen. Die Entstehung ist sehr schön beschrieben auf der Web-Seite des agilen Manifests.

In ihrem Manifest haben die Teilnehmer hehre Ziele formuliert. Wenn man diese Ziele liest, dann wünscht man sich nichts anderes für jede Art von Entwicklung. Und da man diese Ziele nicht oft genug lesen kann und das agile Manifest außerhalb der Software-Szene vielleicht auch nicht so bekannt ist, werden sie hier nochmal aufgeführt:

Manifest für Agile Softwareentwicklung

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.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

 

Prinzipien hinter dem Agilen Manifest

Wir folgen diesen Prinzipien:

• Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
• Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen  Veränderungen zum Wettbewerbsvorteil des Kunden.
• Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
• Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
• Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
• Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
• Funktionierende Software ist das wichtigste Fortschrittsmaß.
• Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
• Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
• Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
• Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

 

Was bedeutet das für die Hardware-Entwicklung?

Lassen wir die Sätze kurz wirken und jeder kann sich überlegen, ob diese Prinzipien in seinem Projekt umgesetzt werden.

Grundsätzlich kann man in den Prinzipien das Wort Software auch durch Hardware (oder Mechanik, oder System) ersetzen. Natürlich hat Hardware oder auch Mechanik einige Besonderheiten, die sie von Software unterscheidet. Aber die meisten agilen Prinzipien sind allgemeingültig und auf jeden Fachbereich anwendbar. Jedes Entwicklungsprojekt wird davon profitieren und sollte diese Prinzipien beherzigen, egal ob man dann noch ein agil davorsetzt oder nicht. Der Punkt „Liefere funktionierende Software regelmäßig (…) und bevorzuge dabei die kürzere Zeitspanne“, kann auch in der Hardware- und Mechanik-Entwicklung beherzigt werden und gewinnt durch neue  Prototyp-Verfahren wie 3D-Druck und den Leiterplattenschnelldiensten an Bedeutung.

Schlussbemerkung

Um auf die Ausgangsfrage  zurückzukommen: Ja, wir kennen uns mit agiler Hardware-Entwicklung aus, und versuchen die Prinzipien des agilen Manifests in unserer Arbeit umzusetzen. Dasselbe würde ich jedem empfehlen, der selbst in Entwicklungsprojekten tätig ist.

Das wichtigste sind die Prinzipien; die Tools ändern sich. Ob man Kanban oder Scrum nutzt, wie schnell man die Leiterplatten bestellt und wieviel man in der Simulation entwickelt, darüber lässt sich streiten. Ich freue mich über Diskussion, Kommentare und eigene Erfahrungen mit Agilität in der Hardware-Entwicklung.

Viele Grüße,
Martin Bosch

 

Links:

[1] http://agilemanifesto.org

Kontaktieren Sie uns!