Blog

Agile Requirements Engineering / Agile Business Analyse – Fünf Prognosen

27 May, 2015
Xebia Background Header Wave

Agilität als Turnaround-Ansatz in grossen Corporate IT Organisationen etabliert sich immestärker. Dadurch werden die klassischen IT-Disziplinen wie z.B. Requirements Engineering respektive Business Analyse bedrängt. Davor warnt auch der diesjährige SwissQ Trends & Benchmarks Report 2015. In diesem Blog wage ich fünf Prognosen, welche Themen im Agilen RE/BA uns wirklich beschäftigen und beschäftigen müssen.

Der SwissQ Trends & Benchmarks Report 2015 hat's belegt. Waren die Organisationen in den Jahren zuvor beschäftigt, RE/BA Methodik, RE/BA Werkzeug, RE/BA Rollen und RE/BA Organisationen auszurollen und zu konsolidieren und man schon debattieren durfte, ob RE/BA endlich "angekommen", professionalisiert worden sei - so scheint jetzt alles wieder zerronnen und verloren.

Trends-2015-RE-Schluesselergebnis-WP-1024x479

Alle die Jahren des mühseligen, ja anstrengenden Aufbaus des RE/BA Berufs in klassischen Corporate IT Organisationen scheinen vergebens. Die Agilität attackiert alle klassischen Rollen und Disziplinen und vereinigt alles im omnipotenten Team. Wozu also benötigen wir noch eine dedizierte RE/BA Rolle und Disziplin in unseren Projektführungssystemen?

Trends-2015-RE-Erfolgsfaktoren-WP-1024x287

Die klassische RE/BA Methodik ist weiterhin erpicht, möglichst vollständige und korrekte Anforderungen produzieren zu können. Diese Erfolgsfaktoren bestätigt auch der SwissQ Trends & Benchmarks Report 2015. Agiles RE/BA widerspricht dem. Im Agilen RE/BA können Vollständigkeit und Korrektheit nicht angestrebt werden. Das Agile kennzeichnet sich dadurch, stets just in time zu liefern, was gerade erforderlich ist - und das gewiss mit dem Vorbehalt, dass man eine lernende Organisation sei und Anforderungen noch nachbessern könne.

In meinem letzten Blog-Beitrag habe ich von meinem Alltag als agiler RE berichtet. Die Erfolgsfaktoren "Vollständigkeit" und "Korrektheit" habe ich darin nie als solche betitelt - weil diese mich eben nicht wirklich herausfordern im agilen Umfeld. Nein, hier möchte ich nun prognostizieren, wie und was Agile RE/BA auf das klassische RE/BA-Tum wirklich wirkt, was uns beschäftigen muss und wird. Dass für das klassische RE/BA der grösste Erfolgsfaktor ist, wie man mit der Agilität zusammenkommt, schenken wir uns heute.

Also, was macht eigentlich:

  1. Agile RE/BA und Spezifizieren von Anforderungen?
  2. Agile RE/BA und Prüfen und Abstimmen von Anforderungen?
  3. Agile RE/BA und Verwalten von Anforderungen?
  4. Agile RE/BA und Organisation?
  5. Agile RE/BA und Ausbildung?

Agile RE/BA und Spezifizieren von Anforderungen?

Ich meine, dass die klassisch typisierte Anforderung als atomares Objekt in einem Word oder sonstigen RE/BA Werkzeug keine zwei Jahre mehr überleben wird. Alles - um einen im RE/BA verpönten Universalquantor zu bemühen - ist eine Anforderung. Eine Anforderung beginnt bei einem Post-It, verwirklicht sich in Screens oder Diagrammen und dokumentiert sich in User Stories.

Im Agilen RE/BA wird niemand eine klassische Requirements Specification gemäss IEEE 830-1998 formulieren wie uns das der durchaus geschätzte IREB CPRE FL Kurs lehrt. Im Agilen RE/BA ist die Spezifikationsform fluid, sehr beweglich, wechselhaft.

Stattdessen werden Diagramme, Visualisierungen, Modelle - ob kurzweilige, langlebige, mit oder ohne Tools - dominieren und die natürlichsprachliche Spezifikation wohl in wenigen Jahren verdrängen.

Agile RE/BA und Prüfen und Abstimmen von Anforderungen?

Alle RE/BA sind aufgewachsen damit, dass eine Anforderung geprüft und abgestimmt werden muss. Hierzu verweisen wir auf klassische Reviewtechniken. Im Agilen RE/BA, das von Prinzipien wie Mut zur Lücke, Geschwindigkeit und Unvollständigkeit-Unvollkommenheit begeistert ist, sind Inspektionen nicht mehr zweckdienlich, die eine lange, schlimmstenfalls sechsmonatige Spezifikationsphase beenden. Im Agilen RE/BA werden kurze und knappe Walkthroughs und schlanke Prototypen klassische Inspektionen ersetzen.

Wie schon das Spezifizieren ist auch das Prüfen und Abstimmen liquid, stets in iterativer Bewegung. Das klappt aber bloss, wenn sich die Projektbeteiligten einander vertrauen. Vertrauen ist für mich nämlich ein wesentlicher Erfolgsfaktor für die gelungene Projektdurchführung - so auch ein agiles Prinzip.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile RE/BA und Verwalten von Anforderungen?

Der klassische RE/BA fordert, dass alle Anforderungen in einem entsprechenden Werkzeug systematisch-ordentlich organisiert werden müssen. Eine Anforderung ist also mindestens kategorisiert, versioniert, priorisiert und ein statusbehaftetes Objekt. Mit diesen Werkzeugen können wir klassische Metriken auswerten - IREB differenziert hier z.B. zwischen Produkt- und Prozesskennzahlen.

Im agilen RE/BA ist alles anders. Einzelne Anforderungselemente schwirren auf Modellen, als Post-Its auf Boards oder konstituieren sich erst im persönlichen Gespräch. Sie werden nicht mehr zentral verwaltet, sondern verpuppen sich in Backlog Items und werden schlüpfen, wenn sie einem Sprint zugeordnet sind. Das Team wird bloss an der Velocity gemessen. Der wichtigste Status ist dabei done. Niemand wird einem sperrigen RE-Werkzeug nachtrauern.

Agile RE/BA und Organisation

Die agile Bewegung zerschlägt alle jene RE/BA Mono-Organisationen, die in den letzten Jahren teils viel investierten, eine mehr oder weniger ausgeprägte RE/BA Methodik zu grundieren. Agilität will aber alle Disziplinen vereinen und gemeinsam zum Ziel - endlich erfolgreichere Projekte - führen. Und eben das ist der grosse Widerspruch.

Gewisse RE/BA Organisationen werden zaudern, andere sich in übergreifende, aber machtlose Pools flüchten. Einige Nachzügler werden sogar in einem Agile RE/BA Framework letzte Hoffnung verspekulieren. Die schweizerische RE/BA Szene verliert jedoch allmählich den organisatorischen Heimathafen. Die RE/BA werden stattdessen den omnipotenten Teams zugeordnet. Wo sie in der Betriebsbuchhaltung zugerechnet werden, ist dann einerlei.

Agile RE/BA und Ausbildung

Die Lehrpläne der klassischen RE/BA Ausbildungen sind noch nicht für das agile Zeitalter aktualisiert. BABOK, der Standard des IIBA, siehe auch Chris' Blog-Serie, hat die sogenannte Agile Extension publiziert, die das BABOK Framework auf die agile Welt transportiert. Der konkurrierende Standard IREB hat derzeit keinen vergleichbaren Agile-Aufsatz. Stattdessen hat IREB eine Abhandlung publiziert, dass der IREB nicht veraltet sei und auch fürs Agile RE/BA gelte.

iSQI hat den Markt für Agile RE/BA Ausbildungen momentan monopolisiert, der Certified Agile Business Analyst (CABA) ist die einzige mir bekannte - und natürlich von SwissQ angebotene - Ausbildung, die sich explizit an Agile RE richtet. Da aber die konkreten Tätigkeiten eines Agile RE/BA nicht standardisiert sind und je nach Ausprägung des Projekts, Teams und des Agile RE/BA selber variieren können - und sich somit die Rolle des Agile RE zunächst stabilisieren muss, warten wir kurzfristig vergebens auf ein international genormtes Agile RE/BA Vorgehen.

Und was empfiehlt SwissQ?

Agilität ist endlich angekommen. Erfolgreiche Projekte bedingen weiterhin RE/BA Fähigkeiten - daran wird sich vorläufig nichts ändern. Denn die Komplexität und Kompliziertheit der schweizerischen Projekte gebieten, eben RE/BA Fähigkeiten zu mobilisieren.

SwissQ sagt, dass die Agile RE/BA Tätigkeiten auf ihr Projekt abgestimmt werden müssen. Was benötigen und fordern PO und Team? Gehört der Agile RE/BA zum Entwicklungs- oder PO-Team? Ist der Agile RE/BA technisch oder fachlich versierter?

Wir unterstützen sie gerne, ihren Agile RE/BA Skills einen neuen Platz in ihrem Unternehmen zu finden. Beginnen sie mit fünf kleinen Schritten in ihrem Team, die wir hier empfehlen:

  1. Schaffen sie Agile RE/BA Aufwand transparent in ihrem Sprint, indem sie diese Tasks farblich hervorheben
  2. Verschieben sie ihre Agile RE/BA organisatorisch zu den Teams, lassen sie aber ihre Agile RE/BA in Pools gruppiert
  3. Definieren sie einen leichtgewichtigen Sprint-Vorbereitungsprozess (Grooming, Preperation, Sprint Planning, etc.) mit Kanban, welchen ihre Agile RE/BA zusammen mit ihrem PO ausführen
  4. Fördern sie das Verständnis, das Vertrauen der Just In Time Spezifikation ihrer Agile RE/BA mit einer kurzen Agile Einführung
  5. Nutzen sie Pair "Writing" für User Stories, PO und Agile RE/BA zusammen und etablieren sie "Muster", wie sie User Stories schneiden

SwissQ kann auf Projekte referenzieren, wo wir den Agile RE/BA unterschiedlich einsetzen und damit Projekte zum Erfolg begleiten durften und weiterhin dürfen. Besuchen sie uns an unserem Stand am diesjährigen Swiss Requirements Day in Zürich. Unsere Agile RE/BA werden gerne von ihrem Agile Alltag erzählen.

Questions?

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