Umfang:
1 Online-Ressource (264 Seiten)
Ausgabe:
3rd ed
ISBN:
9783969105382
Anmerkung:
Description based on publisher supplied metadata and other sources
,
Intro -- Vorwort -- Zielgruppe dieses Buches -- Über die Autoren: unsere Geschichte -- Unsere Vision und Mission -- Abb. 1 Ergebnisse als Mittel zum Zweck, um Wirkungen zu erzielen -- Hinweise zur zweiten Auflage -- Hinweise zur dritten Auflage -- Danksagung -- Überblick über das Buch -- Lesewege -- Inhaltsübersicht -- Inhaltsverzeichnis -- 1 Scrum: Historie, Vorteile, Eignung und Herausforderungen -- 1.1 Historie -- 1.1.1 Scrum-Teams nach Nonaka und Takeuchi -- Abb. 1-1 Klassische Entwicklung vs. Scrum -- Abb. 1-2 Scrum-Team -- Abb. 1-3 Agile Teams lösen Probleme der Endkund:innen. -- 1.1.2 Erste Scrum-Projekte in der Softwareentwicklung -- 1.1.3 Von den ersten Artikeln bis zum Scrum Guide -- 1.1.4 Verbreitung von Scrum -- 1.2 Vorteile von Scrum -- Abb. 1-4 Scrum-Vorteile -- 1.2.1 Kürzere Time-to-Market -- Abb. 1-5 Weniger Work in Progress reduziert Durchlaufzeiten. -- Abb. 1-6 Ein Großteil der Funktionen in Softwaresystemen wird selten oder nie genutzt. -- 1.2.2 Höhere Qualität -- 1.2.3 Größere Effizienz -- 1.2.4 Mehr Innovation -- 1.2.5 Größere Arbeitszufriedenheit -- 1.3 Eignung -- Abb. 1-7 Geschäftssystem vs. Innovationssystem -- Abb. 1-8 Stacey Landscape Diagram -- 1.4 Herausforderung: Denkweise (Mindset) -- 1.5 Das Kapitel in Stichpunkten -- 2 Überblick über den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien -- 2.1 Scrum-Flow -- Abb. 2-1 Der Scrum-Ablauf passt auf einen Bierdeckel. -- 2.2 Die Verantwortlichkeiten -- 2.2.1 Product Owner -- 2.2.2 Entwickler:innen -- 2.2.3 Scrum Master -- 2.2.4 Scrum-Team -- 2.2.5 Kein Projektleiter oder Projektleiterin in Scrum -- 2.3 Meetings (Events) -- 2.3.1 Sprint Planning -- 2.3.2 Daily Scrum -- 2.3.3 Sprint-Review -- 2.3.4 Sprint-Retrospektive -- 2.4 Der Sprint -- 2.5 Artefakte -- 2.5.1 Product Backlog -- 2.5.2 Sprint Backlog -- 2.5.3 Lieferbares Produktinkrement
,
Abb. 2-2 Produktentwicklung in vertikalen Schnitten -- 2.6 Prinzipien -- Abb. 2-3 Scrum-Mechanik als Hilfsmittel zur Installation des agilen Kernzyklus -- Abb. 2-4 Scrum-Prinzipien -- 2.6.1 Autonomes und cross-funktionales Team -- 2.6.2 Inspect & -- Adapt (auch: empirisches Management) -- 2.6.3 Timeboxing -- 2.6.4 Return on Investment (ROI) -- 2.6.5 Qualität einbauen -- 2.6.6 Pull -- 2.6.7 Bewusst unterspezifiziert -- 2.7 Scrum-Werte -- 2.8 Das Kapitel in Stichpunkten -- 3 Scrum produktbezogen -- 3.1 Produktbegriff -- 3.1.1 Beispiel -- 3.1.2 Der passende Produktbegriff -- 3.2 Produktinkremente -- Abb. 3-1 Jedes Produktinkrement enthält Teile der Oberfläche, Logik und Datenhaltung. -- Abb. 3-2 Jedes Produktinkrement enthält seine Vorgänger. -- Abb. 3-3 Eigenschaften von Produktinkrementen (angelehnt an Jussi Pasanen, Aarron Walter) -- 3.3 Endkund:innen -- Abb. 3-4 Endkund:innen/Zielgruppen sind diejenigen, deren Probleme das Produkt lösen soll. -- 3.3.1 Zielgruppen und Personas -- Abb. 3-5 Beispiel-Persona -- 3.3.2 Personas validieren -- 3.4 Produktvision -- Abb. 3-6 Produktvision filtert Endkund:innen und Probleme. -- 3.4.1 Elemente der Produktvision -- Abb. 3-7 SPEG - Situation, Problem, Emotion, Goal -- Abb. 3-8 Lösung des Problems der Kund:innen: Hindernis beseitigen oder umgehen -- 3.4.2 Probleme/Bedürfnisse identifizieren -- 3.4.3 Produktvision kommunizieren: Storytelling -- 3.4.4 Weitere Hilfsmittel für Produktvisionen -- 3.5 Die Product-Owner-Verantwortlichkeit -- 3.5.1 Die Bedeutung von Priorisierung -- Abb. 3-9 Nur 20 % der Funktionen werden immer oder oft benutzt. -- Abb. 3-10 Wertentwicklung bei wertorientierter Priorisierung -- Abb. 3-11 Product Owner müssen sich mit den Bedürfnissen der Kund:innen, Businessmodellen und Technologien auskennen. -- 3.5.2 Bevollmächtigung des Product Owners -- 3.6 Eigenschaften des Product Backlog
,
3.6.1 Das Produktziel -- 3.6.2 Organisation der Product Backlog Items -- Abb. 3-12 Das Product Backlog ist gemäß der Priorisierung detailliert. -- 3.6.3 Größe des Product Backlog -- 3.7 Definition of Ready -- 3.8 Product Backlog Board -- Abb. 3-13 Product Backlog Board nach Roman Pichler -- 3.8.1 Überführung in den »Ready for Sprint«-Bereich -- 3.8.2 Inhomogene Product Backlog Items -- 3.8.3 Physikalisches Board -- 3.9 Priorisierung -- 3.9.1 Priorisierung nach Kosten-Wert -- Abb. 3-14 Priorisierung nach Kosten-Wert -- Abb. 3-15 Paarweiser Vergleich bei der Priorisierung nach Kosten-Wert -- 3.9.2 Priorisierung nach Risiko-Wert -- Abb. 3-16 Priorisierung nach Risiko-Wert -- 3.9.3 Priorisierung mit Verzögerungskosten (Cost of Delay) -- Abb. 3-17 Konstante Verzögerungskosten -- Abb. 3-18 Verzögerungskosten mit Stichtag -- Abb. 3-19 A, B ist günstiger als B, A. -- 3.9.4 Wert bzw. Verzögerungskosten ermitteln -- 3.9.5 Technische Product Backlog Items mit Verzögerungskosten priorisieren -- 3.10 Epics und User Stories -- Abb. 3-20 User Stories vs. Spezifikationen -- 3.10.1 Satzschema für User Stories -- 3.10.2 Typische Fallen bei User Stories -- 3.10.2.1 Nutzen wird weggelassen -- 3.10.2.2 Akteur:in ist zu abstrakt -- 3.10.2.3 Akteur:in ist der Anforderer oder die Anforderin -- 3.10.3 Tipps zu User Stories -- 3.10.3.1 Alternatives Satzschema -- 3.10.3.2 Persona als Akteur:in -- 3.10.4 Akzeptanzkriterien -- 3.10.5 User Stories anhand von Akzeptanzkriterien aufspalten -- 3.10.6 Epics -- Abb. 3-21 Epic und User Stories -- Abb. 3-22 Fortschrittsanzeige mit Epics -- 3.11 Das komplette Produkt als Geschichte: Story Mapping -- Abb. 3-23 Story-Map-Struktur -- 3.11.1 Story-Map-Beispiel -- Abb. 3-24 Story-Map-Beispiel »Pkw-Versicherung« -- 3.11.2 Wirkungen in Story Maps -- Abb. 3-25 Wirkungen in Story Maps -- 3.12 Weitere Techniken zur Anforderungsmodellierung
,
3.13 Empirisches Management produktbezogen -- Abb. 3-26 Empirisches Management benötigt Transparenz, Inspektion und Adaption. -- 3.13.1 Sprint Planning und Sprint-Review -- Abb. 3-27 Mögliche Platzierung von Sprint-Review, -Retrospektive und Planning -- 3.14 Das Sprint Planning -- 3.14.1 Pull-Prinzip im Sprint Planning -- 3.14.2 Tasks als Plan -- 3.14.3 Das Sprint-Ziel -- 3.14.3.1 Finden des Sprint-Ziels -- Abb. 3-28 Product Backlog Items zum Sprint-Ziel selektieren -- Abb. 3-29 Sprint-Ziel ausgehend vom Product Backlog formulieren -- 3.14.3.2 Vorteile guter Sprint-Ziele -- 3.15 Das Sprint-Review -- Abb. 3-30 Empirisches Management im Sprint-Review -- 3.15.1 Transparenz: Demonstration des lieferbaren Produktinkrements -- 3.15.2 Inspektion: Einholen von Feedback zum Produktinkrement -- 3.15.3 Adaption: Integration des Feedbacks in das Product Backlog -- 3.15.3.1 Zusätzliche und alternative Praktiken im Sprint-Review -- Tab. 3-1 Zusätzliche und alternative Praktiken im Sprint-Review -- 3.15.4 Und was ist mit der Abnahme? -- Abb. 3-31 Drei »Quality Gates« in Scrum -- 3.15.5 Sprint-Abbruch -- 3.16 Backlog Refinement -- Abb. 3-32 Möglichkeiten zur Durchführung des Refinements -- 3.16.1 Refinement im Sprint-Review -- 3.16.2 Refinement im Sprint Planning -- 3.16.3 Refinement zwischen Sprint-Review und Sprint Planning -- Abb. 3-33 Refinement zwischen Sprint-Review und Sprint Planning -- 3.16.4 Ad-hoc-Refinement-Meetings -- 3.16.5 Regelmäßige Refinement-Meetings -- Abb. 3-34 Regelmäßige Refinement-Meetings -- 3.16.6 Refinement-Optionen im Vergleich -- Tab. 3-2 Möglichkeiten für Backlog Refinement -- 3.17 Das Kapitel in Stichpunkten -- 4 Entwicklung mit Scrum -- 4.1 Entwickler:innen (Cross-Funktionalität, Autonomie, Selbstorganisation) -- 4.1.1 Cross-Funktionalität
,
Was tun, wenn es für jemanden im Team nichts zu tun gibt, weil er für keine der noch anstehenden Aufgaben qualifiziert ist? -- Abb. 4-1 T-Shaped-Qualifikationsprofile -- Was tun, wenn wir von einer besonders intensiv und häufig benötigten Qualifikation zu wenig haben und deswegen alle anderen nicht genug zu tun haben (während einer überlastet ist)? -- 4.1.2 Autonomie und Selbstorganisation -- 4.1.3 Entwickler:innen nur in einem Team -- 4.2 Sprints -- 4.3 Lieferbare Produktinkremente -- 4.3.1 Definition of Done -- 4.4 Technische Herausforderungen -- 4.4.1 Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint -- 4.4.2 Herausforderung 2: inkrementelle Architekturentwicklung -- Abb. 4-2 Entwicklung in vertikalen Schnitten -- Abb. 4-3 Kosten durch Codeänderungen -- Abb. 4-4 Kosten durch Technologie auf Vorrat -- Abb. 4-5 Gesamtkosten -- Abb. 4-6 Agile Entwicklungspraktiken verschieben die Kurve »Kosten durch Codeänderungen« nach unten. -- 4.5 Sprint Planning: das »Wie« -- 4.5.1 Aufwandsschätzung -- 4.5.2 Story Points als Größenmaß -- Abb. 4-7 Nicht linearer Wertebereich für Story Points -- Abb. 4-8 Fibonacci-Folge für Story Points -- 4.5.3 Vorteile von Story Points -- 4.5.4 Planning Poker -- Abb. 4-9 Planning-Poker-Karten -- 4.5.5 Varianten des Planning Poker -- 4.5.6 Erfahrungen mit Planning Poker -- 4.5.7 Inkrementelles Ziehen in den Sprint -- Abb. 4-10 Thumb-Voting im Sprint Planning -- 4.5.8 Das »Wie« im Sprint Planning: Task-Breakdown -- 4.5.9 Architekturdiskussionen -- 4.5.10 Was wir nicht im Sprint Planning festlegen -- 4.6 Taskboard als Sprint Backlog -- Abb. 4-11 Ein sehr einfaches Taskboard -- Abb. 4-12 Taskboard mit Zeilen je Product Backlog Item -- Abb. 4-13 Taskboard mit zusätzlicher Codereview-Spalte -- 4.7 Sprint-Burndown-Chart -- Abb. 4-14 Sprint-Burndown-Chart kurz vor dem Sprint-Ende -- 4.8 Daily Scrum
,
4.8.1 Umgang mit Problemen im Daily Scrum
Weitere Ausg.:
Erscheint auch als Druck-Ausgabe Wolf, Henning Scrum - verstehen und erfolgreich einsetzen Heidelberg : dpunkt.verlag,c2021 ISBN 9783864908484
Sprache:
Deutsch
Fachgebiete:
Informatik
,
Wirtschaftswissenschaften
Schlagwort(e):
Scrum
;
Projektmanagement
;
Agile Softwareentwicklung
