RE ist tot - lang lebe die User Story?

Requirements Engineering hat in den letzten Jahren etwas von seinem Status eingebüsst. Mit dazu beigetragen hat vermutlich der Fakt, dass man in agilen Projekten endlich die mühevoll erstellten und schweissgetrieben freigegebenen Spezifikationen losgeworden ist. Eines der fassbaren Hauptergebnisse des Requirements Engineering. Was zu tun ist, definiert einzig und alleine das Backlog mit seinen User Stories. Doch ist das die ganze Wahrheit? Wie erfahren wir überhaupt, was der Benutzer / die Benutzerin will? Und wer ist nochmals meine Benutzerin? Dürfen wir jetzt nicht mehr von Use Cases, Satzschablone, Ablaufdiagrammen usw. sprechen? Nur noch von Story Maps, User Stories und User Journeys? RE ist tot?

Das agile Manifest spricht von "Reagieren auf Veränderung mehr als das Befolgen eines Plans". Einen Plan / eine Stossrichtung zu haben ist also alles andere als falsch. Aber ich muss in der Lage sein, diesen Plan veränderten Gegebenheiten anzupassen. Oder aus der Sicht des Requirements Engineering: Ich muss kontinuierlich Anforderungen erheben, dokumentieren, priorisieren und löschen. Das RE ist also mitnichten tot, vielmehr ist die Deadline für die Abgabe einer Spezifikation gestorben.

Um diesen kontinuierlichen Wandel zu beherrschen, gibt es einige wundervolle agile Methoden. Zuvorderst das Konzept der User Story. Steigt aber die Komplexität, steigt auch das Bedürfnis nach Techniken, um den Überblick wahren zu können. Für die Ablauforganisation gibt es bereit eine breite Auswahl an Frameworks und Methoden (Stichwort Scaled Agile), um der Komplexität Herr zu werden. Und wie sieht es für das Requirements Engineering aus?

Wir sind bereits top vorbereitet. Jede*r von uns hat den persönlichen Rucksack prall gefüllt mit klassischen und agilen Methoden und einer Menge Erfahrung in der Konversation mit Stakeholdern. Dieser Wissens- und Methodenschatz hilft uns im agilen RE. Aber zu welchem Zeitpunkt können oder sollen wir welche Methode einsetzen? Im klassischen RE war die Beantwortung dieser Frage leicht. Wir haben eine sechsmonatige Analysephase und am Ende wird eine freigegebene Spezifikation mit den Anforderungen, einem Use Case Diagramm mit den Use Case Beschreibungen und weiteren nützlichen Modellen erwartet. Vollständig und in sich konsistent. Weil das faktisch unmöglich war gabs noch einen komplizierten Change Management Prozess gratis dazu. In agilen Vorhaben befinden sich die Anforderungen immer auf unterschiedlichen Detailierungsebenen. Während User Story X bereits implementiert ist, haben wir bei User Story Y noch keine Ahnung, was dem Stakeholder genau vorschwebt und was das bringen soll. Wir müssen lernen zu erkennen, in welchem Stadium sich eine Story befindet und welche Methoden und Techniken aus der agilen und klassischen Welt zu diesem Zeitpunkt für diese Story den meisten Mehrwert bringen, um Vorwärts zu kommen.

Mit dem am Speech vorgestellten Concept Model für die Kombination von agile und klassische Methoden im Kontext eines agilen Projekts (ACCT - Agile and Classic Combined Technique) ordnet der Vortragende die unterschiedlichen Werkzeuge den unterschiedlichen Stadien einer User Story zu. Er geht dabei nochmals auf den Kern und die Idee von Stories ein (C-Card, C-Conversation, C-Confirmation) und zeigt auf, wie dieser mit ACCT bewahrt werden kann. Weiter erläutert er Ideen, wie erkannt werden kann, bei welcher Story welche Methode am Besten geeignet ist. Da es Unmengen von Techniken gibt und fast täglich neue dazu kommen, spielt auch die selbständige Einordnung von Techniken ins ACCT am Vortrag eine Rolle.

Was lernen die Zuhörer*innen in dem Vortrag?

Die Zuhörer*innen erfahren

  • - wie klassische und agile Methoden & Techniken in Kombination gewinnbringend eingesetzt werden können.
  • zu welchem Zeitpunkt welche Werkzeuge - z.B. Use Case Model, Story Map, Satzschablone, Story schneiden - eingesetzt werden können.
  • von den Risiken und Gefahren beim Einsatz von klassischen Techniken in Kombination mit User Stories.
  • Wie ein Team mit einem auf ihre Bedürfnisse und Kontext zugeschnittenen ACCT-Modell eine Bibliothek von Techniken erhält, in welcher es sich bei Bedarf bedienen kann.
Benjamin Wyss
Benjamin Wyss

Die ersten Erfahrungen in der Business Analyse sammelte Benjamin Wyss vor über 15 Jahren im Anschluss an seine Ausbildung zum Bankkaufmann...

45 Minuten Vortrag

Fortgeschritten
Zeit

16:35-17:20
07. Oktober


Zielgruppe

tba


Themengebiet

Techniken im agilen Anforderungsmanagement


Raum

Kindl 1


ID

Mi1.5

Zurück

Copyright © 2020 HLMC Events GmbH