Braucht ein agiles Projekt einen Requirements Engineer?

In der Applikationsentwicklung und Applikationsintegration ist ein agiles Projektvorgehen heute Standard. Dabei werden bekannte agile Vorgehensweisen wie beispielsweise Scrum oder SAFE eingesetzt, um die Applikation stückchenweise und iterativ zu entwickeln oder zu integrieren. So entsteht ein Produkt mit höchstmöglichem Kundennutzen und in optimaler Qualität. In den agilen Vorgehensweisen ist die Rolle des Requirements Engineers aber gar nicht explizit definiert. Requirements Engineer

Braucht es daher in einem agilen Projekt gar keinen Requirements Engineer? Wir nehmen als Beispiel die agile Vorgehensweise „Scrum“, um dieser Frage auf den Grund zu gehen. Dazu schauen wir uns an, wie die Entwicklung und Einführung einer Applikation bei Scrum vonstatten geht.

Die Organisation

Das Scrum Team setzt sich typischerweise aus den bekannten Rollen des Product Owners und des Entwicklungsteams zusammen und wird durch den Scrum Master unterstützt. Dem Team steht oft auch ein Business Analyst zur Verfügung, welcher entweder direkt im Team eingebunden ist oder es unterstützt. Das Team kann somit mit der Entwicklung starten.

Das Vorgehen

Mit Hilfe der verschiedenen Scrum Zeremonien wie beispielsweise dem Sprint Planning und Review, dem Daily Standup oder der Sprint Retrospektive wird das Backlog konsequent abgearbeitet und Ergebnisse rasch erzielt. Dabei werden die bereits vorhandenen User Stories durchgehend verfeinert, neue Ideen in neuen User Stories festgehalten und in den folgenden Sprints umgesetzt.

Die zu entwickelnde Komponente oder Applikation wird mit jedem Sprint erweitert. Dies erlaubt eine frühe Rückmeldung der Stakeholder und trägt dazu bei, die Qualität der Applikation stetig zu verbessern.

Abbildung 1: Agiles Vorgehen nach Scrum

Soweit tönt doch alles ganz gut – wo liegen denn nun die Herausforderungen?

Häufigste Gefahren und wie Sie diese vermeiden können

• Beim agilen Vorgehen kann nicht erst mit der Entwicklung gestartet werden, wenn alle Anforderungen bekannt sind. Es besteht jedoch die Gefahr, dass die wichtigsten Geschäftsanforderungen noch nicht feststehen und die Entwicklung daher nicht zielgerichtet voranschreitet.

⇒ Legen Sie noch vor dem Start der Entwicklung fest, wo die Reise hingehen soll! Stellen Sie sicher, dass entweder ein abgenommener Business Case besteht oder dass eine Produktvision und die darin erarbeiteten Zielgruppen, Nutzenversprechen, Produktvorstellungen und Geschäftsziele mit den Stakeholdern abgestimmt sind. Dadurch lässt sich auch einfacher auf das Minimal Viable Product (MVP) schliessen und die Priorisierung des darauf ausgerichteten Backlogs prüfen.

• Durch die kurzen Iterationszeiten und dem Anspruch einer nach jedem Sprint lauffähigen Software werden hohe Erwartungen an das Scrum Team gestellt. In User Stories formulierte Anforderungen, welche zu Beginn des Sprints noch nicht fein genug definiert sind, müssen gegebenenfalls innert kürzester Zeit mit den Stakeholdern abgestimmt und präzisiert werden. Dies kann vor allem bei Anforderungen mit grossen Abhängigkeiten dazu führen, dass Entscheide überhastet gefällt werden, ohne dass deren Auswirkungen wirklich bekannt sind. So besteht beispielsweise das Risiko, dass sich wiedersprechende Anforderungen erst zu einem späteren Zeitpunkt entdeckt werden und dadurch ein Teil der Applikation stark überarbeitet werden muss.

⇒ Legen Sie klar fest, welche Anforderungen in welchem Detaillierungsgrad beschrieben werden müssen und prüfen Sie deren Auswirkungen auf andere Anforderungen, bevor diese für die Umsetzung im Sprint Backlog freigegeben werden. Nutzen Sie dazu ebenfalls bekannte Modellierungstechniken, um das gemeinsame Verständnis zu fördern und Abhängigkeiten zu bestimmen.

• Durch die Möglichkeit, kontinuierlich Feedback von Stakeholdern zu erhalten und damit die umgesetzten Anforderungen zu überprüfen, können Verbesserungen an der Applikation schnell vorgenommen werden. Ebenfalls können dadurch weitere nützliche funktionale Ideen an die Applikation entstehen, welche die Customer Journey oder den Nutzen verbessern. Eine agile Vorgehensweise ist grundsätzlich ideal dazu geeignet, auf neue Anforderungen zu reagieren. Es gilt aber, neben diesen positiven Aspekten darauf zu achten, dass das eigentliche Ziel nicht aus den Augen verloren wird.

⇒ Prüfen Sie, ob das Feedback und die daraus entstehenden Anforderungen immer noch der Produktvision entsprechen. Bevor die neuen Anforderungen final spezifiziert werden und den Weg ins Sprint Backlog finden, muss zudem ein Abgleich mit dem Business Case stattfinden.

Und wo bleibt nun der Requirements Engineer?

Bereits durch die obenstehenden häufigsten Gefahren sollte die Notwendigkeit eines Requirements Engineers beziehungsweise eines Requirements Engineering deutlich geworden sein. Dass diese in den agilen Vorgehensweisen nicht auftauchen, liegt dabei aber eher am Ursprung dieser Vorgehensweisen aus der Applikationsentwicklung und nicht an deren fehlender Notwendigkeit. Die Applikationsentwicklung erwartet, dass eine klare Vision und stabile Geschäftsanforderungen durch den Auftraggeber geliefert und verwendet werden können. Das Vorgehen Scrum wurde dabei ursprünglich für die agile Entwicklung von kleineren Vorhaben konzipiert. Für die agile Umsetzung von Grossvorhaben fehlte aber die Erfahrung. Der Product Owner musste daher auch die Fähigkeiten des Requirements Engineers ins Team bringen, um es mit entsprechenden Anforderungen zu versorgen. Erfahrungen haben gezeigt, dass dies den Product Owner gerade bei grösseren Applikationen vor zahlreiche Herausforderungen stellen kann und dieser nicht all seinen Pflichten zeitgerecht und in der entsprechenden Qualität nachkommen kann.

Um auch grössere Vorhaben erfolgreich umsetzen zu können, sollten die nachfolgenden Grundsätze eingehalten werden.

Grundsätze zur Umsetzung grösserer Vorhaben mit agiler Vorgehensweise

• Stellen Sie sicher, dass sämtliche Teammitglieder und Stakeholder verinnerlicht haben, was die Vision des Produktes ist und wie diese gemeinsam erreicht werden kann.
• Stellen Sie ebenfalls sicher, dass noch vor dem Entwicklungsstart das Vorgehen, wie die Anforderungsermittlung, -dokumentation und -verwaltung (Requirements Management Prozess) in den agilen Entwicklungsprozess integriert werden kann, klar definiert ist. Ebenso, dass ein durchgängiger Detaillierungsgrad der Anforderungserfassung (Requirements Information Modell) festgelegt ist.
• Überlegen Sie sich, ob und wie Sie den Product Owner am besten durch den gezielten Einsatz eines Business Analysten und Requirements Engineers unterstützen könnten. Folgende Varianten haben sich bisher in der Praxis bewährt:

Kleinere Anpassungen an einer Applikation

Der Product Owner (PO) benötigt wahrscheinlich keine Unterstützung und kann innerhalb des Topics sowohl seine, als auch die Rolle des Business Analysten / Requirements Engineer (BA / RE) wahrnehmen.

Abbildung 2: Product Owner nimmt auch die Rolle des Business Analysten / Requirements Engineer wahr

Grössere Anpassungen oder Erweiterungen an einer Applikation

Bilden Sie ein enges Team zwischen dem PO und dem BA / RE. Bei grösseren Applikationen werden die anzupassenden Teile meist in mehrere Topics (Themen) und mehrere Teams aufgeteilt. Der PO kann in diesem Fall durch mehrere BA / RE unterstützt werden. Im Zentrum liegt dabei oft die Erweiterung des Funktionsumfangs der Applikation.

Abbildung 3: Unterstützung Product Owner bei Neuentwicklung

Integration einer neuen Applikation

Der BA / RE stellt sicher, dass die neue Applikation ohne Einschränkungen in die bestehende Applikationslandkarte eingegliedert werden kann und keine Einschränkungen für die Organisation entstehen. Das heisst, im Fokus steht die Erhaltung der bestehenden Funktionen auf den Umsystemen. Die Umsysteme müssen also wieder mit denselben Daten versorgt werden, um die Funktionalität weiterhin gewährleisten zu können. Das Verhalten der Umsysteme, die Customer Journey oder die Anwendungsabläufe werden dabei nicht verändert.

Abbildung 4: Unterstützung Product Owner bei Integration einer neuen Applikation

Besonderheiten bei der Integration einer umfangreichen neuen Applikation

Stellen Sie bereits beim Projekt-Setup sicher, dass Sie die agilen Teams mit den richtigen Fähigkeiten besetzen. Die Teamzusammensetzung hängt dabei sehr stark von der zu erledigenden Aufgabe ab. Wählen Sie bei grösseren Vorhaben eine Projektorganisation und eine Aufteilung der Arbeitspakete, welche es den Teams ermöglicht, mit möglichst geringen Abhängigkeiten zu arbeiten. Fassen Sie Arbeitspakete logisch in Topics zusammen, um Abhängigkeiten zu reduzieren und die Kommunikation zu vereinfachen. Die Expertise eines Requirements Engineer bei deren Definitionen stellt dabei sicher, dass einer erfolgreichen Applikationsintegration nichts mehr im Wege steht!

Abbildung 5: Integration einer umfangreichen neuen Applikation

Lesen Sie in einem unserer folgenden Blogs, wie Sie die Valion Requirements Engineering Methodik dabei unterstützt, Ihre Applikation konsequent und über alle Bereiche hinweg auf die Bedürfnisse Ihrer Kunden und Anwender auszurichten und damit ein bestmögliches Kunden- und Anwendererlebnis zu bieten. Requirements Engineer

Möchten Sie keinen Blog mehr verpassen, dann folgen Sie uns auf LinkedIn.