Integriertes, agiles Requirements Engineering mit Use Cases. GPM Region Hamburg Ulrike Umkehrer (Braincourt GmbH) Anita Pacher (MunichRe)

Transkript

1 Integriertes, agiles Requirements Engineering mit Use Cases GPM Region Hamburg Ulrike Umkehrer (Braincourt GmbH) Anita Pacher (MunichRe)

2 Das Team der Corporate Payment Factory (CPF) sah sich 2014 mit folgenden Anforderungen konfrontiert Diese Herausforderungen sollten durch einen Systemupgrade gemeistert werden - unter der Anwendung einer agilen Projektmethode Integriertes, agiles Requirements Engineering

3 Agile Projektmethoden haben den Markt erobert Gemäß der State of Agile Survey der Scrum Alliance.org in 2015 sind mittlerweile ca. 60 Prozent der weltweiten Projekte agil. Von allen agilen Frameworks ist Scrum das am meisten verbreitete. Firmen wie die MunichRe, die Daimler AG oder die BMW Group haben bereits 2011 bis 2013 ihre eigenen agilen Frameworks implementiert agil 32% klassisch 68% agil 60% klassisch 40% Folie 3

4 Die agile Vorgehensweise wird durch fünf wesentliche Prinzipien bestimmt... aber 1. Ermittlung 2. Analyse 3. Beschreibung 4. Konsensbildung und 5. Verabschiedung von Business Anforderungen? Folie 4

5 Vom klassischen Fachkonzept zum Drei-Zeiler auf Karte? Folie 5

6 Der PRODUCT OWNER (PO) formuliert die Erwartungen an das zu entwickelnde System Wie kann ich mit User Stories Business Prozesse bedienen? Folie 6

7 Die MR Essentials Methode der MunichRe gibt dazu Antworten Copyright Munich Re and Ivar Jacobson International SA. Integriertes, agiles Requirements Engineering

8 Warum also nicht gleich mit einem Use Case Modell beginnen? Unser Provider hatte uns nach eigenen Aussagen bereits mit einem ausgereiftem und erprobten Backlog versorgt. Aufgrund der geplanten internationalen Roll Outs und der technischen Neuerungen gab es wenig zeitlichen Spielraum für ein strukturelles Requirements Engineering. Viele neue Projektteilnehmer und Stakeholder aus den Business Einheiten waren nicht mit agilen Methoden und noch weniger mit den Regeln zur Erstellung von Use Cases vertraut. Im Rahmen unserer Möglichkeiten wäre es nicht sinnvoll gewesen zusätzlich zur agilen Projektmethode schnell noch eine Use Case Struktur aufzusetzen. Wir mussten priorisieren Integriertes, agiles Requirements Engineering

9 Unsere Prioritäten im Agilen Requirements Engineering User Story Qualitätsprozess 2 User Story Form und Inhalt 1 Use Cases 3 Integriertes, agiles Requirements Engineering

10 User Story Form und Inhalt Richtlinien für die User Story Formulierung 1. In der User Story wird klar zwischen Ziel und Begründung unterschieden (As a <type of user>, I want <some goal> so that <some reason>). 2. Die User Story ist auf einem Level, den auch ein Nicht-Experte versteht. 3. Annahmen, Vorbedingungen und Abnahmekriterien in der Gegenwartsform. 4. Klare Unterscheidung zwischen Annahmen und Vorbedingungen treffen. 5. Alle Annahmen müssen vor der Übergabe ins Entwicklerteam gelöst sein. 6. Formulierung der Akzeptanzkriterien in der Form, dass sie klar so getestet werden können (ja/nein, failed/passed, schwarz/weiß). 7. Bildunterschriften unter Grafiken, Bilder, Screenshots und Tabellen. 8. Auf Dokument-Referenzen verweisen, Referenzen nicht doppelt im Dokument! 9. Abkürzungen und Business spezifische Begriffe sind im Glossar dokumentiert. Integriertes, agiles Requirements Engineering

11 Interaktiver Teil 1 Verfassen von 2-3 User Stories gemäß den vorher genannten Kriterien für einen frei zu definierenden Entwicklungsauftrag Teams zwischen 5 und 7 Teilnehmern (*3) 5 Min Vorbereitung 10 Min Schreiben 5 Min Präsentation (*3) 5 Min Diskussion (Feed back aus dem Plenum) Interaktiv 35 Minuten Folie 11

12 User Story Vorlage für interaktiven Teil 1 - Die Workshop Teilnehmer definieren in kleinen Teams ein oder zwei funktionale Anforderungen gemäß der unten beschriebenen User Story Vorlage und präsentieren sie anschließend im Plenum 1. Wer: Als <Rolle> 2. Was: möchte ich <Ziel/Wunsch> 3. Warum: um <Nutzen /Business Value> 4. Level of Done: Die US ist nur dann fertig, wenn. 5. Constraints: Welche Rahmenbedingungen/Vorgaben sind einzuhalten, z.b. Security, Corporate Identity, Performance etc. 6. UAT/Verprobung: Definition der Testkriterien für die Abnahme der US durch den PO/PO IT am Sprintende (ggf. auch Teil der User Acceptance Tests durch die Enduser am Release Ende) 7. Dependencies: Welche Abhängigkeiten bestehen (zu anderen User Stories, externe Faktoren etc.) Folie 12

14 Die User Stories wurden einem Qualitätsmanagement Prozess unterzogen Setup Backlog Documentation 1. Setup User Story and align Provider and MunichRe information requirements Responsible - Business Analyst (Provider) - Test Analyst (MunichRe) Quality Gate 1 User story is written according to agreed documentation guidelines (Provider) User story is written on a level of information for a skilled non expert (Provider) User story is accomplished with all relevant information for Provider as well as MunichRe Services (MR) Test cases are setup along acceptance criteria (MR) I t e r a t i o n 2. Reconcile User Story with stakeholder 3. Update User Story Quality Gate 2 4. Final Walk Through Session and approval of User Story (every Thursday) - Requirements Engineer (MunichRe) - Business Analyst (Provider) - Business Analyst (Provider) - Test Analyst (MunichRe) User story is reconciled and enriched with information provided by stakeholder (MR) User story is aligned with stakeholder requirements (MR) - Business Analyst (Provider) - Stakeholder - Product Owner Quality Gate 3 User story is approved by all stakeholders (MR) Test cases are documented (MR) User story is updated and serves as a basis for IT documentation (Provider) 5. Formal Approval of User Story Iteration Planning Day - Programme Manager / Product Owner Integriertes, agiles Requirements Engineering

16 Das Fehlen der Use Cases zu Beginn des Projektes stellte uns vor große Herausforderungen 1. Wie stellen wir den Gesamtzusammenhang zwischen den fertiggestellten User Stories und den damit unterstützten Business Prozessen her? 2. Wie erkennen wir den Gesamt- Fertigstellungsgrad des Projektes? 3. Wie können wir End2End Testfälle generieren?. wir beschlossen, das Thema Use Case so schnell wie möglich anzugehen. Integriertes, agiles Requirements Engineering

17 Teil 1: Für die wichtigsten Business Prozesse wurden Use Cases mit ihren basic und alternative Flows erstellt Use Case Basic happy flow alternative flow Folie 17

18 Teil 2: Die erstellten User Stories wurden den Business Use Cases mit ihren Flows zugeordnet Anforderungen, die im Backlog mit User Stories dokumentiert sind werden thematisch kategorisiert und gebündelt und den Business Use Cases zugeordnet. Folie 18

19 Teil 3: So konnten die entwickelten User Stories gegen jeden Use Case und gegen das Gesamtprojekt abgeglichen werden User Stories User Stories User Stories Gesamtprojekt Use Case1 Use Case2 Use Case3 60% 30% 10% 40% Folie 19

20 Exemplarische Use Case scenarios Unitary Payment Unitary Payments Use Case Manual entry Scheduled upload Cutoff / rex Print Payment outgoing File splitting date Bulking Approval Signing PTK Standing screening routing Others encrypted unencrypted validation Payment Comments/De orders Flow 1 alternative 1 User Story 7 User Story 16 User Story 22 User Story 30 User Story 39 User Story 53 User Story 62 User Story 71 User Story 80 User Story Flow 2 alternative 2 User Story 8 User Story 17 User Story 23 User Story 31 User Story 40 User Story 54 User Story 63 User Story 72 User Story 81 User Story Flow 3 User Story 1 User Story 9 User Story 24 User Story 32 User Story 41 User Story 47 User Story 55 User Story 64 User Story 73 User Story 82 User Story Flow 4 User Story 2 User Story 18 User Story 25 User Story 33 User Story 42 User Story 48 User Story 56 User Story 65 User Story 74 User Story 83 User Story Flow 5 User Story 3 User Story 10 User Story 19 User Story 26 User Story 34 User Story 43 User Story 49 User Story 57 User Story 66 User Story 75 User Story 84 User Story 93 Defect 699,703 Flow 6 User Story 4 User Story 11 User Story 20 User Story 27 User Story 35 User Story 44 User Story 50 User Story 58 User Story 67 User Story 76 User Story 85 User Story 94 Defect 623, 705,70 Flow 7 alternative 1 User Story 5 User Story 12 User Story 21 User Story 28 User Story 36 User Story 45 User Story 51 User Story 59 User Story 68 User Story 77 User Story 86 User Story 95 Defect 640,652,68 Flow 8 alternative 2 User Story 13 User Story 29 User Story 37 User Story 46 User Story 52 User Story 60 User Story 69 User Story 78 User Story 87 User Story ,702 Flow 9 User Story 6 User Story 14 User Story 38 User Story 47 User Story 61 User Story 70 User Story 79 User Story 88 User Story Scenario per Zahlungsformat z.b. MT101, DTAUS, User Story

21 Exemplarische success guarantees Unitary Payment Success guarantees Payment is executed as input by user or imported (=> workflow) All formats work correctly with all banks (EBICS as well as SWIFT) Statement of Accounts can be collected, validated and published correctly Minimum guarantees Logging IE 11 compliance Performance under 3 sec

22 Interaktiver Teil 2 Erstellung eines Use Cases und Zuordnung der relevanten, in Teil 1 erstellen User Stories auf diesen Use Case Teams zwischen 5 und 7 Teilnehmern (3 = Minimum) 5 Min Vorbereitung 10 Min Use Case schreiben / User Stories einordnen 5 Min Präsentation 5 Min Diskussion (Feed back aus dem Plenum) Interaktiv 35 Minuten Folie 22

23 Use Case Vorlage für interaktiven Teil 2-1. Use Case Name (name = Use Case-Goal) 2. Primary Actor (a role name for the primary actor or description) 3. Further Actors (role Name for further actors or description) 4. Stakeholders and their Interests (list of stakeholders and their key interests in the use case) 5. Success Guarantees (the state of the world if goal succeeds) 6. Minimal Guarantees (how the interests are protected under all exits) 7. Trigger (what starts the use case or scenario) 8. Main success scenario 9. Alternative scenario Folie 23

24 Welchen Nutzen haben wir daraus für das Projekt gezogen? Höhere Sichtbarkeit des Gesamtziels und des übergreifenden Geschäftsnutzens durch Konsolidierung der User Stories auf wenige Use Cases. Zusätzliche Validierung der Entwicklung durch Abgleich der User Stories mit den Business Use Cases. Herstellen einer End to End Testability für User Stories. Durchgängigkeit und Nachhaltigkeit der Anforderungsdokumentation für Business und IT. Business Process Optimierung und Effizienzgewinne als Nebenprodukt aus den Validierungsschritten und dem Qualitätsmanagement Prozess für die User Stories. Integriertes, agiles Requirements Engineering

25 Back Up Integriertes, agiles Requirements Engineering

26 Beispiel für eine funktionale Anforderung 1. Als HR-Verantwortlicher (bzw. Marktverantwortlicher). 2. benötige ich die Bereitstellung der KPI Mitarbeiterfluktuation pro Markt in Form eines Online- Reports. 3. so dass ich laufend prüfen kann, wie sich Mitarbeiterzufriedenheit und Beschäftigungsdauer im Unternehmen entwickeln. 4. Level of Done: Report ist entwickelt, getestet, durch den jeweiligen lokalen Marktverantwortlichen abgenommen und auf dem HR Portal bereitgestellt. 5. Constraints/Precondition: Konzernweite Definition für Mitarbeiterfluktuation pro Markt ist getroffen, da Abteilungen unterschiedliches Verständnis haben. 6. UAT Criteria: Kennzahl Mitarbeiterfluktuation pro Markt wird korrekt auf Basis der beigefügten Kalkulationsanweisung berechnet, ist als Online Report auf dem Portal bereitgestellt mit Navigation, Rollen und Rechten, Format entspricht CI. 7. Abhängigkeiten: Es bestehen Abhängigkeiten bzgl. der rechtzeitigen Bereitstellung der HR- und Unternehmenskennzahlen KPI 1, KPI2 und KPI3 zu den vereinbarten polling Zeiten, auf die diese Kennzahl aufgebaut ist. Folie 26

27 Beispiel für einen Use Case 1. Use Case Name / name = Use Case-Goal a. Geld abheben 2. Primary Actor / a role name for the primary actor or description a. Bankkunde 3. Further Actors / Role Name for further actors or description> a Stakeholders and their Interests / list of stakeholders and their key interests in the use case a. Bank: Schutz vor unberechtigtem Zugriff b. Kunde: Abbuchung nur nach Auszahlung 5. Success Guarantees / the state of the world if goal succeeds> a. Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht b. Die Karte wurde vom Automat ausgegeben. c. Das System ist bereit für den nächsten Kunden. 6. Minimal Guarantees <how the interests are protected under all exits> a. Alle Fehler und Transaktionsdaten wurden protokolliert Quelle: OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik Folie 27

28 Beispiel für einen Use Case 1. Trigger / what starts the Use Case (may be a time event) a. Kunde schiebt Karte ein 2. Main Success Scenario a. Kunde schiebt Karte ein b. Das System stellt fest, dass die Karte gültig ist c. Kunde gibt PIN ein d. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist e. Kunde gibt gewünschten Betrag ein f. System bucht Betrag vom Konto ab g. System gibt Karte aus h. System gibt Geld aus 3. Alternative Scenario a. System erkennt, dass die Karte nicht gültig ist b. Das System protokolliert den Versuch c. Das System benachrichtigt den Kunden d. Das System gibt die Karte aus e. Use Case wird abgebrochen Quelle: OOAD, Prof. Dr. Ralf Hahn, SS2008, h_da, Fachbereich Informatik Folie 28