Blog

Die Rollen des PO, RE und BA im Vergleich

07 Sep, 2015
Xebia Background Header Wave

Während einer Bahnfahrt ist eine Diskussion zwischen einem der jüngsten und einem der ältesten Business Analysten der SwissQ über das Thema BA/RE Skills in Agil entstanden. Dies war die Grundlage zu diesem Blog. Lesen sie selbst...

Die Business Analyse (BA) / Requirements Engineering (RE) Szene befindet sich in einem Umbruch. Die Community, die jahrelang um die Anerkennung der Rolle BA/RE in der Schweizer IT-Welt gekämpft hat, wird vom immer stärkeren Trend hin zu agiler Softwareentwicklung (siehe auch SwissQ Trends & Benchmarks Report) stark beeinflusst. Dabei wird das Thema BA/RE in Scrum oder Kanban nicht explizit erwähnt. Bedeutet dies, dass die Aufgaben der klassischen BA/RE nicht mehr vorhanden sind und heisst es auch, dass die Ausbildung und Erfahrung der klassischen BA/RE nichts mehr Wert ist?
Wie würden Sie in der Rolle eines Budgetverantwortlichen gerade jetzt entscheiden, wenn ein Teammitglied bei Ihnen den Antrag für einen Zertifikatskurs zum Thema Requirements Management stellen würde?

In diesem Blog fragen wir uns, welche klassischen BA/RE Disziplinen in Agil von Nutzen sind und in welchen Rollen sie zum Tragen kommen.

Agile Rollen und ihre Tätigkeiten

Auch im agilen Umfeld muss Requirements Engineering betrieben werden. Dies wird jedoch nicht dediziert getan, sondern durch verschiedene Rollen ausgeführt. Schauen wir uns typische Rollen aus den agilen Projekten und deren Tätigkeiten zum Thema Requirements Engineering doch mal genauer an:

  • Nach Scrum hat der Product Owner (PO) die Aufgabe die richtige Funktionalität in der richtigen Priorität ins Projekt zu bringen. Dazu ist es wichtig seine Kunden und Benutzer zu kennen und auch von deren Bedürfnissen und Abläufen eine Ahnung zu haben. Weiterhin muss der PO gute kommunikative Fähigkeiten und Moderations-Skills haben, um Anforderungen zu erheben und entsprechend der Kundenwünsche zu priorisieren. Daraus abgeleitet erscheinen die folgenden wichtigsten Skills für POs sehr wünschenswert:
    • Stakeholder Analyse
    • Erhebungstechniken
    • Konfliktmanagement
    • Prioriserung (z.B. Priority Poker)
  • Die Rolle Business Analyst (BA) wird in Scrum nicht explizit erwähnt, ist jedoch in vielen agilen Projekten vorhanden. Diese Rolle unterstützt den Product Owner bei der Erhebung fachlicher Anforderungen und der Prüfung, ob und wie die Anforderungen zu den Geschäftsprozessen passen. Weiterhin unterstützt der Business Analyst den PO beim Erarbeiten fachlicher Akzeptanzkriterien für die Anforderungen. Hier wird fachliche Erfahrung und Branchen-Know-How benötigt, zudem sollte der BA über die folgenden wichtigsten Skills verfügen:
    • Stakeholder Analyse
    • Kreativitätstechniken
    • Erhebungstechniken
  • Auch der Requirements Engineer (RE) ist nicht in Scrum definiert. Trotzdem findet sich diese Rolle ebenfalls in vielen agilen Projekten. Der Requirements Engineer hat die Aufgabe die Anforderungen nachhaltig zu spezifizieren und dabei auf die Übersetzung der Anforderungen in die technische Umgebung zu achten. Die folgenden wichtigsten Skills für den RE werden ebenfalls im agilen Umfeld sehr geschätzt:
    • Stakeholder Analyse
    • Kreativitätstechniken
    • Erhebungstechniken
    • Dokumentationstechniken
    • Modellierung von Anforderungen (typischerweise mittels UML)
  • Last but not least gibt es weiterhin den Tester. In agilen Projekten oftmals Embedded Tester genannt. Auch diese Rolle sucht man in Scrum vergeblich. Diese Rolle hat folgende wichtigste Tätigkeiten:
      • Analysieren der User Stories auf ihre (Qualitäts-) Risiken
      • (Mit -) Definieren der Akzeptanzkriterien
      • Prüfen der Akzeptanzkriterien auf ihre Testbarkeit
      • Prüfen der Akzeptanzkriterien inkl. Testdaten
      • Sicherstellen der Traceability zwischen User Story und Test

    Um diese Tätigkeiten qualitativ auszuführen bedarf es u. a. guter Kommunikation, analytischer Kenntnisse und methodisches Vorgehen.

Analoge Fähigkeiten und Aufgaben wie im klassischen BA/RE

Wenn man die oben beschriebenen Tätigkeiten der agilen Rollen genauer betrachtet, fällt einem die Verbindung zum klassischen BA/RE auf. Tätigkeiten, welche früher durch den BA/RE durchgeführt wurden, sind nun auf verschiedene Rollen verteilt. Die dafür geforderten Fähigkeiten sind ebenfalls bei klassischen BAs/REs zu finden.

Fazit

Die Techniken die im klassischen RE wichtig waren und sind, helfen auch in agilen Projekten

  • Dokumentation - sicherlich wird agil anders dokumentiert wie in klassischen Projekten:
    • So wird die Dokumentation nicht mehr Monate im Voraus erstellt, sondern bei Bedarf. Und Normierungen wie z.B. die Satzschablone sind nicht mehr gefordert. Erlaubt ist, was hilft.
    • Aber gerade wenn ein Produkt weiterentwickelt wird zeigt die Erfahrung, dass es eine Dokumentation braucht, welche eine Verbindung von einer Anforderung zum Business Value dokumentiert. So ist man bei Änderungen und Erweiterungen ungleich sicherer und somit auch schneller anstatt erst bei der Implementierung zu bemerken, dass es einen Grund hatte wieso das Produkt so funktioniert und nicht anders.
  • Die Anforderungen müssen erkannt, erhoben, konsolidiert und gemanagt werden. Dabei spielt es eine untergeordnete Rolle wie sie umgesetzt werden.
  • Menschen bleiben auch bei agilen Vorgehen Menschen. Es ist also für die Beteiligten BA/RE nach wie vor essentiell, dass sie kommunikativ sind und mit Konflikten umgehen können.

Daher sind die die Techniken die in den IREB-Kursen (Foundation Level, Requirements Modeling und Elicitation & Consolidation) gelernt werden sicher eine solide Basis, auch für agile Projekte und auch eine gute Ausgangslage für den CABA Kurs, da in diesem vor allem auf die agilen Ansätze eingegangen wird. Für die Tester gibt es etwas Analoges von ISTQB  den Agile Tester.
Würden Sie nun den oben beschriebenen Antrag bewilligen?

Und ganz neben bei gesagt, wir von SwissQ suchen zur Erweiterung unseres stetig wachsenden BA/RE Teams, Mitarbeiter die bereits mit BA/RE Themen Erfahrung haben. Dabei spielt es eine untergeordnete Rolle, ob diese in klassischen oder agilen Projekten erworben wurde. Mehr...

Questions?

Get in touch with us to learn more about the subject and related solutions