Agile Vorgehensmodelle PDF

Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 5.2 SCRUM 6. Projektstruktu...

Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 5.2 SCRUM 6. Projektstrukturplanung 5.2.1 Basiskonzepte 7. Aufwandsschätzung 5.2.2 Rollen 5.2.3 Artefakte 8. Ablaufplanung 5.2.4 Planning 9. Zeitplanung 5.2.5 Sprinting 5.3 Scaled Agile Framework (SAFe) 10. Einsatzmittel- und Kostenplanung 5.4 Extreme Programming (XP) 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 196 Literaturempfehlungen https://innolution.com/essential-scrum https://www.scrumguides.org/docs/scrumguide/ v1/Scrum-Guide-DE.pdf Prof. Dr. Wolfgang Wicht Seite 197  Scrum - Gegenstand und Eigenschaften  Gegenstand: „Vorgehensrahmen“ (Framework) für „agile Projekte“ „A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”1)  Eigenschaften: Kleine Teams: 5 – 9 Projektmitglieder Kurze Iterationen: Sprints von 1 – 4 Wochen Inkrementell: Fortlaufende Produktinkremente nach jeder Iteration Verständlichkeit: Einfach aufgrund wenige Konzepte (3 Rollen, 3 Artefakte, 4 Aktivitäten) im Kern-Vorgehensrahmen Breite Anwendbarkeit: Ursprünglich für Software-Entwicklungsprojekte. Aufgrund des generischen Modellelemente auch für andere Domänen (z.B. Mechanical Engineering, Research) anwendbar Prof. Dr. Wolfgang Wicht 1) Quelle: https://www.scrumguides.org/scrum-guide.html, Abruf: 10.10.2018 Seite 198 Scrum - Prinzipien  Selbstorganisation: Team plant und steuert die Entwicklung unter Einbeziehung eines Produktverantwortlichen (Product Owner) und Koordination eines „koordinierenden Dienstleisters“ (Scrum Master)  Dekomposition: Zerlegung des Produktes (Product Backlog Item) und des Vorgehens (Sprints)  Transparenz: Durch regelmäßige kurzfristige Abstimmungen (Daily Scrum) u. mittelfristige Überprüfungen (Sprint Review) sowie Reporting (Burndown Chart)  Flexible Anforderungsanpassung: Änderungsanträge (Change Requests) wer- den kontinuierlich bewertet und in weiteren Iterationen (Increments) realisiert  „Overhead“-Reduktion: Planungs-, Steuerungs- und Dokumentationsaufwand soll im Vergleich zu disziplinierten Vorgehensmodellen reduziert werden  Inspektion: Inspektion des Produktes. Stand der Produktentwicklung und Ur- sachen der Abweichung vom (Sprint-)Ziel werden identifiziert (Sprint Review)  Reflektion: Reflektion des Prozesses bzw. Handelns. Verbesserungen für zukünftige Iterationen werden abgeleitet (Sprint Retrospective) Prof. Dr. Wolfgang Wicht Seite 199  Scrum - Praktiken Product Owner Roles Scrum Master Development Team Sprint Sprint Planning Activities Daily Scrum Sprint Execution Scrum Scrum Practices Sprint Review Ceremonies Sprint Retrospective Product Backlog Grooming Product Backlog Sprint Backlog Artifacts Product Increment Rules … Prof. Dr. Wolfgang Wicht In Anlehnung an: Rubin, K.: Essential Scrum, Pearson, 2013, S. 14 Seite 200 Scrum - Abgrenzung zu Kanban Kriterium Scrum Kanban Kontext Projektmanagement Prozessmanagement Kernobjekte Produkt (z.B. Software) Aufgaben / Prozess Bezugsrahmen-Art Vorgehensrahmen (-modell) Vorgehensrahmen (-modell) Herkunft Software-Entwicklung Produktionsverfahren Anwendungsbereich (Software-)Projekte, … Produktionssteuerung, Projekte, … Steuerung Iteration („Sprint“) „Fluss der Arbeit“ Rollenmodell Product Owner, Dev. Team, n.a. Scrum Master, Stakeholder Elemente Product, Product Increment, Flow, Activity Product Backlog, Sprint Backlog, … Prof. Dr. Wolfgang Wicht Seite 201  Sprints  Gegenstand: Arbeit ist in Iterationen mit gleicher Zeit organisiert. Am Ende jeden Sprints sollen einsetzbare Produktinkremente („potentially shippable procuct increments) fertiggestellt sein.  Regeln: Feste Länge der Sprints von 1 Woche bis zu 1 Monat (häufig: 2 Wochen) (Möglichst) keine Ziel-verändernden Regeln zum Scope während des Sprints Fixed Timeboxes … Sprint 1 Sprint 2 Sprint n Start End Time Product Product Product Increment Increment Increment Prof. Dr. Wolfgang Wicht Seite 202 Scrum - Ablauf Prof. Dr. Wolfgang Wicht Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 17 Seite 203  Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 5.2 SCRUM 6. Projektstrukturplanung 5.2.1 Basiskonzepte 7. Aufwandsschätzung 5.2.2 Rollen 5.2.3 Artefakte 8. Ablaufplanung 5.2.4 Planning 9. Zeitplanung 5.2.5 Sprinting 5.3 Scaled Agile Framework (SAFe) 10. Einsatzmittel- und Kostenplanung 5.4 Extreme Programming (XP) 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 204 Rollen im Scrum - Übersicht  Product Owner: Verantwortlich für die Produktvision, Anforderungen, fachliche Konzeption, Abnahmetests  Development Team: Verantwortlich für die Sprint-Planung, Entwicklung der Produktinkremente, Tests und Qualitätssicherung  Scrum Master: „Koordinierender Dienstleister“ für das Scrum Team (Dev. Team und Product Owner)  Stakeholder (außerhalb Scrum): Alle Rollen der Anspruchsberechtig- ten, die nicht in Scrum definiert sind (z.B. Endanwender, Projektsponsor) 1) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 165 Prof. Dr. Wolfgang Wicht Seite 205  Scrum Master  “The Scrum Master is a servant-leader for the Scrum Team.“ „The Scrum Master acts as a coach to both the development team and the product owner. […] helping everybody understand and embrace the Scrum values, principles, and practices. […] A Scrum Master also provides process leadership, helping the Scrum team and the rest of organization […] 1) Quelle: https://www.scrumguides.org/scrum-guide.html, Abruf: 16.10.2018 2) Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 185 Prof. Dr. Wolfgang Wicht 3) Quelle: https://www.atlassian.com/agile/scrum/scrum-master, Abruf: 16.10.2018 Seite 206 Scrum Master  „Der Dienst des Scrum Masters für den Product Owner […] Vermitteln von Techniken für eine effektive Verwaltung des Product Backlogs; Vermitteln eines Verständnisses für die Notwendigkeit klarer, prägnanter Product Backlog Einträge im Scrum Team; Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld; Sicherstellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet, dass es den größten Wert erzeugt; Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung; Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen.  Der Dienst des Scrum Masters für das Entwicklungsteam […] Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit; Unterstützung des Entwicklungsteams bei der Schaffung hochwertiger Produkte; Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten; Unterstützen bei Bedarf oder auf Anfrage bei der Durchführung von Scrum Ereignissen; Coachen des Entwicklungsteams in Organisationen, in denen Scrum noch nicht vollständig ange- nommen und verstanden wird.  Der Dienst des Scrum Masters an der Organisation […] Leiten und Coachen der Organisation bei der Einführung von Scrum; Planen von Scrum-Implementierungen innerhalb der Organisation; “ Prof. Dr. Wolfgang Wicht Quelle: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf, Abruf: 31.10.2017 Seite 207  Product Owner  “[…] is the single authority responsible for deciding which features and functionality to build and the order in which to build them. The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve. […] the product owner is responsible for the overall sucess of the solution being developed […]“1) Manage economics Participate in planning Product owner Groom the product backlog responsibilities Define acceptance criteria and verify that they are met Collaborate with the development team Collaborate with the stakeholders 1) Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 15 2) Quelle: ebenda, S. 166 Prof. Dr. Wolfgang Wicht Seite 208 Development Team  “[…] is simply a diverse, cross-functional collection of these types of people who are responsible for designing, building, and testing the desired product. The development team self-organizes to determine the best way to accomplish the goal set out by the product owner. The development team ist typically five to nine people in size: It‘s members must collectively have all of the skills needed to produce good quality, working software“1) Perform sprint execution Inspect and adapt each day Development team Groom the product backlog (for tasks, not stories) responsibilities Plan the sprint Inspect and adapt the product 1) Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 16 2) Vgl.: ebenda, S. 197 Inspect and adapt the process Prof. Dr. Wolfgang Wicht Seite 209  Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 6. Projektstrukturplanung 5.2 SCRUM 5.2.1 Basiskonzepte 7. Aufwandsschätzung 5.2.2 Rollen 8. Ablaufplanung 5.2.3 Artefakte 5.2.4 Planning 9. Zeitplanung 5.2.5 Sprinting 5.3 Scaled Agile Framework (SAFe) 10. Einsatzmittel- und Kostenplanung 5.4 Extreme Programming (XP) 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 210 Product Backlog  Gegenstand: Priorisiertes Verzeichnis mit den intendierten Funktionen sowie den verbundenen Arbeiten des zu entwickelnden Produktes Kontinuierliche Anpassung durch das „Product Backlog Grooming“ Product Owner verantwortet die Erstellung und Pflege des Product Backlog Prof. Dr. Wolfgang Wicht Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 19 Seite 211  Product Backlog Item (PBI)  „Most PBIs are features, items of functionality that will have tangible value to the user or customer.  These are often written as user stories.“1) PBI Type PBI Representation Type Feature User Story Defect Product Backlog Item (PBI) Technical Work Task Knowledge Acquisitions 1) Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 100 Prof. Dr. Wolfgang Wicht 2) Obere Bildquelle: ebenda, S. 20 Seite 212 User Story  Gegenstand: „A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.”1)  Format: “As a (role) I want (something) so that (benefit)”2).  Beispiel: “As a customer service representative I want to create a ticket for a customer support issue so that I can record and manage a customer’s request for support”3). 1) Quelle: http://www.agilemodeling.com/artifacts/userStory.htm#InitialFormal, Abruf: 11.10.2018 2) Ebenda Prof. Dr. Wolfgang Wicht 3) Quelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 101 Seite 213  Epic  Gegenstand: „An Epic can be defined as a big chunk of work that has one common objective. It could be a feature, customer request or business requirement. In backlog, it is a placeholder for a required feature with few lines of description. It tells compactly about final output of user needs.”1)  Beispiel: “Epic 01: Provide ordering and priority options to user to manage backlog easily  User Story 01: As a release manager, I want to have my releases mapped to different sprints. I also want to see the priority of each item on same board.  User Story 02: As a system admin, I should be able to provide rights who can prioritize product backlog  User Story 03: As a user I should be able to re-order my backlog using numbered items, star priority or simple drag n drop” 2) 1) Quelle: https://www.yodiz.com/blog/what-is-epic-in-agile-methodology-definition-and-template-of-epic/, Abruf: 11.10.2018 Prof. Dr. Wolfgang Wicht 2) ebenda Seite 214 Stories versus Tasks  „A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person. […]  the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.” 1) Quelle: https://www.mountaingoatsoftware.com/blog/the-difference-between-a-story-and-a-task, Abruf: 10.10.2018 Prof. Dr. Wolfgang Wicht 2) Quelle: https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Seite 215  Stories, Epics, Initiatives and Themes  “Stories, also called “user stories,” are short requirements or requests written from the AdV: work „functionality“ perspective of an end user.  Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories). AdV: tasks „features and higher level tasks“  Initiatives are collections of epics that drive toward a common goal.  Themes are large focus areas that span the organization.” Prof. Dr. Wolfgang Wicht Quelle: https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Seite 216 Sprint Backlog  „Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Pro- duct Backlog-Einträge, ergänzt um den Plan für die Lieferung des Pro- dukt-Inkrements sowie zur Erfüllung des Sprint-Ziels.  Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem fertigen „Done“ - Inkrement zu liefern.  Das Sprint Backlog macht die gesamte Arbeit sichtbar, die das Entwick- lungsteam für notwendig erachtet, um das Sprint-Ziel zu erreichen.  Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fort- schritt innerhalb des Sprints im Daily Scrum erkennen zu können.  Das Entwicklungsteam passt das Sprint Backlog während des Sprints an; […] Wenn weitere Arbeiten erforderlich sind, werden sie vom Entwicklungsteam zum Sprint Backlog hinzugefügt.“ Prof. Dr. Wolfgang Wicht Quelle: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf, Abruf: 31.10.2017 Seite 217  Potentially shippable Product Increment  “potentially shippable” does not mean that what got built must actually be shipped. Shipping is a business decision, which is frequently influenced by things such as “Do we have enough features or enough of a customer workflow to justify a customer deployment?” or “Can our customers absorb another change given that we just gave them a release two weeks ago?”  Potentially shippable is better thought of as a state of confidence that what got built in the sprint is actually done […]“ Prof. Dr. Wolfgang Wicht 1) Text- und Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 23 f. Seite 218 Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 5.2 SCRUM 6. Projektstrukturplanung 5.2.1 Basiskonzepte 7. Aufwandsschätzung 5.2.2 Rollen 5.2.3 Artefakte 8. Ablaufplanung 5.2.4 Planning 9. Zeitplanung 5.2.5 Sprinting 5.3 Scaled Agile Framework (SAFe) 10. Einsatzmittel- und Kostenplanung 5.4 Extreme Programming (XP) 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 219  Ebenen der Planung Level Horizon Who Focus Deliverables Portfolio Possibly a Stakeholders Managing a Portfolio backlog year or and product portfolio of and collection of in more owner products process products Portfolio Product Up to many Product Vision and Product vision, (envi- months or owner, product evolution roadmap, and sioning) longer stakeholders over time high-level features Product Release Three (or Entire Scrum Continuously Release plan Release fewer) to team, balance nine stakeholders customer value Sprint months and overall quality against Daily the constraints of scope, schedule, and budget Sprint Every Entire Scrum What features to Sprint goal and iteration team deliver in the sprint backlog (one week next sprint to one calendar month) 1) Bild- und Tabellenquelle: Daily Every day ScrumMaster, How to complete Rubin, K.: Essential Scrum, development committed Pearson, 2013, S. 257 f. team features Prof. Dr. Wolfgang Wicht Seite 220 Ebenen der Planung 1) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 266 Prof. Dr. Wolfgang Wicht Seite 221  Agile Roadmap  Gegenstand: „A product roadmap is a plan of action for how a product or solution will evolve over time.”1) Initiatives 1) Quelle: https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Prof. Dr. Wolfgang Wicht 2) Quelle Bild: http://blog.trello.com/agile-roadmapping-how-to-think-big-ship-fast, Abruf: 12.04.2017 Seite 222 Agile Roadmap – Prinzipien und Anti-Patterns  Prinzipien: “Product owners use roadmaps to outline future product functionality and when new features will be released. […] To build a roadmap, product owners take into account market trajectories, value propositions, and engineering constraints. […] Multiple agile teams may share a single product roadmap. […] Post the roadmap online and keep it current so the team has a single source of truth. [… ] review roadmaps quarterly, adjust as needed, and share.”1)  Anti-Patterns: “Future planning is completely ignored — we're shootin' from the hip! The "rest of the business" is kept in the dark as to what the team is up to. The roadmap is continuously updated (or never updated). Detailed requirements are weighing down the roadmap.” 2) 1) Quelle: https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Prof. Dr. Wolfgang Wicht 2) Quelle: ebenda Seite 223  Product Backlog Grooming  Gegenstand: „Backlog grooming is when the product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appro- priate items, that they are prioritized […]”1)  Aktivitäten: „removing user stories that no longer appear relevant creating new user stories in response to newly discovered needs re-assessing the relative priority of stories assigning estimates to stories which have yet to receive one correcting estimates in light of newly discovered information splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration”1) 1) Quelle: https://www.agilealliance.org/glossary/backlog-grooming, Abruf: 10.10.2018 Prof. Dr. Wolfgang Wicht 2) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 19 Seite 224 Product Backlog (Item)-Priorisierung Quelle: https://www.scrumdesk.com/start/manual-for-scrumdesk-start/start- Prof. Dr. Wolfgang Wicht moscow-prioritization-product-backlog/, Abruf: 27.11.2017 Seite 225  Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 5.2 SCRUM 6. Projektstrukturplanung 5.2.1 Basiskonzepte 7. Aufwandsschätzung 5.2.2 Rollen 5.2.3 Artefakte 8. Ablaufplanung 5.2.4 Planning 9. Zeitplanung 5.2.5 Sprinting 5.3 Scaled Agile Framework (SAFe) 10. Einsatzmittel- und Kostenplanung 5.4 Extreme Programming (XP) 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 226 Sprint Planning - Gegenstand  „During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve.  Using this goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint […]”1) Duration: Usually an hour per week of iteration Prof. Dr. Wolfgang Wicht 1) Text- und Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 21 f. Seite 227  Sprint Planning - Aktivität Input Description Product Prior to sprint planning, the topmost backlog product backlog items have been groomed into a ready state Team The team‘s historical velocity is an velocity indicator of how much work is practical for the team to complete in a sprint Con- Business or technical constraints straints that could materially affect what the team can deliver are identified Team Capabilities take into account which capa- people are on the team, what skills bilities each team memer has, and how available each person will be in the upcoming sprint. Initial This is the business goal the sprint product owner would like to see goal accomplished during the sprint Prof. Dr. Wolfgang Wicht 1) Bild- und Tabellenquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 338 f. Seite 228 Sprint Planning – Ablauf  „Select a product backlog item (whenever possible, the next-most-important item as defined by the product owner), break the item down into tasks, and determine if the selected item will reasonably fit within the sprint (in combination with other items targeted for the same sprint).  If it does fit and there is more capacity to complete work, repeat the cycle until the team is out of capacity to do any more work.” 1) Text- und Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 21 f. Prof. Dr. Wolfgang Wicht Seite 229  Sprint Execution  „[…] the development team, guided by the ScrumMaster’s coaching, performs all of the task-level work necessary to get the features done  […] team members define their own task-level work and then self- organize in any manner they feel is best for achieving the sprint goal.” Prof. Dr. Wolfgang Wicht 1) Text- und Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 23 f. Seite 230 Agile Workflow  Workflow States: “TO DO: Work that has not been started IN PROGRESS: Work that is actively being looked at by the team. CODE REVIEW: Work that is completed, but awaiting review. DONE: Work that is completely finished and meets the team's definition of done.”1) 1) Quelle Text und Bild: Prof. Dr. Wolfgang Wicht https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Seite 231  Scrum (Task) Board  Gegenstand: Übersicht der Sprint Backlog Items (stories, tasks) mit Bearbeitungsstatus, gepflegt durch die Mitglieder des Development Teams  Struktur (exemplarisch): Story To Do Doing Testing Done (Work in (To Verify) Progress, WiP) User Story Task Task Task Task Task Task Task Task … … … … User Story Task Task Task Task Task Task Task Task … … … … Prof. Dr. Wolfgang Wicht Seite 232 Daily Scrum  „[…] Time Box von 15 Minuten, innerhalb derer das Entwicklungsteam seine Aktivi- täten synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet.  […] an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten. […]  Während des Meetings schildern die Mitglieder des Entwicklungsteams: Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen? Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen? Sehe ich irgendwelche Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?”1) 1) Textquelle: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-German.pdf, Abruf: 31.10.2017 Prof. Dr. Wolfgang Wicht 2) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 23 f. Seite 233  Definition of Done  Gegenstand: „a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.”1) „While the DoD usually applies to all items in the backlog, Acceptance Criteria are applicable to a specific user story. In order to complete the story, both the DoD and acceptance criteria must be met.”2) Status Definition of Done Criteria  Analysis Criteria  Designing Criteria  Coding Criteria  Testing Criteria 1) Quelle:  Documenting Criteria https://www.scrum.org/resources/sc rum-glossary, Abruf: 11.10.2018  Deployment Criteria 2) Quelle: https://www.atlassian.com/blog/jira-  … software/8-steps-to-a-definition-of- done-in-jira, Abruf: 11.10.2018 Prof. Dr. Wolfgang Wicht Seite 234 Definition of Done - Beispiel Status Definition of Done Criteria  Design reviewed  Code completed  Code refactored  Code in standard format  Code is commented  Code checked in  Code inspected  End-user documentation updated  Tested  Unit tested  Integration tested  Regression tested  Platform tested  Language tested  Zero known defects In Anlehnung an: Rubin, K.: Essential Scrum,  Acceptance tested Pearson, 2013, S. 74  Live on production servers Prof. Dr. Wolfgang Wicht Seite 235  Sprint Review  Zweck: Inspektion (mit Demonstration) der Liefergegenstände und Adaption der Rückmeldungen hierzu („inspect and adapt the product“)  Teilnehmer: Development Team, Scrum Master, Product Owner; optional: Project Stakeholder  Dauer: ca. 1 Std./Woche, d.h. bei einem zweiwöchigen Sprint ca. 2 Std. 1) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 23 f. Prof. Dr. Wolfgang Wicht Seite 236 Sprint Retrospective  Zweck: Inspektion der Entwicklungs- und Projektprozesse sowie Adaption der Rückmeldungen hierzu („inspect and adapt the process“). Kontinuierlicher Verbesserungsprozess („continuous improvement“).  Teilnehmer: Development Team, Scrum Master, Product Owner  Dauer: ca. 1 Std. je Sprint 1) Bildquelle: Rubin, K.: Essential Scrum, Pearson, 2013, S. 23 f. Prof. Dr. Wolfgang Wicht Seite 237  Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 6. Projektstrukturplanung 5.2 SCRUM 5.3 Scaled Agile Framework (SAFe) 7. Aufwandsschätzung 5.4 Extreme Programming (XP) 8. Ablaufplanung 9. Zeitplanung 10. Einsatzmittel- und Kostenplanung 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 238 Scaled Agile Framework (SAFe) - Gegenstand  Definition: “SAFe® is an online and “freely-revealed knowledge base of proven success patterns for implementing lean-agile software and systems development at enterprise scale. SAFe® provides ceremonies, roles, metrics, and relationships that allow organizations to leverage lean and agile at enterprise scale.”1)  Constructs: “Agile Release Train (“ART”) - represents a group of 5-12 teams (50-125 people) planning, committing, and delivering business value at the program level. The ART is large enough to deliver significant business value, but small enough for everyone to have meaningful relationships with one another. It ensures a reliable schedule and fixed cadence through a dedicated team and aligned artifacts. Program Increment (“PI”) - a timebox that synchronizes planning, delivery, and reviews within an ART”2) 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 12, https://www.atlassian.com/dam/jcr:b549786a-5967-4603-91eb-16a9d8902061/cPrime_SAFewhitepaper_0829_125636.pdf, Abruf: 07.10.2018 Prof. Dr. Wolfgang Wicht 2) Ebenda, S. 13. Seite 239  Agile Release Train (ART)  Gegenstand: „The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.”1)  Prinzipien (Auswahl): The schedule is fixed – The train departs the station on a known, reliable schedule, as determined by the chosen Program Increment (PI) cadence. If a Feature misses a timed departure and does not get planned into the current PI, it can catch the next one. A new system increment every two weeks – Each train delivers a new system increment every two weeks. The System Demo provides a mechanism for evaluating the working system, which is an integrated increment from all the teams. Synchronization is applied – All teams on the train are synchronized to the same PI length (typically 8 – 12 weeks) and have common Iteration start/end dates and duration. The train has a known velocity – Each ART can reliably estimate how much cargo (new features) can be delivered in a PI.” 2) 1) Quelle: https://www.scaledagileframework.com/agile-release-train/, Abruf: 23.11.2020 2) Quelle: ebenda Prof. Dr. Wolfgang Wicht 3) Bildquelle: ebenda Seite 240 Levels - Portfolio Level  “[…] the highest level of SAFe® that provides systems and solutions to ensure the enterprise meets its strategic objectives value stream”1)  […] the main goal is to intake, evaluate, prioritize, and track all important initiatives.”2) 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 21, https://www.atlassian.com/ dam/jcr:b549786a-5967- 4603-91eb- 16a9d8902061/cPrime_SA Fewhitepaper_0829_1256 36.pdf, Abruf: 07.10.2018 2) Quelle: ebenda, S. 22 3) Bildquelle: Ebenda, S. 17. Prof. Dr. Wolfgang Wicht Seite 241  Initiatives, Epics, Stories (Wiederholung)  “Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user. Anm. d. Verf.: work „functionality“  Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories). Anm. d. Verf.: tasks „features and higher level tasks“  Initiatives are collections of epics that drive toward a common goal.” 1) Quelle: https://www.atlassian.com/agile/project-management/epics-stories-themes, Abruf: 10.10.2018 Prof. Dr. Wolfgang Wicht 2) Bildquelle: ebenda, Abruf: 10.10.2018 Seite 242 Levels - Program Level  “[…] where team resources are applied to critical, ongoing development work”1)  […] the main goal is to prioritize work, assign work across teams based on needed skills and capacity, coordinate activities, manage dependencies, and perform what-if analysis for optimal throughput using available scope, resources, and time.”2) 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 21, https://www.atlassian.com/ dam/jcr:b549786a-5967- 4603-91eb- 16a9d8902061/cPrime_SA Fewhitepaper_0829_1256 36.pdf, Abruf: 07.10.2018 2) Quelle: ebenda, S. 12 3) Bildquelle: Ebenda, S. 17. Prof. Dr. Wolfgang Wicht Seite 243  Levels - Team Level  “Teams are focused on development and delivery of planned feature functionality and track these items and their rollup to the higher initiatives”1)  […] where teams work on a common iteration cadence to define, build, and test stories from their backlog.”2) 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 21, https://www.atlassian.com/ dam/jcr:b549786a-5967- 4603-91eb- 16a9d8902061/cPrime_SA Fewhitepaper_0829_1256 36.pdf, Abruf: 07.10.2018 2) Quelle: ebenda, S. 12 3) Bildquelle: Ebenda, S. 17. Prof. Dr. Wolfgang Wicht Seite 244 Roles - Portfolio Level  “Epic owner – responsible for identification and creation of epics aligned by vision and strategic themes. Create value statements and lightweight creative business case. Owns portfolio backlog, WSJF prioritization, and go/no-go decisions for completed work.  Enterprise architect – responsible for ensuring enterprise-wide architectural system, platform, and infrastructure dependent work is identified and created”1) WSJF: Weighted Shortest Job First 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 14, https://www.atlassian.com/dam/jcr:b549786a-5967-4603-91eb-16a9d8902061/cPrime_SAFewhitepaper_0829_125636.pdf, Abruf: 07.10.2018 Prof. Dr. Wolfgang Wicht 2) Ebenda, S. 13. Seite 245  Roles - Program Level  “Release train engineer – responsible for facilitating value stream and ART processes and execution including PI Planning, alignment with vision, and value stream objectives  System architect/engineer – responsible for alignment with enterprise and solution architecture, and identifying and creation of solution architecture to be delivered by teams architecture”1) 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 13 f., https://www.atlassian.com/dam/jcr:b549786a-5967-4603-91eb-16a9d8902061/cPrime_SAFewhitepaper_0829_125636.pdf, Abruf: 07.10.2018 Prof. Dr. Wolfgang Wicht 2) Ebenda, S. 13. Seite 246 Roles - Team Level  “Product owner – responsible for defining stories, prioritizing the team backlog, review, and accepting stories  Scrum master – responsible for lean-agile leadership, agile process facilitation, enabling the team, and removal of impediments  Scrum team – group of individuals responsible for defining, building, and testing components/features within their agile process”1) Anm. d. Verf.: Scrum „Development“ 1) Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 15 f., https://www.atlassian.com/dam/jcr:b549786a-5967-4603-91eb-16a9d8902061/cPrime_SAFewhitepaper_0829_125636.pdf, Abruf: 07.10.2018 Prof. Dr. Wolfgang Wicht 2) Ebenda, S. 13. Seite 247  Process Quelle: Radigan, D. et.al.: Scaling agile with Atlassian and SAFe, Atlassiona and Cprime, Whitepaper, S. 21, https://www.atlassian.com/da m/jcr:b549786a-5967-4603- 91eb- 16a9d8902061/cPrime_SAFe whitepaper_0829_125636.pdf, Abruf: 07.10.2018 Prof. Dr. Wolfgang Wicht Seite 248 Inhalt 1. Einführung 2. Projektmanagement-Framework 3. Vorgehensmodelle 4. Disziplinierte Vorgehensmodelle 5. Agile Vorgehensmodelle 5.1 Grundlagen 6. Projektstrukturplanung 5.2 SCRUM 5.3 Scaled Agile Framework (SAFe) 7. Aufwandsschätzung 5.4 Extreme Programming (XP) 8. Ablaufplanung 9. Zeitplanung 10. Einsatzmittel- und Kostenplanung 11. Projekt-Controlling I 12. Projekt-Controlling II 13. Projektmanagement-Planspiel Prof. Dr. Wolfgang Wicht Seite 249  Extreme Programming (XP) - Gegenstand  „Extreme Programming or XP is a development process that can be used by small to medium sized teams to develop high quality software within a predictable schedule and budget and with a minimum of overhead.”1)  “The goal of a software process is to guide the software development organization to: Get the right software done. Get the software done right. Get the software done quickly. Get the software done frugally.”2) 1) Quelle: https://eclipse.org/epf/downloads/configurations/pubconfig_downloads.php, Abruf: 15.10.2016 Prof. Dr. Wolfgang Wicht 2) ebenda Seite 250 Extreme Programming (XP) – Planungs- und Feedbackschleifen Prof. Dr. Wolfgang Wicht Bildquelle: https://www.youtube.com/watch?v=FufRFdFFu4k, Abruf: 17.10.2018 Seite 251  Extreme Programming (XP) – Praktiken Prof. Dr. Wolfgang Wicht Text- und Bildquelle: https://eclipse.org/epf/downloads/configurations/pubconfig_downloads.php, Abruf: 15.10.2016 Seite 252 Extreme Programming (XP) - Praktiken  On Site Customer: Kunde ist Teil des Teams und in Spezifikation/Test involviert  Planning Game: Explizite Planung der nächsten Schritte  Kontinuierliche Architekturweiterentwicklung: Evolution der Architektur  Inkrementelle Entwicklung: Entwicklung kleiner ausführbarer Releases  Kontinuierliche Integration: Code wird täglich ins Gesamtsystem integriert  Kontinuierliches Testen: Bei der Erstellung einer Funktion muss auch der entsprechende Testtreiber programmiert werden  Refactoring: Jeder redundante Code wird sofort entfernt und überarbeitet  Coding-Standards: Team folgt einen gemeinsamen Standard  Kollektiver Code: Code gehört stets allen  Einfaches Design: Wahl des einfachsten Designs; nur die notwendigsten Anforderungen werden implementiert  Pair Programming: Jeweils zwei Entwickler programmieren gemeinsam Prof. Dr. Wolfgang Wicht In Anlehnung an: Computerwoche 28/2004 Seite 253  Exkurs: Continuous Integration – Continuous Delivery alerts Application event stream Monitoring feedback store Repository (Source Code, Tests, …) Developer trigger CD Environment Static Integration Performance Smoke Unit Tests Integration Build Deployment UI Tests Security Tests Deployment … Deployment Analysis Tests & Load Tests Test Development Test Staging Production Environment Environment Environment Environment Application Application Application Application Framework Framework Framework Framework Database Database Database Database Prof. Dr. Wolfgang Wicht Seite 254 Extreme Programming (XP) – Roles: XP Coach  „The XP Coach is a supporting role which helps a team stay on process and help the team learn.” Prof. Dr. Wolfgang Wicht Text- und Bildquelle: https://eclipse.org/epf/downloads/configurations/pubconfig_downloads.php, Abruf: 15.10.2016 Seite 255  Extreme Programming (XP) – Roles: XP Customer  „The XP Customer role has the responsibility of defining what is the right product to build, determining the order in which features will be built, and making sure the product actually works.” Prof. Dr. Wolfgang Wicht Text- und Bildquelle: https://eclipse.org/epf/downloads/configurations/pubconfig_downloads.php, Abruf: 15.10.2016 Seite 256 Extreme Programming (XP) – Roles: XP Programmer  „The XP Programmer is responsible for implementing the code to support the user stories.” Prof. Dr. Wolfgang Wicht Text- und Bildquelle: https://eclipse.org/epf/downloads/configurations/pubconfig_downloads.php, Abruf: 15.10.2016 Seite 257  Extreme Programming (XP) – Dokumentation: XP Browser Download: https://eclipse.org/epf/ downloads/configurati ons/pubconfig_downlo ads.php Prof. Dr. Wolfgang Wicht Seite 258