Lean / Agile Business Analyse leicht gemacht

Geschäftsanforderungen in einem agilen (z.B. Scrum), schlanken (z.B. Kanban) oder traditionellen Ansatz (z.B. Wasserfall) erstellen

Die größte Herausforderung für Organisationen auf der ganzen Welt ist die Frage, wie sie ihre Informationstechnologie nutzen können, um sich Wettbewerbsvorteile zu verschaffen. Dabei geht es nicht darum, wie man die Devices programmiert; es geht darum herauszufinden, was die Devices tun sollen. Die Fähigkeiten, die erforderlich sind, um die besten IT-Lösungen zu erarbeiten und die Geschäftsanforderungen für diese Lösungen zu definieren, sind für alle Bereiche und Positionen innerhalb einer Organisation von unschätzbarem Wert.

In der Vergangenheit war es die Aufgabe des Requirements Engineers, die Anforderungen der Stakeholder für eine Softwareanwendung zu erstellen. Es ist jedoch mehr und mehr die Aufgabe von Product Owners, Produktmanagers, Projekt Managers, Business Analysten (Geschäftsanalytikern), Requirements Engineers und Fachexperten, agile oder traditionelle Ansätze zur Software-Entwicklung zu unterstützen. Daher ist es von entscheidender Bedeutung, die Anforderungskompetenzen in der gesamten Organisation zu verbessern.

Wir haben das vorliegende Buch für dieses Publikum geschrieben. Es ist unser Beitrag, der auf fast 60 Jahren kombinierter Erfahrung beruht, in denen wir Organisationen auf der ganzen Welt dabei geholfen haben, die Kommunikation zwischen den Fachabteilungen und der Entwickler-Community zu optimieren.

Anforderungen im Wandel

Der finanzielle Erfolg eines Unternehmens ist eng mit dem Erfolg seiner digitalen Lösungen verbunden. Deshalb entstand in den vergangenen zwei Jahrzehnten eine neue Disziplin – die Business Analyse, um den Business Value digitaler Lösungen zu optimieren. Aber was ist der Unterschied zwischen Business Analyse und Requirements Engineering?

Der Schwerpunkt der Business Analyse liegt auf der Bereitstellung von Lösungen zur Steigerung des Geschäftserfolgs. Die Business Analyse befasst sich neben der Technologie auch mit Menschen und Prozessproblemen. Bei der Business Analyse geht es darum, die Geschäftsprobleme zu verstehen, zu analysieren, Geschäftsbedürfnisse bzw. Anforderungen abzuleiten und dann die Lösungen bereitzustellen.

Im Gegensatz dazu konzentriert sich das Requirements Engineering in erster Linie auf Produkte und Anwendungen. Beim Requirements Engineering geht es darum, die detaillierten Systemanforderungen für eine ausgewählte Lösung zu definieren, zu dokumentieren, zu validieren, zu verhandeln und zu verwalten.

Daher liegt der Schwerpunkt der Business Analyse auf der Lösung von Problemen und der Erzielung von Geschäftsvorteilen und der Schwerpunkt des Requirements Engineering auf der Herstellung von Produkten mit einer Reihe von Features/Funktionen.

Dieses Buch behandelt beide Themen. Das Ziel unseres Buches ist es, einer Organisation dabei zu helfen, herauszufinden, was die Geschäftswelt von der Entwicklungsabteilung benötigt (Business Analyse), und dies dann so darzustellen, dass ihr Entwicklungsteam es verstehen und programmieren kann (Requirements Engineering).

Schritt für Schritt lernen, wann und wie man schlanke/agile Anforderungen herleitet und analysiert

Die größte Herausforderung für Organisationen ist die Frage, wie sie ihre Informationstechnologie nutzen können, um sich Wettbewerbsvorteile zu verschaffen. Dabei geht es nicht darum, wie man die Devices programmiert; es geht darum herauszufinden, was die Devices tun sollen. Die Fähigkeiten, die erforderlich sind, um die besten IT-Lösungen zu erarbeiten und die Geschäftsanforderungen für diese Lösungen zu definieren, sind für alle Bereiche und Positionen innerhalb einer Organisation von unschätzbarem Wert.

Dieses Buch lehrt:

• den Unterschied zwischen traditionellen und schlanken/agilen Anforderungen
• 8 Methoden zur Anforderungserhebung im User Story-Format
• Stakeholder Identifikation, Backlog Erstellung, Cynefin- und Problem-Analyse
• Workshop und Meeting Moderation
• das Timing von Business Analyse und Anforderungsmanagement in schlanken und agilen Lebenszyklen (z.B. Release- und Sprintplanung)
• 9 Techniken zur Anforderungsanalyse
• Reduktion von Ambiguität, User Story Splitting, Spezifikationen, Datenanforderungen und nicht-funktionale Anforderungen
• Akzeptanzkriterien, ATDD (Abnahmetestgetriebene Entwicklung) und BDD (verhaltensgetriebene Entwicklung)
• Features (Funktionen) und User Story drill-down, um Szenarien und Szenario Gliederungen im GEGEBEN-WENN-DANN Schema zu definieren
• Agiles Testdaten-Engineering für Akzeptanz Tests
• 7 Techniken zur Ermittlung von Szenarien

Oft ist es die Aufgabe des Requirements Engineers, die Anforderungen der Stakeholder für eine Softwareanwendung zu erstellen. Es ist jedoch mehr und mehr auch die Aufgabe von:

• Product Owners,
• Produktmanagers,
• Business Analysten,
• Fachexperten,
• Teammitglieder auf Unternehmens- und Kundenseite,
• Agile Teammitglieder,
• Subject Matter Experts (SME),
• Projekt Leiter und Manager,
• Systemanalytiker,
• UND „jeder, der den Business-Analyse-Hut trägt„, d.h. jeder, der für die Definition einer zukünftigen IT-Lösung verantwortlich ist.

Dieses Buch richtet sich an ein nicht-technisches Publikum. Es wird Ihnen helfen die Kommunikation zwischen den einzelnen Geschäftsbereichen und IT zu optimieren.

I. Anforderungen in einer schlanken und agilen Welt

• Agile und schlanke Philosophien
  Agile mit Scrum
  • Schlank mit Kanban
  • DevOps und kontinuierliche Lieferung
  • Testen in einer schlanken und agilen Welt
  • WagiLeanFall or WaterKanScrumBanFall?
• Traditionelle und Lean Anforderungen
  • Traditionelle Anforderungen
  • Agile oder schlanke Anforderungskonzepte
• User Stories sind Stakeholder Requirements
  • Das User Story Paradigma
  • Eine Vorlage für User Stories
  • INVESTiere in gute User Stories
  • User Stories definieren den Geschäftsbedarf
  • Übung: First-Cut User Stories

II. Anforderungserhebung und Backlog-Erstellung

• Fragen, Dokumente und Modelle
  • Dokumente analysieren
  • Modelle und Beispiele
• Verfolgen des Fortschritts mit einem Question File
  • Was ist ein Question File?
  • Einsatz der Question File
• Stakeholder-Identifikation
  • Elementare Stakeholder Ermittlung
  • Verwendung eines Organigramms zur Identifizierung interner Stakeholder
  • Stakeholder-Gruppen
  • Übung: Identifizierung von Stakeholdern
• Das Cynefin Framework zum Umgang mit Ungewissheit und Komplexität
  • Ein Framework zur Quantifizierung der Ungewissheit
  • Einfache Probleme mit offensichtlichen (obvious) Lösungen
  • Das Leben wird kompliziert
  • Die Sachlage wird komplex
  • Oberstes Chaos regiert
  • Eine Cynefin-Erfolgsgeschichte
  • Übung: Cynefin bei geplanten Initiativen anwenden
• Mit Business-Problemanalyse User Stories erstellen
  • Geschäftsprobleme definieren
  • Übung: Geschäftsprobleme Definieren
  • Die Problemanalyse liefert User Stories, Epics und Features
  • Übung: Problem-Symptom-Reduktion
• Konversationen sind der Kern von Lean und Agile
  • Zusammenarbeit mit der Business Community
  • Übung: Was zeichnet einen guten Business Analyst aus?
  • Effektive Anforderungsgespräche
  • Vorbereitung und Planung des Gesprächs
  • Kommunikationsformen
  • Gruppen moderieren
• Nonverbale Kommunikation
  • Kontext verdeutlicht Absicht
  • Basieren Sie Ihre Annahmen auf Clustern
  • Der Unterschied liegt in der Kultur
  • Kongruenz: Gemischte Signale vermeiden
• Der Umgang mit Menschen
  • Verstehen reicht nicht aus
  • Mit schwierigen Menschen umgehen
  • Übung: Schwierige Menschen oder menschliche Schwierigkeiten
• 3 Zuhörtechniken die das gemeinsame Verständnis fördern
  • Aktives Zuhören
  • Informatives Zuhören
  • Highway 350
• Bias kann uns in die Irre führen
  • Confirmation Bias (Bestätigungs-Bias)
  • Emotionales Bias (Emotionale Verzerrung)
  • Der Vividness Effekt (Anschaulichkeitseffekt)
• Konversationen erfolgreich beenden
• Tipps für E-Mails und Chats

III. Agile Anforderungsanalyse und Backlog-Refinement

• Timing der Analyse in einem typischen agilen Lebenszyklus
  • Just in Time (JIT) vs. Just in Case (JIC)
  • Release-Planung
  • Sprint-Planung
  • Aktivitäten während des Sprints
• Reduzierung von Ambiguität zur Beschleunigung der Release-Planung
  • Wer braucht schon Klarheit?
  • Was sind Ambiguität und Subjektivität?
  • Mehrdeutigkeit aufdecken und eliminieren
  • Ein gemeinsames Verständnis fördern
  • Übung: Out-of-Box-Denken einsetzen, um Mehrdeutigkeit zu reduzieren
• Techniken des User Story Splittings
  • Splitting zur Verringerung der Komplexität
  • Splitting basierend auf Datentypen
  • Splitting anhand Business Rules
  • Splitting mit Hilfe von Workflows
  • Splitting nach Use Case Paths
• Anforderungsspezifikationen: Die Business-Perspektive
  • Solution Requirements (Lösungsanforderungen)
  • Daten- und Informationsanforderungen
• Nichtfunktionale Anforderungen, Qualitätsanforderungen und Constraints
  • Verschiedene NFR-Varianten
  • Split Stories mit NFRs

IV. Lean Acceptance Testing: Die Business-Perspektive

• Das neue Akzeptanz Test Paradigma
• Was ist ATDD/BDD?
• Akzeptanzkriterien in Form von GEGEBEN-WENN-DANN-Szenarien
  • Szenarien
  • Die Gherkin Grundlage (Background)
  • Szenario-Gliederungen (Outlines)
  • Beispieltabellen (Examples)
  • Übung: Szenarien im GEGEBEN-WENN-DANN-Format erstellen
• Agiles Testdaten-Engineering
  • Minimieren von Szenarien und Beispielen
  • Übung: Testdaten-Engineering
• Szenarios identifizieren
  • Von User Stories zu Szenarien
  • Von Business-Rules zu Szenarien
  • Von Problemen / Symptomen zu Szenarien
  • Von Use Cases zu Szenarien
  • Von Ist- und Soll-Zustand zu Szenarien
  • Von Funktionsanforderungen zu Szenarien
  • Von nicht-funktionalen Anforderungen zu Szenarien

V. Und wie geht es weiter?

Über die Autoren

Wie alle guten IT-Stories begann auch ihre vor vielen (vielen) Jahren mit einem Projekt. Tom war der Supertechniker, Angela der Super-Fachexperte. Sie kämpften sich durch die dreijährige Entwicklung eines neuen Underwriting- und Schadensystems für eine prominente deutsche Versicherungsgesellschaft.

Sie waren sich in vielen Aspekten vehement uneinig, entdeckten dabei aber eine grundlegende Wahrheit über IT-Projekte. Die Business-Community (Angela) sollte über die geschäftlichen Bedürfnisse entscheiden, während die Aufgabe des technischen Teams (Tom) darin bestand, dafür zu sorgen, dass die Technologie das liefert, was das Unternehmen benötigt. Eine revolutionäre Idee! Alles, was blieb, war zu lernen, wie man ohne Blutvergießen miteinander kommunizieren konnte, um das Projekt zu einem durchschlagenden Erfolg zu machen. Mission erfüllt.

Sie beschlossen, dass diese Epiphanie so wichtig sei, dass die Welt davon erfahren müsse. Infolgedessen machten sie es sich zur Aufgabe (und zu ihrer Leidenschaft), dieses bahnbrechende Konzept mit dem Rest der Welt zu teilen.

Um dieses hochgesteckte Ziel zu erreichen, heirateten sie und begannen mit der Mission, die noch heute ihr Leben bestimmt. Nachdem sie über 30 Jahre lang Tag und Nacht zusammengelebt und gearbeitet haben, sind sie immer noch voller Enthusiasmus dabei, den „Opfern der Technologie“ (auch Anwender genannt) zu helfen, die IT-Lösungen zu fordern und zu erhalten, die sie brauchen, um ihre Arbeit besser zu erledigen. Noch wichtiger ist, dass sie sich mit mehr Enthusiasmus als je zuvor ineinander verliebt haben!