gpm-ipma.de - integriertes, agiles requirements …...das team der corporate payment factory (cpf)...
Post on 07-Aug-2020
3 Views
Preview:
TRANSCRIPT
Integriertes, agiles Requirements
Engineering mit Use Cases
GPM Region Hamburg
Ulrike Umkehrer (Braincourt GmbH)
Anita Pacher (MunichRe)
Das Team der Corporate Payment Factory (CPF) sah
sich 2014 mit folgenden Anforderungen konfrontiert
9.5.2016 2 Integriertes, agiles Requirements Engineering
Diese Herausforderungen sollten durch einen Systemupgrade
gemeistert werden - unter der Anwendung einer agilen Projektmethode
Folie 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%
2010 2015
Folie 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 5
Vom klassischen Fachkonzept zum Drei-Zeiler auf Karte?
Folie 6
Der PRODUCT OWNER (PO) formuliert die Erwartungen an das zu entwickelnde System
Wie kann ich mit User Stories
Business Prozesse bedienen?
Die MR Essentials Methode der MunichRe gibt dazu
Antworten
9.5.2016 7 Integriertes, agiles Requirements Engineering
Copyright © Munich Re and Ivar Jacobson International SA.
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…
9.5.2016 8 Integriertes, agiles Requirements Engineering
Unsere Prioritäten im Agilen Requirements
Engineering
9.5.2016 9 Integriertes, agiles Requirements Engineering
User Story
Form und Inhalt
User Story
Qualitätsprozess Use Cases
2 1
3
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.
9.5.2016 10 Integriertes, agiles Requirements Engineering
Folie 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 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.)
Unsere Prioritäten im Agilen Requirements
Engineering
9.5.2016 13 Integriertes, agiles Requirements Engineering
User Story
Form und Inhalt
User Story
Qualitätsprozess Use Cases
2 1
3
Die User Stories wurden einem Qualitätsmanagement
Prozess unterzogen
9.5.2016 14 Integriertes, agiles Requirements Engineering
Setup Backlog Documentation Responsible
1. Setup User Story and align Provider and MunichRe information requirements - Business Analyst (Provider)
- Test Analyst (MunichRe)
2. Reconcile User Story with stakeholder - Requirements Engineer (MunichRe)
- Business Analyst (Provider)
3. Update User Story - Business Analyst (Provider)
- Test Analyst (MunichRe)
4. Final ‚Walk Through Session‘ and approval of User Story (every Thursday)
- Business Analyst (Provider)
- Stakeholder
- Product Owner
5. Formal Approval of User Story - Programme Manager / Product Owner
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)
• User story is reconciled and enriched with information provided by stakeholder (MR)
• User story is aligned with stakeholder requirements (MR) Quality Gate 2
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)
Iteration Planning Day
I
t
e
r
a
t
i
o
n
Unsere Prioritäten im Agilen Requirements
Engineering
9.5.2016 15 Integriertes, agiles Requirements Engineering
User Story
Form und Inhalt
User Story
Qualitätsprozess Use Cases
2 1
3
Das Fehlen der Use Cases zu Beginn des Projektes
stellte uns vor große Herausforderungen
9.5.2016 16 Integriertes, agiles Requirements Engineering
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.
Folie 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 18
Teil 2: Die erstellten User Stories wurden den Business Use Cases mit ihren Flows zugeordnet
… thematisch
kategorisiert und
gebündelt…
Anforderungen, die im Backlog mit User
Stories dokumentiert sind werden…
… und den Business
Use Cases zugeordnet.
Folie 19
Teil 3: So konnten die entwickelten User Stories gegen jeden Use Case und gegen das Gesamtprojekt abgeglichen werden
60%
Use Case1
30%
Use Case2
10%
Use Case3 …
40%
User Stories User Stories User Stories Gesamtprojekt
Exemplarische Use Case scenarios ‘Unitary Payment’
Standing
ordersOthers encrypted unencrypted Payment Comments/Defects
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 89 703
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 90 703
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 91 703
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 92 703
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
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 ,703,697
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,682,703,685
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 96703,702
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 97703
File splitting
Cutoff / rex
date
validation
Payment
screeningBulking Approval PTK Signing
outgoing
routing
Flow 6
Flow 9
Scheduled uploadManual entry
Use Case
Scenario per
Zahlungsformat
z.B. MT101, DTAUS,… User Story
Unitary Payments
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
Folie 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 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
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.
9.5.2016 24 Integriertes, agiles Requirements Engineering
Back Up
9.5.2016 25 Integriertes, agiles Requirements Engineering
Folie 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 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. -
4. 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 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
top related