mehr als bits und bytes

Man spricht von "Cyber-physical" im Zusammenhang mit einem Produkt oder einem System, welches nicht nur rein digitale Softwareanteile enthält, sondern wo es auch Hardware und Mechanik zu entwickeln gilt. Eine Smartwatch oder ein Fahrradcomputer sind hierfür Beispiele. Solche Produkte besitzen abgesehen von der Software, eine Elektronik mit beispielsweise Batterie, Controller und Display. Die Entwicklung der Mechanik ist insbesondere bei Outdoor-Produkten ebenso eine Herausforderung. Das Zusammenspiel dieser Disziplinen beeinflusst viele Produktmerkmale, darunter auch das Produktdesign, das immer wichtiger wird und zusätzlich zu den Funktionen ein weiteres wichtiges Merkmal bei der Kaufentscheidung darstellt. Ein kleineres Gehäuse kann die Temperatur im Inneren erhöhen oder eine kleinere Batterie notwendig machen. Eine kleinere Batterie kann wiederum die Software dazu zwingen, sich öfter in den Ruhezustand zu versetzen.

Wenn diese Disziplinen zeitlich und inhaltlich zu synchronisieren sind, muss man die Unterschiede verstehen. Es geht also nicht nur um Bits um Bytes, sondern unter anderem auch um Widerstände, Leiterbahnen, ein Gehäuse und Schrauben.

alles agil?

Spricht oder liest man über agile Entwicklung werden oft rein digitale Anwendungen referenziert. Das kann eine Cloud-Anwendung oder eine Smartphone-App sein. Die Rahmenbedingungen, welche hier gelten, sind ideal, um schnell und iterativ Features zu entwickeln, zu erproben und zu verbessern. Man beginnt damit ein Backlog zu erarbeiten, zu priorisieren, ein MVP [1] zu definieren und arbeitet sich Sprint für Sprint dem Release entgegen. Ist ein MVP erst einmal beim Kunden, werden kontinuierlich Verbesserungen oder Erweiterungen schnell und direkt ausgeliefert.

Die Welt der Hardware und Mechanik ist anders getaktet. Auch hier ist ein agiles Vorgehen eine Option. Es gibt Beiträge in der Literatur hierzu, wie man auch die Hardware so modular entwickeln kann, dass einzelne Subsysteme iterativ und unabhängig voneinander verbessert und getestet werden können. Dennoch sind Overhead und Mehrkosten dem Benefit gegenüberzustellen. In jedem Fall ist der benötigte Vorlauf deutlich größer. Eine Platine ist nicht so schnell neu bestückt oder ein Gehäuse mit geändertem Werkzeug neu gegossen wie ein konstanter Wert in der Software geändert. Es ist eine andere Planung notwendig.

Die meisten Softwareprojekte, in denen die Umfänge noch nicht zu Beginn klar sind, werden mit agilen Methoden entwickelt. Die Hardware und Mechanik werden häufig im V-Modell definiert, entwickelt und getestet. Das funktioniert sehr gut. Spannend wird es da, wo diese Welten aufeinandertreffen. Zum Beispiel wenn die Hardware einen Bootloader benötigt, der bereits in der Produktion zur Verfügung stehen muss. Das ist ein klassisches Beispiel. Hier gilt es den Spagat zu schaffen, um das Produkt erfolgreich auf den Markt zu bringen.

die gesamtperspektive ist entscheidend

Man kann versuchen eine Disziplin in die jeweils andere Welt zu überführen. Die Hardware kann man beispielsweise, statt im V-Modell, agil von Sprint zu Sprint entwickeln. Das kann Vorteile haben. Man kann zu diesem Zweck beispielsweise das Hardwaredesign aufspalten und, statt alle Subsysteme auf einer Platine unterzubringen, über zusätzliche, im endgültigen Produkt nicht mehr vorhandene, Schnittstellen entkoppeln. Eine Änderung in einem Subsystem lässt sich auf diesem Wege besser isolieren. Je nach Problemstellung stehen die Vorteile aber in keinem guten Verhältnis zu dem Mehraufwand und den Mehrkosten. In solchen Fällen ist es effektiver, sich die Anforderungen an den Berührungspunkten der Disziplinen genauer anzusehen.

Was brauchen Hardware und Mechanik von der Software? Wann ist der Bootloader erforderlich und mit welchem Funktionsumfang? Was ist für den EMV-Test [2] notwendig? Viele derartige Fragen gilt es zu stellen und zu beantworten. Dabei orientiert man sich an der Disziplin, welche einen längeren Vorlauf benötigt. Das bedeutet konkret, es werden die Softwareanteile identifiziert, welche für die anderen Disziplinen unerlässlich sind, und priorisiert die entsprechenden Arbeitspakete so, dass die richtigen Sprint-Inkremente der Software auf die Meilensteine der Hardware und Mechanik fallen.

Das klingt zunächst einfacher als es ist. Auf jeden Fall erfordert es ein Verständnis der Gesamtarchitektur des Produktes, um die Abhängigkeiten zwischen Software und Hardware zu identifizieren und sehr früh zu definieren. Kennt man die Inhalte, müssen auch diese Aufwände geschätzt werden. Zu berücksichtigen ist hier allerdings, dass die Velocity des Teams über die Zeit schwankt und diese identifizierten Arbeitspakete weiter in der Zukunft liegen können. Eine Verfolgung des Fortschritts im Sinne von “Inspect & Adapt” sowie eine flexible Planung ist dadurch umso wichtiger. Ein cross-funktionales Team, welches die Zusammenarbeit zwischen den Disziplinen Software, Hardware und Mechanik vereinfacht und Silos verhindert, ist neben dem Blick auf die Gesamtarchitektur ebenfalls eine Grundvoraussetzung für das Gelingen.

Natürlich kann ein solcher kurzer Blog-Beitrag die relevanten Themen nur anreißen. Die Kombination dieser unterschiedlichen „Welten“ ist und bleibt eine Herausforderung. Man sollte sich aber stets bewusst sein, dass es eben um mehr als Bits und Schrauben geht, sondern eben auch um ein cross-funktionales Team, vorausschauende Planung, Architekturverständnis und ganz viel Erfahrung, Architekturverständnis und ganz viel Erfahrung.

Informationen:

Kategorien

Themen