Einführung in die agile Business-Analyse - David J. Paul - E-Book

Einführung in die agile Business-Analyse E-Book

David J. Paul

0,0

Beschreibung

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.

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 79

Veröffentlichungsjahr: 2021

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Anmerkung:

Prince2, DSDM, AgilePM u.a. sind eingetragene Warenzeichen. Für eine bessere Lesbarkeit wurden entsprechende Vermerke wie (™), © etc. im Buchtext weggelassen. Die entsprechenden Anmerkungen gelten aber stets als mit gemeint.

INHALT

Vorwort

Was ein Business-Analyst macht

Die Rolle des Business-Analysten

Business Analysis Process Model

Investigate Situation

Consider Perspectives

Analyse Needs

Evaluate Options

Define Requirements

Strategische Analyse

Die 4 Ps nach Mintzberg (1994)

SWOT-Analyse

Planning Onion (Planungszwiebel)

Techniken der Business-Analyse

Vision

Kano-Modell

Pet Projects & Communities of Practice

Observations

Prototyping

Funktionale und nicht-funktionale Anforderungen

Business-Analyse und -Projekt

Anforderungsmanagement beim “Wasserfall” und beim “agilen Kontext”

Verschiedene Projektvorgehensmodelle

Beispiel 1: Die Rolle des BA im Rahmen von DSDM®-Projekten

Beispiel 2: Die Rolle des BA im Kontext von Prince2™

Beispiel 3: Die Rolle des BA im Kontext von Scrum

Anforderungsmanagement

3C – Agiler Kontext und “Wasserfall”

Card

Conversation

Confirmation

Umsetzung von 3C im klassischen Kontext

User Storys

Beispiel 1: Agiles Anforderungsmanagement: der Product Backlog in Scrum

Beispiel 2: Die priorisierte Anforderungsliste (Prioritised Requirements List PRL) in DSDM ®

Definition of Done

Agile und nicht-agile Business-Analyse?

Die Methoden

Der Prozess / die Prozesse

Die Rollen

Business-Analyse und Führung

Design Thinking als agile Vorgehensweise in der Business-Analyse

Nachwort

Vorwort

Die Business-Analyse und die Rolle oder Aufgabe des Business-Analysten ist aus klassischem Projektmanagement nicht wegzudenken. In vielen Fällen kommt dem Business- Analysten die Aufgabe zu, das Pflichtenheft entweder selbst zu schreiben oder zumindest zu dessen Entstehung beizutragen.

Die Rolle des Business-Analysten soll dabei sicherstellen, dass die richtigen Anforderungen aufgenommen und schließlich umgesetzt werden können. Damit soll der spätere Nutzen und das Entstehen einer Lösung mit gutem Kosten-Nutzen-Verhältnis sichergestellt werden.

Obwohl dieser Rolle im Rahmen klassischer Projektmanagements eine so gewichtige Aufgabe zufällt – welche mit einem erheblichen Maß an Verantwortung gekoppelt ist – verfügen die wenigsten Menschen, welche diese Aufgabe wahrnehmen, auch über die dazu notwendige Ausbildung und Werkzeuge. Dies, obwohl es sogar ganze Ausbildungsgänge bis hin zur Master-Zertifizierung von verschiedenen Bildungsträgern und Zertifizierern gibt, wie beispielsweise der British Computer Society oder auch von Zertifizierern wie EXIN, welche hier ein weites Spektrum abdecken.

Eine Frage, welche ebenfalls von großer Unsicherheit geprägt ist, ist jene danach, wie die Rolle und Aufgaben eines Business-Analysten im Rahmen agiler Projekt-Vorgehensweisen organisiert wird. Ist doch auch da die Bedeutung, den Kundennutzen zu maximieren – indem unter anderem sichergestellt wird, dass an den richtigen Anforderungen gearbeitet wird – ein Kern-Versprechen.

Im vorliegenden Buch werde ich zunächst in die Rolle des Business-Analysten einführen und einige wichtige Vorgehensweisen und Prozesse im Rahmen seiner Aufgabe darstellen. Danach werden wir die Rolle im Rahmen verschiedener Methoden und Frameworks betrachten. Aus dem Bereich des “klassischen Projektmanagements” werden dabei Aspekte aus dem Kontext von Prince2 berücksichtigt, aus dem Bereich “agiles Projektmanagement” Aspekte der DSDM (Dynamic Systems Development Method), der wohl erfolgreichsten und vollständigsten agilen Projektmanagement-Methodik, und schließlich werden Aspekte von Scrum – als einem Framework, welches die Produkterstellung fokussiert, dabei aber keine vollständige Projektmanagement-Methodik darstellt – behandelt.

Darüber hinaus werden wir eine Business-Analyse im Zusammenhang mit Design Thinking und Lean UX betrachten – zwei Frameworks, die sich ebenfalls im Kontext von Business-Analyse und Produktentwicklung / Innovation ansiedeln.

Was ein Business-Analyst macht

In der Business-Analyse geht es darum, die Grundlage für eine Veränderung zu schaffen, indem Anforderungen, basierend auf den Bedürfnissen und dem Nutzen des Kunden, definiert werden.

Diese Aufgabe wird oft durch eine interne Fachperson durchgeführt, welche eine Art interne Beraterrolle einnimmt. Daneben kommen auch immer wieder externe Berater zum Einsatz, wenn es darum geht, Anforderungen zu erheben und formulieren.

Typische Aufgaben eines Business-Analysten bestehen darin, die aktuelle Situation zu analysieren und darauf basierend Optionen für Veränderungen zu identifizieren und zu evaluieren. Diese Evaluationen bieten die Grundlage für die Verbesserung der Ist-Situation mit dem Ziel einer Erfüllung von Business-Anforderungen und -Nutzen. Dabei gilt es die bestehenden Rahmenbedingungen in Hinblick auf Zeit, Kosten, Qualität und zur Verfügung stehende Ressourcen zu berücksichtigen.

Sie erhalten einen guten Einblick in BA im Kontext von agilen Umgebungen, aber auch in die Wichtigkeit und Nützlichkeit entsprechender Kompetenz im Rahmen von Projektmanagement und Produktentwicklung.

Beste Grüße

Der Autor

Die Rolle des Business-Analysten

Die Aufgaben eines Business-Analysten sind mannigfaltig und in unterschiedlichen Unternehmen und unterschiedlichem Kontext verschieden ausgeprägt. Zu den Aufgaben gehören:

Probleme und Chancen erkennen

Anforderungen ermitteln und dokumentieren

Verschiedene Lösungsansätze festhalten und evaluieren

Lösungsoptionen testen

Lösungen implementieren

Den Nutzen und die erzielte Erfüllung der Anforderungen festhalten – auch über die Grenzen des Umsetzungsprojektes hinaus.

Dies erfordert Menschen, welche als Generalisten breit aufgestellt sind und fähig sind, über den Tellerrand zu schauen. Aber sie sollten auch als Spezialisten in einigen Bereichen in die Tiefe vordringen können, um Zusammenhänge zu verstehen und darauf basierend neue Möglichkeiten zu formulieren. Um diesen Anforderungen gerecht zu werden, ist sowohl das Vorhandensein von analytischen Fähigkeiten als auch eine gute Kommunikation mit den verschiedenen Anspruchsträgern und Spezialisten notwendig.

Dabei nimmt der Business-Analyst auch eine Übersetzerrolle ein. Er muss sicherstellen, dass von Fachabteilung und Spezialisten formulierte oder mit ihnen abgestimmte Anforderungen so formuliert und übermittelt werden, dass diese auch von den Entwicklern verstanden werden. Oft stellt man fest, dass beide “Bereiche” eine völlig unterschiedliche Sprache nutzen. Die Business-Language der Fachabteilung ist oft mit Begrifflichkeiten aus deren Fachgebiet durchsetzt. Entwickler dagegen haben oft einen im Kontext ihrer Entwicklungstätigkeit eingesetzten technischen Sprachgebrauch.

Um seine Aufgaben zielführend wahrnehmen zu können, muss der Business-Analyst die Ziele und Herausforderungen des Unternehmens verstehen und dabei seinen Blick auch über die aktuelle Situation hinaus auf die von der Unternehmung formulierten strategischen Weiterentwicklungen richten. Dabei kann er – je nach seiner Position und Aufgabenstellung – auch in die Entwicklung der Unternehmensstrategie eingebunden sein. In der Zusammenarbeit mit den verschiedenen Stakeholdern muss er die Umsetzung dieser Strategien vorantreiben und überwachen.

Abhängig von den weiterführenden Fähigkeiten, aber auch von den Erfordernissen und Rahmenbedingungen von Unternehmen kommen Business-Analysten in unterschiedlichem Kontext zum Einsatz, was sich auch durch eine Vielzahl von Stellenbezeichnungen zeigt. Dazu gehören beispielsweise “Business Process Analysten”, “Requirements Analyst”, “System Analyst”, “Data Analyst” oder “User Experience Analyst”. Im Kontext von Scrum werden Business-Analysten auch sehr gerne in der Rolle eines “Product Owner” eingesetzt. Natürlich sind für die verschiedenen Aufgabenstellungen in der Praxis oft auch weiterführende Kenntnisse und Fähigkeiten notwendig, welche der Business-Analyst, soweit er sie nicht schon besitzt, erwerben muss.

Business Analysis Process Model

Das Business Analysis Process Model geht auf die British Computer Society (BCS) zurück. Es stellt ein fünfstufiges Modell zur Definition von Anforderungen dar.

Investigate Situationn

In dieser Phase geht es darum, zunächst den Projektumfang zu definieren und dabei die Rahmenbedingungen und das Umfeld, in dem das Projekt durchgeführt wird, zu verstehen. Hier wird die Grundlage für die weiteren Schritte gelegt. Werden diese nicht richtig durchgeführt, besteht das Risiko, dass darauf aufbauende weitere Schritte entweder nicht wirklich das angestrebte Ziel verfolgen oder aber nicht zu zielführenden Ergebnissen kommen, weil beispielsweise bestehende Beschränkungen oder Rahmenbedingungen nicht ausreichend berücksichtigt wurden.

Daneben ist in dieser Phase auch entscheidend, dass die beteiligten Personen und Stellen zu einer gemeinsamen Sprache und einem gemeinsamen Verständnis zu den genannten Positionen kommen. Oft stellt man fest, dass Personen, die in einem Projekt zusammenarbeiten, bereits in dieser frühen Phase – basierend auf ihren Erfahrungen und Ausbildungen – ein sehr unterschiedliches Bild der Situation haben und dabei quasi nur den in ihrem Kontext stehenden Aspekt der Herausforderung wahrnehmen. Dies führt später zu einer Herausforderung in Hinblick auf ein Alignment der beteiligten Personen.

Typische Mittel und Werkzeuge in dieser Phase sind:

Workshops

Shadowing – sowie weitere Methoden, bei denen die Anwender der Ist-Situation beobachtet werden

Interviews

Mindmaps

Consider Perspectives

In der zweiten Phase geht es darum, sich unterschiedliche Perspektiven anzusehen. Beteiligte und Betroffene werden womöglich unterschiedliche Vorstellungen von den zu erreichenden Zielen haben. Dazu gehört auch, dass wir feststellen, welche Stakeholder überhaupt existieren und welche Ziele und Anforderungen sie haben. Dabei gilt es auch zwischen den verschiedenen, sich womöglich widersprechenden oder stark voneinander abweichenden Vorstellungen zu vermitteln oder abzuwägen.

Methoden und Werkzeuge in dieser Phase sind beispielsweise:

Stakeholder-Analyse

Produkt-Struktur-Analyse

Kontext-Diagramme

Analyse Needs

Anschließend werden die Bedürfnisse der Zielgruppe/n analysiert. Dabei können auch weitere Aspekte und Bedürfnisse eine Rolle spielen. Dazu gehört zum Beispiel die strategische Ausrichtung des Unternehmens oder Bereichs. Anforderungen werden miteinander verglichen und gegeneinander evaluiert, bestehende Business Rules und Policies werden berücksichtigt und schließlich soll gemeinsam dargestellt werden, was bereits erreicht wurde und was es noch zu erreichen gilt (Gap Analysis).

Evaluate Options

In dieser Phase werden verschiedene Optionen für eine Umsetzung genauer betrachtet. Zum einen besteht immer die “Null-Option”, also die Möglichkeit, nicht aktiv zu werden. Sie bildet einen wichtigen Vergleichswert in Bezug auf die Nützlichkeit von Alternativen.

In vielen Projekten scheint der Lösungsweg schon festzustehen, noch bevor das Problem ganz erfasst wurde. Alternativen werden oft kaum beachtet, was das Risiko umfasst, dass möglicherweise bessere (günstigere, schnellere, nützlichere) Lösungen nicht berücksichtigt werden. Auch wird oft zu wenig evaluiert, inwiefern Lösungen einen Fortschritt oder Mehrwert gegenüber der “Null-Option” bringen und ob diese Lösungen durch die zu erwartenden Kosten und Risiken gerechtfertigt sind.

In diese Phase gehört auch eine Machbarkeitsprüfung (Feasibility Study). Dazu gehören sowohl der Aspekt der Sinnhaftigkeit und Umsetzbarkeit aus Business- / oder Auftraggebersicht als auch die technische Realisierbarkeit und die sich daraus womöglich ergebenden Risiken.

Define Requirements