Leuchtturmprojekt Docs-as-Code im Defence-Bereich
Bei einem Tier-1-Zulieferer im Defence-Bereich hat ein Software-Team mit 40 Leuten gezeigt, dass Docs-as-Code funktioniert und die Arbeit effizienter macht – mit Sphinx-Needs, ubCode, CI und eigenem Firmen-Branding.
- Branche
- Defence, Tier-1-Zulieferer, Software-Entwicklung
- Team
- Software-Entwicklungsteam mit 40 Leuten
- Zeitraum
- 2026
- Meine Rolle
- Beratung, Umsetzung und Training
Problem
Ein Tier-1-Zulieferer im Defence-Bereich wollte wissen, ob Docs-as-Code zu seiner Software-Entwicklung passt. Ein Leuchtturmprojekt sollte zwei Fragen beantworten: Ist es machbar, und wird die Arbeit dadurch spürbar effizienter?
Der Nachweis musste belastbar sein, denn er sollte als Grundlage für weitere Entscheidungen dienen.
Was wir gemacht haben
Mit einem Software-Team aus 40 Leuten habe ich Docs-as-Code mit Sphinx-Needs und ubCode von useblocks umgesetzt. Ein CI-System baut und prüft die Dokumentation bei jeder Änderung.
HTML- und PDF-Ausgaben tragen das Branding des Unternehmens, sodass die Dokumente direkt in die gewohnte Unternehmenswelt passen. Die bestehenden Workflows haben wir nur leicht angepasst, damit das Team ohne großen Umbruch umsteigen konnte. Trainings haben den Einstieg begleitet.
Ergebnis
Das Leuchtturmprojekt hat gezeigt, dass Docs-as-Code im Defence-Umfeld machbar ist und die Arbeit effizienter macht – nachvollziehbar belegt statt nur behauptet.
Eingesetzte Tools: Sphinx-Needs
Feature-Planung mit Sphinx-Needs
Bei useblocks läuft die Bedarfsplanung für Produkt-Features in Sphinx-Needs – vom Kundenwunsch über das Problem bis zum Feature, zur Roadmap und zu den Aufgaben der Entwicklungsteams.
- Branche
- Software-Tools, useblocks (intern)
- Zeitraum
- 2025–2026
- Meine Rolle
- CPO und Product Owner einer Software-Lösung
Problem
Kundenwünsche kommen über viele Wege: aus Projekten, Gesprächen, Supportanfragen. Schnell geht dabei verloren, woher ein Wunsch kam, welches Problem dahintersteckt und was am Ende daraus geworden ist.
Für die Produktplanung bei useblocks brauchte es einen Ort, an dem Wünsche, Probleme und Features zusammenhängen – nachvollziehbar vom ersten Kundengespräch bis in die Entwicklung.
Was wir gemacht haben
Ich habe die Bedarfsplanung mit Sphinx-Needs aufgebaut. Kundenwünsche, Probleme und Features sind eigene Objekte, die miteinander verlinkt sind. Ein Workflow regelt, wie ein Wunsch geprüft, einem Problem zugeordnet und in ein Feature überführt wird. Ein CI-System baut und prüft das Ganze bei jeder Änderung.
Features werden aus Sicht der Nutzenden beschrieben: Wer braucht was, und warum? Von dort werden sie heruntergebrochen und in Aufgaben für die Entwicklungsteams abgeleitet. Aus denselben Daten entstehen die Feature-Roadmaps.
Ergebnis
Jeder Kundenwunsch ist nachverfolgbar: welchem Problem er zugeordnet ist, welches Feature ihn löst und wann es kommt. Die Entwicklungsteams sehen, warum sie etwas bauen, und die Roadmap bleibt mit den Wünschen dahinter verbunden.
Eingesetzte Tools: Sphinx-Needs
Bestandsdaten in Docs-as-Code überführt
Machbarkeitsnachweis bei einem Tier-1-Zulieferer: Anforderungen, Spezifikationen, Code und Tests eines Steuergeräte-Projekts laufen in einer Docs-as-Code-Toolchain – und das Modell wurde danach im ganzen Unternehmen ausgerollt.
- Branche
- Automotive, Tier-1-Zulieferer, Steuergeräte-Entwicklung
- Team
- Projekt mit ca. 500 Leuten; Machbarkeitsnachweis mit 3 Leuten und ca. 40 Nutzern
- Zeitraum
- 2025
- Meine Rolle
- Beratung und Umsetzung
Problem
Ein Steuergeräte-Projekt mit rund 500 Leuten hatte über Jahre Daten in klassischen Werkzeugen angesammelt: Software-Anforderungen, Spezifikationen, Code und Tests – getrennt voneinander gepflegt und schwer zu verbinden.
Docs-as-Code klang vielversprechend. Offen war aber, ob es mit echten Bestandsdaten und den Anforderungen eines Automotive-Projekts funktioniert. Bevor das Unternehmen umstellen wollte, brauchte es einen Beweis.
Was wir gemacht haben
In einem Machbarkeitsnachweis haben wir mit einem Team aus 3 Leuten die Bestandsdaten in eine Docs-as-Code-Toolchain von useblocks überführt: Software-Anforderungen, Spezifikationen, Code und Tests, verlinkt und nachvollziehbar in einer Dokumentation.
Rund 40 Nutzer haben im echten Projektalltag damit gearbeitet. Für die Hardware-Anforderungen haben wir ein Konzept erstellt, wie sie in dieselbe Struktur passen.
Ergebnis
Der Nachweis hat funktioniert: Bestandsdaten und neue Inhalte liegen in einer gemeinsamen, verlinkten Dokumentation, und die Teams arbeiten in ihren gewohnten Tools.
Auf dieser Grundlage hat das Unternehmen Docs-as-Code später firmenweit ausgerollt.
Eingesetzte Tools: Sphinx-Needs, Sphinx-Test-Reports
Docs-as-Code für ein ADAS-Projekt
Im zentralen Team eines Tier-1-Zulieferers habe ich Docs-as-Code in einem ADAS-Projekt für einen OEM eingeführt – von der Datenmigration über Tooling und CI bis zu Prozessen, Monitoring und Training.
- Branche
- Automotive, Tier-1-Zulieferer und OEM, Fahrerassistenzsysteme (ADAS)
- Team
- ADAS-Projekt mit bis zu 1.500 Leuten bei Tier-1 und OEM; zentrales Docs-as-Code-Team
- Zeitraum
- 2021–2024
- Meine Rolle
- Beratung, Tool-Entwicklung, CI, Training und Support
Problem
Ein ADAS-Projekt für einen OEM, mit bis zu 1.500 Leuten bei Tier-1 und OEM zusammen. Anforderungen und Tickets lagen in klassischen Requirements- und Ticket-Tools, und die sollten nicht über Nacht verschwinden.
Docs-as-Code sollte die Basis für Anforderungen, Spezifikationen und Nachweise werden. Dafür brauchte es mehr als ein Tool: Bestandsdaten, Schnittstellen zu den bestehenden Tools, eine CI, die bei dieser Größe schnell bleibt, und Teams, die mitziehen.
Was wir gemacht haben
Ich war Teil des zentralen Teams, das Docs-as-Code im Projekt eingeführt hat. Die Bestandsdaten aus den Requirements- und Ticket-Tools haben wir nach Sphinx-Needs überführt, und für den laufenden Abgleich mit diesen Tools habe ich Importer und Exporter gebaut.
Dazu kam ein CI-System, das die Dokumentation baut und prüft. Bei dieser Datenmenge wurde Performance schnell zum Thema: Ich habe analysiert, wo Sphinx und Sphinx-Needs Zeit verlieren, und Features und Optimierungen direkt in Sphinx, Sphinx-Needs und Sphinx-Test-Reports umgesetzt. Damit die Arbeit im Editor leichter fällt, ist ein IDE-Plugin für Sphinx-Needs entstanden.
Neben dem Tooling ging es um die Arbeitsweise: Prozesse und Workflows habe ich mit den Teams beraten, definiert und umgesetzt. Kennzahlen aus CI und Projekt laufen in Grafana-Dashboards zusammen. Trainings und der First-Level-Support haben die Teams beim Umstieg begleitet.
Ergebnis
Anforderungen und Nachweise liegen als Docs-as-Code im Repository, verlinkt und automatisch gebaut. Die bestehenden Tools bleiben über Importer und Exporter angebunden.
Die Verbesserungen an Sphinx, Sphinx-Needs und Sphinx-Test-Reports stecken in den Open-Source-Projekten und helfen damit auch anderen.
Eingesetzte Tools: Sphinx-Needs, Sphinx-Test-Reports
