Success Story: CI optimiert Embedded-Projekte

Die Firma stand vor mehreren Herausforderungen bei der Erstellung von mehreren C++-Applikationen und den dazugehörigen Yocto Linux Images. Die Build-Prozesse waren zeitaufwändig, wurden selten durchgeführt und waren aufgrund des lokalen Aufbaus auf den Arbeitsrechnern der Entwickler nicht reproduzierbar. Zudem war das Wissen um den Build-Prozess auf eine einzige, notorisch überlastete Person konzentriert, was zu einem hohen Bus-Faktor führte.

Ein weiteres Problem war die späte und seltene Integration. Fehler wurden erst kurz vor der Auslieferung entdeckt, was zu grossem Stress und entweder zu verspäteter oder fehlerhafter Auslieferung führte. Dieser ständige Druck sorgte dafür, dass die Entwickler keine Zeit hatten, um Verbesserungen vorzunehmen, was die Stimmung zwischen Entwicklung und Management belastete.

Die Entwickler selbst hatten viele Ideen zur Verbesserung, konnten diese aber nicht umsetzen, da ihnen die Zeit und der Raum dafür fehlten. Eine «Analysis Paralysis» trat ein – es gab den Drang, alle Anforderungen perfekt abzudecken, wodurch niemand vorwärtskam.

Um die Situation zu verbessern, habe ich einen Crash-Kurs zu Agilität, Komplexität und bewährten Vorgehensmodellen durchgeführt. Wir haben iteratives und inkrementelles Arbeiten besprochen und den Fokus auf kleine, machbare Schritte gelegt. Dabei wurde klar kommuniziert, dass das Ziel der Initiative darin bestand, den Single Point of Failure zu beseitigen, die Entwickler zu entlasten und den Stress kurz vor dem Release zu reduzieren.

Für die CI-Gruppe haben sich die Entwickler freiwillig gemeldet, darunter auch der Hauptträger des Yocto-Know-hows. Gemeinsam haben wir uns einen Überblick über die laufenden Projekte verschafft und entschieden, zunächst für ein einziges Projekt eine Build/CI-Pipeline aufzubauen.

Ich habe die zweiwöchentlichen Meetings organisiert und geleitet, in denen die Entwickler reflektierten und die nächsten Schritte planten. Die Zeit, um an der CI/Build-Pipeline zu arbeiten, nahmen sich die Entwickler jedoch selbst, indem sie sich bewusst aus dem Tagesgeschäft herauszogen. Ich unterstützte die Entwickler punktuell bei spezifischen Themen, um sicherzustellen, dass sie in den jeweiligen Bereichen Fortschritte machen konnten. Dabei wurde stets darauf geachtet, dass die Massnahmen bereits einen Mehrwert bieten und die Arbeit in Richtung des Endziels – einer automatisierten und reproduzierbaren CI-Pipeline – vorankommt.

In kurzer Zeit wurden signifikante Fortschritte erzielt. Die ersten Automatisierungen führten bereits zu einer deutlichen Entlastung der Entwickler, und die späte Fehlererkennung konnte durch häufigere Integration minimiert werden. Das Wissen wurde erfolgreich verteilt, und der Bus-Faktor wurde erheblich gesenkt. Langfristig führte dies zu weniger Stress und einer verbesserten Zusammenarbeit zwischen Entwicklung und Management.

Die externe Unterstützung hat sich als notwendig erwiesen, da die Beziehung und Kommunikation zwischen den Abteilungen festgefahren war. Durch meine Rolle als Entwickler konnte ich schnell Vertrauen aufbauen und die Beteiligten dazu bewegen, neue Arbeitsweisen auszuprobieren. Die Schaffung von Raum zur Selbstorganisation war entscheidend, und die Verantwortung für den Erfolg der CI-Initiative wurde von den Entwicklern bereitwillig übernommen.