Anforderungen in Softwareentwicklungsprojekten werden oft in unzähligen und umfangreichen Dokumenten aufgenommen und von verschiedenen Erstellern beschrieben. Zudem sind die Inhalte meist aus rein technischer Sicht definiert, in unterschiedlicher Tiefe dargestellt und fachsprachlich beschrieben. Das Behavior Driven Development (BDD) stellt dagegen das Softwareverhalten in den Vordergrund, indem es zwischen der textuellen und der Programmiersprache vermittelt. Im Fokus steht nicht das Produkt an sich, sondern die Funktionalitäten und deren Messkriterien zur Erfüllung (Akzeptanzkriterien) der Anforderungen.
Fragestellung in die Gruppe: Wer kennt das Bild nicht?
s. Chaos Report der Standish Group (CHAOS Summary 2009 ff.) oder auch CIO analysis (2011)
Ressourcen Planung, Zeitpläne, Risiken
Requirements – Unklare Anforderungen, keine Vereinbarung zischen Nutzer und Entwickler, Mehrdeutigkeiten, Kunden wissen nicht was sie wirklich wollen, Kunden benutzen ihre eigene Fachsprache, verschiedene Stakeholder können widersprüchliche Anforderungen haben, politische und organisatorische Faktoren können Anforderungen beeinflußen, Anforderungen ändern sich während der Analyse und Entwicklung, neue Stakeholder mischen sich ein
Kurze Frage in die Gruppe nach einblenden der drei Kästen:
Was wird in den Bildern aus unterschiedlichen Perspektiven (Customer, Programmer, Business Analyst beschrieben?
-> eine Schaukel
Kurze Frage in die Gruppe:
Was möchte der Kunde wirklich tun, was ist der Mehrwert für den Kunden?
-> Schaukeln, um Spaß zu haben. Ist das Zielbild
Gemeinsames Verständnis der Anforderungen, damit alle Beteiligten weitest gehend eine einheitliche Basis der Anforderungen haben und die Funktionalität mit dessen Mehrwert im Fokus stehen.
Prinzipien hinter dem Agilen Manifest
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.
Heisse Anforderungsänderungen sind selbst spät in der Entwicklung sind willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Frage in Gruppe:
Wer hat schon mal Erfahrungen in agilen Vorhaben gesammelt?
Projekt-Scheiterungsgrund „Requirements“ zu minimieren und damit die Lücke in der agilen Vorgehensweise zu verkleinern.
BDD ist einen „outside-in“ Vorgehensweise. Startet „outside“ (außerhalb), in dem die „business outcomes“ (Liefergegenstände) identifiziert werden und dann in einzelne Funktionen [Funktionalitäten] heruntergebrochen werden.
Jede Funktion [Funktionalität] wird dann aus Sicht des Users (Anfordernden) in einer Story (Geschichte) beschrieben. Jede Geschichte enthält Akzeptanzkriterien, die das erwartete Ergebnis der Geschichte festhalten und einen Mehrwert enthalten.
Jedes Akzeptanzkriterium wird zusätzlich noch durch frühe Einbindung der Entwicklung sowie der Tester verschiedene Szenarien aufgebrochen.
Hierbei handelt es sich um eine iterative Vorgehensweise, bei der alle Beteiligten (Fachbereich, Entwickler und Tester) ein gemeinsames Verständnis vom Inhalt und dem erwarteten Ergebnis der Anforderungen erhalten.
Warum User Stories? Die User Story beschreibt eine Funktionalität, die für einen User von Wert ist.
Die wichtigsten Grundregeln sind:
Card (Karte) = man ging in der Historie davon aus, dass Pappkarten genutzt werden, in man auf der Vorderseite die Anforderung (User Story) und auf der Rückseite die Akzeptanzkriterien aufgeschrieben hatte. Die „card“ ist eine schriftliche Beschreibung der Story, die zur Planung und als Erinnerung verwendet wird. -> Überführung zu Kanban-Board!
Conversation (Kommunikation) = User Story Card soll der Kommunikation dienen, damit sich die Beteiligten (Anforderden, Entwickler, Tester) sich gegenseitig austauschen, um ein gemeinsames Verständnis über die Anforderungen zu erhalten. Die Ergebnisse werden in Form von Akzeptanzkriterien und deren Szenarien aufgeschrieben. Diese bilden die Grundlage für die weiteren Aktivitäten und gelten als Abnahmevoraussetzungen. Die Kommunikation ist elementarer Bestandteil, da in Gesprächen über die Story wichtige Details der Story herausgearbeitet werden.
Confirmation (Bestätigung) = die gemeinsam festgelegten Akzeptanzkriterien und deren Szenarien gelten als verbindlich und werden nicht geändert. Sofern Änderungen oder Ergänzungen erfolgen, sind diese in das Change Request Verfahren zu überführen. Die Akzeptanzkriterien und deren Szenarien sind Grundlage für Tests, die dokumentieren, wann eine Story vollständig umgesetzt ist und genau so funktioniert, wie sie beschrieben wurde. (Definition of Done [DoD]
Gherkin language
Ist eine domänenspezifische Sprache, die vom Fachbereich und den Entwicklern gelesen und verstanden werden kann und das Verhalten einer Software beschreibt ohne Details über deren Implementierung zu verraten.
Gherkin Sprache erfüllt sowohl den Zweck der Dokumentation von Anforderungen als auch die des automatisierten Testens. Sie wird in ca. 37 Landessprachen verfügbar, so dass die Keywords von dem Team in der jeweiligen Landessprachen verwendet werden können.
Mit Gherkin wird ein Akzeptanzkriterium in verschiedene Szenarien zerlegt und beschrieben. Die Vollständigkeit und damit die Anzahl der Szenarien richtet sich nach der Kritikalität der Anforderung und dem Verständnis der Funktionalität durch die Beteiligten.
Wie vollständig müssen die Szenarien sein? Ist keine Teststrategie, sondern eine Designstrategie
Gherkin Syntax eines acceptance criteria:
Voraussetzung (given): Darin werden die notwendigen Vorbedingungen (z.B. Zustand der Software, aktueller Prozessschritt, Zustand der GUI,…) definiert.
Auslöser (when): Darin wird die Aktion (z.B. User Aktion, Eingehender Request, Triggern eines Events,…) beschrieben, die den Soll-Zustand triggert beschrieben.
Soll-Zustand (then): Beschreibt den vom Kunden gewünschten Soll-Zustand mit den notwendigen technischen Details.
Ergänzend können noch weitere Bedingungen (or = oder, but = aber) hinzugefügt werden.
Qualitätskriterien als Akronym „INVEST“ formuliert von (Bill Wake)
Q U A L I T Ä T
Independent (unabhängig) = möglichst keine Abhängigkeiten zu anderen User Stories, da sonst u.U. Probleme bei der Priorisierung entstehen könnten
Negotiable (verhandelbar) = kurze Beschreibungen der Anforderungen der Funktionalität mit Detaillierung in Gesprächen miteinander. User Stories mit einem zu detaillierten Inhalt „Bezahlung mit Master Card, Visa und American Express, aber nicht mit Dinners Club“ helfen nicht weiter, hier ist es zweckdienlich eine Abstraktion vorzunehmen, z.B. „Bezahlung mit einer Kreditkarte“
Valuable (werthaltig) = Inhalte sollen vom User als werthaltig betrachtet werden und nicht vom Käufer, dieses bei der Erstellung beachten. Zum Beispiel kann es für den Käufer wichtig sein, dass als Akzeptanzkriterium „Konfigurationsdaten werden von zentraler Stelle gelesen“ vorhanden ist, dem User ist es egal, wo die Konfigurationsdaten gelesen werden.
Estimateable (schätzbar) = den Umfang der Story so schreiben, dass der Zeitraum oder entsprechende Story Points abgeschätzt werden kann, große Stories als Epic aufbauen und dann in kleinere User Stories aufteilen. Die User Story „Ich als Kunde möchte Bücher suchen, damit ich diese Bücher bestellen kann“ ist zu groß und sollte aufgeteilt werden.
Short (kurz) = zu große oder zu kleine User Stories können nicht geplant werden (s. schätzbar), diese Einschätzung hängt vom Team ab
Testable (testbar) = nur wenn der Test der User Story erfolgreich war, wurde die User Story korrekt umgesetzt. Vorsicht ist bei „nichtfunktionalen“ User Stories geboten, da diese sich nicht direkt auf die Funktionalität beziehen. Hier kann man mit dem nachfolgenden Beispiel als Akzeptanzkriterium behelfen „In 95 Prozent aller Fälle werden neue Bildschirmmasken nach spätestens 2 Sekunden angezeigt“
I N H A L T
Specific (spezifisch) = Erläutern Sie detailliert, was Sie erreichen wollen z.B. “Erhöhung des ROI in Deutschland“
Measurable (messbar) = Legen Sie Zahlen fest z.B. „Erhöhung des ROI um 2 % vom aktuellen ROI von 13 % aus dem Jahresabschlussbericht 2012“
Agreed upon (vereinbart) = Dokumentieren Sie, wer zugestimmt hat z.B. ist eine Unterschrift eine gute Absicherung
Realistic (realistisch) = Das Gegenteil von idealistisch
Time bound (zeitgebunden) = Setzen Sie einen Meilenstein z.B. „bis Dezember 2013“ oder „innerhalb der nächsten 6 Monate“
s. Flipchart
Einfaches Beispiel:
Acceptance criteria „Bücher können dem Warenkorb hinzugefügt werden“
Voraussetzung (given): ausgewähltes Buch auf der Web-Seite
Auslöser (when): Bestätigung des Buttons „in den Warenkorb“
Soll-Zustand (then): der Warenkorb wird mit der Anzahl „1“ auf der Web-Seite angezeigt
Komplexeres Beispiel:
Acceptance criteria „Bücher können dem Warenkorb hinzugefügt werden“
Voraussetzung (given): Suchergebnis verschiedener Bücher zum Thema „User Stories“
Und (and): Markierung von 2 unterschiedlichen Büchern aus dem Suchergebnis
Auslöser (when): Bestätigung des Buttons „in den Warenkorb“
Soll-Zustand (then): der Warenkorb wird mit der Anzahl „2“ auf der Web-Seite angezeigt
Und (and): beim „mouse-over“ über den Warenkorb werden die im Warenkorb befindlichen Bücher mit der jeweiligen Anzahl angezeigt
In einer Iteration oder Release sind nur die User Stories enthalten, die wirklich fertig sind (keine fast fertigen User Stories).
Neben der Priorisierung nach dem MuSCoW-Prinzip sollte für die Iterations- und der Releaseplanung beachtet werden,
Interesse der breiten Usermasse an der Story (Funktionalität)
Interesse einer kleinen Usermasse an der Story (Funktionalität)
Abhängigkeiten zu anderen User Stories
Dauer der Umsetzung der User Story
Riskante User Stories mit infrastrukturellen oder nichtfunktionalem Hintergrund (z.B. neue Technologie)
Performance des Teams (Velocity)
Abstimmung mit Beteiligten
Automobiler Finanzdienstleister, der in 38 Ländern aktiv ist
Neben Finanzdienstleistungen (Kredit, Leasing und Versicherung) auch zentrale IT Dienstleistungen gegenüber Landesgesellschaften
Strategisches Projekt in einem von 4 Cluster (Mitarbeiter/People) zur Stärkung und Verbesserung der Zusammenarbeit
Verschiedene Kommunikationsplattformen gegenüber Landesgesellschaften, zu Langeantwortzeit, unklare Ansprechpartner, Individuallösungen für Reports zu Landesgesellschaften (Portfolio, Projekten)
Zentrale Landingplattform zur Kanalisierung und Ordnung/Strukturierung der Informationen
Anfragesystem