SAFe - Das Scaled Agile Framework Lean und Agile in grossen Unternehmen skalieren
Das Scaled Agile Framework (SAFe) ist ein offenes Framework, um Lean- und agile Methoden unternehmensweit in großen Organisationen umzusetzen.Der Autor gibt einen praxisorientierten Überblick über Struktur, Rollen, Schlüsselwerte und Prinzipien von SAFe und führt den Leser im Detail durch die Ebenen...
| Otros Autores: | , |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Alemán |
| Publicado: |
Heidelberg, Germany :
dpunkt.verlag
2018.
|
| Edición: | 2., überarbeitete und aktualisierte Auflage |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009629869406719 |
Tabla de Contenidos:
- Intro
- Vorwort zur 2. Auflage
- Was will dieses Buch
- Die wichtigsten Änderungen für SAFe 4.5
- Neue Liefer- oder Delivery Pipeline
- Integration von Lean-Startup-Strategien
- Scalable DevOps als Kultur-, Organisations- und technische Aufgabe
- Die Einführungsstrategie ist konkreter geworden
- Viele kleine Änderungen
- Danksagung
- Viel Erfolg beim Umsetzen
- Geleitwort
- 1
- Inhaltsübersicht
- Inhaltsverzeichnis
- 1 Einleitung
- 1.1 Was macht Agilität erfolgreich
- 1.2 Warum skalieren
- Muss man wirklich skalieren?
- Teamgrößen
- Die Dunbar-Zahl
- 1.3 Die neuen Herausforderungen an Agilität
- Große Vorhaben unterstützen
- Der ganze Wertstrom
- Die ganze Organisation und Hierarchie
- Große und etablierte Entwicklungen
- Der Zyklus von Produkt und Markt
- Kultur oder wie Agile aus dem Radarschatten kam
- 2 Überblick über SAFe
- SAFe basiert auf Lean und Agile
- Alignment, Zusammenarbeit, Lieferung
- SAFe ist ein definierter Startpunkt für eine agile und Lean-Transformation
- SAFe skaliert für große Organisationen
- 2.1 Woher kommt SAFe
- 2.2 Die Struktur von SAFe
- Das Gesamtbild (Big Picture)
- 2.2.1 Teamebene
- 2.2.2 Programmebene (Agile Release Train)
- Das Programminkrement
- Arbeiten im Takt - Liefern auf Nachfrage
- Wertströme
- Architectural Runway oder Landebahn
- 2.2.3 Solution-Ebene
- 2.2.4 Portfolioebene
- 2.3 Strukturierung von Anforderungen
- 2.4 Rollen
- 2.5 Schlüsselwerte
- Das Agile Manifest
- Codequalität
- Lieferzuverlässigkeit
- Alignment
- Transparenz
- 2.6 Agile Architektur und Software Engineering
- 2.7 Integrierte Qualitätskultur
- Qualität einbauen
- Fehler beheben, nicht verwalten
- Äußere und innere Softwarequalität
- 2.8 SAFe-Prinzipien für einen effektiven Entwicklungsfluss
- #1: Nimm einen ökonomischen Standpunkt ein
- #2: Denke in Systemen.
- #3: Erwarte Variabilität - bewahre Optionen
- #4: Entwickle inkrementell mit schnellen integrierten Lernzyklen
- #5: Lege Meilensteine basierend auf einer objektiven Bewertung laufender Systeme fest
- #6: Visualisiere und begrenze WIP-Limits, reduziere Losgrößen und manage die Länge von Warteschlangen
- #7: Nutze Kadenzen und synchronisiere über Bereichsgrenzen hinweg
- #8: Entwickle die intrinsische Motivation von Wissensarbeitern
- #9: Dezentralisiere Entscheidungsfindung
- 2.9 Leadership
- Führung kommt in den Fokus
- Führungsbild und Rolle der Führung
- 3 Agile Teams in SAFe
- 3.1 Zwei Wurzeln agiler Entwicklung
- 3.2 Vier Vorteile agiler Teams
- Vorhersagbare Entwicklung
- Schnelles Feedback und belastbare Fortschrittsberichte
- Mehr Spaß und Motivation in der Entwicklung
- Beschleunigtes Lernen
- 3.3 Beschleunigtes Lernen ist Team-Lernen
- Team-»Ba« als Voraussetzung
- Darum sind Teams so wichtig
- 3.4 Vier Vorteile agiler Softwaretechniken
- Technische Schulden beherrschen
- Stabilisierung des Prozesses und der Entwicklungsgeschwindigkeit
- Regelmäßige Lieferung in kleinen Inkrementen
- Valide Fortschrittskontrolle
- 3.5 Herausforderungen in skalierten Umgebungen
- Wertströme und Fluss
- Takt
- Content Ownership
- Selbstorganisation und Führung
- Abhängigkeiten und Übergaben zwischen Teams
- Liefern in kurzen Zyklen
- 3.6 Teams bei SAFe
- Cross-funktionale stabile Teams
- Feature-Teams
- Der Agile Release Train als Team von Teams
- Scrum/Kanban und XP als Grundlage
- Codequalität und Architektur
- Alignment - Unterschiede zu einzelnen Teams
- Transparenz
- Planung und Schätzung
- Teams im Kanban-Modus
- 4 Die Programmebene
- 4.1 Einführung
- Skalieren in verschiedenen Dimensionen
- Die Metapher des Agile Release Train
- 4.2 Der Agile Release Train
- 4.2.1 Arbeitsprinzipien.
- 4.2.2 ARTs sind multifunktional
- 4.2.3 Rollen
- 4.2.4 Release Trains aufsetzen
- Wertströme identifizieren und Trains etablieren
- Programminkrement: PI-Planung und Arbeitsweise festlegen
- 4.2.5 Arbeiten im Programminkrement
- PI-Planung
- Reporting
- Scrum of Scrums
- Inspect &
- Adapt
- 4.3 Das Programminkrement
- 4.3.1 Das PI als Super-Sprint
- 4.4 Entwickeln im Takt - liefern nach Bedarf
- 4.4.1 Entwickeln im Takt
- Man kann nicht auf Kosten der Qualität Zeit sparen
- Der Entwicklungsfluss in SAFe
- Die Lieferpipeline
- Synchronisation
- 4.4.2 Liefern nach Bedarf
- Releases und potenziell auslieferbare Software
- Häufigkeit von Releases
- Features tragen Kundennutzen
- Laufende Software: potenziell auslieferbares Inkrement
- Von potenziell auslieferbar bis zum Release
- Systemvalidierung
- Fertigstellen des Release
- 4.5 Artefakte des Release Train
- 4.5.1 Die Programmvision
- Inhalt
- Quellen der Vision
- Repräsentation der Vision
- 4.5.2 Die Roadmap
- 4.5.3 Das ART-Backlog
- Quellen und Inhalt
- Priorisierung
- Schätzen im ART-Backlog
- 4.5.4 Programm-Epics
- 4.5.5 Features
- Features und Nutzen
- Akzeptanzkriterien für Features
- Die »Top Ten«-Features in der PI-Planung
- 4.5.6 Enablers oder Architektur-Features
- 4.6 Planen für den Agile Release Train
- 4.6.1 Das ART-Backlog vorbereiten
- 4.6.2 Features aufsplitten
- 4.6.3 Features zwischen Teams aufteilen
- 4.6.4 Schätzen von Features
- 4.6.5 Kapazitäten allokieren
- 4.6.6 Die optimale Länge des Backlogs
- 4.7 Meetings
- 4.7.1 PI-Planung - Start des Programminkrements
- Vorbereitung des Meetings
- Das Meeting
- Tag 1
- Tag 2
- Ergebnisse
- PI-Planung und Sprint-Planung der Teams
- 4.7.2 Die zweiwöchentliche Systemdemo
- 4.7.3 Die ART-Demo
- 4.7.4 Das Inspect &
- Adapt-Meeting
- Demo der Lösung
- Quantitative Messungen.
- Der Problemlösungsworkshop
- 4.8 Architectural Runway - die Landebahn
- Die Landebahn-Metapher
- Eine Landebahn aufbauen
- Systemarchitektur ändert sich
- 4.9 Der Innovations- und Planungs-Sprint
- Inspect &
- Adapt- und PI-Planungsaktivitäten
- Schätzpuffer
- Weiterbildung und Teamentwicklung
- Arbeiten an der Entwicklungsinfrastruktur
- Innovation
- Validierung für das PI-Release
- Ein beispielhafter IP-Sprint-Kalender
- 4.10 Nicht funktionale Anforderungen
- NFRs auf jeder Ebene
- NFRs als Backlog-Eigenschaften
- 4.11 Priorisierung
- 4.11.1 Weighted Shortest Job First (WSJF)
- Kosten der Verzögerung
- Dauer
- Die Berechnung
- 4.12 DevOps
- DevOps muss Teil des Release Train sein
- Sechs Praktiken zur Lieferpipeline
- #1: Erstelle und pflege eine produktionsähnliche Staging-Umgebung
- #2: Pflege konsistente Entwicklungs- und Testumgebungen
- #3: Liefere jeden Sprint in die Staging-Umgebung - liefere oft in die Produktion
- #4: Alles unter Versionskontrolle stellen
- #5: Erstelle automatisiert neue Build-Umgebungen
- #6: Automatisiere den tatsächlichen Auslieferungsprozess
- 5 Rollen auf der Programmebene
- 5.1 Produktmanagement
- Unterschiede zum traditionellen Produktmanagement
- Verantwortlichkeiten des Produktmanagers
- 5.2 Releasemanagement
- Aufgaben des Releasemanagements
- 5.3 Der Release Train Engineer
- Der Release Train Engineer als Servant Leader
- 5.4 Der Systemarchitekt
- Aufgaben des Systemarchitekten
- 5.5 Übergreifende und geteilte Ressourcen
- 5.6 Benutzerschnittstellen-Verantwortlicher
- Aufgaben des UX-Verantwortlichen
- Wann ein separates UX-Team notwendig ist
- 5.7 Die Business Owner
- Aufgaben der Business Owner
- Wert der PI-Ziele festlegen
- 6 Der Solution Train
- 6.1 Die Solution-Ebene
- 6.2 Features und Capabilities
- 6.3 Solution Intent
- 6.4 Analogien zum ART.
- 6.5 Prinzipien eines Solution Train
- 6.6 Neue Rollen im Solution Train
- 6.7 Koordination von ARTs und Zulieferern
- Pre- und Post-Planungsmeetings
- Solution-Demo
- Einbinden von Lieferanten
- 6.8 Release Governance
- 7 Portfoliomanagement
- 7.1 Portfolios in einem Unternehmen
- Elemente eines SAFe-Portfolios
- Solutions identifizieren und Release Trains etablieren
- Rollen auf der Portfolioebene
- 7.2 Lean Portfolio Management - Lean Budgeting
- 7.3 Strategische Themen
- Wie entstehen strategische Themen?
- 7.4 Die Bearbeitung von Epics
- 7.4.1 Was ist ein Epic?
- Business-Epics und Enablers
- 7.4.2 Der Lean Business Case eines Epics
- Hypothesen-Statement für ein Epic
- Leichtgewichtiger Lean Business Case
- Praxis
- 7.4.3 Portfolio-Kanban
- 7.4.4 Ein prototypisches Kanban-System
- 7.4.5 Schrittweise Implementierung
- 7.4.6 Priorisierung im Portfolio-Backlog
- 7.4.7 Schätzen und Planen für das Portfolio
- 7.4.8 Weiterentwicklung von Epics im Portfolio-Kanban
- 7.5 Budgets
- 7.5.1 Das Problem mit klassischen Budgets
- 7.5.2 Budgeting durch Lean Portfolio Management
- #1: Finanziere Agile Release Trains, nicht Projekte
- #2: Stärke die Entscheidungskompetenz der Release Trains
- #3: Steuere Release Trains über dynamische Budgets
- #4: Halte eine Reserve für das Portfolio-Backlog
- 7.6 Wertströme
- 7.6.1 Den Wertstrom identifizieren
- Fragen zur Identifikation des Wertstroms
- Finde die »Niere«
- 7.6.2 Mehrere Release Trains organisieren
- 7.6.3 Koordination über mehrere Trains
- Integration
- 7.6.4 Andere Arten der Entkopplung
- 8 Portfolio-Rollen
- 8.1 Lean Portfolio Management
- Unterschiede zum klassischen Portfoliomanagement
- Strategie- und Investitionenfinanzierung
- Unterstützung des Programmmanagements
- Steuerung und Feedback
- 8.2 Epic Owner
- 8.2.1 Verantwortlichkeiten des Epic Owners.
- Epic zur Freigabe vorbereiten.
