Internationales Projektmanagement International Project Management

Transkript

1 Internationales Projektmanagement International Project Management Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: /

2 Scrum

3 Inhalte Agile Modelle Manifesto Übersicht Scrum Übersicht Rollen: product owner scrum Master scrum Team 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 Eigenschaften Skalierung Feature Teams Spotify Referenzen

4

5 Release Planning

6 Scrum Release Planning Quelle: Pichler, 2010 Magisches Dreieck Projekt beachten Frühe, häufige Releases Quartalszyklen, statt Jahreszyklen Planning Poker Story points Non-Function Requirements Velocity forecast Release Plan erstellen

7 Sprint Burndown Chart

8 Mehr Details

9 Definition of Done (DoD) Clear and concise list of requirements that a software increment must adhere to for being called complete. The Definition of Done is not changed during a sprint. Definition of Done Global DoD and team-based DoD Code complete possible. Unit tests written and executed Integration tested Performance tested Documented (just enough)

10 Daily Clean Code Do not keep a bug list Each bug has to be handled at least twice Good bug reports take time and effort wo write Bug lists tend to grow; minor bugs may never be fixed Possibility of duplicates Fix all bugs in less than one day Fix bugs as soon as you find them - they are fresh in your mind If you can t fix it that day put it on the backlog so it can be fixed the very next day Further development might depend on bugs, making them really difficult to fix

11 Velocity (points) Aktualisieren des Release Plans mit Hilfe der velocity 40 Last Iteration = Mean (last 8) = 31 Low Mean (worst 3) = Iteration Quelle: Mike Cohn, bayxp Meeting on Agile Planning, 2007

12 Vorhersage release scope durch Extrapolation velocity Mit unsere niedrigsten low mean velocity schaffen wir diese stories Mit unserer langfristigen mean velocity Mit unserer last velocity: bis hierhin

13 Tools für das Sprint Backlog

14 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 Meeting Drei Fragen S. Video: 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 trifft Entscheidungen Feedback, Wie in Zukunft Weitermachen?

15 The sprint review Team presents to product owner and others what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule No slides Whole team participates Invite the world

16 Sprint Retrospective The retrospective is the second most important event in Scrum (the first being the.. meeting) Periodically take a look at what is and is not working Typically minutes 3hrs, time-boxed Done after every sprint Whole team participates ScrumMaster Team (Product owner) (Possibly customers and others)

17 Sprint Retrospective Team und Scrum Master besprechen zwei Fragen: What went well What could be improved? Wichtig: Ensure that everyone can speak freely Do not play the blame game Do not allow vague statements Transform identified improvements to concrete action points Ensure that the action points are finished.

18 Sprint Retrospective

19 Velocity Sprint Retrospectives Impact on Velocity over Time Sprint With retrospectives Without retrospectives

20

21 Reasons for a failed retrospective Quelle: No Preparation No Focus Failing to Gather Data One or Two People Dominating the Conversation Focusing Only on Impediments That Are Outside the Control of the Team Biting Off More than the Team Can Chew Choosing Actions the Team Doesn't Have Energy For Keeping a Separate "Improvement Plan"

22 Understanding is easy mastering is hard!

23 Distributed Teams

24 Source: scaledagileframework.com

25 Roles The development team Source: scaledagileframework.com

26

27 Anhang: Zusammenfassung und Wiederholung Scrumguides.org Vgl. auch:

28 Verantwortlichkeiten des PMs sind wo? In Scrum? Geld Zeit Risiko Konflikte Zuweisung Arbeit Accept. Criteria DoD Stkhld. Mgtm. Projektkontrolle

29 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.

30 Wichtige Aussagen: Die Prinzipien der agilen Methoden Quelle: Sommerville, Software Engineering, 2012, Abbildung 17.3

31 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 Team 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 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