Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand:

Transkript

1 Projektmanagement Agile Vorgehensweise / Scrum Version: 1.0 Stand:

2 Lernziel Sie können in eigenen Worten darstellen warum Agilität notwendig ist. Sie können mit eigene Worten das Framework Scrum beschreiben. Sie können die Rollen, Aktivitäten und Artefakte von Scrum nennen und erläutern. Sie können zeigen, wie ein Scrum Projekt gesteuert wird. 2

3 Vorgehensmodelle Agilität?... Warum? Softwareentwicklung Agilität im Projektinhalt Produkterweiterung Applikationsrollout Umzug IT Abteilung Agilität im Projektumfeld Änderung der Anforderungen bei der Softwarenentwicklung von ca. 1%-5% pro Monat Quelle: Ebert, C. (2014). Systematisches Requirements Engineering: Anforderungen ermitteln, dokumentieren, analysieren und verwalten. dpunkt. verlag. 3

4 Was ist Scrum? Ist ein Framework für Agile Software -Projekte Besteht aus wenigen Regeln (5 Aktivitäten / 3 Rollen / 3 Artefakten) Hat ein / das agile Wertesystem Fokus auf der Reduktion von Komplexität 4

5 Scrum Überblick Daily Scrum Meeting Product Backlog enthält alle bekannten Anforderung an das System Scrum Master täglich Team Sprint Planung Sprint Backlog enthält alle Feature für den Sprint Sprint 2-4 Wochen Sprint Review Am Ende des Sprint präsentiert das Team dem Product Owner die neue Funktionalität Produkt Product Owner Sprint Retrospektive Was haben wir gelernt? Was lässt sich verbessern? 5

6 Scrum Framework Rollen Aktivitäten Artefakte Product Owner Scrum Master Team Sprint-Planung Sprint-Review Sprint- Retrospektive Daily Scrum- Meeting Product Backlog Refinement Product Backlog Sprint Backlog Product Increment 6

7 Scrum Rollen Product Owner Definiert das Produkt und Produkt-Features Pflegt das Produkt Backlog Priorisiert Features (was kommt in welchen Sprint) Akzeptiert oder weist Arbeitsergebnisse zurück 7

8 Scrum Rollen Scrum Master Verantwortlich für die Einhaltung des Scrum Prozesses Schützt das Team vor äußeren Störungen Beseitigt Hindernisse sorgt für Informationsfluß zwischen Product Owner und Team moderiert Scrum-Meetings hat die Aktualität der Scrum-Artefakte (Product Backlog, Sprint Backlog, Burndown Charts) im Blick 8

9 Scrum Rollen Team Ideal <= 10 Personen ist interdisziplinär zusammengesetzt (Entwickler, Architekten, Tester, ) Teams organisieren sich selbst Zerlegt selbstständig die Requirements in Task Trifft sich Täglich zum Daily Scrum Meeting 9

10 Der Sprint Time-Box für die Implementation einer auslieferbaren Funktionalität Klassische Länge: zwischen 14 und 30 Kalendertage Beginnt mit dem Sprint Planning Meeting Endet mit dem Sprint Review Meeting und anschließendem Sprint Retrospective Meeting Während des Sprints wird das Team nicht durch neue oder geänderte Anforderungen unterbrochen. Damit erreicht man Kontinuität und konzentriertes Arbeiten auf das vom Product Owner ausgegebene Sprint Goal hin. 10

11 Aktivitäten Sprint-Planung Übernahme eines Backlog Items (auch eines Teils) Zerlegen des Backlog Items in weitere kleiner Einheiten (User Stories) Übernahme der Aufgaben durch die Teammitglieder (selbstorganisatorisch) 11

12 Aktivitäten Sprint-Review Team präsentiert dem Product Owner die realisierte Funktionalität Product Owner gibt Feedback und nimmt die Funktionalität ab oder weist sie zurück! 12

13 Aktivitäten Sprint - Retrospektive Das Team diskutiert rückblickend den soeben zu Ende gegangenen Sprint und überlegt sich, was weshalb gut oder schlecht gelaufen ist und was man tun könnte, um den nächsten Sprint produktiver zu machen 13

14 Aktivitäten Daily Scrum-Meeting Kurzes (15min), tägliches Status-Meeting des Teams Scrum Master nimmt teil und moderierend Product Owner nimmt nach Möglichkeit auch teil, um auf dem neuesten Stand zu bleiben und bei Bedarf fragen zu beantworten Folgende Fragen werden geklärt: Was habe ich seit dem letzten Daily Scrum getan? Was plane ich, bis zum nächsten Daily Scrum zu tun? Was hat mich bei der Arbeit behindert (Impediments)? 14

15 Aktivitäten Product Backlog Refinement Weiterentwicklung des Produkt-Backlogs Product Owner trägt die Verantwortung Beinhaltet: Einfügen / Löschen / Bearbeiten von Backlog Items Schätzen von Backlog Items Detaillierung von Backlog Items 15

16 Artefakte Product Backlog Liste aller Anforderungen an ein Produkt Ist in Requirements (Anforderungen oder Featutres) unterteielt Requirements sind mit relativen Schätzwerten versehen 16

17 Artefakte Sprint Backlog Eine Liste von Tasks, welche den Arbeitsumfang des Teams für den Sprint festlegt Entsteht aus der Verfeinerung von Backlog Items wird täglich aktualisiert (siehe Scrum Task Board) 17

18 Artefakte Product Increment Nutzbares (!!!) Teilprodukt Summe aller fertiggestellter Product-Backlog-Items 18

19 Scrum Überblick Daily Scrum Meeting Product Backlog enthält alle bekannten Anforderung an das System Scrum Master täglich Team Sprint Planung Sprint Backlog enthält alle Feature für den Sprint Sprint 2-4 Wochen Sprint Review Am Ende des Sprint präsentiert das Team dem Product Owner die neue Funktionalität Produkt Product Owner Sprint Retrospektive Was haben wir gelernt? Was lässt sich verbessern? 19

20 Scrum Prozess Userstory Ist die Formulierung einer Anforderung an die Software Definition nach folgender Vorlage: "Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> Beispiel Als User möchte ich in meinem Profil die Telefonnummer speichern, um anderen Nutzern diese Information zugänglich zu machen Wird meist als StoryCard am Scrum Task Board plaziert 20

21 Scrum Prozess StoryCard - Beispiel Priorität Name der UserStory Storypoints Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> Risiko Post Storypoints 21

22 Scrum Prozess Schätzen Im Agilen Umfeld löst man sich bewusst von der Schätzung spezielle Aufwände: Warum? Entwickler programmieren unterschiedlich schnell Schätzungen sind immer subjektiv Geschätzt wird die Komplexität. Ist etwas schwieriger / leichter als eine andre Aufgabe Storys erhalten Storypoints nach der von Mike Cohn angepasste Fibonacci-Reihe 1, 2, 3, 5, 8, 13, 20, 40,

23 Scrum Prozess Qualität - Akzeptanzkriterium Jeder UserStory erhält mehrere Akzeptanzkriterien, die beschreiben wann die Story erfolgreich implementiert wurde. Festgelegt nach folgender Vorlage: "Angenommen <Vorbedingungen>, wenn <Aktion>, dann <Ergebnis>" Beispiel: Angenommen ich habe in der Telefonnummer einen Buchstaben eingegeben und ich drücke den Button Speichern, dann erhalte ich einen Hinweis und das Profil wird nicht gespeichert 23

24 Scrum Prozess Informieren und Steuern Scrum Task Board Burndown Chart / Product Burndown Chart Velocity 24

25 Scrum - Informieren und Steuern Scrum Task Board Stories To Do In Progress Testing Done User Story 4 25

26 Scrum - Informieren und Steuern Burndown Chart Daily Completed Planned Actual 26

27 Scrum - Informieren und Steuern Velocity Anzahl der vollendeten Storypoints pro Team und Sprint Velocity 27

28 Copyright Alle Rechte vorbehalten. Ohne ausdrückliche, schriftliche Genehmigung von Olaf Boczan ist es nicht gestattet, das Vorlesungsskript (diese Folien) oder Teile daraus in irgendeiner Form durch Fotokopie, Mikrofilm oder ein andere Verfahren zu vervielfältigen oder zu verbreiten. Dasselbe gilt für das Recht der öffentlichen Wiedergabe. Inhalte dürfen im Rahmen der Forschung und Lehre in Präsentation und Skripten unter Angabe der Quelle auch ohne schriftliche Genehmigung veröffentlich werden. Ich mache weiterhin darauf aufmerksam, dass die genannten Firmen- und Markennahmen sowie Produktbezeichnungen in der Regel marken-, patent- oder warenzeichenrechtlichen Schutz unterliegen. Auf den Folie sind Teile aus unterschiedlichen Quellen übernommen. Um die Lesbarkeit der Präsentation sicherzustellen, sind stellenweise Zitate nicht als solche eindeutig gekennzeichnet, sondern durch eine Quellenangabe am Ende der Folie verdeutlicht. Es handelt sich dabei aber ausdrücklich um Zitat aus bzw. von diesen Quellen. 28