Kundenbeispiele nutzen nicht nur Kunden zum Beispiel

In mehreren Blog-Artikeln betrachten wir, wo und wie Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz kommen, welche Aufgaben und Aktivitäten sie dabei ausüben. Den Auftakt machte eine Übersicht zum Thema. Nach und nach erläutern wir die 7 Prinzipien für erfolgreiche „agile“ Business Analyse:

Drei Prinzipien beschreiben das Was? und Warum?

1. Sieh auf das Ganze (auf Personen, Prozessen und Technologie); mit den Techniken Personas und Value Stream Mapping (Wertstromanalyse).
2. Denke wie ein Kunde (und höre auf die Stimme des Kunden mit seinen Werten und Erwartungen); mit den Techniken User Story, Story Decomposition, Story Elaboration, Story Mapping.
3. Bestimme das Wertvolle (entwickle dadurch eine Lösung, die wertvoll und positiv bewertet ist).

Vier Prinzipien für das Wie? und Wann?

4. In diesem Blog-Artikel: Nutze reale Beispiele (um echte Kundenbedürfnisse zu ermitteln und zu validieren).
5. Verstehe, was machbar ist (und unterstütze dadurch die Entwickler in ihrer Umsetzung der Anforderungen); mit den Techniken Schätzung und Planungsworkshop.
6. Fördere Zusammenarbeit und kontinuierliche Verbesserung; mit den Techniken Collaborative Games und Retrospektive.
7. Vermeide Verschwendung (und erkenne diese rechtzeitig).

Viertes der sieben Prinzipien: Nutze reale Beispiele

In agilen Vorgehensmodellen sollten reale Beispiele der Kunden verwendet werden, um Anforderungen zu erheben und zu validieren. Diese Beispiele sind hilfreich bei der Kommunikation mit dem Entwicklungsteam, aber insbesondere im Gespräch mit den Kunden. Dies gilt sowohl für interne als auch für externe Kunden. Zum einen wird mit realen Beispielen deutlicher, was der Kunde braucht. Zum anderen schärft sich das Bild, wie die zu entwickelnde Lösung dem Kunden künftig helfen soll.

Anforderungsmodelle (z.B. UML-Modelle) helfen normalerweise den Entwicklern, sind aber für den Kunden nicht unbedingt verständlich; anders bei Beispielen, die der Kunde nachvollziehen und verstehen kann.
Dabei kann es sinnvoll sein zwischen den Anforderungsmodellen und den Kundenbeispielen zu wechseln, um so verschiedene Sichten auf die Lösung zu ermöglichen (z.B. verschiedene Rollen der Benutzer, Benutzeraktionen, Datensicht, Geschäftsregeln). Die Kunden werden sinnvollerweise in die Erhebung, Analyse und Validierung der Anforderungen mit eingebunden.

Die Granularität der Beispiele und Modelle sollte sich an der angestrebten Lösung orientieren. Bei der groben Planung der Lösung werden die Modelle und Beispiele zunächst den Kontext beschreiben. Entwicklern und Kunden wird dadurch geholfen, den Lösungsumfang (Scope) zu identifizieren. Die Modelle sind dabei abstrakter und bieten eine breitere Perspektive auf die Lösung.
Wenn die Lösung bzw. ihre Komponenten umgesetzt werden sollen, kann das gleiche Modell nach und nach detailliert werden. Dadurch wird eine tiefere Diskussion der verschiedenen Sichten auf die Lösung erleichtert. Mit Hilfe der realen Beispiele können Akzeptanzkriterien formuliert werden, die bei der Entwicklung der Lösung helfen und eine Grundlage für das Testen bieten.
Auch hier gilt also die „goldene Regel“: Vom Groben zum Detail, von der Breite in die Tiefe.

Als Technik, um reale Kundenbeispiele zu nutzen, kann Behaviour Driven Development eingesetzt werden.

Behaviour Driven Development

Diese Technik beruht auf einer einfachen Struktur:

• VORAUSGESETZT (Kontextbeschreibung);
• WENN (ein Ereignis),
• DANN (ein Ergebnis).

Diese Struktur wird mit realen Beispielen gefüllt, hier im Fall eines Geldausgabeautomaten:

• VORAUSGESETZT ich bin im Guthaben;
• WENN ich 20 Euro abheben möchte,
• DANN erhalte ich 20 Euro; UND mein Kontostand verringert sich um 20 Euro, UND meine Karte wird mir zurückgegeben.

• VORAUSGESETZT ich habe mein Konto überzogen;
• WENN ich 20 Euro abheben möchte,
• DANN erhalte ich kein Geld; UND meine Karte wird mir zurückgegeben.

Die beschriebenen Kontextbeschreibungen, Ereignisse und Ergebnisse können verifiziert werden. Sie sind für den Kunden verständlich und nachzuollziehen Sie können auch als Akzeptanzkriterien für User Stories dienen; der Weg zu den von mir als Triple A bezeichneten Akzeptanzkriterien ist dabei nur noch kurz.

Drei Prinzipen verbleiben, die (nicht nur) „agile“ Business Analysten erfolgreich machen. Mehr zu diesen Prinzipien, die die Agile Extension zum BABOK benennt, in den nächsten Blog-Artikeln.

Sie wollen mehr zum Thema Business-Analyse erfahren? Mit dem ibo-Newsletter bleiben Sie immer up to date!