Mit diesem dritten Blogbeitrag sind wir am Ende unserer Serie zu Fragen, die in der agilen Szene [1] große Beachtung finden. Von Generalisten über Spezialisten sind wir nun beim Requirements-Engineer angelangt.

Dieser Blogbeitrag beschäftigt sich mit der Frage, ob es nicht sinnvoll wäre, das Steckenpferd der SOPHISTen, also Requirements-Engineering, in Scrum zu integrieren. Hier gibt es zur Abwechslung einmal eine klare, schnelle Antwort: Ja.  Dieses Ja wird durch den Fakt gestützt, dass die Dokumentation in Projekten häufig von Generalisten erstellt wird. Auch die Tatsache, dass Kommunikation im Scrum großgeschrieben wird und nicht jeder Entwickler daran gewöhnt ist, liefert einen weiteren Grund für die Verstärkung im Scrum-Team. Der Zeitpunkt bzw. die Scrum-Phase, in der es Sinn ergibt, einen Requirements-Engineer zu integrieren, ist allerdings nicht so schnell festzulegen und wird daher in diesem Blogeintrag näher betrachtet.

Sprint Zero

Die Klärung über den Umfang der Dokumentation sollte vor dem Beginn der eigentlichen Produktentwicklung abgeschlossen sein. Das kann z. B. in einem Sprint Zero erfolgen. [2] Für diesen Sprint ist es sinnvoll, einen Requirements-Engineer im Team zu haben. Der Sprint Zero dient dazu, das Gerüst eines Projekts aufzubauen. Der Requirements-Engineer kann bei der System- und Kontextanalyse unterstützen als auch Fragen zur Dokumentation (wie Vor- und Nachteile natürlichsprachlicher und modelbasierter Dokumentation, welche Gliederung usw.) klären.

Sprint Review

Im Sprint Review prüft der Product-Owner, ob das Entwicklungs-Team die für den Sprint ausgewählten User Storys (das Sprint Backlog)  korrekt umgesetzt hat und das Ergebnis die in der Definition of „Done“ und den Akzeptanzkriterien festgehaltene Qualität hat. Auch hier empfiehlt es sich, einen Requirements-Engineer zu Rate zu ziehen. Auch wenn Dokumentation im Rahmen eines agilen Projektes nicht im Vordergrund steht und oft nur als ein Nebenprodukt angesehen wird, erleichtert gute Dokumentation  die Kommunikation im Entwicklungsprozess und fördert das gemeinsame Verständnis des Produkts. Der Requirements-Engineer kann den Product-Owner bei der Qualitätssicherung der Dokumentation (auch außerhalb des Reviews) unterstützen. Wurden z. B. die Standards eingehalten, die im Sprint Zero vereinbart wurden? Wird in der Anforderung der Akteur genannt? Gibt es Begriffe, bei denen nicht ganz klar ist, worum es sich genau handelt, z. B. bei Benutzerrollen oder benötigten Daten (hier verweisen wir auf das SOPHIST REgelwerk, mit dem Dokumentation, also z. B.  Anforderungen und User Stories, auf Qualität geprüft werden kann)? Da während eines Sprints der mündliche Austausch im Vordergrund steht, könnten sich leicht Anforderungsdefekte in die Spezifikation geschlichen haben – denn es ist ja alles klar und gesagt und dann brauchen wir es auch nicht so genau aufzuschreiben.

Product-Owner

In einigen Veröffentlichungen wird der Product-Owner in die Pflicht eines Requirements-Engineers genommen. [3] Als Spezialist kann der Requirements-Engineer den Product-Owner bei folgenden Aufgaben [4] unterstützen: Beim Schreiben und Verfeinern von User Storys (hier haben die SOPHISTen das REgelwerk für Anforderungen angepasst), beim Ausarbeiten von Akzeptanzkriterien, und beim Sprint Planning 1, wenn das Scrum-Team die User Storys diskutiert und beim Product-Owner nachfragt, um Inhalte der User Storys wirklich zu verstehen.

Auch um die Kommunikation zwischen dem Product-Owner und Entwicklungs-Team zu verbessern, kann das Hinzuholen eines Requirements-Engineers hilfreich sein. Er kann die Kommunikationsfähigkeit der Scrum-Teammitglieder fördern, ohne dabei selbst der Kommunikationskanal zu sein. [5] Der Requirements-Engineer übernimmt also nicht die Rolle des Kommunikators im Team, sondern ermutigt das Team vielmehr, selbst zu kommunizieren.

Zum Abschluss eine Beobachtung, die hoffentlich Ihre Kommunikation mit uns erhöht: Viele Beiträge zum Thema Requirements-Engineering und Scrum kommen zu dem Schluss, dass sich Requirements-Engineering sehr gut mit Scrum verträgt. [6]

“[A] better understanding of the base concepts in requirements engineering deepens the understanding of the mechanisms in agile projects.“ [7]

Wenn das kein Grund ist, uns zu kontaktieren! 0911 40 900 0 oder heureka@sophist.de.

———————————————–

Quellen:
[1] Mehr Informationen zu Scrum finden Sie auch neuen Auflage unseres Bestsellers: Chris Rupp & die SOPHISTen: Requirements Engineering und -Management. Aus der Praxis von klassisch bis agil. Hanser 2014.