Folie 1 Projektmanagement Vorlesung 12/ 13 Prof. Adrian Müller, PMP FH Kaiserslautern phone: +49 6332 914-329 http://www.fh-kl.de/~amueller Folie 2 Inhalte Agile Modelle Manifesto Übersicht XP Prinzipien und Vorgehensweisen Story Card Planning Game Beispiele echter Projekte, Team Rooms Pair Programming Refactoring Tracking Cont. Integration Test Driven Development Scrum Übersicht Rollen: product owner, scrum Master, scrumteam Aufgaben der Rollen Daily scrum, review, retrospective grooming product backlog Sprint sprint planning sprint backlog Release Planning Planning Poker Release Plan Velocity Burndown Chart Release Burndown Bar 2
Folie 6 Agile Modelle in IT vs. Wasserfall 6 Folie 7 Wichtige Aussagen: Die Prinzipien der agilen Methoden Quelle: Sommerville, Abbildung 17.3 7
Folie 9 Scrum - Ursprünge Jeff Sutherland Initiale Scrums bei Easel Corp., 1993 IDX und über 500 Personen arbeiten mit Scrum Ken Schwaber ADM Präsentiert Scrum auf der OOPSLA 96 mit Sutherland Autor von drei Büchern über Scrum Mike Beedle Scrum-Pattern in PLOPD4 Ken Schwaber und Mike Cohn Scrum Alliance in 2002 gegründet; zuerst innerhalb der Agile Alliance 9 Folie 10 Scrum - Überblick Quelle: Mountain Goat Software 10
Folie 11 Scrum (primäre) Rollen Produkt Owner Definiert Produkt-Features Bestimmt Auslieferungsdatum und Inhalt Ist verantwortlich für den Gewinn des Projekts (ROI) Priorisiert Features abhängig vom Marktwert Passt Features und Prioritäten nach Bedarf für jede Iteration an Akzeptiert oder weist Arbeitsergebnisse zurück Scrum Master Repräsentiert das Management gegenüber dem Projekt Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken Entfernt Hindernisse Stellt sicher, dass das Team vollständig funktional und produktiv ist (Coach) Unterstützt die enge Zusammenarbeit zwischen allen Rollen und Funktionen Schützt das Team vor äußeren Störungen Team Typischerweise fünf bis zehn Leute funktionsübergreifend Mitglieder sollten Vollzeitmitglieder sein Vielleicht Ausnahmen (z.b. Systemadministratoren) Teams organisieren sich selbst Mitgliedschaft kann sich nur zwischen Sprints verändern 11
Folie 12 Scrum - Management Sprint-Planung In: Product Backlog, Stand Project, Team Entscheider: Scrum Team Out: Sprint Goal, Sprint Backlog tägliche Scrum-Meetings 15min, stand-up Drei Fragen Sprint-Review Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo von neuen Features oder der zugrunde liegenden Architektur Sprint-Retrospektive Nur das Team Feedback, Weitermachen? 12
Folie 13 Product Backlog Quelle: Mountain Goat Software 13
Folie 14 Sprint Backlog Quelle: Mountain Goat Software 14
Folie 15 Scrum - Management Sprint-Planung In: Product Backlog, Stand Project, Team Entscheider: Scrum Team Out: Sprint Goal(s), Sprint Backlog tägliche Scrum-Meetings 15min, stand-up Drei Fragen Sprint-Review Team präsentiert, was es während eines Sprints erreicht hat Typischerweise in Form einer Demo von neuen Features oder der zugrunde liegenden Architektur Sprint-Retrospektive Nur das Team Feedback, Weitermachen? 15
Folie 16 Scrum Tracking: Sprint BurndownChart 16
Folie 17 Scrum Release Planning Quelle: Pichler, 2010 Magisches Dreieck Projekt beachten Frühe, häufige Releases Quartalszyklen, statt Jahreszyklen PlanningPoker Story points Non-Function Requirements Velocityforecast Release Plan erstellen 17
Folie 18 Story Point Estimation Quelle: http://kanemar.com 18
Folie 19 Scrum: Eigenschaften Größe, Skalierbarkeit: typisch: 5-10 Personen im Team Größe Projekte (100 500 Personen möglich) Teams von Teams ermöglichen Skalierbarkeit Faktoren des Skalierens Typ der Anwendung Teamgröße Teamverteilung (örtlich) Projektdauer Scrum ist mehrmals für 500-Personenprojekte verwendet worden 19
Folie 20 Wichtige Aussagen Scrum ist ein agiler Prozess, der es erlaubt auf die Auslieferung der wichtigsten Geschäfts-Anforderungen innerhalb kürzester Zeit zu fokussieren. Scrum gestattet es schnell und in regelmäßigen Abschnitten (von zwei Wochen bis zu einem Monat) tatsächlich lauffähige Software zu inspizieren. Das Business setzt die Prioritäten. Selbst-organisierende Entwicklungsteams legen das beste Vorgehen zur Auslieferung der höchst priorisierten Features fest. Alle zwei Wochen bis zu einem Monat kann jeder lauffähige Software sehen und entscheiden, diese so auszuliefern oder in einem weiteren Abschnitt zu ergänzen. 20
Folie 21 Quellennachweis Diverse Folien stammen von Mike Cohn mike@mountaingoatsoftware.com, www.mountaingoatsoftware.com 21