Agile Methoden / 16.01.2020 / Florian Maier

Setups für agiles Requirements Engineering

Welches Bild verbinden Sie mit Requirements Engineering (RE)? Denken Sie dabei an das Projekt, in dem eine 1000-seitige Feinspezifikation erstellt wurde, die im Moment ihrer Entstehung schon überholt war? Oder denken Sie dabei an das Projekt, in dem das agile Team regelmäßig den Anwendern das Zwischenergebnisse präsentierte um Feedback einzuholen?

Unabhängig davon, welches Bild Ihnen in den Sinn kommt, zeigen die beiden Extreme eine Gemeinsamkeit: das Streben danach, Anforderungen möglichst gut zu verstehen und umzusetzen, wird als der Schlüssel zu einem erfolgreichen Produkt wahrgenommen.

Das erste Bild wird voraussichtlich in der Praxis immer seltener zu beobachten sein, da immer mehr Unternehmen eine agile Transformation als Voraussetzung für den Erhalt ihrer Wettbewerbsfähigkeit einschätzen. Eine 2019 veröffentliche Studie bringt diese Existenzfrage bereits im Titel „Agile or irrelevant“[1] zugespitzt auf den Punkt. Vor diesem Hintergrund stellt sich umso mehr die Frage, in welcher Form das Requirements Engineering als zentraler Faktor für eine erfolgreiche Produktentwicklung in einen agilen Kontext eingebettet werden kann. Im Folgenden werden hierzu drei Varianten einer Rollenaufteilung in einem agilen Kontext beispielhaft für Scrum bzw. SAFE vorgestellt. Scrum ist hierbei laut der „13th annual State of Agile survey“[2] mit 72% Anteil das aktuell meistverbreitete agile Vorgehensmodell, das Scaled Agile Framework (SAFE) nimmt mit 30% den ersten Platz unter den skalierten agilen Modellen ein.

 

Der offizielle Scrum Guide definiert drei Rollen, wovon potenziell zwei Aufgaben aus dem Bereich des RE übernehmen können:

  • Der Product Owner hat die Aufgabe, den Wert des Produkts zu maximieren. Er ist für die Inhalte des Product Backlogs als zentrale Quelle für Anforderungen an dieses Produkt verantwortlich.
  • Das Entwicklungsteam liefert nach jedem Sprint ein auslieferbares Inkrement, das die Definition-of-Done erfüllt. Bei diesem Inkrement handelt es sich häufig um Software, jedoch kann auch eine Anforderung selbst als Inkrement betrachtet werden.

 

Der Scrum Guide lässt die Frage offen, wie Anforderungen in das Product Backlog gelangen. Eine Antwort hierauf gibt beispielsweise das International Requirements Engineering Board (IREB), das folgende Rolle definiert:

  • Der Requirements Engineer befasst sich mit der Ermittlung, Abstimmung, Dokumentation und Verwaltung von Anforderungen und greift hierzu auf Methoden wie beispielsweise Befragungstechniken, modellbasierter Dokumentation oder Konfliktlösungstechniken zurück.

 

Damit ergeben sich drei grundsätzliche Varianten, wie die Tätigkeiten des RE auf die Rollen verteilt werden können.

  • Variante 1: Der Product Owner übernimmt selbst die Rolle des Requirements Engineers.
  • Variante 2: Der Product Owner gibt RE Aufgaben an das Entwicklungsteam weiter.
  • Variante 3: RE Aufgaben werden durch einen oder mehrere Requirements Engineers außerhalb des Scrum Teams wahrgenommen.

 

Unter welchen Voraussetzungen bieten die Varianten welche Vor-und Nachteile? Hierzu finden Sie im Folgenden drei Beispiele für Projektsituationen, die eindeutig für jeweils eine der drei Varianten sprechen.

 

Beispiel Variante 1

Bei den Stakeholdern handelt es sich um eine kleine Gruppe von „On-Site-Customer“ mit hoher Verfügbarkeit. Kurzfristige Abstimmungen zwischen dem Product Owner und den Stakeholdern sind jederzeit möglich. Die Stakeholder nehmen bei Bedarf an Reviews teil und geben Feedback zum Sprint-Inkrement. Der Product Owner trifft im Hinblick auf die Wertmaximierung des Produkts die Entscheidung, welche Anforderungen ins Backlog aufgenommen werden. Zur Dokumentation von Anforderungen existieren keine externen Vorgaben, d.h. das Team entscheidet, welcher Dokumentationsumfang zweckmäßig für die Erreichung des Sprintziels ist. Außerdem hat der Product Owner bereits Erfahrungen im RE und bringt die nötigen Skills wie analytisches Denken und Kommunikationsfähigkeit mit. Durch kurze Wege zu den Stakeholdern und seiner Erfahrung im RE kann der Product Owner selbst alle Tätigkeiten im RE abdecken, ohne dass deshalb die Verfügbarkeit für das Entwicklungsteam bei Rückfragen leidet. Aufgrund der Personalunion als Product Owner und Requirements Engineer bildet er damit das entscheidende Bindeglied zwischen den zukünftigen Anwendern und dem Entwicklungsteam.

 

Beispiel Variante 2

Die im Bereich RE Engineering anfallenden Aufgaben können auf Grund ihrer Komplexität und der Zahl der zu berücksichtigten Stakeholder nicht von einer Person alleine abgedeckt werden. Der Product Owner entscheidet sich deshalb, RE Aufgaben an das Entwicklungsteam weiterzugeben, das über die entsprechenden Erfahrungen und Skills verfügt. Das Entwicklungsteam ermittelt und stimmt Anforderungen selbstorganisiert mit den Stakeholdern ab und erstellt Stories, über deren Aufnahme in das Product Backlog der Product Owner final entscheidet.  Da im Entwicklungsteam mehrere Teammitglieder über Kenntnisse im RE verfügen, ergibt sich die Möglichkeit, Abstimmungstermine auch mit mehreren verteilten Stakeholder-Gruppen zu parallelisieren und somit entsprechend der anfallenden Aufgaben zu skalieren. Das Product Backlog enthält einerseits Stories, die eine klassische Entwicklungstätigkeit erfordern, andererseits Stories, die auf die Erfassung von Anforderungen zielen. Diese Zweiteilung setzt sich auch in der Definition-of-Done sowie in der Retrospektive fort. Da das Team bereits einen hohen Reifegrad in Bezug auf agile Zusammenarbeit erreicht hat, beeinträchtigt dies nicht die Sprint-Velocity oder das Zusammengehörigkeitsgefühl des Teams. Durch die Ermittlung und Umsetzung von Anforderungen innerhalb eines Teams sinkt das Risiko von Missverständnissen bei der Umsetzung von Anforderungen.

 

Beispiel Variante 3

Die Stakeholder sind weltweit verteilt, weshalb auf Grund von Sprachbarrieren und Zeitverschiebungen die Durchführung von Workshops direkt vor Ort favorisiert wird - teilweise unter Beteiligung von Dolmetschern. Bei der Dokumentation der Anforderungen müssen sowohl gesetzliche Vorgaben als auch unternehmensseitige Vorgaben für interne Revisionen berücksichtigt werden. Das agile Team ist eingebettet in einen skalierten agilen Kontext (wie etwa SAFE) und arbeitet in synchronen Sprint-Takts parallel zu anderen Teams an einer Teilkomponente der zukünftigen Anwendung. Anforderungen werden zunächst zentral durch Requirements Engineers in Zusammenarbeit mit den Stakeholdern auf einer Feature-Ebene erfasst und abgestimmt. In einem zweiten Schritt erfolgt durch eine übergeordnete Programm-Ebene die Zuordnung, welche Teams die Umsetzung dieser Anforderungen übernehmen. Auf Basis dieser Vorgaben leitet der Product Owner konkrete Stories ab, priorisiert diese und stellt die Qualität der Ergebnisse sicher.

Abstrahiert man von diesen drei konkreten Beispielen, kann die Beantwortung folgender Fragestellungen dabei helfen, eine durchdachte Entscheidung für eine der drei Varianten zu treffen:

  • Welche und wie viele Stakeholder müssen berücksichtigt werden?
  • Welcher Aufwand in Bezug auf RE Tätigkeiten ist zu erwarten?
  • Welche Skills und Erfahrungen im RE sind im Entwicklungsteam und beim Product Owner vorhanden? 
  • Welche Erfahrungen in Bezug auf eine agile Vorgehensweise sind beim Entwicklungsteam und beim Product Owner vorhanden?
  • Welche Kommunikationswege sind besonders kritisch oder anfällig für Missverständnisse?
  • Welche externen Vorgaben zur Anforderungsdokumentation müssen berücksichtigt werden?
  • Welche Abhängigkeiten bestehen zu anderen Teams?

Und falls sich nun trotz intensiver Beschäftigung mit der Frage nach dem richtigen Setup später herausstellt, dass eine andere Variante vielleicht die bessere wäre? Auch auf diese Frage gibt es eine „agile“ Antwort: „inspect and adapt“.

[1] KPMG International, Agile or irrelevant, 2019, https://assets.kpmg/content/dam/kpmg/xx/pdf/2019/05/kpmg-global-ceo-outlook-2019.pdf

[2] CollabNet VersionOne, 13th annual State of Agile Report, 2019, https://www.stateofagile.com/

Einblicke

Shaping the future with our clients