Ein Reifegradmodell für agiles Requirements Engineering

Durch die Umstellung der Softwareentwicklung auf die agile Vorgehensweise hat sich in der Arbeitswelt vieles geändert. Entgegen der „vorgesehenen“ agilen Rollen wurde bei DATEV eG auch die Rolle „Requirements Engineer“ (RE) eingeführt. Der RE bei DATEV ist zuständig für die fachliche Analyse, Detaillierung der Anforderung und Traceability der Anforderungen bis hin zur Umsetzung und zu fachlichen Tests. Hauptaufgabe ist damit, die „Übersetzung“ der Anforderungen vom Problemraum über den fachlichen Lösungsraum hin zum technischen Lösungsraum.

Neben den Rolleninhabern in den Entwicklungsteams gibt es auch eine kleine Einheit mit „zentralen“ REs. Diese sind zuständig für die Vernetzung der Jobrolleninhaber und Pflege der Community, für das Qualifizierungskonzept der REs und die Professionalisierung der Disziplin. Nach dem Aufbau einer einheitlichen Ausbildung (angelehnt an das CPRE des IREB¹ ) und einer zweijährigen Laufzeit, war natürlich interessant zu erfahren, wie das vermittelte Wissen in den Teams und der täglichen Arbeit der REs ankommt. Um Verbesserungspotentiale in der Qualifizierung und im täglichen Ablauf erkennen und sinnvolle Maßnahmen ableiten zu können, ist die Erhebung des Reifegrads eine anerkannte Methode. So gibt es z.B. das Kreitzbergmodell zur Erhebung des UX-Reifegrades eines Unternehmens. Also sollte sich doch auch für die Feststellung des Reifegrades für agiles Requirements Engineering ein geeignetes Modell finden lassen.

Die Methode der Reifegradmodelle

Unserer Entscheidung ging eine kritische und differenzierte Auseinandersetzung mit der Methode der Reifegradmodelle voraus. Ein Merkmal traditioneller Modelle ist, dass man durch das bloße Befolgen eines festgelegten Prozesses automatisch zu einem perfekten Ergebnis gelangt. Diese Aussage kann man aber nur in einem stabilen Umfeld treffen, denn sie steht im Widerspruch zu den komplexen und volatilen Umgebungen, in dem man sich mit der Softwareentwicklung meistens befindet. Ein Blick in die Leitsätze des agilen Manifests, welches Prozesse und das Befolgen eines Plans zugunsten von Reagieren auf Veränderung zurückstuft, stützt diese Beobachtungen. Außerdem gehen die bekannten Modelle meist auch von „fertigen“ Artefakten aus und prüfen die Erfüllung bestimmter Qualitätskriterien (z.B. Vollständigkeit). In den agilen Vorgehensweisen lernt und verbessert man sich aber vor allem mit „unfertigen“, just-in-time erzeugten Ergebnissen (Stichwort: MVP).

Gerne setzt man Reifegradmodelle ein, um Schritt für Schritt gewisse Fähigkeiten zu erlangen und zu verbessern. Das Stufenkonzept beinhaltet notwendigerweise eine höchste Stufe, deren Erreichen die Scheinsicherheit suggeriert, man habe ein Optimum erreicht. Auch diese Denkweise widerspricht den Werten und Prinzipien, die die Basis für die Bewältigung von komplexen adaptiven Aufgabenstellungen bilden. Der für uns entscheidende Faktor war eben nicht die Reifegradmessung von Prozessen, sondern die Fähigkeiten einer Organisation, gut mit Anforderungen umzugehen.²

Nach einiger Recherche stand daher fest, dass es kein adäquates Modell gibt, welches sowohl unseren Anspruch an Transparenz als auch den Umgebungen, in dem die Disziplin Requirements Engineering in der DATEV betrieben wird, gerecht wurde. Initiiert aus unserer zentralen Einheit und unter unternehmensweitem Einbezug einiger Kollegen aus der großen RE-Community schickten wir uns daher an, unser eigenes Reifegradmodell für agiles Requirements Engineering zu erstellen.

Der Fokus lag dabei weniger auf der Bewertung der persönlichen Arbeit einzelner Mitarbeiter, sondern eher auf der Einschätzung der Reife der Disziplin Requirements Engineering in den oft cross-funktionalen Entwicklungsteams.

Der Aufbau des Reifegradmodells für agiles RE

Grundlage für unsere Überlegungen war Scrum, das wohl bekannteste Framework für agile Softwarenentwicklung. Dessen Basis, nämlich die Theorie der empirischen Prozesssteuerung³, zogen auch wir für unser Modell heran. Die Theorie beschreibt, dass in regelmäßigen Abständen überprüfbare Ergebnisse entstehen. Ergebnisse werden mit den Erwartungen an das Produkt abgeglichen und geprüft, ob die zu erfüllenden Anforderungen den umgesetzten entsprechen. Über notwendige Anpassungen nimmt man unmittelbar Einfluss auf zukünftige Ergebnisse. Die drei Säulen Transparenz, Überprüfung und Anpassung ergeben somit die Basiskategorien unseres Modells.

Angelehnt an den RE-spezifischen PDCA-Zyklus⁴ zogen wir fünf weitere Bewertungsebenen ein:

1. Das große Ganze im Blick behalten. Eine Produktvision ist der Nordstern für die Entwicklung. Sie adressiert die Kundenbedürfnisse und gibt die Richtung vor. Sie sorgt für die Motivation, als Team an einem Strang zu ziehen, um gemeinsam ein herausforderndes Ziel anzustreben.
2. Die Planung der nächsten Lieferung kann mehrere Sprints/Iterationen umfassen. In der Softwareentwicklung wird auch von Releaseplanung gesprochen. Wichtig ist, dass auf Details der Anforderungen weiterhin weitgehend verzichtet wird.
3. In der Planung des Inkrements werden die Details der Anforderungen festgelegt, so etwa die Akzeptanzkriterien von User Storys. Auch während der Umsetzung können Anforderungen noch detaillierter werden, sofern neue Erkenntnisse gewonnen werden.
4. Die Überprüfung und Anpassung für das Inkrement, den Entwicklungsgegenstand, findet statt.
5. Auch der gelebte Prozess des Requirements Engineerings wird als solches regelmäßig überprüft und bei Bedarf angepasst.

Die Modellstruktur hinterlegten wir beispielhaft mit einer Vielzahl von Artefakten, Ereignissen und Regeln und ergänzten diese durch bewährte Praktiken.

Vorbereitung der Befragung

Letztendlich entschieden wir uns für eine anonymisierte Befragung der Rolleninhaber in Form eines schriftlichen Fragebogens.
Bei der Erstellung orientierten wir uns im Aufbau an der Struktur unseres Reifegradmodels. Für die inhaltliche Gestaltung der Fragen zogen wir unsere Mustersammlung heran. Analog zu den fünf Bewertungsebenen fanden die Teilnehmer fünf thematisch zusammengehörige Blöcke mit insgesamt 19 Fragen vor. Darunter Einschätzungen zu Artefakten wie der Produktvision, Methoden zur Anforderungserhebung und Priorisierung oder zu Ereignissen wie der Teamretrospektive (alle 19 Fragen im Detail finden Sie im Fragebogen⁵).

Die Beantwortung bzw. Bewertung der Fragen erfolgt auf einer Skala von +3,0 („stimme vollkommen zu“) bis -3,0 („stimme gar nicht zu“). Freitextantworten waren aufgrund der datenschutzrechtlichen Vorgaben nicht möglich. Die bereits angesprochene und von anderen Modellen gewohnte Stufigkeit ist nicht möglich und für dieses Model auch nicht notwendig.

Erhebung und Bewertung der Ergebnisse

Wir berichten regelmäßig über den Fortgang und die Entwicklung des Modells. Als Startschuss der Befragung initiierten wir, neben der Info per E-Mail an ca. 280 Rolleninhaber, zusätzlich Community-Termine, um den Fragebogen vorzustellen. Wichtigste Botschaft war, dass bei der Beurteilung nicht die eigene Tätigkeit als Grundlage herangezogen, sondern der Umgang mit Requirements Engineering im gesamten Entwicklungsteam bewertet werden sollte. Nach einer Bearbeitungsdauer von vier Wochen hatten wir schließlich eine Rücklaufquote von 25%.

Die anschließende Auswertung zeigte im Mittel erstmal eine relativ gleichmäßige Bewertungssituation von +1,0. Ein detaillierter Blick offenbarte allerdings das eher zu erwartende heterogene Bild. Hier zeigt sich mitunter ein eklatanter Schwankungsbereich zwischen „sehr positiv“ bis „eher negativ“. Da unser Hauptaugenmerk auf der kontinuierlichen Professionalisierung der Disziplin RE im Haus liegt, taten wir uns entsprechend schwer, möglichst sinnvolle Handlungsfelder zu definieren. Wir entschieden uns daher für zwei Workshops in der Community  −einmal in der Runde der Requirements Engineers und einmal in einer gemischten Runde mit den Product Ownern − um die Erkenntnisse bedarfsgerecht zu strukturieren. Hier wählten wir die Fragestellung mit den breitesten Streuungen in den Ergebnissen heraus, analysierten diese und diskutierten folgende Fragen:

• Warum kommt es teilweise zu einer großen Streuung bei den Einschätzungen?
• Was sind mögliche Ursachen?
• Wie können diese Impediments beseitigt werden?

Die Ergebnisse zielten in zwei Richtungen. Auf der einen Seite gab es hilfreiche Empfehlungen für die Verbesserung und Weiterentwicklung des Fragebogens. Auf der anderen Seite erhielten wir wertvolle Impulse, um konkrete Handlungsfelder und mögliche Maßnahmen abzuleiten. Hierbei entstand aus den konsolidierten Arbeitsergebnissen im Nachgang ein Dokument, welches neben aktuellen Herausforderungen und zugehörigen potenziellen Lösungsansätzen auch etablierte Vorgehen bzw. Best-Practices zu den Handlungsfeldern bereitstellt. Dieses dient den Teams heute schon als Möglichkeit, ihren Umgang mit Requirements Engineering zu verbessern. Gleichzeitig ist das Dokument ein Leitfaden für die zentralen Unterstützungseinheiten, in welchen Themenfeldern weitere Verbesserungen erzielt werden können.

Fazit

Einige der erkannten Herausforderungen bzw. Impediments wurden im Laufe des letzten Jahres bereits behoben. Um z.B. regelmäßiger und intensiver Kundeneinbezug durchführen zu können, wurde eine separate Rolle User Researcher eingeführt. Dem Bedarf nach effektiverer Überprüfung der Ergebnisse wird mit einer erweiterten Bandbreite an Unterstützungsangeboten aus der zentralen Qualitätseinheit begegnet. Zusätzliche Hilfsmittel für eine bessere Zusammenarbeit der beteiligten Rollen wurden erarbeitet und zur Verfügung gestellt. Außerdem konnte auch der Fragebogen selbst verbessert werden – so wird zukünftig der Kontext abgefragt, in dessen Bezug die Bewertung und Einschätzung gesetzt werden soll:

• Wie ist das Entwicklungsvorgehen?
• In welcher Technologie ist das Produkt angesiedelt?
• In welcher Phase des Produktlebenszyklus befindet sich das Produkt?

Die Dynamik der Veränderung macht auch vor DATEV nicht Halt. Es wurden u.a. weitere Rollen (z.B. Business Analyst) definiert, deren Aufgaben auch in der Disziplin Requirements Engineering angesiedelt sind. Wenn wir also eine Aussage über den Reifegrad der Disziplin erhalten wollen, müssen wir den Adressatenkreis erweitern. Daraus ergeben sich weitere Fragen, die vor der nächsten Erhebung zu klären sind:

• Müssen für einen sinnvolle Ermittlung der Reife der gesamten Disziplin Requirements Engineering nicht alle am RE-Prozess Beteiligten befragt werden?
• Sollen weiter Einzeleinschätzungen der Rolleninhaber eingeholt werden oder besser die Teams in ihrer Gesamtheit direkt befragt werden?
• Wie kann man eine regelmäßige Erhebung etablieren, welche vor allem auch der Weiterentwicklung der Disziplin in den Teams zugutekommt? (kann der Scrum Master der richtige Fänger bzw. die Team-Retrospektive ein sinnvolles Format sein?)

Dieses Reifegradmodell ist aus einem internen Bedarf der DATEV heraus entstanden. Wir haben allerdings bewusste eine Metaebene gewählt, die auch viele andere Unternehmungen in die Lage versetzt, das Modell für sich zu adaptieren. Dabei wäre es interessant, ob es neben den bereits aufgeworfenen Fragen noch andere Herausforderungen oder Impulse gibt. Nehmen Sie gerne mit uns Kontakt auf und teilen uns Ihre Meinung mit.

 

Hinweise:

Interessieren Sie sich für weitere Erfahrungen aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

[1] CPRE als weltweit anerkannte Zertifizierung des Internation Requirements Engineering Board
[2] Optimieren von Requirements Management & Engineering, Colin Hood, Rupert Wiebel, Springer Verlag 2005
[3] empirische Prozesssteuerung als Kernprinzip von Scrum
[4] PDCA-Zyklus
[5] Fragebogen zur Bewertung des Reifegrads im agilen Requirements Engineering

Das Project Management Institute definiert mit OPM3 auch ein Reifegradmodell. Es adressiert mit einer Sammlung von Best Practices, Konzepten und Methoden „organisatorisches Projektmanagement“.

Veit Joseph hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.