SAFe-Tutorial (Scaled Agile Framework).

Was ist SAFe (Scaled Agile Framework)?

Skaliertes agiles Framework (SAFe) ist eine frei verfügbare Online-Wissensdatenbank, die es Ihnen ermöglicht, Lean-Agile-Praktiken auf Unternehmensebene anzuwenden. Es bietet eine einfache und leichte Erfahrung für die Softwareentwicklung. Dabei handelt es sich um eine Reihe von Organisationen und Workflow-Mustern, die Unternehmen bei der Skalierung schlanker und agiler Praktiken unterstützen sollen. Es ist in drei Segmente unterteilt: Team, Programm und Portfolio.

Sicher Das Framework ermöglicht es dem Team,

• Implementierung von Lean-Agile-Software und -Systemen auf Unternehmensebene
• Es basiert auf Lean- und Agile-Prinzipien.
• Es bietet detaillierte Anleitungen für die Arbeit im Unternehmensportfolio, im Wertstrom, im Programm und im Team.
• Es ist darauf ausgelegt, die Bedürfnisse aller Beteiligten innerhalb einer Organisation zu erfüllen.

SAFe wurde erstmals in diesem Bereich entwickelt und weiterentwickelt Dean Leffingwell's Bücher und Blog. Version 1.0 ist die erste offizielle Veröffentlichung im Jahr 2011. Die neueste Version ist 4.6 und wurde im Oktober 2018 veröffentlicht. Sie bietet Anleitungen für die Arbeit auf Unternehmensportfolio-, Wertstrom-, Programm- und Teamebene.

Warum das SAFe Agile Framework verwenden?

Es ist ein einfaches und leichtgewichtiges Framework, das dennoch die Anforderungen großer Wertströme und komplexer Systementwicklung erfüllen kann. Durch die Implementierung des agilen SAFe-Frameworks profitieren Sie von den folgenden Vorteilen:

• Produktivität gesteigert by 20 - 50%
• Qualität mehr als erhöht 50%
• Time to Market ist schneller als 30 -75%
• Vergrößerte Engagement der Mitarbeiter und Arbeitszufriedenheit.

Das detaillierte Rahmendiagramm finden Sie auf der Website . Es zeigt alle wichtigen Rollen, Aktivitäten, Leistungen und Abläufe. Es dient auch als Navigationshilfe für den Rest der Website.

Das folgende Bild erklärt, wie der agile Prozess funktioniert. Epen sind ein großes Werkwerk, das weiter in eine Reihe kleinerer Geschichten oder Unterepen unterteilt ist. Diese Unterepen werden dem Team als Story zugeordnet. Jedes Team arbeitet dann entsprechend an diesen Geschichten oder Softwarefunktionen.

Wann sollte das Scaled Agile Framework verwendet werden?

• Wenn ein Team daran interessiert ist, einen agilen Ansatz konsequent in größeren Programmen und Portfolios mit mehreren Teams umzusetzen.
• Wenn mehrere Teams ihren eigenen Weg der agilen Implementierung verfolgen, aber regelmäßig mit Hindernissen, Verzögerungen und Fehlern konfrontiert sind.
• Wenn Teams unabhängig arbeiten wollen.
• Wenn Sie Agile im gesamten Unternehmen skalieren möchten, sich aber nicht sicher sind, welche neuen Rollen möglicherweise erforderlich sind oder welche vorhandenen Rollen (z. B. das Management) wie geändert werden müssen.
• Wenn Sie versucht haben, Agile in Ihrem gesamten Unternehmen zu skalieren, aber Schwierigkeiten haben, eine einheitliche oder konsistente Strategie über alle Geschäftsabteilungen hinweg zu erreichen, von der Portfolio- bis zur Programm- und Teamebene.
• Wenn ein Unternehmen seine Produktentwicklungsvorlaufzeit verbessern muss und wissen möchte, wie es anderen Unternehmen gelungen ist, Agile mit SAFe zu skalieren.

Wie anders als andere agile Praktiken

In diesem Tutorial zum Scaled Agile Framework wollen wir nun sehen, wie sich das Scaled Agile Framework von anderen agilen Praktiken unterscheidet.

• Es ist öffentlich zugänglich und kostenlos nutzbar.
• Erhältlich in einer sehr zugänglichen und benutzerfreundlichen Form.
• Es ist leichtgewichtig, bietet praxiserprobte Ergebnisse und ist niveauspezifisch.
• Es modifiziert/pflegt ständig/regelmäßig die am häufigsten verwendeten agilen Praktiken.
• Bietet nützliche Erweiterungen für gängige agile Praktiken.
• Verankert agile Praktiken im Unternehmenskontext.
• Bietet ein vollständiges Bild der Softwareentwicklung.
• Sichtbarkeit bzw. Transparenz gibt es auf allen Ebenen mehr.
• Kontinuierliches oder regelmäßiges Feedback zu Qualität und Verbesserung.

Foundations des Scaled Agile Framework

Scaled Agile Framework (SAFe): Es basiert auf den Grundlagen seiner

1. Lean-Agile-Prinzipien
2. Grundwerte,
3. Lean-Agile Führung
4. Lean-Agile Denkweise,
5. Praxisgemeinschaften (Gruppe von Personen, die ständig an SAFe-Praktiken arbeiten)
6. Umsetzung von 1-2-3

SAFe Lean-Agile-Prinzipien

Diese grundlegenden SAFe-Agile-Prinzipien und -Werte für SAFe müssen verstanden, dargelegt und fortgeführt werden, um die gewünschten Ergebnisse zu erzielen.

• Betrachten Sie die Wirtschaftlichkeit
• Systemdenken anwenden
• Variabilität annehmen; Optionen beibehalten
• Bauen Sie schrittweise mit schnellen, integrierten Lernzyklen auf
• Basieren Sie Meilensteine ​​auf einer objektiven Bewertung funktionierender Systeme
• Visualisieren und begrenzen Sie den WIP, reduzieren Sie die Chargengröße und verwalten Sie die Länge der Warteschlangen
• Kadenz anwenden, mit domänenübergreifender Planung synchronisieren
• Fördern Sie die intrinsische Motivation von Wissensarbeitern
• Entscheidungsfindung dezentralisieren

SAFe Agile-Grundwerte

Die SAFe Agile-Methodik basiert auf diesen vier Werten.

Ausrichtung:

• SAFe unterstützt die Ausrichtung.
• Die Ausrichtung beginnt bei,
  • Strategische Themen im Portfolio-Backlog und
  • Geht nach unten zu Vision und Roadmap der Programmrückstände und dann
  • Wechselt zu den Team-Backlogs.

Integrierte Qualität:

• Es stellt sicher, dass jede inkrementelle Lieferung den Qualitätsstandards entspricht.
• Qualität wird nicht „nachträglich hinzugefügt“, sondern ist eingebaut.
• Eingebaute Qualität ist eine Voraussetzung und Pflicht von Lean

Transparenz:

• Transparenz ist der Wegbereiter für Vertrauen.
• SAFe hilft dem Unternehmen, Transparenz auf allen Ebenen zu erreichen – Führungskräfte, Portfoliomanager und andere Stakeholder.
• Jeder kann das Portfolio-Backlog/Kanban, das Programm-Backlog/Kanban und das Team-Backlog/Kanban einsehen.
• Jede Ebene hat ein klares Verständnis der PI-Ziele.
• Train-Programme haben Einblick in die Rückstände des Teams sowie in andere Programmrückstände
• Teams und Programme haben Einblick in Geschäfts- und Architektur-Epics. Sie können sehen, was auf sie zukommen könnte.

Programmausführung:

• SAFe legt großen Wert auf funktionierende Systeme und daraus resultierende Geschäftsergebnisse.
• SAFe ist nicht sinnvoll, wenn Teams nicht in der Lage sind, kontinuierlich Mehrwert zu liefern.

Lean-Agile-Führungskräfte

Die Lean-Agile-Führungskräfte sind lebenslange Lernende und Lehrer. Es hilft Teams, bessere Systeme aufzubauen, indem es die Lean-Agile SAFe-Prinzipien versteht und anwendet.

Als Enabler für die Teams liegt die oberste Verantwortung in der Akzeptanz, dem Erfolg und der kontinuierlichen Verbesserung von Lean-Agile-Entwicklungen. Für den Wandel und die kontinuierliche Verbesserung müssen Führungskräfte geschult werden.

Führungskräfte müssen sich einen neuen Führungsstil aneignen. Eines, das Einzelpersonen und Teams wirklich befähigt und motiviert, ihr höchstes Potenzial auszuschöpfen.

Prinzipien dieser Lean-Agile-Führungskräfte

• Führen Sie den Wandel an
• Den Weg kennen; Betonen Sie lebenslanges Lernen
• Menschen entwickeln
• Inspirieren und sich an der Mission ausrichten; Einschränkungen minimieren
• Entscheidungsfindung dezentralisieren
• Entdecken Sie die intrinsische Motivation von Wissensarbeitern

Lean-Agile-Denkweise

Die Lean-Agile-Denkweise wird durch zwei Dinge repräsentiert:

1. Das SAFe House of Lean
2. Agiles Manifest

Das SAFe House of Lean:

SAFe basiert auf den Prinzipien und Praktiken der Lean Manufacturing. Basierend auf diesen Faktoren präsentiert SAFe das „SAFe House of Lean“. Es ist vom „Haus“ des schlanken Toyota inspiriert.

Das Ziel von Lean ist unschlagbar: Den Kunden maximalen Kundennutzen in kürzester Vorlaufzeit mit höchstmöglicher Qualität zu liefern

Die folgende Abbildung erläutert das Ziel, die Säulen und Foundation von „SAFe House of Lean“.

Agiles Manifest

Wir entdecken bessere Wege der Entwicklungping Software, indem man es tut und hilftping Andere tun es auch. Durch diese Arbeit haben wir Folgendes schätzen gelernt:

Deshalb schätzen wir die Elemente auf der linken Seite höher ein, während die Elemente auf der rechten Seite einen Wert haben.

Agiles Manifest

1. Oberste Priorität hat die Zufriedenheit des Kunden durch kontinuierliche und frühzeitige Lieferung wertvoller Software.
2. Berücksichtigen Sie die sich ändernden Anforderungen, auch spät in der Entwicklung. Agile SAFe-Methodikprozesse nutzen Veränderungen zum Nutzen des Kunden.
3. Liefern Sie funktionsfähige Software häufig, von ein paar Wochen bis zu ein paar Monaten, wobei der kürzere Zeitraum bevorzugt wird.
4. Entwickler und Geschäftsleute müssen während des gesamten Projekts täglich zusammenarbeiten.
5. Bauen Sie Projekte rund um motivierte Personen auf. Geben Sie ihnen Unterstützung und das Umfeld, das sie brauchen, und vertrauen Sie ihnen, dass sie ihre Arbeit erledigen.
6. Die effizienteste Methode zur Kommunikation mit einem Entwicklungsteam ist ein persönliches Gespräch.
7. Funktionierende Software ist der wichtigste Maßstab für den Fortschritt.
8. Agile Prozesse fördern eine nachhaltige Entwicklung. Sponsoren, Entwickler und Anwender sollten in der Lage sein, ein konstantes Tempo dauerhaft aufrechtzuerhalten.
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design steigert die Agilität.
10. Einfachheit – die Kunst, die Menge der nicht erledigten Arbeit zu maximieren – ist von entscheidender Bedeutung.
11. Die besten Architekturen, Anforderungen und Designs entstehen aus sich selbst organisierenden Teams.
12. In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.

Verschiedene Stufen in SAFE

Es gibt zwei verschiedene Arten der SAFe-Implementierung:

1. SAFe 4.0-Implementierung
2. SAFe 3.0-Implementierung

• Bei der SAFe 4.0-Implementierung gibt es 4 Ebenen: Portfolio, Wertstrom, Programm und Team.
• Bei der SAFe 3.0-Implementierung gibt es 3 Ebenen: Portfolio, Programm und Team
• 3-Level SAFe eignet sich für kleinere Implementierungen mit 100 oder weniger Personen. Programme, die keine nennenswerte Zusammenarbeit erfordern.
• 4-Level SAFe ist für Lösungen gedacht, die typischerweise viele Hundert Praktiker für die Entwicklung, Bereitstellung und Wartung von Software erfordern.

Teamebene

Rollen/Teams	VERANSTALTUNGEN	Artifacts
Agiles Team	Sprint Planung	Team-Backlog
Produktinhaber	Rückstandspflege	Nicht-funktionale Anforderungen
Scrum Master	Tägliches Stand-up	Team PI Ziele
	Ausführung	Iterationen
	Sprint Demo	Geschichten (Funktionierende Software)
	Sprint Retrospektive	Sprint Ziele
	IP Sprints	Integrierte Qualität
		Spikes
		Team Kanban

• Alle SAFe-Teams sind Teil des einen oder anderen Agile Release Train (ART).
• SAFe-Teams sind befähigte, selbstorganisierende, selbstverwaltende, funktionsübergreifende Teams
• Jedes Team ist gleichermaßen dafür verantwortlich, Storys aus seinem Team-Backlog in Iterationen fester Länge zu definieren, zu erstellen und zu testen
• Die Teams planen und führen Iterationen mit einem Zeitrahmen von zwei Wochen gemäß den vereinbarten Iterationszielen aus.
• Die Teams nutzen die ScrumXP/Team-Kanban-Routine, um qualitativ hochwertige Systeme bereitzustellen und alle zwei Wochen eine Systemdemo zu erstellen.
• Alle verschiedenen Teams im ART (Agile Release Trains) werden ein integriertes und getestetes System erstellen. Die Stakeholder bewerten und reagieren mit schnellem Feedback
• Sie wenden integrierte Qualitätspraktiken an.
• Jedes ScrumXP-Team besteht aus 5–9 Teammitgliedern, was alle Rollen umfasst, die erforderlich sind, um in jeder Iteration einen qualitativ hochwertigen Mehrwert zu schaffen.
• Zu den ScrumXP-Rollen gehören:
  • Team (Entwicklung + Qualitätssicherung)
  • Scrum Master
  • Produktinhaber. Usw..
• SAFe unterteilt die Entwicklungszeitleiste in eine Reihe von Iterationen innerhalb eines PI (Programminkrement).
• Die PI-Dauer liegt zwischen 8 und 12 Wochen.
• Das Team wird Geschichten verwenden, um den Wert zu liefern. Der Product Owner hat die inhaltliche Autorität über die Erstellung und Akzeptanz der Geschichten.
• Geschichten enthalten die Anforderungen des Kunden.
• Team Backlog umfasst Benutzer- und Enabler-Stories, die während der PI-Planung identifiziert werden. Wenn das Produktmanagement die Roadmap, Vision und das Programm-Backlog vorlegt.
• Das Erkennen, Ausarbeiten, Priorisieren, Planen, Implementieren, Testen und Akzeptieren der Geschichten sind die Hauptanforderungen an die Managementarbeit auf Teamebene.
• Jede Iteration bietet:
  • Eine wertvolle Ergänzung neuer Funktionalität
  • Erreichen Sie dies durch sich ständig wiederholende Muster
  • Planen Sie die Iteration
  • Verpflichten Sie sich zu einigen Funktionen
  • Führen Sie die Iteration durch, indem Sie Stories erstellen und testen
  • Demo der neuen Funktionalität
  • Retrospektive
  • Wiederholen Sie dies für die nächste Iteration
• Teams unterstützen außerdem die Systemdemo am Ende jeder Iteration. Dies ist der kritische Integrationspunkt für ART.
• Größere Wertströme werden mehrere ARTs haben.
• Die Innovations- und Planungsiterationen (IP) bieten den Teams die Möglichkeit zur Innovation und Erkundung.

Programmebene

Rollen/Teams	VERANSTALTUNGEN	Artifacts
DevOps	PI-Planung (Programminkrementplanung)	Vision
Systemteam	Systemdemos	Roadmap
Release-Verwaltung	Workshop „Inspektion und Übernahme“	Metrik
Produktmanagement	Archistrukturelle Landebahn	Meilensteine
UEX Architect	Jederzeit veröffentlichen	Mitteilungen
Release Train Engineer (RTE)	Agile Release Train	Programm Epics
System Architekt/Ingenieur	Loslassen	Kanban-Programm
Unternehmer		Programmrückstand
Lean-Agile-Führungskräfte		Nicht-funktionale Anforderungen
Praxisgemeinschaften		Gewichteter kürzester Job zuerst (WSJF)
Geteilte Dienstleistungen		Programm-PI-Ziele
Durch den		Funktion
		Enabler
		Lösung
		Wertstromkoordination

• Auf Programmebene wird der Wert von SAFe durch langlebige Agile Release Trains (ART) bereitgestellt. Iteration ist für das Team und Training ist für das Programm.
• Agile Release Trains (ART) ist das wichtigste Mittel zur Wertschöpfung auf Programmebene. Es liefert einen Wertstrom für die Organisation.
• Die Dauer der Programmschritte (PIs) beträgt 8 bis 12 Wochen.
• ART besteht aus 5 – 12 agilen Teams (ca. 50 – 125+ Personen), die alle Rollen und Infrastruktur umfassen, die für die Bereitstellung vollständig getesteter, funktionierender Software auf Systemebene erforderlich sind.
• Jedes PI ist ein Zeitfenster mit mehreren Iterationen, in dem ein signifikanter, wertvoller Systemerweiterungsschritt entwickelt und bereitgestellt wird.
• In jedem PI finden eine „Demo“- und eine „Inspizieren und Anpassen“-Sitzung statt, und die Planung für das nächste PSI beginnt.
• Auf Programmebene legt SAFe Wert auf das Prinzip der Ausrichtung. Dies liegt daran, dass mehrere agile Teambemühungen integriert werden, um Kundennutzen zu schaffen.
• Die SAFe-Artefakthierarchie ist Epics->Features->User Stories.
• Auf Programmebene hat der Produktmanager/Programmmanager die inhaltliche Autorität. Er definiert und priorisiert den Programmrückstand.
• Beim Programmrückstand handelt es sich um eine priorisierte Liste von Funktionen.
• Auf Programmebene können Features ihren Ursprung haben oder aus auf Portfolioebene definierten Epics abgeleitet werden.
• Features werden in User Stories zerlegt und fließen in Backlogs auf Teamebene ein.
• Die Rolle des Produktmanagers oder des Release Train Engineers könnte vom Programmmanager/Senior Project Manager übernommen werden
• System ArchiDie Rolle des Architects auf Programmebene besteht in der täglichen Zusammenarbeit mit den Teams. Sie stellt sicher, dass nicht-funktionale Anforderungen erfüllt werden. Außerdem arbeiten sie auf Portfolioebene mit dem Enterprise-Architekten zusammen, um sicherzustellen, dass genügend architektonischer Spielraum vorhanden ist, um zukünftige Benutzer- und Geschäftsanforderungen zu erfüllen.
• Interface-Design, User-Experience-Richtlinien und Designelemente für die Teams werden von UX-Designern bereitgestellt.
• Die Rolle des Chief-Scrum-Masters wird vom „Release Train Engineer“ übernommen.
• Verschiedene Teams (aus Marketing, Entwicklung, Qualität, Betrieb und Bereitstellung) bilden das „Release Management Team“. Sie genehmigen routinemäßige Releases von Qualitätslösungen für Kunden.
• Das DevOps-Team kümmert sich um die Bereitstellung der Software in Kundenumgebungen und die erfolgreiche Bereitstellung.

Portfolioebene

Rollen/Teams	VERANSTALTUNGEN	Artifacts
Enterprise Architect	Strategische Investitionsplanung	Strategische Themen
Programmportfolio-Management	Kanban-Portfolio-Planung (Epic-Planung)	Unternehmen
Epic-Besitzer		Portfolio-Backlog
		Portfolio-Kanban
		Nicht-funktionale Anforderungen
		Episch und Ermöglicher
		Wertstrom
		Budgets (CapEx und OpEx)

• Das höchste Maß an Interesse/Besorgnis/Engagement/an SAFe ist SAFe-Portfolio
• Das Portfolio stellt die Grundbausteine ​​für die Organisation des Lean-Agile-Enterprise-Wertflusses über einen oder mehrere Wertströme bereit.
• Das Portfolio hilft bei der Entwicklung von Systemen und Lösungen, die in strategischen Themen beschrieben werden (verknüpft ein SAFe-Portfolio mit der sich ändernden Geschäftsstrategie eines Unternehmens).
• Um strategische Ziele zu erreichen, werden diese Elemente auf Portfolioebene zusammengefasst. Es bietet grundlegende Budgetierungs- und andere Governance-Mechanismen. Auf diese Weise wird sichergestellt, dass die Investition in die Wertströme die für das Unternehmen erforderliche Rendite erbringt.
• Ein Portfolio ist bidirektional mit dem Geschäft verbunden:
  • Um das Portfolio auf die größeren, sich ändernden Geschäftsziele auszurichten, werden strategische Themen bereitgestellt.
  • Eine andere Richtung weist auf den stetigen Fluss von Portfoliowerten hin.
• Das Programmportfoliomanagement fungiert als Stakeholder und ist für die Bereitstellung der Geschäftsergebnisse verantwortlich.
• Die SAFe-Portfolioebene enthält Personen, Prozesse und notwendige Build-Systeme und Lösungen, die ein Unternehmen benötigt, um seine strategischen Ziele zu erreichen.
• Wertströme sind die Hauptziele im Portfolio, mit denen die Finanzierung der Mitarbeiter und anderer Ressourcen erfolgt, die zum Aufbau der Lösungen erforderlich sind.
• Wichtige Schlüsselkonzepte, die hier verwendet werden, sind:
  • Anbindung an das Unternehmen,
  • Programmportfoliomanagement,
  • Verwalten des Flusses von Portfolio-Epen.

Wertstromebene

Rollen/Teams	VERANSTALTUNGEN	Artifacts
DevOps	Vor- und Nachbereitungsplanung (Programminkrement)	Vision
Systemteam	Lösungsdemos	Roadmap
Release-Verwaltung	Workshop „Inspektion und Übernahme“	Metrik
Lösungsmanagement	Agile Release Train	Meilensteine
UEX Architect		Mitteilungen
Wertstromingenieur (RTE)		Wertstrom-Epics
Lösung Architekt/Ingenieur		Wertstrom-Kanban
Geteilte Dienstleistungen		Wertstrom-Rückstand
Durch den		Nicht-funktionale Anforderungen
Anbieter		Gewichteter kürzester Job zuerst (WSJF)
		Wertstrom-PI-Ziele
		Capability
		Enabler
		Lösungskontext
		Wertstromkoordination
		Wirtschaftliche Rahmenbedingungen
		Lösungsabsicht
		MBSE
		Set-basiert
		Agil Architektur

• Der Value Stream Level ist in SAFe optional.
• Value Stream Level ist neu in SAFe 4.0.
• Die Wertstromebene ist für Unternehmen/Bauherren/Organisationen gedacht/entworfen, die:

1. Groß in der Größe
2. Unabhängig
3. Komplexe Lösungen haben
4. Ihre Lösungen erfordern typischerweise mehrere ARTs
5. Sie haben einen Lieferantenbeitrag.
6. Sie stehen vor den größten Systemherausforderungen
7. Für cyber-physische Systeme
8. Für Software, Hardware, Elektrik und Elektronik, Optik, Mechanik, Fluidik und mehr.

• Für den Aufbau dieser Art von Systemen sind oft Hunderte oder sogar Tausende von Praktikern sowie externen und internen Lieferanten erforderlich.
• Wenn die Systeme geschäftskritisch sind. Das Scheitern der Lösung oder sogar eines Teilsystems hat unannehmbare wirtschaftliche und soziale Folgen.
• Wenn die Enterprises mit ein paar Hundert Praktikern gebaut werden können, sind die Konstrukte dieser Stufe möglicherweise nicht erforderlich. In diesem Fall können sie aus dem 'Reduzierte Ansicht' Das ist 3-Level-SAFe.
• Der Aufbau von Wertstromlösungen nach einem Lean-Agile-Muster erfordert zusätzliche Artefakte, Koordination und Konstrukte. Diese Ebene enthält also einen wirtschaftlichen Rahmen, um finanzielle Grenzen für den Wertstrom festzulegen
• Es unterstützt Kadenz und Synchronisierung für mehrere ARTs und Lieferanten. Es umfasst Pre- und Post-PI-Planungsmeetings und eine Lösungsdemo.
• Es gibt zusätzliche Rollen: Value Stream Engineer, Solution Architect/Engineering und Solution Management.

Häufig gestellte Fragen