REConf 2016 – Connecting People – overcome barriers

Auch dieses Jahr war ich wieder auf der REConf, der größten Requirements Engineering Konferenz im deutschsprachigen Raum. Im Gegensatz zum letzten Jahr allerdings nur als Besucher und aus Zeitgründen leider auch nur am zweiten Tag.

Das Angebot an Vorträgen war wie immer recht breit aufgesetzt – vier Tracks (Agile, Industries 4.0, Zuständigkeiten Kunden/Lieferanten und Solution Track) und zeitweise noch weitere Vorträge parallel. Die Speedpräsentationen als Appetizer am Morgen zwischen den Key-Notes waren mir hier eine wirkliche Entscheidungshilfe – „Härtefall“-Entscheidungen blieben aber leider dennoch nicht aus. 

Key-Notes

Die erste Keynote hielt Dr. Siegmar Haasis, derzeit CIO für Research & Development bei Mercedes Benz, bei der es um die Veränderungen vom klassischen, textuellen Requirements Engineering (RE) hin zum Model Based Systems Engineering (MBSE) ging.  Das Model Based Systems Engineering, das bevorzugt in der Konstruktion mechatronischer Systeme eingesetzt wird, virtualisiert das Systemmodell und präsentiert es überdies in Schichten (top down). Dadurch steigt das gemeinsame Verständnis und die Validierung kann entscheidend verbessert werden.

Es geht bei Daimler dabei nicht nur um die Synchronisierung von Hardware- und Softwareentwicklungszyklen in Bezug auf einzelne Komponenten in Autos, sondern vielmehr schon um Offboard-Systeme, im gezeigten Beispiel um das Aufladen eines Elektro-Autos an einer beliebigen Ladestation, bei der z.B. das Ladekabel zum Fahrzeug passen muss und der Ladestatus auf dem Handy in Echtzeit angezeigt werden soll. Wir betrachten dabei nicht nur ein System mit diversen Anforderungen, sondern diverse Systeme (mit wiederum diversen spezifischen Anforderungen) und überdies mit ganz unterschiedlichen Entwicklungsbereichen (IT, Maschinenbau, Elektrotechnik). Die Umstellung vom textuellen RE hin zu MBSE  verglich Dr. Haasis mit der Wandlung von Konstruktionszeichnungen am Reißbrett vor 40-50 Jahren hin zu CAD-Anwendungen. Daher kann die Umstellung auch nicht als "Big Bang" erfolgen, sondern es braucht kleine Keimzellen im Unternehmen.

Tooling

Vor dem Mittag hörte ich mir noch den Vortrag zum „Professionellen Requirements Management mit Jira“ (Atlassian) an. Dieser war im Vorfeld einer der interessantesten für mich, da wir intern ebenfalls an einer Lösung arbeiten, um Requirements Management mit Atlassian-Produkten abzubilden - und wir auch schon einiges umgesetzt haben. In so einer Phase die Möglichkeit zu haben, mal beim „Nachbarn“ zu schauen, ist natürlich wunderbar. Und ich wurde auch nicht enttäuscht. Die Kollegen nutzen grundsätzlich die Jira-Basis-Funktionalitäten und bauen dort die fehlenden Features ein, z.B. ein Baselining und eine Im- und Exportfunktionalität für Anforderungen. Diese ermöglicht es auch offline zu arbeiten und die Änderungen später in Jira hochzuladen. Dass der Vortrag keinen Showcase enthielt, fiel nicht ins Gewicht, da diese an einem Stand auf der Konferenz angeboten wurde. Das nahm ich im Anschluss auch wahr und konnte noch einige interessante Anregungen für unser internes Projekt mitnehmen. Bei dem liegt der Fokus dabei auch auf dem Requirements Engineering, bietet die durchgehenden Transparenz (bzw. Traceability) vom Prozess über Anforderungen und Test bis zum Code – und zurück. Dazu werden aber neben eigenem Customizing z.B. auch Plugins wie Gliffy für BPMN Modellierung in Confluence und das Testing Plugin Zephyr , dass wir auch für die Automation im Rahmen der continous Integration einsetzen.  

Die Mittagspause konnte ich zu weiteren netten Gesprächen nutzen; ich traf auch einen Kollegen, den ich schon lange kenne und mit dem ich mich bereits in der Vergangenheit zum Thema RE ausgetauscht habe. Interessant war dabei, dass wir beide derzeit das Gefühl haben, dass das Thema DevOps (Development & Operations) vermehrt angefragt wird. Wir befassen uns intern schon eine ganze Weile mit diesem Thema und konnten DevOps bereits bei einem großen Energie-Unternehmen erfolgreich einführen. Gestützt wurde dieser Eindruck zudem auch durch Vorträge, bei denen eine stärkere Einbindung des Betriebs innerhalb des Projekts an den Fachbereich und die Entwicklung immer wieder als Schlüssel zu erfolgreichen Projekten und kürzeren Release-Zyklen angesehen wurde. Das Thema nimmt offensichtlich Fahrt auf.

Kanban

Am Nachmittag erwartete mich ein weiteres spannendes Thema: „Skaliertes Anforderungsmanagement mit Kanban". Wie man ein Projekt mit Kanban führt, wusste ich und tatsächlich bin ich aufgrund der großen Transparenz ein Fan davon. Aber in einem Projektumfeld mit 500 Mitarbeitern? Wie groß da wohl das Board ist… Der Vortrag beruhte auf eigenen Erfahrungen aus einem realen Projekt im Logistikbereich - dies macht Vorträge immer sehr schön anschaulich und lebendig. Die Details möchte ich hier nicht alle wiedergeben, dafür aber kurz die für mich wichtigsten Erkenntnisse. Basis für die Zusammenarbeit war eine „Triade“ aus jeweils einem Stakeholder aus den Gebieten Fachbereich, Architektur und Betrieb(!). Gemeinsam wurden die Stories besprochen, priorisiert (z.B. bei Abhängigkeit von anderen Teams) und runtergebrochen sowie anschließend an die Umsetzungsteams weitergegeben. Diese hatten wiederum ihr eigenes Kanban-Board. Der Fortschritt der Stories wurde regelmäßig gemeinsam vorgestellt. Kommunikation wurde hier besonders in den Vordergrund gestellt und Dokumentation auf das Notwendigste reduziert. Am Ende konnte mit Kanban die Durchlaufzeit einer Story von der Beauftragung bis zum Deployment von 150 auf 30 Tage reduziert werden, wobei hier wohl immer noch Luft sei…

Inspections

Der letzte Vortrag handelte von „Extreme Inspections“  von Anforderungsdokumenten. Hier geht es natürlich vor allem darum die Qualität der Anforderungen auf ein möglichst hohes Niveau zu heben, um hohe Folgekosten durch späte Fehlerbehebung zu vermeiden. Dabei wird nicht zunächst das Review durchgeführt, sondern es erfolgen sich wiederholende Inspektionen (z.B. wöchentlich) auf Grundlage weniger (hier drei) einfacher Regeln (z.B. Ist das Beschriebene testbar?). Es wird dabei allerdings nicht das ganze Dokument geprüft, sondern nur ein Ausschnitt von etwa zwei Seiten. Die gefundenen Issues werden gezählt, aber nicht weiter kommentiert und auf das gesamte Dokument hochgerechnet. Normal sind im Anfangsstadium etwa 80 Issues/Seite. Erfahrungsgemäß halbieren sich die Issues nach jedem Durchlauf. Ziel sind meist weniger als acht Issues/Seite (bei der NASA sind weniger als ein Issue/Seite gefordert). Insgesamt sollen damit Projekte „5x effizienter sein und 90% weniger Fehler beinhalten“. Ich bin bei solchen Aussagen immer etwas skeptisch, aber sinnvoll erscheint es auf jeden Fall. Verstärken lässt sich dies durch einen Specification-by-Example bzw. Test-Driven-Development-Ansatz.

Fazit

Die REConf 2016 war wieder eine Veranstaltung mit vielen tollen Vorträgen und der Möglichkeit sich mit Gleichgesinnten und Interessierten auszutauschen. Nächstes Jahr werde ich sicher wieder dabei sein, evtl. dann auch wieder mit eigenem Vortrag.

Die REConf findet im nächsten Jahr übrigens vom 27.-30.März statt.