This entry is part 3 of 3 in the series Was ist BEYOND RE - Unser Open Space!
Spannende fachliche Diskussionen und kaltes Bier sind eine super Mischung für den Open Space der REConf
Spannende fachliche Diskussionen und kaltes Bier sind eine super Mischung für den Open Space der REConf

Nach dem ersten und zweiten Teil haben wir bereits sechs spannende Themen und Ergebnisse aus dem Open Space der REConf 2019 behandelt. Heute widmen wir uns den letzten drei. Passend zum Thema der REConf „BEYOND RE“, schauen wir, wie es mit RE weiter geht. Wir fragen: „Kommt das Behaviour Driven Development allen Vorgehensweisen zugute? Und schließlich diskutieren wir, ob RE noch zeitgemäß ist, oder nicht doch ein PO reicht?“ 

7. Wie geht es mit RE weiter?

Requirements Engineering umfasst heutzutage einen „Bauchladen“ mit verschiedenen Methoden und Techniken. Diese beginnen mit Systemscope definieren, Stakeholdermanagement, Anforderungsermittlung, Anforderungsdokumentation, geht über zu Prüfen und Abstimmen, Workflows und Vorgehensweisen, bis hin zu Verwalten und Tooling von Anforderungen, etc.

7.1 RE als Kern

RE ist eine Kerntätigkeit in der Systementwicklung. Es ist ein wichtiger Teil im Systems Engineering (SE). Wir stellen uns die Frage, ob  RE irgendwann in SE aufgehen wird? Eventuell werden auch Teile des RE von anderen „Disziplinen“ wie „Agil“, „Organisationsentwicklung“ oder „Business Analysis“ übernommen?

7.2 RE++ gleich SE?

Diese Fragen sind  nicht leicht zu beantworten. Sie haben in unserer Runde noch weitere Fragen und Diskussion aufgeworfen. Heute ist RE definitiv ein Teil des SE.
Wird ein „RE++“ einem modernen „Systems Engineering“ entsprechen? Viele von uns meinen: „Ja, so wird es sein“.
Jedoch was bedeutet SE eigentlich für RE? SE beschreibt Kontext und System, die beide bekannt sein müssen. Eine wesentliche Voraussetzung, um überhaupt sinnvoll Anforderungen (an was genau?) aufstellen zu können, ist die klare Definition des Systems, das entwickelt werden soll. Ansonsten verlaufe ich mich ganz sicher mit meinen erstellten Anforderungen.

7.3 Die richtigen Fragen stellen

Aus „Wie formuliere ich Requirements richtig?“ machen wir: „Welche Anforderungen werden wirklich benötigt?“, und „Auf welcher Detaillierungsebene formuliere ich optimalerweise?“. Denn häufig beobachten wir, dass Lösungen einfach als Anforderungen definiert werden. Dadurch schränken wir den Lösungsraum der neuen Systeme unnötig ein. Wir müssen Anforderungen daher immer eher lösungsarm stellen. Sie sollten über den Design- und Architekturentscheidungen, die dann anders dokumentiert werden sollten, stehen.

Angeregte Diskussionen auf dem Open Space unserer REConf2019
Angeregte Diskussionen auf dem Open Space unserer REConf

8. Behaviour Driven Development

Ein paar der Vorreiter des BDDs (Behaviour Driven Development) waren auf der REConf vertreten und initiierten diesen Open Space. Das Interesse unter den Teilnehmern war groß. Erfahrungen mit BDD hatten allerdings bislang deutlich weniger Teilnehmer als mit dem verwandten Test Driven Development TDD .

8.1 Was hat es damit auf sich?

Die „Nachprüfbarkeit“ von Anforderungen ist ein wichtiges Qualitätskriterium im RE. Von daher wissen wir als RE’ler schon, wie wichtig die konkrete Beschreibung der Abnahmekriterien bzw. Testkriterien innerhalb der Anforderungsspezifikation und der Entwicklung ist. Eine gute Beschreibung der Nachprüfbarkeit in einer Anforderung führt zu sehr aussagekräftigen, verständlichen und konkreten Spezifikationen. Daher ist es eigentlich etwas verwunderlich, dass Testgetriebene Entwicklungen (wie TDD, ATDD (Acceptance Test Driven Development) und BDD oft noch ein Schattendasein in der Systementwicklung führen.

8.2 Andere Herangehensweise

BDD geht konsequent „von hinten“ an die Anforderungen heran. Was bedeutet das? Eine automatisierbare Beschreibung des Verhaltens (zum Beispiel in der Beschreibungssprache Gherkin) führt bei BDD zu klar nachprüfbaren Anforderungen. Das fördert und fordert auch die Kommunikation mit den Stakeholdern.
Dan North ist einer der Vertreter von BDD. Er entwickelte auch ein Software Framework „JBehave“ um BDD zu unterstützen.

9. Ist RE noch zeitgemäß, da reicht doch ein PO*?

Die Aufgaben eines PO
Die Aufgaben eines POs

*PO: Product Owner. Nicht zu verwechseln mit „Po“, der Glutealregion. Der PO füllt eine von drei Rollen in dem agilen Framework „Scrum“ aus. Er steht der klassischen Rolle des „Produktmanagers“ nahe, allerdings mit ein paar wenigen aber wichtigen Unterschieden.

„Da gibt es ein paar Manager, die nur deswegen „agil“ werden, um sich des ‚bürokratischen und damit aufwendigen, blindleistung-erzeugenden Anforderungsmanagements‘ zu entledigen.“  Ja, diesen Spruch kennen einige von uns. Die Entwickler und Tester dürfen bleiben (sie werden jetzt „Development Team“ genannt), der Produktmanager wird zum PO, der Projektmanager wird zum ScrumMaster und der Rest wird eingespart! Und ruck-zuck haben wir effiziente effektive = agile Teams. Management kann so einfach sein!

Im Ernst, nicht nur wir, sondern auch zum Glück viele im Management wissen, dass RE mehr als zeitgemäß ist, und eine Einführung der Rolle PO nicht ausreicht. Der PO hat vielfältige Aufgaben, die sich durchaus mit RE kreuzen, aber keinesfalls decken.

Spannend und interessant für uns als RE`ler ist, dass in den (meisten) agilen Vorgehensweisen die Anforderung gar keine Rolle spielt und auch nicht explizit genannt wird. Der Grund dafür ist, dass die agilen Vorgehensweisen eine Nutzer- und Produktsicht innerhalb der Entwicklung im Fokus halten wollen. Allzu schnell verliert man diese Sichten im klassischen Wasserfallvorgehen. Man konzentriert sich dort nur auf korrekte Einhaltung von Prozessen („Prozessbefriedigung“), formale Aspekte bei der Dokumentation, Erfüllung von Plänen und Vorgaben etc. Dabei geht der Blick fürs Wesentliche (wie Nutzerbedürfnisse und schnelle effiziente Entwicklung eines Qualitätsproduktes) schnell verloren. Das konnten nahezu alle Teilnemer des Open Spaces aus Erfahrung bestätigen.

Trotz allem: RE ist eine wunderbare Brücke zwischen den Interessen des Managements (Unternehmen, Quality, Projektmanagement etc.), der Entwickler, und – last but not least – den Kunden und externen Stakeholdern. RE ist Brückenbauer zwischen all diesen. Und das kann keine andere Rolle in diesem Maße realisieren.

Daher ist es für den klassischen PO aus Scrum sehr vorteilhaft, ein RE-Wissen zu haben und RE-Methoden und Techniken anzuwenden. In kleinen Projekten kann der PO sehr gut die wesentlichen RE-Aufgaben mit übernehmen oder unterstützen.

Ich hoffe, dir hat mein Rückblick zum Open Space gefallen. Schreibe mir gerne deine Meinung, Fragen & Wünsche in das Kommentarfeld. Bis bald, vielleicht ja schon im nächsten Jahr auf einem Open Space auf der REConf 2020.

Series Navigation<< Was ist BEYOND RE – unser OpenSpace! – Teil 2