Einführung in die agile Business-Analyse

Herausforderungen und Lösungsansätze für die Business-Analyse in Scrum, DSDM und Prince2

David J. Paul

• Verlag: Books on Demand
• Jahr: 2021
• ISBN drucken: 9783754330289
• eBook-ISBN: 9783752617702
• Auflage: 1
• Thema: Informatik
• Thema: Informationstechnologie

Die Business-Analyse ist eine zentrale Aufgabe bei der Entwicklung von Produkten oder Dienstleistungen. Diese Aufgabe wird in vielen Vorgehensmodellen durch die Rolle eines Business-Analysten oder Requirements Engineers wahrgenommen. Doch gerade im Kontext agiler Methoden und Frameworks verschiebt sich sowohl die Aufgabenstellung als auch die Anforderung an die Person(en), welche die Anforderungen an das zu erstellende Produkt erheben. Nicht nur verändern sich Anforderungen im Projektverlauf; es kommen neue hinzu, manche fallen weg oder werden verändert. Zunehmend wird auch mit Ansätzen gearbeitet, welche scheinbar nicht mehr mit der Idee eines Einzelnen oder einer kleinen Gruppe von Experten zu vereinen sind. Ansätze wie Design Thinking, Lean UX, Lego ® Serious Play ® oder Design Sprint werden immer häufiger eingesetzt, wenn es darum geht, Anforderungen zu erarbeiten und festzuhalten.In diesem Buch beschreibt der Autor, der seit Jahren selbst als Berater im Kontext agiler Business-Analyse tätig ist, die Herausforderungen, Vorgehensmodelle und eine mögliche Zukunft für die Rolle des Business-Analysten in einer sich zunehmend verändernden Welt.

Anforderungsmanagement

Wer sich mit verschiedenen Methoden des Anforderungsmanagements auseinandersetzt, wird feststellen, dass hier neben der Herausforderung, die richtigen Anforderungen zu formulieren, weitere wichtige Herausforderungen bestehen. Zunächst die eher trivial anmutende Herausforderung, die Anforderungen richtig und verständlich zu beschreiben. Dies ist insbesondere deshalb eine Herausforderung, weil in vielen Projekten Menschen mit völlig unterschiedlichem Sprachgebrauch involviert sind. Dabei sind nicht Sprachen wie Deutsch oder Englisch gemeint, sondern die Herausforderung, dass manche der involvierten Personen Fachausdrücke verwenden, die anderen Beteiligten oft nicht bekannt sind oder von diesen ggf. anders verwendet werden. Es gilt also sicherzustellen, dass alle Beteiligten unter einer Anforderung dasselbe verstehen. Schon dies ist in sehr vielen Projekten ein Hauptgrund für umfangreiche Fehler und Zusatzaufwand.

Daneben existiert aber auch eine weitere Herausforderung, welche beispielsweise so gravierend ist, dass viele Methoden, wie beispielsweise Design Thinking, als Teil ihres Prozesses einen erheblichen Aufwand haben, diese Herausforderung zu meistern. Gemeint ist die Tatsache, dass wir sehr oft über Lösungsideen und -ansätze diskutieren, bevor uns überhaupt das Problem im vollem Ausmaß klar geworden ist. Alle Beteiligten haben verstanden, dass es eine Herausforderung, ein Problem oder eine Aufgabenstellung gibt. Allzu oft stellen wir aber, wenn wir genauer hinschauen, fest, dass die verschiedenen Beteiligten, basierend auf ihrem Background (Erfahrungen, Wissen usw.), ganz unterschiedliche Teilaspekte der Herausforderung wahrnehmen oder unterschiedlich gewichten oder ggf. auch Anforderungen insgesamt unterschiedlich verstehen und positionieren. Entsprechend wichtig ist es, sicherzustellen, dass alle Beteiligten dasselbe Problemverständnis haben und dieses – im Idealfall – jenes des Auftraggebers / Kunden / Benutzers ist (wobei auch nicht zwingend sicher ist, dass hier alle dasselbe Verständnis von der Anforderung haben). Dies ist der Grund, warum beispielsweise Ansätze wie Design Thinking einen maßgeblichen Teil des Prozesses auf das Thema “Problemverständnis” verwenden, da es tatsächlich nicht zielführend ist, sich über Lösungen eines nicht wirklich verstandenen Problems Gedanken zu machen, da dadurch das eigentliche Problem höchstens zufällig gelöst wird.

Ein weiterer wichtiger Aspekt im Rahmen des Anforderungsmanagements ist die Tendenz, dass wir oft, wenn wir ein Problem wahrnehmen, schon viel zu schnell bei einer Lösung sind, welche wir dann auch entsprechend angehen. Oft nehmen wir uns nicht genug Zeit, zu untersuchen, ob es ggf. noch andere, womöglich bessere Lösungsansätze gibt. Dies ist ein Grund, warum beispielsweise Prince2 als Teil eines Business Cases den Abschnitt “Optionen” vorschlägt, welcher im Handbuch wie folgt beschrieben wird:

“Analyse und begründete Empfehlung für die grundsätzlichen Optionen eines Unternehmens, nämlich die Nulloption („ Do nothing“), die Minimumoption („ Do the minimum“) oder die Minimum-Plus-Option („ Do something“). Die Ausgangsbasis sollte in jedem Fall die Nulloption sein, anhand derer die anderen Optionen quantifiziert werden. Der Unterschied zwischen der Nulloption und der Minimumoption bzw. der Minimum-Plus-Option ist der Nutzen, den die Investition bringen wird. Die Analyse der einzelnen Optionen liefert dem Lenkungsausschuss und den Stakeholdern des Projekts ausreichende Informationen, damit sie beurteilen können, welche Option für ein Projekt den größten Nutzen für das Unternehmen verspricht. Sie beantwortet die Frage, ob im Vergleich zum vorgesehenen Investitionsbetrag der voraussichtliche Nutzen wünschenswerter, lohnender und besser realisierbar ist als bei anderen Alternativen. Der Business Case für die ausgewählte Option sollte laufend daraufhin geprüft werden, ob er weiterhin wünschenswert, lohnend und realisierbar ist, denn wenn sich neue Risiken und/ oder Änderungen ergeben, kann durchaus eine der anderen Alternativen die bessere Lösung sein.

AXELOS. Erfolgreiche Projekte managen mit PRINCE2 (German Edition) (Kindle-Positionen 8555-8565). The Stationery Office Ltd. Kindle-Version.”

3C – Agiler Kontext und “Wasserfall”

Die meisten Herausforderungen im Kontext des Anforderungsmanagements stehen in Zusammenhang mit einer guten, zielführenden Kommunikation unter den Beteiligten. Im Kontext der Zusammenarbeit zwischen dem Business-Analysten (oder einer anders benannten Rolle, welche die entsprechende Aufgabe übernimmt) und Stakeholdern hat sich im agilen Kontext eine Technik etabliert, welche allgemein unter dem Stichwort “3C” bekannt ist. “3C” steht dabei für “Card”, “Conversation”, “Confirmation”. Die Technik wird insbesondere im Kontext von Scrum von erfolgreichen Product Ownern eingesetzt, wenn es darum geht, sicherzustellen, dass Anforderungen der Stakeholder wirklich verstanden werden. Sie lässt sich aber grundsätzlich im Kontext des Anforderungsmanagements erfolgreich einsetzen, unabhängig davon, mit welcher Herangehensweise oder welchem Framework die anschließende Umsetzung erfolgen soll.

Card

Card steht für die Karte (virtuell oder physisch), auf welcher die Anforderung festgehalten ist. Sie enthält alle bekannten Anforderungen, deren Aspekte, Akzeptanzkriterien usw. – alles, was der Product Owner über die Anforderung weiß oder zu wissen glaubt. Dies zu verifizieren und zu ergänzen ist der Zweck der Methode. Dabei wird das Gespräch mit den Personen gesucht, die die Anforderung stellen. Es kann sein, dass es sich dabei um eine spezifische Person handelt. Genauso ist es aber möglich, dass entweder mehrere Personen diese Anforderung formuliert haben oder aber zumindest mehrere Personen oder Gruppen Stakeholder in Bezug auf diese konkrete Anforderung sind. Es ist sinnvoll, hier mit den verschiedenen Beteiligten zu sprechen. Dabei können Einzelgespräche sinnvoll sein oder auch Gespräche mit allen gleichzeitig. Dies hängt vom Setting und der Ausgangssituation ab.

Conversation

Der erste Schritt besteht darin, mit dem/den Stakeholder/n zu klären, ob der Product Owner und der/die Stakeholder dasselbe Verständnis von den Anforderungen haben. Dazu trägt der Product Owner seine Erkenntnisse vor und bittet sein Gegenüber, ihm mitzuteilen, ob diese Darstellung aus dessen Sicht korrekt und vollständig ist. Ist dies nicht der Fall, wird die Unterhaltung so lange fortgesetzt, bis alle Beteiligten überzeugt sind, dass sie dieselbe Vorstellung von der Anforderung haben. Dabei ist anzumerken, dass es dabei nicht darum geht, dass der Product Owner sein Gegenüber beispielsweise von einer alternativen Idee oder Ähnlichem überzeugt, sondern es geht nur darum, sicherzustellen, dass die Beteiligten dieselbe Vorstellung haben. Ist dies nicht gegeben, wird der Product Owner (oder in anderem Kontext der Business-Analyst) auch nicht in der Lage sein, den Umsetzenden gegenüber die Anforderung korrekt wiederzugeben und entsprechender Aufwand zur Realisierung ist Verschwendung.

Im agilen Kontext schiebe ich hier gern eine weitere Frage ein, welche aber in klassischem Kontext womöglich schwieriger umzusetzen ist. Ich werde mein Gegenüber nach Grenzen der Anforderung befragen: Gehört X dazu, ist dabei Funktion Y wichtig etc.? Dieser Punkt muss gut positioniert werden, damit er auch zielführend ist. Im agilen Kontext gehen wir von einem Mindset aus, welches besagt, dass Anforderungen auch spät jederzeit willkommen sind und natürlich alle Beteiligten – auch der Kunde / die Stakeholder – das Recht haben, zu lernen. Entsprechend gehe ich mit Gesprächspartnern immer eine “Vereinbarung” ein, welche besagt, dass mein Gesprächspartner mir seinen aktuellen Kenntnisstand mitteilt und – sollte sich daran was ändern – diesen jederzeit (selbst nach Umsetzung) revidieren kann. Ansonsten gehen wir das große Risiko ein, dass unser Gegenüber schon aus Selbstschutz alles zu Teilen des Projektes und zu den Anforderungen erklärt, um sicherzustellen, nicht in irgendeiner Weise verantwortlich gemacht zu werden – wenn eine Lösung beispielsweise nicht eingesetzt werden kann, weil genau diese Anforderung fehlt. Durch ein entsprechendes Agreement – welches natürlich nicht nur deklariert, sondern auch gelebt werden muss – lassen sich viele unnütze Anforderungen eliminieren. Diese werden oft nur in Anforderungskatalogen aufgenommen, weil Beteiligte sichergehen wollen, dass am Ende nichts vergessen wird und ihnen womöglich die Schuld dafür gegeben wird. In einer Vorgehensweise, welche eher klassisch geprägt ist, wo Anforderungsänderungen im Projektverlauf eher unwillkommen sind, ist dies oft sehr schwierig, während im agilen Kontext das Entstehen und Erkennen neuer Anforderungen quasi Teil des Prozesses ist und entsprechend weniger in einem negativen Kontext wahrgenommen wird.

Confirmation

Der letzte Schritt steht unter dem Stichwort “Confirmation”. Es geht dabei darum, die Akzeptanzkriterien aus Sicht des Gesprächspartners zu erfahren, also die Aspekte und Elemente der Lösung der Anforderung, welche für den Gesprächspartner im Vordergrund stehen. Was macht die Umsetzung der Anforderungen für ihn aus? Welchen Nutzen, welchen Beitrag zur Lösung erwartet er und welche Aspekte stehen für ihn womöglich eher im Hintergrund oder fallen gar nicht ins Gewicht? Je genauer wir diese Aspekte kennen, desto zielführender können Ressourcen eingesetzt werden. Dabei ist natürlich zu beachten, dass Personen – je nach Anwendungsfall – ganz unterschiedliche Akzeptanzkriterien haben können.

Auch wenn die Vorgehensweise auf den ersten Blick reichlich kompliziert und aufwendig aussieht, bedeutet gerade dieser Schritt für viele Projekte einen enormen Gewinn. In vielen Fällen ist den Personen, welche Anforderungen erheben – ob nun im agilen oder klassischen Kontext – gar nicht bewusst, was die wirkliche Anforderung ist und was damit bezweckt wird und entsprechend kann dies auch nicht an die umsetzenden Personen übermittelt werden. Dies führt zum einen dazu, dass es kaum zu einem wirklichen Commitment der Beteiligten zu ihrer Arbeit und Aufgabe kommt, da “Sinn” ein ganz zentraler Wert in Bezug auf Identifikation und Einsatz ist. Daneben wird dies auch potentiell dazu führen, dass Entscheidungen im Entwicklungsprozess, welche nicht dokumentiert sind, ggf. falsch getroffen werden, da die Entwickler nicht wissen, was der Nutzen und die Zielsetzung der Anforderung sind. Im Worst Case wird sogar eine teilweise oder ganz falsche Anforderung umgesetzt, weil die Anforderung schon auf der Ebene der Analyse falsch oder unklar wahrgenommen wurde und entsprechende Fehler und Falschinformationen sich im Projektverlauf tendenziell eher verstärken als korrigieren.

Umsetzung von 3C im klassischen Kontext

Der 3C-Ansatz ist im Kontext klassischer Vorgehensweisen in der Art weniger verbreitet. Dies kann zu einem guten Teil daran liegen, dass im Allgemeinen quasi summarisch vor Projektbeginn alle Anforderungen formuliert und anschließend abgearbeitet werden. Man kann sich aber fragen, ob dies tatsächlich so sein muss. Klassische Anforderungsdokumente glänzen in vielen Fällen nicht gerade durch Detailtiefe und viele Fragen und Präzisierungsnotwendigkeiten ergeben sich eigentlich erst im Rahmen der Umsetzung. Das führt einerseits dazu, dass in manchen Fällen, wo der Zugang zu den Know-how-Trägern eher schwierig ist, tendenziell “geraten” wird, und andererseits dazu, dass sich im Proj...

Inhaltsverzeichnis

• Anmerkung
• Inhaltsverzeichnis
• Vorwort
• Was ein Business-Analyst macht
• Die Rolle des Business-Analysten
• Business Analysis Process Model
• Strategische Analyse
• Techniken der Business-Analyse
• Business-Analyse und -Projekt
• Anforderungsmanagement beim “Wasserfall” und beim “agilen Kontext”
• Verschiedene Projektvorgehensmodelle
• Anforderungsmanagement
• Agile und nicht-agile Business-Analyse?
• Business-Analyse und Führung
• Design Thinking als agile Vorgehensweise in der Business-Analyse
• Nachwort
• Impressum