Читать книгу Scrum – verstehen und erfolgreich einsetzen - Henning Wolf - Страница 8
Inhaltsverzeichnis
Оглавление1 Scrum: Historie, Vorteile, Eignung und Herausforderungen
1.1.1 Scrum-Teams nach Nonaka und Takeuchi
1.1.2 Erste Scrum-Projekte in der Softwareentwicklung
1.1.3 Von den ersten Artikeln bis zum Scrum Guide
1.2.5 Größere Arbeitszufriedenheit
1.4 Herausforderung: Denkweise (Mindset)
1.5 Das Kapitel in Stichpunkten
2 Überblick über den Scrum-Ablauf, die Verantwortungen, Meetings, Artefakte und Prinzipien
2.2.5 Kein Projektleiter oder Projektleiterin in Scrum
2.5.3 Lieferbares Produktinkrement
2.6.1 Autonomes und cross-funktionales Team
2.6.2 Inspect & Adapt (auch: empirisches Management)
2.6.4 Return on Investment (ROI)
2.6.7 Bewusst unterspezifiziert
2.8 Das Kapitel in Stichpunkten
3.1.2 Der passende Produktbegriff
3.3.1 Zielgruppen und Personas
3.4.1 Elemente der Produktvision
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
3.5.2 Bevollmächtigung des Product Owners
3.6 Eigenschaften des Product Backlog
3.6.2 Organisation der Product Backlog Items
3.6.3 Größe des Product Backlog
3.8.1 Überführung in den »Ready for Sprint«-Bereich
3.8.2 Inhomogene Product Backlog Items
3.9.1 Priorisierung nach Kosten-Wert
3.9.2 Priorisierung nach Risiko-Wert
3.9.3 Priorisierung mit Verzögerungskosten (Cost of Delay)
3.9.4 Wert bzw. Verzögerungskosten ermitteln
3.9.5 Technische Product Backlog Items mit Verzögerungskosten priorisieren
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.1 Alternatives Satzschema
3.10.3.2 Persona als Akteur:in
3.10.5 User Stories anhand von Akzeptanzkriterien aufspalten
3.11 Das komplette Produkt als Geschichte: Story Mapping
3.11.2 Wirkungen in Story Maps
3.12 Weitere Techniken zur Anforderungsmodellierung
3.13 Empirisches Management produktbezogen
3.13.1 Sprint Planning und Sprint-Review
3.14.1 Pull-Prinzip im Sprint Planning
3.14.3.1 Finden des Sprint-Ziels
3.14.3.2 Vorteile guter Sprint-Ziele
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
3.15.4 Und was ist mit der Abnahme?
3.16.1 Refinement im Sprint-Review
3.16.2 Refinement im Sprint Planning
3.16.3 Refinement zwischen Sprint-Review und Sprint Planning
3.16.4 Ad-hoc-Refinement-Meetings
3.16.5 Regelmäßige Refinement-Meetings
3.16.6 Refinement-Optionen im Vergleich
3.17 Das Kapitel in Stichpunkten
4.1 Entwickler:innen (Cross-Funktionalität, Autonomie, Selbstorganisation)
4.1.2 Autonomie und Selbstorganisation
4.1.3 Entwickler:innen nur in einem Team
4.3 Lieferbare Produktinkremente
4.4 Technische Herausforderungen
4.4.1 Herausforderung 1: lieferbares Produktinkrement ab dem ersten Sprint
4.4.2 Herausforderung 2: inkrementelle Architekturentwicklung
4.5 Sprint Planning: das »Wie«
4.5.2 Story Points als Größenmaß
4.5.3 Vorteile von Story Points
4.5.5 Varianten des Planning Poker®
4.5.6 Erfahrungen mit Planning Poker®
4.5.7 Inkrementelles Ziehen in den Sprint
4.5.8 Das »Wie« im Sprint Planning: Task-Breakdown
4.5.10 Was wir nicht im Sprint Planning festlegen
4.6 Taskboard als Sprint Backlog
4.8.1 Umgang mit Problemen im Daily Scrum
4.8.2 Der Product Owner im Daily Scrum
4.8.3 Hindernisbearbeitung im Daily Scrum
4.9 Das Kapitel in Stichpunkten
5 Kontinuierliche Verbesserung
5.1 Scrum-Master-Verantwortung
5.1.1 Scrum-Master-Dienste für den Product Owner
5.1.2 Scrum-Master-Dienste für das Scrum-Team
5.1.3 Scrum-Master-Dienste für die Organisation
5.1.4 Der Scrum Master und die Entwickler:innen
5.1.5 Der Scrum Master und der Product Owner
5.1.6 Der Scrum Master und die Organisation
5.1.7 Der Scrum Master und die Scrum-Meetings
5.1.8 Haltung und Einstellung des Scrum Masters
5.1.9 Braucht es einen Vollzeit-Scrum-Master?
5.1.9.1 Entwickler:innen als Scrum Master
5.1.9.2 Scrum Master als Entwickler oder Entwicklerin in einem anderen Scrum-Team
5.1.9.3 Scrum Master für ein zusätzliches Team
5.1.9.4 Der Scrum Master als Change Agent im Unternehmen
5.1.9.5 Der richtige Weg für den eigenen Kontext
5.1.10 Der Business Case zum Scrum Master
5.1.11 Die Super-Power des Scrum Masters
5.4.2.1 Set the stage (die Bühne bereiten)
5.4.2.2 Gather data (Daten sammeln)
5.4.2.3 Generate insights (Einsichten generieren)
5.4.2.4 Decide what to do (entscheiden, was zu tun ist)
5.4.3 Moderation von Retrospektiven
5.4.4 Teilnehmer:innen der Sprint-Retrospektive
5.5 Agile Werte und Prinzipien
5.6 Das Kapitel in Stichpunkten
6.1 Grenzen der Releaseplanung
6.2 Das Warum der Releaseplanung
6.3 Das beste Releasemanagement ist Sprint-Management
6.4 Schätzung mit Story Points
6.5.2 Probleme mit Story Points
6.5.3 Alternativen zu Story Points
6.7.1 Release-Burndown-Bar-Charts
6.8.1 Werkverträge ohne Festpreis
6.8.2 Alternative Vertragsformen
6.9 Das Kapitel in Stichpunkten
7 Streiflicht auf fortgeschrittenes Scrum
7.1.1 Veränderte Verhaltensweisen
7.1.2 Scrum im Unternehmen verankern
7.1.3 Kulturwandel im Unternehmen
7.1.3.2 Autonome Business Units
7.1.4 Agilität mit agilen Verfahren ausbreiten
7.1.6.1 Ökonomie des Coachings
7.1.7 Externe Coaches auswählen
7.1.8 Interne Coaches ausbilden
7.2.2 Praktiken zur Reduktion von Abhängigkeiten
7.2.3 Praktiken zur Koordination von Teams
7.2.4 Die Organisation entwickeln
7.4.1 Vertrauen ist essenziell
7.5 Interventionen durch Führungskräfte
7.5.1 Selbstverständnis von Führungskräften
7.5.3 CDE: Containers, Differences, Exchanges
7.6 Vertragsgestaltung für agile Entwicklung
7.6.2 Werkvertrag und Festpreis vs. Dienstvertrag und Bezahlung nach Aufwand
7.6.3 Flexibilität des Vertragswerks
7.6.4 Kosten- vs. nutzenorientierte Verträge
7.6.5 Vorgehen wichtiger als Ergebnisse
7.7 Das Kapitel in Stichpunkten
A Überblick über die Verantwortungen, Meetings und Artefakte in Scrum
A.1.2 Teamübergreifende Organisationsebene
A.1.3 Anforderungsebene und Product Owner unterstützen
A.2.2 Zusammenarbeit mit dem Team
A.2.3 Kund:innen/Anwender:innen
A.2.4 Management sonstiger Stakeholder
A.3 Aufgaben der Entwickler:innen
