18. November 2015

Agile Elektronik-Entwicklung

Agile Elektronik-Entwicklung bewegt sich in einem Umfeld, in dem bewährte agile Konzepte wie Scrum oder Kanban nicht eins zu eins angewendet werden können. Die drei größten Herausforderungen sind in der Regel:

  • eine hohe Abhängigkeit der Anforderungen untereinander
  • hohe Transaktionskosten zum Erstellen eines Relases
  • Abhängigkeiten von internen oder externen Zuliefereren wie z.B. Layout, EMV-Labor, Musterbau

Dennoch kann auch die Hardware-Entwicklung von Scrum, Kanban und Co profitieren. Im Folgenden ein paar Gedanken dazu aus meiner Erfahrung in der agilen Mechanik- und Elektronik-Entwicklung:

Scrum oder Kanban?

Der grundsätzliche Unterschied: Scrum liefert ein agiles Framework für den Einsatz im komplexen Business. Ich empfehle Scrum im Umfeld in denen das Geschäftsmodell oder die Technologie sich erst im laufe der Projekte ergeben, also im innovativen Umfeld.

Kanban hingegen ist zunächst einmal noch nicht agil, Ihr könnt es als Lean Development betrachten. Kanban hilft dabei Aufgaben in Prozessen schnell und im gleichmäßigen Fluss abzuarbeiten. Kanban kann agil gemacht werden, wenn Aspekte wie Teamwork, Einbindung des Kunden, Kadenz, Feedback hinzugefügt werden. Das ganze kann unter Umständen auch eine hohe Änlichkeit zu Scrum entwickeln. Kanban hat der Vorteil, dass die Einführung “sanft” geschieht, auf der Basis von bestehenden Prozessen und Rollen.

Kanban eignet sich auch dazu bestehende Lieferantenverbindungen in Organisationen transparent zu machen. Im Gegensatz zur Software-Entwicklung kann ein Team in der Elektronik-Entwicklung im Normalfall nicht das komplette Produkt selbst herstellen, sondern ist wie oben beschrieben auf Musterbau, Messlabore und zentrale Experten.

Was ist ein Release?

Während die Kolleginnen und Kollegen in der Software vielleicht sogar jede Woche ein Release veröffentlichen, sind wir in der Elektronik-Entwicklung von mehreren Seiten eingeschränkt:

  • Es ist nicht mögich einzelne Anforderungen zu releasen
  • Das Release kann nicht vom Team autark erstellt werden
  • Die Transaktionskosten und -zeiten sind im Vergleich zur Software sehr hoch (Tests sind aufwändig und teuer, Muster müssen aufgebaut werden, inkl Beschaffung von Leiterplatte und Bauteilen, usw. )

Dennoch ist es, egal ob mit Scrum oder Kanban, wichtig, regelmäßig ein Release zu liefern um Feedback zu bekommen und Driften von Projektattributen einzufangen. Bei Scrum sind das Sprints, bei Kanban wird es als Kadenz bezeichnet. Hier ist es hilfreich, verschiedene Level für Releases zu definieren. Ein Release für eine Elektronik kann auch ein Konzept sein, ein Schaltplan, eine Simulation, ein Test, oder eben im Idealfall ein bestücktes und getestetes Board. Der Katalog an möglichen Releases (hier im Sinne von “Reifestufen”) sollte im Vorfeld definiert sein anstatt den Begriff “Release” ad hoc zu definieren.

Umgang mit Schnittstellen

Je mehr Kompetenz im Team selbst ist, desto besser. Selbstverständlich sollten wir nur von “Team” reden, wenn alle Mitglieder auch in einem Raum sitzen und die Kommunikationswege entsprechend kurz sind. Die Bedeutung von schnellen Lieferzeiten der internen und externen Zulieferer sollten nicht unterschätzt werden. Express-Zuschläge (externe Zulieferer) oder ausreichend Kapazität (interne Zulieferer) sind in der Regel gut investiertes Geld. Mehr zu diesem Thema findet Ihr auch in meinem Artikel “Mythos Vollauslastung“.

Für die Schnittstellen die parallel Entwickeln, wie Software oder Mechanik, muss ein gemeinsamer Takt gefunden werden in dem die Ergebnisse zusammengeführt werden und die Entwicklung synchronisiert wird. Wieder das Thema Kadenz. Meist liefert die Software in den kürzesten Zyklen aus und bildet damit den Grundtakt. Kadenzen oder Sprints von Elektronik, Mechanik, Integration und Test sollten ein vielfaches der Software-Zyklen sein.

Was fehlt der agilen Elektronik-Entwicklung?

Wenn wir unseren Fokus auf Scrum oder Kanban belassen, entgehen uns wichtige Bausteine für eine schlagkräftige agile Elektronik-Entwicklung. Folgende Aspekte halte ich für sehr wichtige Ergänzungen zum verwendeten agilen Kernansatz:

  • Einsatz der Warteschlangentheorie zur Prozesssteuerung und Absicherung von Lieferzeiten
  • Einsatz von Critical Chain Konzepten zum Management von Multiprojektumgebungen
  • Kalkulation oder Schätzungen zu Verzögerungskosten um betriebswirtschaftlich sinnvolle Vorgaben bezüglich Durchlaufzeit und damit Werkzeugen, Zulieferungen und Auslastung machen zu können.

Dies nur als kurzer Überblick, in meinem Artikel “Kanban in der Produktentwicklung” findet Ihr weitere Informationen zu diesen Punkten

Mein Fazit

Agile Elektronik-Entwicklung ist möglich und wird auch erfolgreich eingesetzt. Agilität bringt auch hier viele Vorteile hinsichtlich Durchsatz, Transparenz und Motivation. Aus der Transparenz ergibt sich wiederum die fortlaufende Verbesserung der Arbeitsabläufe und Werkzeuge. Ich habe schon mehrere Projekte mit verschiedenen Ansätzen zur agilen Elektronik-Entwicklung begleitet. Der konkrete Ansatz ergibt sich immer in der Diskussion mit dem Team und dem Management. Die Themen die aber immer auftreten habe ich oben auszugsweise dargestellt, ich hoffe der eine oder ander Punkt konnte Euch ein wenig inspirieren.

Lesefutter

Neben den oben verlinkten Themen ist vielleicht noch interessant:

Blog-Beitrag zu Kanban in der Embedded-Entwicklung

Mein Kanban-Training

Workshops und Trainings und Vorträge des agilen Automotive Teams

 

Ähnliche Beiträge

Automotice SPICE & Scrum: SYS.2/SWE.1 System/Software Requirements Analysis

Automotice SPICE & Scrum: SYS.2/SWE.1 System/Software Requirements Analysis

Automotive SPICE & Scrum: SYS.1 Requirements Elicitation

Automotive SPICE & Scrum: SYS.1 Requirements Elicitation

Automotive SPICE & Scrum: MAN.3 Project Management

Automotive SPICE & Scrum: MAN.3 Project Management

Automotive SPICE & Scrum: Einführung

Automotive SPICE & Scrum: Einführung