UID:
kobvindex_ERBEBC6947439
Format:
1 online resource (482 pages)
Edition:
1
ISBN:
9783826684739
Note:
Cover -- Titel -- Impressum -- Inhaltsverzeichnis -- Vorwort von Mike Cohn -- Vorwort von Ron Jeffries -- Einleitung -- Danksagungen -- Über den Autor -- Kapitel 1: Einführung -- 1.1 Was ist Scrum? -- 1.2 Die Ursprünge von Scrum -- 1.3 Wieso Scrum? -- 1.4 Ergebnisse bei Genomica -- 1.5 Kann Scrum Ihnen helfen? -- 1.5.1 Die Complex-Domäne -- 1.5.2 Die Complicated-Domäne -- 1.5.3 Die Simple-Domäne -- 1.5.4 Die Chaotic-Domäne -- 1.5.5 Disorder (Nicht-Wissen, Regellosigkeit) -- 1.5.6 Unterbrechungsgesteuerte Arbeit -- 1.6 Abschließende Bemerkungen -- Teil I: Kernkonzepte -- Kapitel 2: Das Scrum-Framework -- 2.1 Überblick -- 2.2 Scrum-Rollen -- 2.2.1 Product Owner -- 2.2.2 ScrumMaster -- 2.2.3 Das Entwicklungsteam -- 2.3 Scrum-Aktivitäten und Artefakte -- 2.3.1 Product Backlog -- 2.3.2 Sprints -- 2.3.3 Sprint-Planung -- 2.3.4 Sprint-Ausführung -- 2.3.5 Daily Scrum -- 2.3.6 Fertig (Done) -- 2.3.7 Sprint Review -- 2.3.8 Sprint-Retrospektive -- 2.4 Abschließende Bemerkungen -- Kapitel 3: Agile Prinzipien -- 3.1 Überblick -- 3.2 Veränderlichkeit und Unsicherheit -- 3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen -- 3.2.2 Iterative und inkrementelle Entwicklung nutzen -- 3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz -- 3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit -- 3.3 Vorhersage und Anpassung -- 3.3.1 Optionen offen halten -- 3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann -- 3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen -- 3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen -- 3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen -- 3.4 Validiertes Wissen -- 3.4.1 Schnelles Validieren wichtiger Annahmen -- 3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen
,
3.4.3 Organisieren des Workflows für schnelle Feedbacks -- 3.5 Work in Process (WIP) -- 3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen -- 3.5.2 Lagerbestände erkennen und sinnvoll verwalten -- 3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter -- 3.5.4 Verzögerungskosten betrachten -- 3.6 Fortschritt -- 3.6.1 An Echtzeitinformationen anpassen und umplanen -- 3.6.2 Fortschritt messen, indem man funktionierende Güter validiert -- 3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren -- 3.7 Leistung -- 3.7.1 Gehe schnell, aber hetze nicht -- 3.7.2 Baue Qualität ein -- 3.7.3 Mache alles ohne großes Zeremoniell -- 3.8 Abschließende Bemerkungen -- Kapitel 4: Sprints -- 4.1 Überblick -- 4.2 Timeboxing -- 4.2.1 Legt ein WIP-Limit fest -- 4.2.2 Erzwingt eine Priorisierung -- 4.2.3 Demonstriert Fortschritt -- 4.2.4 Verhindert unnötigen Perfektionismus -- 4.2.5 Motiviert die Fertigstellung -- 4.2.6 Verbessert die Vorhersagbarkeit -- 4.3 Kurze Zeitdauer -- 4.3.1 Erleichterte Planung -- 4.3.2 Schnelles Feedback -- 4.3.3 Verbesserter Return on Investment -- 4.3.4 Begrenzte Fehler -- 4.3.5 Wiedererweckte Begeisterung -- 4.3.6 Häufige Checkpoints -- 4.4 Konsistente Dauer -- 4.4.1 Vorteile der Kadenz -- 4.4.2 Vereinfacht die Planung -- 4.5 Keine das Ziel beeinflussenden Änderungen -- 4.5.1 Was ist ein Sprint-Ziel? -- 4.5.2 Gegenseitige Verpflichtung -- 4.5.3 Änderungen versus Klärung -- 4.5.4 Konsequenzen einer Änderung -- 4.5.5 Pragmatisch sein -- 4.5.6 Abnormaler Abbruch -- 4.6 Definition von Fertig (Done) -- 4.6.1 Wie lautet die Definition von Fertig? -- 4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln -- 4.6.3 Definition von Fertig versus Akzeptanzkriterien -- 4.6.4 Fertig versus Fertig-Fertig -- 4.7 Abschließende Bemerkungen -- Kapitel 5: Anforderungen und User Stories -- 5.1 Überblick -- 5.2 Gespräche
,
5.3 Progressive Verfeinerung -- 5.4 Was sind User Stories? -- 5.4.1 Card (Karte) -- 5.4.2 Conversation (Gespräch) -- 5.4.3 Confirmation (Bestätigung) -- 5.5 Der Detaillierungsgrad -- 5.6 In gute Stories INVESTieren -- 5.6.1 Independent (unabhängig) -- 5.6.2 Negotiable (verhandelbar) -- 5.6.3 Valuable (werthaltig) -- 5.6.4 Estimatable (schätzbar) -- 5.6.5 Passende Größe (klein) -- 5.6.6 Testable (prüfbar) -- 5.7 Nichtfunktionale Anforderungen -- 5.8 Stories zum Wissenserwerb -- 5.9 Stories sammeln -- 5.9.1 Workshop zum Schreiben von User Stories -- 5.9.2 Story Mapping -- 5.10 Abschließende Bemerkungen -- Kapitel 6: Das Product Backlog -- 6.1 Überblick -- 6.2 Product-Backlog-Elemente -- 6.3 Merkmale guter Product Backlogs -- 6.3.1 Detailed appropriately (ausreichend detailliert) -- 6.3.2 Emergent -- 6.3.3 Estimated (geschätzt) -- 6.3.4 Prioritized (priorisiert) -- 6.4 Pflege -- 6.4.1 Was bedeutet Pflege? -- 6.4.2 Wer führt die Pflege durch? -- 6.4.3 Wann findet die Pflege statt? -- 6.5 Die Definition von Bereit -- 6.6 Flow Management -- 6.6.1 Release Flow Management -- 6.6.2 Sprint Flow Management -- 6.7 Welche und wie viele Product Backlogs? -- 6.7.1 Was ist ein Produkt? -- 6.7.2 Große Produkte - hierarchische Backlogs -- 6.7.3 Mehrere Teams - ein Product Backlog -- 6.7.4 Ein Team - mehrere Produkte -- 6.8 Abschließende Bemerkungen -- Kapitel 7: Schätzung und Velocity -- 7.1 Überblick -- 7.2 Was und wann wir schätzen -- 7.2.1 Schätzungen für Portfolio-Backlog-Elemente -- 7.2.2 Product-Backlog-Schätzungen -- 7.2.3 Aufgabenschätzungen -- 7.3 Schätzkonzepte für Product-Backlog-Elemente -- 7.3.1 Als Team schätzen -- 7.3.2 Schätzungen sind keine Verpflichtungen -- 7.3.3 Exaktheit versus Präzision -- 7.3.4 Relative Größenschätzung -- 7.4 Schätzeinheiten für Product-Backlog-Elemente -- 7.4.1 Story-Punkte -- 7.4.2 Idealtage -- 7.5 Planungspoker
,
7.5.1 Schätzskala -- 7.5.2 Wie man spielt -- 7.5.3 Vorteile -- 7.6 Was ist Velocity? -- 7.7 Einen Velocity-Bereich berechnen -- 7.8 Die Velocity vorhersagen -- 7.9 Die Velocity beeinflussen -- 7.10 Missbrauch der Velocity -- 7.11 Abschließende Bemerkungen -- Kapitel 8: Technische Schulden -- 8.1 Überblick -- 8.2 Die Folgen technischer Schulden -- 8.2.1 Unvorhersehbarer Wendepunkt -- 8.2.2 Zunehmend verzögerte Auslieferung -- 8.2.3 Beträchtliche Anzahl an Defekten -- 8.2.4 Steigende Entwicklungs- und Support-Kosten -- 8.2.5 Das Produkt verkümmert -- 8.2.6 Schwindende Vorhersehbarkeit -- 8.2.7 Leistungseinbruch -- 8.2.8 Allgemeiner Frust -- 8.2.9 Sinkende Kundenzufriedenheit -- 8.3 Ursachen der technischen Schulden -- 8.3.1 Druck hinsichtlich des Erreichens einer Deadline -- 8.3.2 Erfolglose Versuche der Velocity-Beschleunigung -- 8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen -- 8.3.4 Schulden bauen auf Schulden auf -- 8.4 Technische Schulden müssen organisiert werden -- 8.5 Die Zunahme technischer Schulden überwachen -- 8.5.1 Bewährte technische Praktiken anwenden -- 8.5.2 Eine starke Definition von Fertig benutzen -- 8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen -- 8.6 Technische Schulden sichtbar machen -- 8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen -- 8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen -- 8.7 Technische Schulden abbauen -- 8.7.1 Nicht alle technischen Schulden sollten abgebaut werden -- 8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen) -- 8.7.3 Bauen Sie technische Schulden schrittweise ab -- 8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab -- 8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt -- 8.8 Abschließende Bemerkungen
,
Teil II: Rollen -- Kapitel 9: Der Product Owner -- 9.1 Überblick -- 9.2 Hauptaufgaben -- 9.2.1 Organisation der wirtschaftlichen Belange -- 9.2.2 Mitwirkung an der Planung -- 9.2.3 Pflege des Product Backlogs -- 9.2.4 Definition und Verifikation der Akzeptanzkriterien -- 9.2.5 Zusammenarbeit mit dem Entwicklungsteam -- 9.2.6 Zusammenarbeit mit den Stakeholdern -- 9.3 Eigenschaften/Fähigkeiten -- 9.3.1 Fachwissen -- 9.3.2 Soziale Kompetenz -- 9.3.3 Entscheidungsfindung -- 9.3.4 Verantwortung -- 9.4 Der Alltag eines Product Owners -- 9.5 Wer sollte Product Owner sein? -- 9.5.1 Interne Entwicklung -- 9.5.2 Gewerbliche Entwicklung -- 9.5.3 Ausgelagerte Entwicklung -- 9.5.4 Komponentenentwicklung -- 9.6 Product Owner kombiniert mit anderen Rollen -- 9.7 Das Product-Owner-Team -- 9.7.1 Product-Owner-Stellvertreter -- 9.7.2 Chief Product Owner -- 9.8 Abschließende Bemerkungen -- Kapitel 10: ScrumMaster -- 10.1 Überblick -- 10.2 Wichtigste Aufgaben -- 10.2.1 Coach -- 10.2.2 »Dienende Führungskraft« -- 10.2.3 Prozessautorität -- 10.2.4 Schutz vor störenden Einflüssen -- 10.2.5 Beseitigung von Hindernissen -- 10.2.6 Berater in der Organisationsentwicklung -- 10.3 Eigenschaften/Fähigkeiten -- 10.3.1 Sachkundig -- 10.3.2 Neugierig -- 10.3.3 Geduldig -- 10.3.4 Teamfähig -- 10.3.5 Schützend -- 10.3.6 Transparent -- 10.4 Alltag -- 10.5 Die Rolle ausfüllen -- 10.5.1 Wer sollte ScrumMaster sein? -- 10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung? -- 10.5.3 ScrumMaster in Kombination mit anderen Rollen -- 10.6 Abschließende Bemerkungen -- Kapitel 11: Das Entwicklungsteam -- 11.1 Überblick -- 11.2 Rollenspezifische Teams -- 11.3 Wichtigste Aufgaben -- 11.3.1 Durchführung des Sprints -- 11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«) -- 11.3.3 Pflege des Product Backlogs -- 11.3.4 Den Sprint planen
,
11.3.5 Produkt und Prozess untersuchen und anpassen
Additional Edition:
Print version: Rubin, Kenneth S. Essential Scrum Frechen : mitp,c2014
Keywords:
Electronic books.
URL:
https://ebookcentral.proquest.com/lib/th-brandenburg/detail.action?docID=6947439
Bookmarklink
