Agiles Systems Engineering aus Sicht von VW- und Vector-Mitarbeitern
Kürzlich entdeckte ich ein vor wenigen Jahren veröffentlichtes Paper mit dem Titel „Agile Systems Engineering“, geschrieben von Christof Ebert (Vector Consulting) und Frank Kirschke-Biller (Volkswagen). Auch wenn die Autoren nicht explizit auf die Situation bei Ihren Unternehmen eingehen, so ist die Perspektiven von diesen Personen für viele Leser sicher interessant.
Um es vorweg zu nehmen: Mir fehlt insbesondere der Aspekt von extrem kurzen Entwicklungszyklen und regelmäßigen Systemtests, die ich beim agilen Systems Engineering für essentiell halte. Andererseits enthält der Artikel sinnvolle Checklisten, um im eigenen Unternehmen die agile Transformation in Gang zu setzen.
Das Paper
Das neun Seiten lange Paper ist kostenlos erhältlich und schnell gelesen. Veröffentlicht wurde es 2021 in IEEE Software. Das war vor dem ChatGPT-Hype, was insofern relevant ist, da es am Ende kurz auf die Rolle von Künstlicher Intelligenz eingeht. Ebenso geht der Artikel (nicht sehr positiv) auf SysML ein. Viele Kritikpunkte, insbesondere bezüglich Formalität, werden von SysML v2 entschärft. Da diese bereits seit 2017 in Entwicklung ist, ist es schade, dass die Autoren dies nicht berücksichtigen.
Die Herausforderungen
Das Paper beginnt mit den üblichen Statements: Komplexität explodiert, Innovation, Kosten und Qualität haben sich branchenübergreifend als die wichtigsten kurzfristigen Herausforderungen herauskristallisiert.
Ein weiteres Problem sehen die Autoren in fehlenden Basiskompetenzen wie Anforderungsmanagement und Traceability. Diese sehen sie als Grundvoraussetzung, um überhaupt mit agilem Systems Engineering beginnen zu können. Dieser Aussage stimme ich nur zum Teil zu: Es ist richtig, dass „agil“ manchmal als Entschuldigung verwendet wird, um bestimmte Praktiken auszulassen. Andererseits unterscheiden sich Anforderungsmanagement und Traceability im agilen Systems Engineering radikal von diesen Praktiken in der traditionellen Produktentwicklung.
Vier Dimensionen entlang des Produktlebenszyklus
Die Autoren betonen, dass die folgenden vier Dimensionen über dem gesamten Produktlebenszyklus betrachtet und für agiles Systems Engineering folgendermaßen umgesetzt werden müssen:
- Business: Anforderungen müssen einen klar erkennbaren Geschäftswert haben, um Nacharbeit zu vermeiden und die Qualität zu sichern. Produktkataloge mit Feature-Planung beschleunigen Entscheidungen und schaffen klare Entwicklungsroadmaps. Systematische Regressionstechniken erleichtern Agile Delivery, während wiederverwendbare Hardware- und Softwareelemente mit Rückverfolgbarkeit den Entwicklungsprozess effizienter machen. KPIs unterstützen die Steuerung und Identifikation von Trends.
- Menschen: Die Zusammenarbeit muss gewährleistet sein und erfordert ein effektives Management von Lieferketten auf Basis vertraglich festgelegter Anforderungen. Effizientes Wissensmanagement und zentrale Rollen wie ein Safety Officer in Scrum-Teams sichern die Koordination und Einhaltung von Standards.
- Prozess: Angepasste agile Methoden mit hierarchischem Scrum und testgetriebenen Ansätzen gewährleisten Konsistenz zwischen Entwicklung und Validierung. Regelmäßige Synchronisationspunkte und eine flexible Abstimmung von Hardware- und Softwarelieferungen ermöglichen kontinuierliche Integration und Auslieferung. Eine klare Trennung von Aufgabenbereichen sorgt für Transparenz und bessere Zusammenarbeit.
- Technologie: Modellierung, Simulation und der Einsatz digitaler Zwillinge ermöglichen frühe Validierung und Anpassungen, bevor reale Systeme betroffen sind. Architektur- und Schnittstellensimulation sowie leistungsstarke Werkzeugketten mit Integration in Softwareentwicklungs-Tools sind essentiell.
Aus dieser Liste schreit förmlich der Spagat zwischen echter Agilität, ohne zu disruptiv zu sein (Hierarchischer Scrum?!?). Daher ist diese Liste insbesondere für kleine oder bereits agile Teams mit viel Vorsicht zu genießen. Ebenso gehen die Autoren zwar auf Continuous Delivery ein, was allerdings dem Prozess nachgeordnet ist. Hier fehlt der Mut zu echtem agilen Systems Engineering, wie es bspw. bei SpaceX praktiziert wird.
Systems Engineering-Perspektiven
Eine weitere nützliche Liste ist die Tabelle mit 9 Perspektiven, einschließlich typischer Risiken und Taktiken zur Entschärfung:
| Perspektive | Relevanz | Gefahren und Risiken | Entschärfung |
|---|---|---|---|
| Wert | Der wahrgenommene Wert, der das Produkt in ein tragfähiges Geschäftsmodell übersetzt | Endlose Feature-Listen ohne Rückverfolgbarkeit zum Geschäftswert | Sicherstellen der Rückverfolgbarkeit von Anforderungen zu einem Geschäftswert, einem Verantwortlichen und vorzugsweise einem Kunden. Priorisierung verwenden. |
| Verhalten | Primäre Funktionen und deren Ergebnisse, wie Algorithmen und deren Ergebnisse, Ende-zu-Ende | Funktionen werden nur für „Sonnenschein-Szenarien“ spezifiziert | Erfassen von realen Worst-Case-Funktionalitäten. Negative Anforderungen nutzen, wie Missbrauchs- und Fehlerszenarien. |
| Struktur | Logische Bausteine und deren Schnittstellen | Systeme wachsen organisch, indem Inhalte hier und da hinzugefügt werden | Periodisches Refactoring und Architektur-Analyse anwenden. Metriken wie Kopplung, Überschreibung und Ähnliches verwenden. |
| Information | Systeminformationsobjekte und deren Beziehungen, Validität und Datenschutz | Inkonsistente Daten und unklare Validität der Informationen | Datenobjekte zur Laufzeit mit Plausibilitätsprüfungen überprüfen. |
| Services | Zugriffspunkte, um zur Laufzeit Verhaltensweisen auszulösen, einschließlich Definition, Discovery und Orchestrierung | Software-Funktionen werden als Service bezeichnet, ohne die notwendige Orchestrierung | Aufbau einer serviceorientierten Architektur mit Orchestrierung, Registry und flexibler Nutzung. |
| Performance | Laufzeitinteraktion, einschließlich Management zur Sicherstellung von Robustheit und Verfügbarkeit | Laufzeitverhalten wird nicht berücksichtigt, wodurch das gesamte System verlangsamt wird | Analyse der Planbarkeit, Echtzeit-Reaktionen und Zeitbeschränkungen basierend auf tatsächlichen Anforderungen. |
| Wiederverwendung | Definierte Variationspunkte in der Systemstruktur | Nicht wartbare, eigenständige Varianten | Variationspunkte für Black-Box-Wiederverwendung definieren, um Systeme in spezifischen Marktlieferungen einzusetzen. Ein Master-Produktkatalog und eine Roadmap pflegen. |
| Portierbarkeit | Nutzung eines Systems oder Produkts in einem anderen Kontext | Produktkomponenten sind miteinander oder mit einer spezifischen Hardware verbunden | Komponenten und Produkte dynamisch zuordnen und flexibel halten. |
| Deployment | Zuordnung von Diensten zu Software und von Software zu Hardware-Bausteinen | Zu spezifische Einschränkungen oder keine Berücksichtigung von Hardware-Anforderungen | Hardware-Einschränkungen und mögliche Deployment-Szenarien bereits während der Anforderungsanalyse spezifizieren. |
Auch bei dieser Tabelle habe ich mich gefragt, was das mit Agilität zu tun hat. Bestenfalls müssen wir sicherstellen, dass wir diese Perspektiven bei agilem Systems Engineering nicht vernachlässigen.
Dennoch ist auch diese Liste durchaus nützlich. Denn diese Perspektiven müssen eigentlich immer im Systems Engineering berücksichtigt werden, ob agil oder nicht. Andererseits ist diese Liste nicht neu und auch im INCOSE-SE-Handbuch zu finden.
Erwünschte Ergebnisse
Die dritte und letzte Liste in diesem Paper kann hilfreich sein, die Effektivität von Maßnahmen jeglicher Art zu messen. Diese sind:
- Zuverlässigkeit: Selbstorganisation reduziert den Aufwand der Koordinierung im Vergleich zum klassischen Projektmanagementansatz.
- Transparenz: Die Transparenz des Projektstatus und somit auch des Projektmanagements wird verbessert.
- Effizienz: Geschwindigkeit und Qualität werden optimiert. Führungskräfte und Teams erkennen Verbesserungen. Insbesondere die frühzeitige Definition von Anforderungen und die Akzeptanz von Änderungen während der Entwicklung als Teil eines agilen Prozesses sind entscheidend für die Effizienz.
- Lebenszyklusmanagement: Die Komplexität von Produkten wird besser gehandhabt und kontrolliert.
- Qualität: Wiederverwendung und eine eingebettete Qualitätsverantwortung führen zu einer höheren Qualität.
Nun ja, auch hier fehlt der Bezug zur Agilität. Auch hätte ich mich über konkrete Zahlen aus einem echten Projekt gefreut.
Schwächen
Leider hat das Paper wesentliche Schwächen und sogar Fehler, insbesondere bezüglich SysML (1.x). Auf Seite 11 schreiben die Autoren, dass es „keinen einheitlichen Standard für SysML gäbe“ und dass es „SysML-Modellen an präziser, eindeutiger Semantik fehle, so dass formale Verifikation und Modellprüfung nicht möglich sind“.
Diese Aussagen sind zumindest stark irreführend: SysML ist ein internationaler, abgestimmter Standard. An manchen Stellen ist der Standard mehrdeutig, was in der Tat zu Problemen führen kann. Erweiterungen wie MARTE oder UPDM können hier Eindeutigkeit schaffen. Dazu kommt, dass SysML v2 genau diese Probleme löst.
Der gröbste Schnitzer ist es wohl, MagicDraw als „Malwerkeug“ zu bezeichnen. Ich vermute, die Autoren haben einfach vom Namen auf die Funktion geschlossen.
Fazit
Leider ein enttäuschendes Papier, zumindest für diejenigen, die auf einen innovativen Ansatz für agiles Systems Engineering gehofft haben. Die Listen und Tabellen hingegen sind durchaus brauchbar, und zwar für jede Art des Systems Engineerings. Denn auch diese haben mit Agilität nur wenig zu tun.
Photo by Martin Katler on Unsplash
