26. Oktober 2018
| |
0 Kommentar

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.

Requirements Engineer

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

⇒ 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.

⇒ 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.

⇒ 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

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.

Requirements Engineer

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.

Requirements Engineer

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.

Requirements Engineer

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!

Requirements Engineer

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.

Jean-Marc Riser
Jean-Marc Riser
Senior Solution Architect

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert