gpm-ipma.de - Integriertes, agiles Requirements …...Das Team der Corporate Payment Factory (CPF)...

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


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…


Unsere Prioritäten im Agilen 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.


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.)


Engineering


User Story

Form und Inhalt

User Story


2 1

3

Die User Stories wurden einem Qualitätsmanagement

Prozess unterzogen


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


Engineering


User Story

Form und Inhalt

User Story


2 1

3

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.

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’

Print

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.


Back Up


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

gpm-ipma.de - Integriertes, agiles Requirements …...Das Team der Corporate Payment Factory (CPF)...

Documents

Transcript of gpm-ipma.de - Integriertes, agiles Requirements …...Das Team der Corporate Payment Factory (CPF)...