Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Scrum in der Rückversicherung Eine Erfolgsgeschichte
Wolfgang Pleus (www.pleus.net)
Scrum Day – SAP St. Leon Rot , 05.07.2012
Agenda
Ausgangslage und Motivation
Phase 1 - Initialisierung
• Vom UseCase zur UserStory
• Wasserfall trifft Scrum
Phase 2 – Durchführung
• Spezifizieren mit Scrum?
• Umgang mit dynamischen Teams
• Qualitätssicherung und Test
• Projektmanagement im veränderlichen Umfeld
Phase 3 - Perspektiven
• Übertragbarkeit auf andere Projekte
• Organisatorische Verankerung
Ausgangslage
Hannover Re - Einer der weltgrößten Rückversicherer
Technische und methodische Erneuerung des zentralen Business Partner
Management Systems
Geschäftskritisches Projekt, weltweites Rollout, 11.2009 – 01.2012
Bereitschaft neue Wege zu gehen
Wolfgang Pleus - PLEUS Consulting
• IT- und Methodenberatung seit 1993
• Scrum Master und Coach, Solution Architect
• Begleitet das Projekt von der Analyse bis zur Produktion
Vom UseCase zur UserStory
Strukturierte Anforderungs-
analyse
• Ergebnisse: Usecases, Requirements und Grobkonzept
• 3 Personen: Erschliessen des Kontextes
• Dauer: 3 Monate
Product Backlog
Workshop
• Ergebnis: Initiales Product Backlog
• Gesamtes Team (20): Verteilung des Kontextwissens
• Dauer: 3 Tage
Umsetzung
• Ergebnisse: Konzeption und Produkt
• Dynamisches Team: Iterative Umsetzung
• Dauer: 23 Monate
Product Owner und Solution Architect transportieren Kontextwissen
Vom UseCase zur UserStory
Strukturierte Anforderungs-
analyse
• Ergebnisse: Usecases, Requirements und Grobkonzept
• 3 Personen: Erschliessen des Kontextes
• Dauer: 3 Monate
Product Backlog
Workshop
• Ergebnis: Initiales Product Backlog
• Gesamtes Team (20): Verteilung des Kontextwissens
• Dauer: 3 Tage
Umsetzung
• Ergebnisse: Konzeption und Produkt
• Dynamisches Team: Iterative Umsetzung
• Dauer: 23 Monate
Lessons learned:
1. Grobanalyse hilft den Kontext zu verstehen.
2. Product Owner und Solution Architect müssen das Projekt
fortwährend begleiten (Kontextwissen).
3. Trennung von Analyse- und Entwicklungsteam nicht hilfreich
Product Backlog Workshop
Storypoints
Business value
Team
Product
Owner
Scrum
Master
Product Backlog Workshop
Storypoints
Business value
Team
Product
Owner
Scrum
Master
Lessons learned:
1. Unterscheidung von Konzeption und Umsetzung ist hilfreich.
2. Mapping der Anforderung stellt 100% Abdeckung sicher.
3. Workshop ermöglicht gemeinsames Verständnis im Team
(Fach/IT).
Wasserfall trifft Scrum
Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung
Analyse Design Entwicklung Betrieb
Grobkonzept
REVIEW MEETING
RETROSPECTIVE
MEETING
Agile Spezifikation
Agile Entwicklung
Agiler Test
Agiles Projektmanagement
Pflichten:
Abgenommene Konzepte
Testfälle
Monatliche Statusberichte
Wasserfall trifft Scrum
Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung
Analyse Design Entwicklung Betrieb
Grobkonzept
REVIEW MEETING
RETROSPECTIVE
MEETING
Agile Spezifikation
Agile Entwicklung
Agiler Test
Agiles Projektmanagement
Pflichten:
Abgenommene Konzepte
Testfälle
Monatliche Statusberichte
Lessons learned:
1. Klassische und agile Methoden sind kombinierbar, solange die
Artefakte geliefert werden.
2. Klassischer Mehraufwand bringt wenig Mehrwert.
3. Prinzipiell jederzeit zu Scrum gewechselt werden.
Spezifizieren mit Scrum?
Silverlight SketchFlow
Enterprise Architect
XML
Annotationen
und Screens Entwerfen / Spezifizieren
Generieren
Veröffentlichen
Interne Freigabe
(DoD)
Offizielle Abnahme
Pflicht:
Abgenommene Konzepte
Word Wiki
Spezifizieren mit Scrum?
Silverlight SketchFlow
Enterprise Architect
XML
Annotationen
und Screens Entwerfen / Spezifizieren
Generieren
Veröffentlichen
Interne Freigabe
Offizielle Abnahme
Pflicht:
Abgenommene Konzepte
Word
Lessons learned:
1. Erst konzipieren, dann implementieren.
2. Konzeption steigert Verbindlichkeit und Klarheit.
3. Spezifizieren nur soviel wie nötig.
4. Zeitliche Nähe von Spezifikation und Umsetzung erhält den
Wissenskontext (1 Sprint Vorlauf ideal).
5. Bug or Change Problem (Vertrauen ist essentiell).
Umgang mit dynamischen Teams
Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Entwicklung
snb (dev) 26 25 10 15 18 17 13 8 20 17 16 19 18 22 21 16 17 21 8 15 10 9
pw2 (dev) 26 25 23 20 22 23 9 22 20 19 14 23 17 19 19 20 14 19 19 21 20 10
ren (db, bi, dev) 10 10 8 6 10 10 13 7 15 19 18 20 22 22 18 19 17 12 22 21 19 15
mf2 (dev) 21 19 22 20 21 20 20 20 14 20 23 20 15
hto(db) 10 10 10 10 10 10 5 18 10 8 12
sb3 (migration) 14 20 15 14 25 25 4
Spezifikation
svd (po) 5 13 13 12 11 12 10 8 5 10 7 7 10 9 9 5 9 8 8 10 10 5
jds (spec) 5 20 20 12 15 16 16 12 8 8 7 5 4 5 8 9 9 9 5 9 9 5
htn (spec, test) 8 13 10 10 12 8 7 9 7 7 7 12 11 13 11 10 21 17 19 10 8
sta (spec) 8 8 6 5 5 2 3 3 1 1 2 2 2 4 4 4 4 3 3 5 3
eth (spec) 3 4 8 9 10 6 3 10 6 5 2 5 3 2 2 4 6
ghc/dki (spec) 8 4 5 9 6 6 4 4 2 6
tj (spec) 1 1 1 1 3 1 5 2
knt (spec) 3 3 4 6 10 10 10 3 3 3 5 2 3
Test
krc (test) 7 10 10 13 9 10 9 12 15 15 18 19 20 25 14 25 23 23
dai (training) 6 8 8 8 5
fnn (test) 20 20 9 5 5
Weitere
mrk (bi) 10 10 8 6 3 5 6 5 10 4 2 1
lad (db) 3 4 5
dai (training) 6 8 8 8 5
le2 (trainings) 6 2
Umgang mit dynamischen Teams
Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Entwicklung
snb (dev) 26 25 10 15 18 17 13 8 20 17 16 19 18 22 21 16 17 21 8 15 10 9
pw2 (dev) 26 25 23 20 22 23 9 22 20 19 14 23 17 19 19 20 14 19 19 21 20 10
ren (db, bi, dev) 10 10 8 6 10 10 13 7 15 19 18 20 22 22 18 19 17 12 22 21 19 15
mf2 (dev) 21 19 22 20 21 20 20 20 14 20 23 20 15
hto(db) 10 10 10 10 10 10 5 18 10 8 12
sb3 (migration) 14 20 15 14 25 25 4
Spezifikation
svd (po) 5 13 13 12 11 12 10 8 5 10 7 7 10 9 9 5 9 8 8 10 10 5
jds (spec) 5 20 20 12 15 16 16 12 8 8 7 5 4 5 8 9 9 9 5 9 9 5
htn (spec, test) 8 13 10 10 12 8 7 9 7 7 7 12 11 13 11 10 21 17 19 10 8
sta (spec) 8 8 6 5 5 2 3 3 1 1 2 2 2 4 4 4 4 3 3 5 3
eth (spec) 3 4 8 9 10 6 3 10 6 5 2 5 3 2 2 4 6
ghc/dki (spec) 8 4 5 9 6 6 4 4 2 6
tj (spec) 1 1 1 1 3 1 5 2
knt (spec) 3 3 4 6 10 10 10 3 3 3 5 2 3
Test
krc (test) 7 10 10 13 9 10 9 12 15 15 18 19 20 25 14 25 23 23
dai (training) 6 8 8 8 5
fnn (test) 20 20 9 5 5
Weitere
mrk (bi) 10 10 8 6 3 5 6 5 10 4 2 1
lad (db) 3 4 5
dai (training) 6 8 8 8 5
le2 (trainings) 6 2
Lessons learned:
1. Je kleiner die Entfernung vom Projektbüro umso größer das Committment.
2. Das Kernteam muss stabil bleiben.
3. Projektbüro und Vor-Ort-Präsenz sind essentiell.
4. Kurze Wege zwischen Spezifikation, Entwicklung und Test steigern die
Produktivität.
5. Teamgröße teilweise am Limit (erschwerte Kommunikation), Split erschien
als Nachteil.
Qualitätssicherung und Test
Strukturierte Qualitätssicherung im Team
• Unit, Integration, Akzeptanz, Last&Performance
Qualität in der DoD
• Anzahl neue Testfälle = SP im Sprint *Testfälle pro SP-Faktor (z.B. 2)
• Durchführen aller Neuen + 25% Retest
Bug Backlog als messbarer Qualitätsindikator (bei >50 Eintrag ins Changelog)
Testfälle für die QM-Endabnahme wiederverwendbar. uc Load profile
Sperren setzen (pid:
277511)
Standard user (95,5%)
Power user (4,5%)
Datamanager
(1,1%)
Stammdaten ändern /
anlegen (Bids)
Run off manager
(2,8%)
Simple user
(Protection Re)
(1,1%)
Standard user (z.B.
Underwriter)
(66,1%)
Security Consumer
(4,4%)
Security Analyst
(0,6%)
Maximalnutzung: Maximal 900 User können
RoBP potentiell gleichzeitig verwenden und
verschiedene Geschäftsvorgänge ausführen.
Fav oriten erzeugen -
Limit 3s
Suchergebnis exportieren -
Limit 6s
Änderung/Neuanlage
beantragen (bid:13553)
Verfahren durchführen
(Pids, pid:370661)
Stammdaten ansehen (Bids)
Dokument anhängen
(pid:370661)
RoBP starten - Limit 12s
Portal ansehen
Current Accountant
(3,3%)
Technical
Accountant (20,6%)
Keine RoBP
Benutzung
Suchen (QueryStrings) - Limit
0,5s
Report anzeigen (pid:
370661)
Approv e durchführen
(pid:370661)
Kontext anzeigen
Validieren
50%
20%
100%
10%
50%30%
35%
20%
50%
10%
20%
25%
80%
50%
25%
N:98%, H:
95%
N:2% ,H:5%
N:15%, H:
40%
N:70%, H:
5%
N:15%, H:
55%
2%20%
Pflicht:
Testfälle
Pflicht:
Testfälle
Qualitätssicherung und Test
Strukturierte Qualitätssicherung im Team
• Unit, Integration, Akzeptanz, Last&Performance
Qualität in der DoD
• Anzahl neue Testfälle = SP im Sprint *Testfälle pro SP-Faktor (z.B. 2)
• Durchführen aller Neuen + 25% Retest
Bug Backlog als messbarer Qualitätsindikator (bei >50 Eintrag ins Changelog)
Testfälle für die QM-Endabnahme wiederverwendbar. uc Load profile
Sperren setzen (pid:
277511)
Standard user (95,5%)
Power user (4,5%)
Datamanager
(1,1%)
Stammdaten ändern /
anlegen (Bids)
Run off manager
(2,8%)
Simple user
(Protection Re)
(1,1%)
Standard user (z.B.
Underwriter)
(66,1%)
Security Consumer
(4,4%)
Security Analyst
(0,6%)
Maximalnutzung: Maximal 900 User können
RoBP potentiell gleichzeitig verwenden und
verschiedene Geschäftsvorgänge ausführen.
Fav oriten erzeugen -
Limit 3s
Suchergebnis exportieren -
Limit 6s
Änderung/Neuanlage
beantragen (bid:13553)
Verfahren durchführen
(Pids, pid:370661)
Stammdaten ansehen (Bids)
Dokument anhängen
(pid:370661)
RoBP starten - Limit 12s
Portal ansehen
Current Accountant
(3,3%)
Technical
Accountant (20,6%)
Keine RoBP
Benutzung
Suchen (QueryStrings) - Limit
0,5s
Report anzeigen (pid:
370661)
Approv e durchführen
(pid:370661)
Kontext anzeigen
Validieren
50%
20%
100%
10%
50%30%
35%
20%
50%
10%
20%
25%
80%
50%
25%
N:98%, H:
95%
N:2% ,H:5%
N:15%, H:
40%
N:70%, H:
5%
N:15%, H:
55%
2%20%
Lessons learned:
1. Test beginnen, sobald etwas Testbares da ist.
2. Akzeptanztest: Kosten/Nutzen-Verhältnis zugunsten manueller Tests.
3. Messbare Qualitätsindikatoren etablieren (Wann ist etwas gut?).
4. Tester müssen im Team sein - kurze Wege.
5. Nähe von Spezifikation und Test sicherstellen (Wissenskontext).
6. Entspannte Produktivsetzung als neue Erfahrung.
Projektmanagement im veränderlichen Umfeld
Velocity = Storypoints / Personentage
• Vorher / Nachher Betrachtung (Commitment und Realität)
Releaseprognosen unter Einbeziehung regelmäßiger SP Zuwächse
Grooming Workshops als zentraler Steuerungsmechanismus
31.12.2010 Ursprüngliche
Annahme
10.03.2010 Initiales Backlog
18.06.2013 - Grooming +
Reestimation
20.12.2011 Grooming
17.06.2012 06.01.2012 Grooming
16.01.2012 Release
06.07.200914.10.200922.01.201002.05.201010.08.201018.11.201026.02.201106.06.201114.09.201123.12.201101.04.201210.07.201218.10.201226.01.201306.05.201314.08.201322.11.2013
0100200300400500600700800900
10001100120013001400150016001700180019002000
13
.11
.200
9
13
.12
.200
9
13
.01
.201
0
13
.02
.201
0
13
.03
.201
0
13
.04
.201
0
13
.05
.201
0
13
.06
.201
0
13
.07
.201
0
13
.08
.201
0
13
.09
.201
0
13
.10
.201
0
13
.11
.201
0
13
.12
.201
0
13
.01
.201
1
13
.02
.201
1
13
.03
.201
1
13
.04
.201
1
13
.05
.201
1
13
.06
.201
1
13
.07
.201
1
13
.08
.201
1
13
.09
.201
1
13
.10
.201
1
13
.11
.201
1
13
.12
.201
1
13
.01
.201
2
Pro
gn
ose E
nd
ete
rmin
Pro
du
ct
Backlo
g
Erfassungsdatum
Product Backlog und Releaseprognose Product Backlog
Prognose Endetermin
Pflicht:
Statusberichte
Projektmanagement im veränderlichen Umfeld
Velocity = Storypoints / Personentage
• Vorher / Nachher Betrachtung (Commitment und Realität)
Releaseprognosen unter Einbeziehung regelmäßiger SP Zuwächse
Grooming Workshops als zentraler Steuerungsmechanismus
31.12.2010 Ursprüngliche
Annahme
10.03.2010 Initiales Backlog
18.06.2013 - Grooming +
Reestimation
20.12.2011 Grooming
17.06.2012 06.01.2012 Grooming
16.01.2012 Release
06.07.200914.10.200922.01.201002.05.201010.08.201018.11.201026.02.201106.06.201114.09.201123.12.201101.04.201210.07.201218.10.201226.01.201306.05.201314.08.201322.11.2013
0100200300400500600700800900
10001100120013001400150016001700180019002000
13
.11
.200
9
13
.12
.200
9
13
.01
.201
0
13
.02
.201
0
13
.03
.201
0
13
.04
.201
0
13
.05
.201
0
13
.06
.201
0
13
.07
.201
0
13
.08
.201
0
13
.09
.201
0
13
.10
.201
0
13
.11
.201
0
13
.12
.201
0
13
.01
.201
1
13
.02
.201
1
13
.03
.201
1
13
.04
.201
1
13
.05
.201
1
13
.06
.201
1
13
.07
.201
1
13
.08
.201
1
13
.09
.201
1
13
.10
.201
1
13
.11
.201
1
13
.12
.201
1
13
.01
.201
2
Pro
gn
ose E
nd
ete
rmin
Pro
du
ct
Backlo
g
Erfassungsdatum
Product Backlog und Releaseprognose Product Backlog
Prognose Endetermin
Lessons learned:
1. Initiale Terminschätzung (vor Scrum) war unrealistisch.
2. Releaseprognose besser verständlich als das Product Backlog.
3. Frühzeitiger Erkenntnissgewinn ist ungewohnt.
4. Flexbilität bei Anforderungen (was und wie) und …
5. … Flexibilität bei der Realisierung (wie) als Schlüssel zum Termin.
6. Product Owner mit Kompetenz für schnelle Entscheidungen.
Pflicht:
Statusberichte
Übertragbarkeit auf andere Projekte
Übertragbarkeit ist schwierig
• Integration der Fachbereiche ist ungewohnt und teilweise nicht gewollt
• Scrum Master Schulung macht keinen Scrum Master
• Nicht jeder Product Owner hat die notwendigen Entscheidungskompetenzen
Falsche Schlussfolgerung: Scrum für kleine Projekte, klassisches Vorgehen für
große Projekte
Richtig wäre: Scrum für ALLE Projekte, bei denen die Voraussetzungen
stimmen
Naive Anwendung
• schadet mehr als sie nutzt
• Scrum ist kein Dogma, aber …
• … nenne es nicht Scrum wenn es kein Scrum ist
Organisatorische Verankerung
Projekt-Retrospektive/Review erzeugen Impulse in die Organisation
Beteiligte IT und Fachbereich sehen Scrum als hilfreich an
Zentrales QM und PM sehen sich subjektiv in Frage gestellt
Weitgehende Unkenntniss im Management
Fürstentümer und hierarchische Kultur stehen im Weg
„Was du mir sagst, das vergesse ich. Was du mir zeigst, daran erinnere ich mich.
Was du mich tun lässt, das verstehe ich.“ – Konfuzius, chinesischer Philosoph
= schwieriges Klima für nachhaltige Veränderung
Organisatorische Verankerung
IT und Fachbereich sehen Scrum als hilfreich an
Zentrales QM und PM sehen sich subjektiv in Frage gestellt
Weitgehende Unkenntniss im Management
Fürstentümer und hierarchische Kultur
„Was du mir sagst, das vergesse ich. Was du mir zeigst, daran erinnere ich mich.
Was du mich tun lässt, das verstehe ich.“ – Konfuzius, chinesischer Philosoph
= schwieriges Klima für nachhaltige Veränderung
Lessons learned:
1. Scrum von unten stößt schnell an Grenzen
2. Überzeugen durch Erfolg ist der Weg
3. Projektmarketing und Informieren sind wichtig
4. Nachhaltige Agilität ist ein langwieriger Prozess
5. Ohne das Management ist sie nicht zu erreichen
Fazit
Scrum hat sich sehr bewährt
Scrum gibt dem Team Struktur und Beweglichkeit
Die Beteiligten empfinden es als Modell für die Zukunft
Scrum allein ist ok, aber …
… individuelle Antworten für Test, Spezifikation, Projektmanagement, etc. sind
erforderlich
Teambesetzung (Persönlichkeit und Expertise) ist der Schlüssel zum Erfolg
Scrum erscheint einfach aber kulturelle Implikationen sind weitreichend