UID:
kobvindex_ERBEBC5621369
Format:
1 online resource (166 pages)
ISBN:
9783960886846
Note:
Mit dem Nexus™-Framework Scrum skalieren -- Geleitwort -- Vorwort -- Wer sollte dieses Buch lesen? -- Wie dieses Buch aufgebaut ist -- Danksagungen -- Inhaltsübersicht -- Inhaltsverzeichnis -- 1 Einführung in agile Skalierung -- 1.1 Warum agil? -- 1.2 Warum Scrum? -- 1.2.1 Was ist ein Produkt? -- 1.2.2 Was ist Scrum? -- Abb. 1-1 Das Scrum-Framework -- 1.3 Warum Nexus? -- 1.4 Einfachheit ist der Schlüssel zur Skalierung -- 2 Einführung in Nexus -- 2.1 Was ist Nexus? -- Abb. 2-1 Das Nexus-Framework zur Skalierung von Scrum (Nexus™ Framework © Scrum.org) -- 2.2 Nexus erweitert Scrum -- Tab. 2-1 Rollen, Ereignisse und Artefakte in Nexus (Scrum.org) -- 2.3 Das Nexus-Integrationsteam -- Abb. 2-2 Das NIT ist für die Maximierung des Werts des integrierten Produkts verantwortlich. (Scrum.org) -- Abb. 2-3 Mitglieder des NIT kommen in der Regel aus Scrum-Teams. (Scrum.org) -- 2.4 Nexus-Ereignisse -- 2.4.1 Refinement -- 2.4.2 Nexus Sprint Planning -- Abb. 2-4 Nexus Sprint Planning (Scrum.org) -- 2.4.3 Das Nexus Daily Scrum -- 2.4.4 Das Nexus-Sprint-Review -- 2.4.5 Die Nexus-Sprint-Retrospektive -- 2.4.6 Fragen, die in jeder Nexus-Sprint-Retrospektive gestellt werden sollen -- 2.5 Nexus-Artefakte -- 2.5.1 Product Backlog -- 2.5.2 Nexus-Ziel -- 2.5.3 Nexus Sprint Backlog -- 2.5.4 Integriertes Inkrement -- 2.5.5 Transparenz der Artefakte -- 2.5.6 »Definition of Done« im Nexus-Framework -- 2.6 Was brauchen Sie, um mit Nexus zu beginnen? -- 2.7 Fazit -- 3 Einen Nexus aufsetzen -- Abb. 3-1 Die Vereinbarkeit von Teamstruktur, Produktarchitektur und Arbeitsaufbau hilft Unternehmen, teamübergreifende Abhängigkeiten zu reduzieren oder zu vermeiden. -- 3.1 Entwicklung eines cross-funktionalen Teams -- 3.1.1 Praxis: Öffnen der Codebasis -- 3.1.2 Praxis: Teams rund um Teile des Geschäftswerts bilden -- 3.1.3 Praxis: Selbstorganisierte Teams bilden
,
3.2 Einen Nexus wachsen lassen -- 3.2.1 Klein anfangen und dann wachsen -- 3.2.2 Aufbau von Scrum-Teams mit Pairing und »Praktikum« -- Abb. 3-2 Neue Teammitglieder werden zu bestehenden Teams hinzugefügt, um die Teamkultur und -werte kennenzulernen. Wenn die Teams eine bestimmte Größe erreicht haben, teilen sie sich in separate Teams auf, die dann weiterwachsen können. -- 3.2.3 Warum nur drei bis neun Scrum-Teams in einer Nexus-Implementierung? -- 3.3 Bildung des Nexus-Integrationsteams (NIT) -- Abb. 3-3 Das NIT setzt sich aus Mitgliedern des Scrum-Teams und dem Product Owner zusammen. (Scrum.org) -- 3.3.1 Wer ist im Nexus-Integrationsteam? -- 3.4 Wie funktioniert Nexus? -- 4 Planen in Nexus -- 4.1 Konsolidierung und Validierung des Product Backlogs -- Abb. 4-1 Eine Impact Map, die den Zusammenhang zwischen Zielen und Ergebnissen aufzeigt. -- 4.1.1 Refinement des Product Backlogs -- Abb. 4-2 Das initiale Product Backlog vor dem Refinement, das die Abhängigkeiten des Teams zeigt. -- 4.1.2 Teamübergreifendes Product Backlog Refinement -- Abb. 4-3 Verfeinertes und geordnetes Product Backlog -- 4.1.3 Abhängigkeiten von Product-Backlog-Elementen -- 4.1.4 Optionale Praxis: Mit Story Mapping Fähigkeiten und Abhängigkeiten verstehen -- Abb. 4-4 Mit Story Maps können Teams besser verstehen, wie ein Produkt im Laufe der Zeit die Benutzeranforderungen erfüllt. Story Maps helfen den Teams außerdem, die Geschichte des Produkts zu erzählen und vorausschauend zu planen. -- 4.1.5 Optionale Praxis: Verwendung eines teamübergreifenden Refinement Board zum Verständnis von Abhängigkeiten -- Abb. 4-5 Visualisierung von Abhängigkeiten mit einem teamübergreifenden Refinement Board (Scrum.org) -- 4.2 Planung eines Sprints in Nexus -- Abb. 4-6 Sprint-Planung im Nexus auf einen Blick (Scrum.org) -- 4.2.1 Festlegung des Nexus-Ziels
,
4.2.2 Schätzung und Dimensionierung von Product-Backlog-Elementen -- Abb. 4-7 Relative Größenbestimmung hilft Teams, ihre Kapazität zur Fertigstellung von PBIs zu messen. -- 4.2.3 Optionale Praxis: Verbindung zwischen Product-Backlog-Elementen und Wertbeitrag -- Abb. 4-8 Die Verknüpfung von PBIs mit Ergebnissen und Messungen hilft Lücken aufzudecken. -- 4.2.4 Aufbau des Nexus Sprint Backlog und der Scrum-Team-Backlogs -- Abb. 4-9 Nexus nutzt den Nexus Sprint Backlog, um den Arbeitsfluss zu managen. (Scrum.org) -- Wie lange dauert das Sprint Planning? -- 4.3 Fazit -- 5 Einen Nexus Sprint durchführen -- Abb. 5-1 Nexus ist immer noch Scrum, es passt nur ein paar der Ereignisse an. -- 5.1 Das Nexus Daily Scrum -- 5.2 Transparenz innerhalb und außerhalb des Nexus schaffen -- 5.2.1 Optionale Praxis: Product Backlog Treemap -- Abb. 5-2 Die Product Backlog Treemap, wie sie in Sprint 3 aussehen könnte, zeigt die relative Größe und Vollständigkeit der Product-Backlog-Elemente an. -- 5.2.2 Optionale Praxis: Visualisierung von Product Backlog Burndown und Umsetzungsgeschwindigkeit -- Abb. 5-3 Ein Burndown-Velocity-Diagramm, das die verbleibende Arbeit (Burndown) und die abgeschlossene Arbeit (Velocity) zeigt. -- Wie viel Planungssicherheit ist ausreichend? -- Abb. 5-4 Teams müssen weniger weit vorausplanen, wenn sie Vertrauen erworben haben und eine nachweisbare Erfolgsbilanz vorweisen können. -- 5.2.3 Das Nexus-Sprint-Review -- 5.2.4 Optionale Praxis: Verwendung des Expo-Formats für Nexus-Sprint-Reviews -- 5.2.5 Optionale Praxis: Verwendung von Offline-Review-Techniken für Nexus-Sprint-Reviews -- 5.3 Die Nexus-Sprint-Retrospektive -- Abb. 5-5 Der Prozess der Nexus-Retrospektive (Scrum.org) -- Abb. 5-6 Ein einfaches Sprint-Retrospektiven-Board -- Abb. 5-7 Ein Sprint-Retrospektiven-Board mit Demingkreis-ähnlichen Spalten -- 5.4 Fazit -- 6 Nexus weiterentwickeln
,
Warum Komponententeams zum Problem werden können -- Entwicklungsteams in Scrum bestehen aus mehr als »Entwicklern« -- 6.1 Optionale Praxis: Scrum-Teams um Features herum organisieren -- 6.2 Optionale Praxis: Code wie in einem Open-Source-Projekt verwalten -- Abb. 6-1 Feature-Teams sind für die End-to-End-Bereitstellung von Produktfeatures oder -eigenschaften verantwortlich. -- 6.3 Optionale Praxis: Teams um Personas herum organisieren -- Abb. 6-2 Die Bildung von Teams um Personas herum kann die Verbindung eines Teams zu seinen Kunden verbessern. -- 6.4 Erweiterung des Nexus-Integrationsteams -- 6.5 Aktualisierung und Verfeinerung des Product Backlogs -- Abb. 6-3 Aktualisiertes Product Backlog mit PBI-Zielen für den aktuellen Sprint in schwarzem Text -- 6.6 Nexus Sprint Planning, Teil zwei -- 6.7 Das Nexus Daily Scrum, Teil zwei -- 6.8 Das Nexus-Sprint-Review, Teil zwei -- 6.9 Die Nexus-Sprint-Retrospektive, Teil zwei -- Abb. 6-4 Teamentwicklung durchläuft vorhersehbare Phasen. -- 6.9.1 Zu viel Arbeit, nicht genug Fortschritt -- 6.9.2 Wachsende technische Schulden -- 6.9.3 Nicht verfügbarer Product Owner -- 6.9.4 Unzureichende Build- und Testautomatisierung -- 6.9.5 Einen Plan zur Verbesserung erstellen -- 6.9.6 Die Herausforderungen bei der Skalierung von Scrum -- Abb. 6-5 Reibungskräfte bei der Skalierung können dazu führen, dass gewünschte und tatsächliche Ergebnisse voneinander abweichen. -- 6.10 Fazit -- 7 Nexus im Notfallmodus -- Abb. 7-1 Geografisch verteilte Teams schaffen neue Herausforderungen für die Zusammenarbeit. -- 7.1 Product Backlog Refinement, Teil drei -- Abb. 7-2 Product Backlog, verfeinert durch Refactoring der mobilen Anwendung und Integration mit dem Sicherheitsdienstleister -- Abb. 7-3 Visualisierung von Abhängigkeiten mit einem teamübergreifenden Refinement Board -- 7.2 Das Nexus Sprint Planning, Teil drei
,
7.2.1 Gestaltung und Moderation von weit verteilten Sprint-Planning- Terminen -- 7.2.2 Nexus mit gemischter Hardware-/Softwareentwicklung -- 7.2.3 Zusammenarbeit von Teams mit verschiedenen Sprint-Längen -- Abb. 7-4 Teams können mit verschiedenen Sprint-Längen arbeiten, solange die Sprint-Grenzen übereinstimmen. -- 7.2.4 Mischen von Scrum- und Wasserfall-Ansätzen in Nexus -- 7.3 Das Nexus Daily Scrum, Teil drei -- 7.3.1 Das Nexus Daily Scrum mit verteilten Teams -- 7.4 Was tun, wenn jeder im Nexus mit Schwierigkeiten zu kämpfen hat? -- Verantwortlichkeit des NIT -- 7.4.1 Das Nexus-Integrationsteam im Notfallmodus -- 7.4.2 Rückskalierung -- 7.4.3 Mit einem Gesundheitscheck die Gefühlslage des Teams erkennen -- Abb. 7-5 Ergebnisse des Gesundheitschecks, zusammengefasst nach Teams -- 7.4.4 Scrumbling -- 7.5 Das Nexus-(Pseudo-)Sprint-Review und die Retrospektive -- Abb. 7-6 Ergebnisse des Gesundheitschecks nach dem Scrumbling, zusammengefasst nach Teams -- 7.6 Fazit -- 8 Retrospektive zur Nexus-Reise -- 8.1 Was gut funktioniert hat -- 8.1.1 Das Nexus Daily Scrum -- 8.1.2 Das Nexus-Integrationsteam (NIT) -- 8.1.3 Releasehäufigkeit -- 8.1.4 Produktivität -- 8.1.5 Selbstorganisation -- 8.2 Bereiche für Verbesserungen -- 8.2.1 Umgang mit technischen Schulden -- 8.2.2 Skalierung der Product-Owner-Rolle -- 8.2.3 Entwicklung persönlicher Fähigkeiten -- 8.2.4 Transparenz und Vertrauen -- Abb. 8-1 Scrum-Werte (Scrum.org) -- Scrum-Werte -- Tab. 8-1 Die fünf Scrum-Werte -- 8.3 Wie geht's weiter? -- 8.4 Fazit -- Wo Sie mehr erfahren können -- Anhang -- Glossar -- A -- B -- C -- D -- E -- F -- I -- K -- N -- P -- R -- S -- T -- U -- Z -- Index
Additional Edition:
Print version: Bittner, Kurt Mit dem Nexus™ Framework Scrum skalieren Heidelberg : dpunkt.verlag,c2018 ISBN 9783864905766
Keywords:
Electronic books.
URL:
https://ebookcentral.proquest.com/lib/th-brandenburg/detail.action?docID=5621369
Bookmarklink
