Scrum in der Rückversicherung

Transkript

1 Scrum in der Rückversicherung Eine Erfolgsgeschichte Wolfgang Pleus ( Scrum Day SAP St. Leon Rot,

2 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

3 Ausgangslage Hannover Re - Einer der weltgrößten Rückversicherer Technische und methodische Erneuerung des zentralen Business Partner Management Systems Geschäftskritisches Projekt, weltweites Rollout, 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

4 Phase 1 - Initialisierung

5 Vom UseCase zur UserStory Strukturierte Anforderungsanalyse Ergebnisse: 3 Personen: Dauer: Usecases, Requirements und Grobkonzept Erschliessen des Kontextes 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

6 Vom UseCase zur UserStory Strukturierte Anforderungsanalyse Ergebnisse: 3 Personen: Dauer: Lessons learned: Usecases, Requirements und Grobkonzept Erschliessen des Kontextes 3 Monate Product Backlog Workshop Umsetzung 1. Grobanalyse hilft den Kontext zu verstehen. Ergebnis: Initiales Product Backlog Gesamtes Team (20): Verteilung des Kontextwissens fortwährend Dauer: begleiten (Kontextwissen). 3 Tage 2. Product Owner und Solution Architect müssen das Projekt 3. Trennung von Analyse- und Entwicklungsteam nicht hilfreich Ergebnisse: Konzeption und Produkt Dynamisches Team: Iterative Umsetzung Dauer: 23 Monate

7 Product Backlog Workshop Storypoints Business value Product Owner Team Scrum Master

8 Product Backlog Workshop Storypoints Business value Lessons learned: 1. Unterscheidung von Konzeption und Umsetzung ist hilfreich. Product Owner 2. Mapping der Anforderung stellt 100% Abdeckung sicher. 3. Workshop ermöglicht gemeinsames Verständnis im Team (Fach/IT). Team Scrum Master

9 Wasserfall trifft Scrum Analyse Design Entwicklung Betrieb Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung Grobkonzept Pflichten: Abgenommene Konzepte Testfälle Monatliche Statusberichte Agile Spezifikation Agile Entwicklung REVIEW MEETING Agiler Test RETROSPECTIVE MEETING Agiles Projektmanagement

10 Wasserfall trifft Scrum Analyse Design Entwicklung Betrieb Initialisierung Planung Definition Entwurf Implementierung Einführung Wartung Lessons learned: Grobkonzept Pflichten: Abgenommene Konzepte Testfälle Monatliche Statusberichte 1. Klassische und agile Methoden sind kombinierbar, solange die Artefakte geliefert werden. Agile Spezifikation 2. Klassischer Mehraufwand bringt wenig Mehrwert. 3. Prinzipiell jederzeit zu Scrum gewechselt werden. Agile Entwicklung REVIEW MEETING Agiler Test RETROSPECTIVE MEETING Agiles Projektmanagement

11 Phase 2 Durchführung

12 Spezifizieren mit Scrum? Entwerfen / Spezifizieren Silverlight SketchFlow XML Annotationen und Screens Interne Freigabe (DoD) Generieren Veröffentlichen Enterprise Architect Offizielle Abnahme Pflicht: Abgenommene Konzepte Wiki Word

13 Spezifizieren mit Scrum? Lessons learned: Entwerfen / Spezifizieren Silverlight SketchFlow XML Annotationen und Screens 1. Erst konzipieren, dann implementieren. 2. Konzeption steigert Verbindlichkeit und Klarheit. Interne Freigabe Generieren 3. Spezifizieren nur soviel wie nötig. 4. Zeitliche Nähe von Spezifikation und Umsetzung erhält den Wissenskontext (1 Sprint Veröffentlichen Vorlauf ideal). 5. Bug or Change Problem (Vertrauen ist essentiell). Enterprise Architect Offizielle Abnahme Pflicht: Abgenommene Konzepte Word

14 Umgang mit dynamischen Teams Sprint Entwicklung snb (dev) pw2 (dev) ren (db, bi, dev) mf2 (dev) hto(db) sb3 (migration) Spezifikation svd (po) jds (spec) htn (spec, test) sta (spec) eth (spec) ghc/dki (spec) tj (spec) knt (spec) Test krc (test) dai (training) fnn (test) Weitere mrk (bi) lad (db) dai (training) le2 (trainings) 6 2

15 Umgang mit dynamischen Teams Sprint Entwicklung snb (dev) pw2 (dev) ren (db, bi, dev) mf2 (dev) hto(db) sb3 (migration) Spezifikation svd (po) jds (spec) htn (spec, test) sta (spec) eth (spec) ghc/dki (spec) tj (spec) knt (spec) Test 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. krc (test) dai (training) fnn (test) Weitere mrk (bi) lad (db) dai (training) le2 (trainings) 6 2

16 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. Pflicht: Testfälle

17 Qualitätssicherung und Test Strukturierte Qualitätssicherung im Team Unit, Integration, Akzeptanz, Last&Performance Lessons learned: Qualität in der DoD Anzahl 1. Test neue beginnen, Testfälle sobald = SP im etwas Sprint Testbares *Testfälle da pro ist. SP-Faktor (z.b. 2) Durchführen aller Neuen + 25% Retest Bug 2. Backlog Akzeptanztest: als messbarer Kosten/Nutzen-Verhältnis Qualitätsindikator zugunsten (bei >50 manueller Eintrag ins Tests. Changelog) Testfälle für die QM-Endabnahme wiederverwendbar. 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. Pflicht: Testfälle

18 Product Backlog Prognose Endetermin 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 Product Backlog und Releaseprognose Grooming + Reestimation Initiales Backlog Ursprüngliche Annahme Grooming Product Backlog Prognose Endetermin Grooming Release Erfassungsdatum Pflicht: Statusberichte

19 Product Backlog Prognose Endetermin Projektmanagement im veränderlichen Umfeld Velocity = Storypoints / Personentage Vorher / Nachher Betrachtung (Commitment und Realität) Releaseprognosen Lessons learned: unter Einbeziehung regelmäßiger SP Zuwächse Grooming Workshops als zentraler Steuerungsmechanismus 1. Initiale Terminschätzung (vor Scrum) war unrealistisch Releaseprognose besser verständlich als das Product Backlog. Product Backlog und Releaseprognose Grooming + Reestimation Initiales Backlog Ursprüngliche Annahme Grooming Product Backlog 3. Frühzeitiger Erkenntnissgewinn ist ungewohnt. Prognose Endetermin 4. Flexbilität bei Anforderungen (was und wie) und Grooming Release Flexibilität bei der Realisierung (wie) als Schlüssel zum Termin Product Owner mit Kompetenz für schnelle Entscheidungen. Erfassungsdatum Pflicht: Statusberichte

20 Phase 3 - Perspektiven

21 Ü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

22 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

23 Organisatorische Verankerung IT und Fachbereich sehen Scrum als hilfreich an Zentrales QM und PM sehen sich subjektiv in Frage gestellt Lessons learned: Weitgehende Unkenntniss im Management Fürstentümer und hierarchische Kultur 1. Scrum von unten stößt schnell an Grenzen 2. Überzeugen durch Erfolg ist der 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 3. Projektmarketing und Informieren sind wichtig = schwieriges Klima für nachhaltige Veränderung 4. Nachhaltige Agilität ist ein langwieriger Prozess 5. Ohne das Management ist sie nicht zu erreichen

24 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

25 Vielen Dank