Wir können auch anders agile Business Analysis mit BDD

979 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Business
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
979
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
12
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • 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
  • Wir können auch anders agile Business Analysis mit BDD

    1. 1. PASSION FOR IMPROVEMENTS © Acando GmbH Agile Business Analyse nach der BDD - Methode 15.05.20141 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    2. 2. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 2
    3. 3. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 3
    4. 4. PASSION FOR IMPROVEMENTS © Acando GmbH Was lief schief? Business Analysis: Anforderungsanalyse 15.05.20144 Wir können auch anders – Agile Business Analyse nach der BDD- Methode Bildquelle: http://www.buena-la-vista.de/buenalog/2010/02/08/projektmanagement-mal-anders/
    5. 5. PASSION FOR IMPROVEMENTS © Acando GmbH Wie können wir dieses Zielbild erreichen? Business Analysis: Anforderungsanalyse mit BDD 15.05.20145 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    6. 6. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 6
    7. 7. PASSION FOR IMPROVEMENTS © Acando GmbH Werte aus dem agilen Manifest Business Analysis: Agilität ● Individuen und Interaktionen - mehr als Prozesse und Werkzeuge ● Funktionierende Software - mehr als umfassende Dokumentation ● Zusammenarbeit mit dem Kunden - mehr als Vertragsverhandlung ● Reagieren auf Veränderung - mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. 15.05.20147 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    8. 8. PASSION FOR IMPROVEMENTS © Acando GmbH klassische und agile Vorgehensweise Business Analysis: Anforderungsaufnahme 15.05.20148 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    9. 9. PASSION FOR IMPROVEMENTS © Acando GmbH Business Analysis Body of Knowledge (BABOK-Techniken) Business Analysis: Anforderungsanalyse mit BDD 15.05.20149 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    10. 10. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 10
    11. 11. PASSION FOR IMPROVEMENTS © Acando GmbH „Behavior Driven Development ist die Implementierung einer Applikation oder Teilen einer Applikation durch die Beschreibung ihres Verhaltens aus der Perspektive ihrer Stakeholder.“ (Dan North, 2009) Was ist das? Business Analysis: Behavior Driven Development (BDD) Projektziele ProduktEntwicklung und Testmanagement Rückkopplung mit dem Auftraggeber Wünsche und Ideen des Auftraggebers 15.05.201411 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    12. 12. PASSION FOR IMPROVEMENTS © Acando GmbH Basic I: Was ist Triple C? Business Analysis: User Stories mit BDD Confirmation Notwendigkeit von Akzeptanzkriterien Conversation Grundlage für Kommunikation und Abstimmung zwischen Anfordernden, Tester und Entwickler Card Gerade genug Text, um die Anforderungen zu identifizieren und zu priorisieren 15.05.201412 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    13. 13. PASSION FOR IMPROVEMENTS © Acando GmbH Geschichte (User Story) ● Ich als <Rolle> möchte <etwas> <tun>, damit ich einen <Mehrwert> erreiche. Merkmale von Akzeptanzkriterien (Acceptance Criteria) ● Fokussierung Substantiv (etwas) und ein Vollverb (tun) ● Untersuchung anhand gezielter Fragen ● Festhalten und Verifizierung der Antworten ● konkrete Kriterien durch Szenarien in formaler Sprache (Gherkin language) ● Abstimmung der Ergebnisse mit den Stakeholdern Überführung in konkrete Testfälle (Test Cases) ● Vorbedingung ● Auszuführende Testschritte ● Erwartetes Ergebnis ● Nachbedingungen ● Verwendete Testdaten Basics II: Wie geht das? Business Analysis: User Stories mit BDD 15.05.201413 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    14. 14. PASSION FOR IMPROVEMENTS © Acando GmbH Basics II: Wie geht das? User Story <etwas> Business Analysis: User Stories mit BDD 15.05.201414 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    15. 15. PASSION FOR IMPROVEMENTS © Acando GmbH Basics II: Wie geht das? User Story <tun> Business Analysis: User Stories mit BDD 15.05.201415 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    16. 16. PASSION FOR IMPROVEMENTS © Acando GmbH Basics II: Wie geht das? User Story <Gherkin language> Business Analysis: User Stories mit BDD 15.05.201416 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    17. 17. PASSION FOR IMPROVEMENTS © Acando GmbH Independent Specific Negotiable Measurable Valuable Achievable Estimateable Realistic Short Time-bound Testable Inhalts- und Qualitätskriterien (INVEST to be SMART) Business Analysis: User Stories mit BDD 15.05.201417 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    18. 18. PASSION FOR IMPROVEMENTS © Acando GmbH ● Rollen ● Welche Beteiligten gibt es? ● Kann man die Beteiligten clustern? ● Kann man die Beteiligten in generische Rollen zusammenfassen? ● Welche Attribute haben die generischen Rollen? ● Ziele/Funktionalitäten in Bezug auf die Rollen ● Welche Funktionalitäten soll die Software erfüllen? ● Welche Funktionalitäten sind besonders wichtig? ● Welche Präferenzen sind vorhanden? (Benutzerfreundlichkeit, Technologie) ● Welche Geschäftsziele sollen mit der Software erreichen werden? Beispiel 1: Online-Buchshop Business Analysis: User Stories mit BDD 15.05.201418 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    19. 19. PASSION FOR IMPROVEMENTS © Acando GmbH User Story: ● Ich als potenzieller Neukunde möchte Bücher in meinen Warenkorb legen, damit ich Bücher bestellen kann. Acceptance Criteria: ● Bücher können dem Warenkorb hinzugefügt werden ● Hinzufügen des gleichen Buches erhöht die Menge ● Verschiedene Bücher von einer Merkliste in Warenkorb auf ein Mal hinzufügen ● Marketingkampagne bei bestimmten Buch im Warenkorb durchführen Scenarios per Acceptance Criteria: ● Given  (And) ● When  (And) ● Then  (And) Beispiel 2: Online-Buchshop Business Analysis: User Stories mit BDD 15.05.201419 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    20. 20. PASSION FOR IMPROVEMENTS © Acando GmbH Beispiel 2: Online-Buchshop Business Analysis: User Stories mit BDD 15.05.201420 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    21. 21. PASSION FOR IMPROVEMENTS © Acando GmbH ● Just in time ● Up to date ● In Abstimmung mit Stakeholder ● Einfachheit ist essenziell (KISS-Prinzip) Lebendige Dokumentation Business Analysis: User Stories mit BDD 15.05.201421 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    22. 22. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 22
    23. 23. PASSION FOR IMPROVEMENTS © Acando GmbH ● Die tägliche Arbeit der Mitarbeiter mit verschiedenen IT Rollen soll unterstützt und verbessert werden. ● Es sollen Informationen zentral zusammengeführt werden und es werden Möglichkeiten geschaffen, Informationen für die internen und externen Partner dieser virtuellen Organisationseinheit strukturiert abzulegen und abzurufen. ● Als interne Partner werden in diesem Konzept Mitarbeiter anderer, lokaler Organisationseinheiten und als externe Partner die verschiedenen Auslandsgesellschaften selbst sowie Mitarbeiter aus den Auslandsgesellschaften verstanden. ● Erfüllung der regulativen Anforderungen im Finanzdienstleistungssektor sowie der Projektvorgehensweise. Geschäftsziele für Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201423 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    24. 24. PASSION FOR IMPROVEMENTS © Acando GmbH ● Regional IT Manager ● Regional IT Mentor ● IT Service & Account Manager ● Regional Head of IT ● CIO ● Central Releasemanagement ● Governance Compliance and Risk ● Project Managers ● Visitors Beteiligte für Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201424 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    25. 25. PASSION FOR IMPROVEMENTS © Acando GmbH ● News können eingestellt, abgerufen und durchsucht werden ● Anfragen aus den Auslandsgesellschaften werden aufgenommen und nachverfolgt (Requestsystem) ● Links zu anderen SharePoint-Räumen, Webseiten, Anwendungen u.ä. können eingestellt werden ● Kontaktinformationen zu Ansprechpartnern des Regional IT Management und den Auslandsgesellschaften können angezeigt werden ● (Länderspezifische) Informationen können erfasst, abgerufen und durchsucht werden (benutzerabhängig) Ziele der Beteiligten für Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201425 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    26. 26. PASSION FOR IMPROVEMENTS © Acando GmbH Ausgangsvoraussetzungen: ● Verschiedene Benutzerrollen mit unterschiedlichen Berechtigungen ● Inhaltliche Beschränkungen je Benutzerrolle ● Standardfunktionalitäten (out-of-the-box) & corporate design nutzen ● Verschiedene Zugangs-URLs auf den SharePoint-Raum ● Verschiedene Medien ● Verschiedene Technologien und Browser ● Verschiedene News-Listen News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201426 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    27. 27. PASSION FOR IMPROVEMENTS © Acando GmbH Benutzerrollen und Benutzerrechte: News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.2014 SharePointSite SubSite Web-PartSite 27 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    28. 28. PASSION FOR IMPROVEMENTS © Acando GmbH User Stories: ● Ich möchte News aufrufen, um mich über Neuigkeiten zu informieren. ● Ich möchte nur aktuelle News angezeigt bekommen, um keine schon abgelaufenen Informationen zu lesen und angezeigt zu bekommen. ● Ich möchte bei Verwendung von Links in einer News Zugriff auf den verknüpften Inhalt erhalten, um ihn lesen und abrufen zu können. ● Ich möchte auf der Startseite aggregiert News aus den einzelnen Bereichen angezeigt bekommen, um nicht selbst die aktuellsten News in den einzelnen Bereichen abrufen zu müssen und um mich über News informieren zu können. News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201428 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    29. 29. PASSION FOR IMPROVEMENTS © Acando GmbH Acceptance Criteria: ● Ich bin als Nutzer eingerichtet, auf der Startseite und den Startseiten der einzelnen SharePoint-Bereiche werden mir News-Informationen aggregiert angezeigt. ● News werden mir immer nach Änderungen sortiert angezeigt (absteigende Sortierung nach Listenfeld „modified“) ● Ich sehe bei jeder News, wann sie veröffentlicht worden ist. ● Es werden maximal zwei News-Einträge pro SharePoint-Bereich aggregiert auf der Startseite angezeigt, um die Anzeige der News übersichtlich zu halten. News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201429 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    30. 30. PASSION FOR IMPROVEMENTS © Acando GmbH Gherkin: ● Given Externer Aufruf der SharePoint-URL (https-Protokoll) ● And Authentifizierung am Collaboration Gateway ● When Nutzer ist am SharePoint System authentifiziert ● And mit Berechtigungsstufe „Read“ oder einer höheren Berechtigungsstufe ● Then Anzeige von hinterlegten News auf Startseite ● And News werden nach dem aktuellen Datum absteigend sortiert News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201430 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    31. 31. PASSION FOR IMPROVEMENTS © Acando GmbH Gherkin: ● Given Interner Aufruf der SharePoint-URL (http-Protokoll) ● And Authentifizierung am Collaboration Gateway ● When Nutzer ist am SharePoint System authentifiziert ● And mit Berechtigungsstufe „Read“ oder einer höheren Berechtigungsstufe ● Then Anzeige von hinterlegten News auf Startseite ● And Max. zwei News-Einträge pro SharePoint-Bereich aggregiert News-Anzeige in Kollaborationsplattform Business Analysis: User Stories mit BDD – Kundenprojekt 15.05.201431 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    32. 32. PASSION FOR IMPROVEMENTS © Acando GmbH ● Abgründe ● Anspruch ● Methode ● Einsatz ● Fazit Wir können auch anders (Detlev Buck) – Agile Business Analyse nach der BDD - Methode 32
    33. 33. PASSION FOR IMPROVEMENTS © Acando GmbH Zusammenfassung Business Analysis: Behavior Driven Development 15.05.2014 Organisatorisch ● Integration in bestehende Vorgehensmodelle ● Frühe Einbindung aller Stakeholder ● Sehr gute Ausgangsbasis für das Testmanagement und das Testen ● Sehr gute Werkzeug- unterstützung im Testen und in der Testautomation Fachlich ● Reduzierung von unklaren Anforderungen ● Gemeinsames Verständnis der Anforderungen ● Beschreibung in einer verständlichen Sprache ● Funktionalität steht im Vordergrund ● Nur Anforderungen mit Mehrwert (value-driven) ● Gute Dokumentationsgrundlage 33 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    34. 34. PASSION FOR IMPROVEMENTS © Acando GmbH ●Nach Lernkurve einfach anwendbar ●Anforderungen verständlich und übersichtlich ●Punktlandung in den Umsetzungen ●BDD als Werkzeug anerkannt ●Hohe Akzeptanz der Anwendung Rückmeldungen des Kunden Business Analysis: User Stories mit BDD 15.05.201434 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    35. 35. PASSION FOR IMPROVEMENTS © Acando GmbH Fragen, Anmerkungen und Anregungen
    36. 36. PASSION FOR IMPROVEMENTS © Acando GmbH Kontakt Vielen Dank für Ihre Aufmerksamkeit! Mitglied in der GPM Fachgruppe Agiles Management Lars Bottke Consultant Business Area Nord 040/822259-318 lars.bottke@acando.de 15.05.201436 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    37. 37. PASSION FOR IMPROVEMENTS © Acando GmbH Backup 15.05.201437 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    38. 38. PASSION FOR IMPROVEMENTS © Acando GmbH Literaturverzeichnis ● Agiles Manifest http://agilemanifesto.org/iso/de/ ● Dan North http://dannorth.net/introducing-bdd/ ● User Stories http://www.amazon.de/User-Stories-Software-Entwicklung-u- Professional/dp/3826658981 ● Gherkin language http://docs.behat.org/guides/1.gherkin.html ● Werkzeuge ● Cucumber http://cukes.info/ ● JBehave http://jbehave.org/ ● NBehave http://nbehave.org/ ● Geb http://www.gebish.org/testing/ 15.05.2014 Wir können auch anders – Agile Business Analyse nach der BDD- Methode
    39. 39. PASSION FOR IMPROVEMENTS © Acando GmbH Zusammenfassendes Beispiel CMS Business Analysis: Behavior Driven Development 15.05.2014 Wir können auch anders – Agile Business Analyse nach der BDD- Methode ● User Story ● Ich als Publisher möchte ein Dokument veröffentlichen, damit ich das Dokument online auf dem Server verfügbar machen kann ●Acceptance Criteria ● User mit Rechten zur Veröffentlichung ●Abbildung im JAVA Quellcode StoryPublication() { @Test scenario_publish_to_live_server() { Reference<User> refA = ref("A"); // some simple container for values… given_user_A_with_publish_permissions(refA); // set value given_document_D_to_be_published(refD); given_user_A_is_logged_in(refA); // use value when_user_A_publishes_document_D(refA, refD); then_document_D_appears_on_live_server(refD); } } 39

    ×