08-2017 bis 06-2019
• Coaching des Teams in den Bereichen Spezifikation und Softwaremodellierung
• Transparente Anforderungen über verschiedene Organisationsbereiche
• Verbesserung der Anforderungsqualität
• Optimierung der Anforderungen bzgl. Testbarkeit
Ziel des Projektes war es nicht irgend einen Prozess überzustülpen sondern gezielt die Probleme im Anforderungsmanagement anzugehen. Langwierige Schulungsprogramme für Tooling und Methodik sollten vermieden werden um einerseits den Projektfortschritt nicht zu gefährden und andererseits auch nur an realen Problemstellungen zu arbeiten. Nach kurzer Orientierungsphase konnte das Team schnell einen praktikablen Spezifikationsstil finden. In Arbeitssessions stand ich als Experte für Fragen direkt zur Verfügung.
Sowohl die Anforderungsqualität als auch die Vollständigkeit der Anforderung konnte innerhalb weniger Wochen gesteigert werden. Weitere Kollegen aus dem Bereich Testing konnten hinzugezogen werden und fügten Abnahmekriterien und Testfälle hinzu.
Projektbeschreibung
Der Kunde befand sich in mehrerlei Hinsicht stark im Wandel. Zum einen wurde Konzernweit die Transformation Richtung IoT vorangetrieben. Zum anderen sollten aber auch immer mehr Produkte aus Standartkomponenten eines Baukastensystems entwicklet werden. Für viele der bereits existierenden Komponenten existierten keine Vollständigen Spezifikationen (insbesondere nicht nach Spezifikationslevels getrennt). Im Bereich Software sollte eine klare Trennung der Layer (Prozess, Controller, Driver, µC) erreicht werden um der zukünftigen Zielsoftwarearchitektur zu genügen.
Ziel des Projektes sollte sein, anhand eines Entwicklungsprojekt die Methodik zu veranschaulichen und ein reales Best-Practise Beispiel zu erhalten an dem sich weitere Projekte orientieren können.
Projektablauf
Wie in fast allen meiner Projekte sah ich mir erstmal den Status Quo an. Eine Beurteilung des Requirement Engineerings, Spezifikationsgranularität, Methodik und der Entwicklungsprozesse bildet die Grundlage für ein erstes Feedback. Hierauf bassierend erarbeitete ich Vorschläge wie aktuelle Best Practises aus der Anforderungsanalyse und dem System Engineering adaptieret werden können. Gemeinsam mit dem Kunden wurde dann eine Strategie festgelegt wie und in welcher Reihenfolge die Punkte angegangen werden sollten.
Einführung des Zig-Zag Approaches

Elementar für mich ist das Verständnis der Trennung zwischen Anforderungen, Architektur und Implementierung. Und die nicht nur in zwei Teile sonder über alle Hirachien eines Produktes. Nach einführung der Methodik versuchte ich alle Probleme immer wieder auf das Pattern zu mappen und aufzuzeigen welche Anforderung auf welches Level gehört und wie diese sich durch den Baum hindurchzieht.
Die Core Gruppe für diesen Ansatz bildeten ein Prozesstechniker, der Product Owner sowie die System Architekten. Als Vorgehensweise wurden Hands On Regelmeetings gewält. Ich wollte von Anfang an erreichen, das dieses Team sich die Methodik selbst aneigenet und die dahinterstehenden Prinzipien versteht. In den Sessions stand ich lediglich als Coach zu Verfügungen um gewisse Problemstellungen beantworten zu können und Lösungsmöglichketien aufzuzeigen.
Im Bereich Requirements Engineering erfolgte keine Grundlagenschulung sondern eher ein PDCA Vorgehen. Anforderungen schreiben, gemeinsames Review mit dem Experten, Tipps hinsichlich Formulierung, Granularität, Atomarität, Testbarkeit, weiter spezifizieren. Innerhalb weniger Wochen konnten wir eine Anforderungsqualität erreichen wie sie bisher in diesem Unternehmen noch nie vorhanden war.
Im Bereich Architektur galt es zukünfig mit Enterprice Architekt zu modellieren. Auch hier erfolgte nur eine kurze Einführung in die SysML. Die Grundzüge des Block Diagrams wurden vorbereitet und dann wieder zügig das Team in die Pflicht genommen. Ich zeigte verschiedene Diagrammarten auf überließ es aber dem Team eine adequate Darstellung auszuwählen die auch im Kollegenkreis ohne große Einarbeitung in SysML verstanden wird. (Block Diagram, State Diagram und Aktivitätsdiagram eigneten sich besonders gut.
Spezifikationsstruktur
Obwohl das Umfeld zunehmend Agilen Entwicklungsmethodiken folgte sollten die Spezifiaktion dennoch im klassichen Dokumentestil verfügbar sein. (Reuse, externe Vergabe, Freigabeprozess …) Ich wählte dafür den Ansatz der Microspezifikationen. Kleine überschaubare Spezifikation – jeweils passend zum Spezifikationslevel strukturiert nach einer Standartstruktur. So konnte die Problematik aufgelöst werden das umfangreiche Spezifikationen nie vollständig gereviewed werden und damit dem Projektverlauf oft deutlich hinterherhinken. Mikrospecs haben nur eine überschaubare Anzahl an Stakeholdern. Diese sind zügig greifbar und ermöglichen es kurzfristig eine Spezifikation freizugeben. Gerade im Sinne einer Agilen Entwicklungmethodik kann so auch früh an einzelnen Bereichen gearbeitet werden während andere Bereiche noch nicht oder nur grob spezifiziert sind. Die Abhängigkeiten ergeben sich hierbei aus der modellierten Architektur. Diese Tranzparenz ermöglicht es hier valide Entscheidungen zu treffen und nicht auf Gut Glück zu entwickeln.
weiterer Rollout
Wirklich begeisterte Entwickler machten später noch intensivere Schulungen im Bereich Modellierung. Im Bereich RE vermittelte ich einem Kurzworkshop einem erweiterten Kollegenkreis nochmal Grundlagenwissen. Nachdem der Ansatz mit dem Core Team gut funktionierte wurden nach und nach weitere Komponentenentwickler mit hinzugezogen. Diese konnten das Vorgehen zügig adaptieren. Eine Person des Core Teams übernahm langsam meine Position und versuchte die Best Practise im Unternehmen weiter zu verbreiten.
Kundenfeedback
Ich hatte im laufe des Projekt auch immer wieder mit Stabsstellen des Unternehmen zu tun. Eine derartige Durchgängigkeit im System Engineering war bisher noch nicht gelungen. Insbesondere wurde mein Ansatz geschätzt: Schnell Projektspezifische Ergebnisse zu liefern und dennoch langfristig eine Methodik im Team zu entwickeln.
Herausforderungen
Teile des Entwicklungsteams waren über mehrere Standorte verteilt. Insbesondere einzelne Komponentenentwicklungen hatten noch nie etwas von moderenen System Engineering Ansätzen gehört. Hier entsprechend Wissen beizusteuern, Schulungen anzubieten und als Support bereitzustellen war der Schlüssel um alle mit ins Boot zu holen und keinen auf der Strecke zu lassen.
Rollen im Projekt
Coach
System Engineer
Requirement Engineer
Tooling Spezialist (Polarion / Enterprice Architect)
Entwicklungsmethodik
Agil (in Transformation),
System Engineering Team: Kanban
Entwicklerteam: Scrum, Klassisch
Standards / Technologie
klassisches Requirement Engineering
Tools
Polarion, Enterprice Architect, Jira, Confluence
Projekt Retrospective
Im Nachgang betrachtet würde ich dieses Projekt als sehr gelungen einstufen. Genau so stelle ich mir externe Unterstützung für einen Kunden vor. Ich konnte konkret einen Mehwert schaffen und das schon nach wenigen Wochen. Die Methodik wurde vom Team verstanden, dokumentiert und immer weiter gelebt. Andere Abteilungen übernahmen den Ansatz weil ersichtlich wurde das er funktioniert und Mehrwert bietet. Auch nach meinem Projekteinsatz gibt es Personen die den Ansatz gut genug verstanden haben um ihn im Unternehmen weiterzutragen.
Insbesondere den Pragmatischen Hands-On Ansatz habe ich seitdem noch einige Male angewendet.