Scrum - verstehen und erfolgreich einsetzen

Long description: Das ultimative Scrum-Handbuch didaktisch sehr gut aufgebautes Grundlagenbuch mit Empfehlungen der Autoren aus der Praxis für die Praxis geeignet auch für Scrum-Zertifizierungskurse: Scrum Basics, Certified Scrum Master Scrum dient dem agilen Management innovativer Pro...

Descripción completa

Detalles Bibliográficos
Autor principal:	Wolf, Henning (-)
Otros Autores:	Roock, Stefan
Formato:	Libro electrónico
Idioma:	Alemán
Publicado:	Heidelberg : dpunkt.verlag 2021.
Edición:	3rd ed
Materias:	Change Management Produktentwicklung Projektmanagement Leadership Produktmanagement Softwareentwicklung Teamführung Product Owner Scrum Agiles Projektmanagement Agile Methoden Scrum Master Agiles Management selbstorganisierte Teams Entwicklungsteam innovative Produktentwicklung Scrum Basics Certified Scrum Master Przessverbesserung
Ver en Biblioteca Universitat Ramon Llull:	https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009631628706719

Tabla de Contenidos:

Intro
Vorwort
Zielgruppe dieses Buches
Ü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
Überblick über das Buch
Lesewege
Inhaltsü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 lö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 Kü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 Höhere Qualität
1.2.3 Größere Effizienz
1.2.4 Mehr Innovation
1.2.5 Größere Arbeitszufriedenheit
1.3 Eignung
Abb. 1-7 Geschäftssystem vs. Innovationssystem
Abb. 1-8 Stacey Landscape Diagram
1.4 Herausforderung: Denkweise (Mindset)
1.5 Das Kapitel in Stichpunkten
2 Überblick ü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 &amp
Adapt (auch: empirisches Management)
2.6.3 Timeboxing
2.6.4 Return on Investment (ROI)
2.6.5 Qualitä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 enthält Teile der Oberfläche, Logik und Datenhaltung.
Abb. 3-2 Jedes Produktinkrement enthält seine Vorgä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 lö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 Lösung des Problems der Kund:innen: Hindernis beseitigen oder umgehen
3.4.2 Probleme/Bedürfnisse identifizieren
3.4.3 Produktvision kommunizieren: Storytelling
3.4.4 Weitere Hilfsmittel fü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 müssen sich mit den Bedürfnissen der Kund:innen, Businessmodellen und Technologien auskennen.
3.5.2 Bevollmä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 gemäß der Priorisierung detailliert.
3.6.3 Größ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 Überfü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 Verzögerungskosten (Cost of Delay)
Abb. 3-17 Konstante Verzögerungskosten
Abb. 3-18 Verzögerungskosten mit Stichtag
Abb. 3-19 A, B ist günstiger als B, A.
3.9.4 Wert bzw. Verzögerungskosten ermitteln
3.9.5 Technische Product Backlog Items mit Verzögerungskosten priorisieren
3.10 Epics und User Stories
Abb. 3-20 User Stories vs. Spezifikationen
3.10.1 Satzschema fü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 benötigt Transparenz, Inspektion und Adaption.
3.13.1 Sprint Planning und Sprint-Review
Abb. 3-27 Mö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 Zusätzliche und alternative Praktiken im Sprint-Review
Tab. 3-1 Zusä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 Möglichkeiten zur Durchfü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 Regelmäßige Refinement-Meetings
Abb. 3-34 Regelmäßige Refinement-Meetings
3.16.6 Refinement-Optionen im Vergleich
Tab. 3-2 Möglichkeiten für Backlog Refinement
3.17 Das Kapitel in Stichpunkten
4 Entwicklung mit Scrum
4.1 Entwickler:innen (Cross-Funktionalität, Autonomie, Selbstorganisation)
4.1.1 Cross-Funktionalität.
Was tun, wenn es für jemanden im Team nichts zu tun gibt, weil er für keine der noch anstehenden Aufgaben qualifiziert ist?
Abb. 4-1 T-Shaped-Qualifikationsprofile
Was tun, wenn wir von einer besonders intensiv und häufig benötigten Qualifikation zu wenig haben und deswegen alle anderen nicht genug zu tun haben (während einer ü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 Codeänderungen
Abb. 4-4 Kosten durch Technologie auf Vorrat
Abb. 4-5 Gesamtkosten
Abb. 4-6 Agile Entwicklungspraktiken verschieben die Kurve »Kosten durch Codeänderungen« nach unten.
4.5 Sprint Planning: das »Wie«
4.5.1 Aufwandsschätzung
4.5.2 Story Points als Größenmaß
Abb. 4-7 Nicht linearer Wertebereich für Story Points
Abb. 4-8 Fibonacci-Folge fü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 zusä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.

Scrum - verstehen und erfolgreich einsetzen

Ejemplares similares