Scrum in der Produktwartung. Martin Heilemann Lynx-Consulting GmbH

Transkript

1

2 Scrum in der Produktwartung Martin Heilemann Lynx-Consulting GmbH Seite 2

3 Themen Produktwartung Scrum Warum Scrum in der Produktwartung? Die Ausgangssituation Der Weg zu Scrum Fazit Literatur Seite 3

4 Produktwartung Seite 4

5 Produktwartung Warum ist Wartung nötig Entropie Lack of movement Fehlende Anpassung der Software an eine geänderte Umgebung Ignorant surgery Anpassung der Software ohne Beachtung der Basisstruktur Seite 5

6 Produktwartung Begriffe der Wartung Software Softwarewartung Wartbarkeit Softwareevolution Seite 6

7 Produktwartung Kategorien der Softwarewartung Korrektive Wartung Präventive Wartung Adaptive Wartung Perfektionierende Wartung Seite 7

8 Produktwartung Grundsätze Lebenszyklus als Basis aller Überlegungen Qualitätssichernde Maßnahmen Klare Rollenverteilung und Organisation Eingespielte Prozesse Seite 8

9 Produktwartung Softwareevolution Softwareevolution: Prozess der Veränderung eines Softwaresystems von der Erstellung bis zur Außerbetriebnahme Erstellung Wartung Weiterentwicklung Migration Stilllegung Weiterentwicklung Neue Funktionalität und Nutzen Wartung Vorbeugende Pflege Seite 9

10 Produktwartung Herausforderungen bei der Wartung Programmverständnis Fehlende Dokumentation Kenntnis verschiedener Programmiersprachen oder Plattformen Software ist redundant Komplexer Entwicklungsprozess Image der Wartung Reaktiv Unkreativ Unangenehm Seite 10

11 Scrum Seite 11

12 Scrum Scrum Methode zur Produktentwicklung (1986 entwickelt von Hirotaka Takeuchi und Ikujiro Nonaka) Methode für das Management agiler Softwareprojekte (ca entwickelt von Ken Schwaber und Jeff Sutherland) Seite 12

13 Scrum Scrum besteht aus Rollen Artefakten Arbeitszyklen (Sprints) Seite 13

14 Scrum Die Rollen Product Owner Team ScrumMaster Seite 14

15 Scrum Artefakte Product Backlog Lebendes Dokument Priorisierung von Einträgen - Mit unterschiedlichem Detaillierungsgrad - Mit abgeschätzten Aufwänden Sprint Backlog Burndown Chart Impediment Backlog Seite 15

16 Scrum Sprints Umwandlung der Anforderungen in ein Produktinkrement Sprint Planungssitzung Sprint Backlog Daily Scrum Sprint Review Sprint Retrospektive Fortschritt wird mit dem Burndown Chart verfolgt Sprintlänge ca. 30 Tage Begutachtung der entstandenen Software durch den Product Owner Potenziell auslieferbar Team und Product Owner legen fest, wann Anforderungen erledigt sind. Seite 16

17 Scrum Sprint Planungssitzung Product Owner definiert Sprint-Ziel und Vorauswahl Team erstellt Sprint Backlog ScrumMaster moderiert Seite 17

18 Scrum Sprint Backlog Aktivitäten zur Umsetzung der Anforderungen Organisation des Sprints Tägliche Aktualisierung mit Restaufwänden Seite 18

19 Scrum Daily Scrum Besprechung (ca. 15 Minuten) Welche Aktivitäten wurden seit dem letzten Daily Scrum abgeschlossen? Woran wird bis zum nächsten Daily Scrum gearbeitet? Was behindert die Ausführung einer Aktivität? Teilnehmer Team ScrumMaster Product Owner optional Dokumentation der Hindernisse Seite 19

20 Scrum Sprint Review Begutachtung der Arbeitsergebnisse Darstellung des Projektfortschritts Überprüfung der Anforderungen aus der Sprint Planungssitzung durch den Project Owner Teilnehmer Team ScrumMaster Product Owner Interessenvertreter Seite 20

21 Scrum Sprint Retrospektive Verbesserung der Zusammenarbeit Teilnehmer Team Product Owner ScrumMaster Seite 21

22 Scrum Burndown Chart Darstellung der täglichen Restaufwände Summe der Stunden aus dem Sprint Backlog Arbeitstage Seite 22

23 Warum Scrum in der Produktwartung? Seite 23

24 Warum Scrum in der Produktwartung? Qualitätssicherung Inkrementelle Entwicklung Verbesserte Kommunikation Visueller Arbeitsplatz Ergebnisorientiertes Arbeiten Einfacher Aufbau Regeln, Rollen, Prinzipien, Artefakte und Meetings Kurzer Releasezyklus Flexibilität im Hinblick auf Änderungen Selbstorganisation des Teams Frühzeitiges Erkennen von Hindernissen Risikominimierung Konzentration auf die Umsetzung Termingerechtes Liefern Verbesserter Informationsfluss Seite 24

25 Die Ausgangssituation Seite 25

26 Ausgangssituation Produktwartung Aufgaben Monatliche Produktion (Reporting) Software Erweiterungen Software Änderungen Releasezyklen alle 3-6 Monate Anwenderunterstützung Fehlerbehebung Situation Langfristige Projektplanung Parallele Anwenderunterstützung und Entwicklung Laufende Änderung der Anforderungsprioritäten Release sind fehlerhaft fehlende Abstimmung mit dem Produktverantwortlichen Seite 26

27 Der Weg zu Scrum Seite 27

28 Der Weg zu Scrum Vorbereitung Rollenbesetzung Product Backlog mit priorisierten Anforderungen Sprintdauer: 3 Wochen Festlegung der Abnahmekriterien Der erste Sprint Daily Scrum dauert zu lang Schätzungen nicht eingehalten Paralleler Support Burndown Chart visualisiert die Aufgaben Seite 28

29 Der Weg zu Scrum Weitere Sprints Verfügbarkeit des Product Owner Anpassung der Sprintlänge Umsetzung weniger Anforderungen Automatisierte Tests Releasezyklus alle 4 Wochen Stabilere Release Verbesserter Informationsfluss Abbruch eines Sprints Bei gravierenden Produktionsfehlern Seite 29

30 Fazit Seite 30

31 Fazit Vorteil Termingerechte Lieferung Qualitätsverbesserung der Software Erhöhte Anwenderzufriedenheit Steigerung der Motivation der Entwickler Verbessertes Durchdringen der Software Visueller Arbeitsplatz Nachteil Gravierende Produktionsfehler können nicht optimal erfasst werden Seite 31

32 Literatur Seite 32

33 Literatur Literatur Harry M. Sneed, Martin Hasitschka, Maria Therese Teichmann: Software Produktmanagement, dpunkt.verlag, 2005 Christoph Bommer, Markus Spindler, Volkert Barr: Softwarewartung, dpunkt.verlag, 2008 Ralf Wirdmann: Scrum mit User Stories, Carl Hanser Verlag, 2009 Roman Pichler: Scrum, dpunkt.verlag, 2009 Ken Schwaber: Agiles Projektmanagement mit Scrum, Microsoft Press, 2007 Esther Derby, Diana Larsen: Agile Retrospecktives, The Pragmatic Bookshelf, 2009 Seite 33

34 ? Fragen? Seite 34

35 Vielen Dank für Ihre Aufmerksamkeit! Seite 35