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:

Vorteile der Verwendung des Agile Framework
Vorteile der Verwendung des Agile Framework
  • 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.

Skaliertes agiles Framework Architektur
Skaliertes agiles Framework Architektur

Wann sollte das Scaled Agile Framework verwendet werden?

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

Foundations des Scaled Agile Framework
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. Communities of Practice (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โ€œ.

Ziele und Foundations des Scaled Agile Framework
Ziele und Foundations des Scaled Agile Framework

Agiles Manifest

Wir entdecken bessere Mรถglichkeiten, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Arbeit haben wir zu schรคtzen gelernt:

Agiles Manifest
Agiles Manifest

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
Verschiedene Stufen in SAFE
SAFe-Stufen
  • 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 * Teamrรผckstand
* Produktinhaber * Rรผckstandspflege * Nicht-funktionale Anforderungen
* Scrum Master * Tรคgliches Aufstehen * Team-PI-Ziele
* Ausfรผhrung * Iterationen
* Sprint Termin vereinbaren * Geschichten (Arbeitssoftware)
* Sprint Retrospektive * Sprint Ziele
* IP Sprints * Integrierte Qualitรคt
* Spitzen
* 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 (Entwickler + 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 (Programminkrement). * Vision
* Systemteam * Systemdemos * Roadmap
* Release-Management * Werkstatt prรผfen und รผbernehmen * Metriken
* Produkt Management * Archistrukturelle Landebahn * Meilensteine
* UEX Architect * Jederzeit freigeben * Verรถffentlichungen
* Release Train Engineer (RTE) * Agile Release Train * Programm-Epen
* System Architekt/Ingenieur * Freisetzung * Kanban programmieren
* Unternehmer * Programmrรผckstand
* Lean-Agile-Fรผhrungskrรคfte * Nicht-funktionale Anforderungen
* Praxisgemeinschaften * Gewichteter kรผrzester Job zuerst (WSJF)
* Geteilte Dienstleistungen * PI-Ziele programmieren
* Kunde * Besonderheit
* Mรถglichmacher
* 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
* Programm-Portfolio-Mgmt * Kanban-Portfolio-Planung (episch). * Unternehmen
* Epische Besitzer * Portfolio-Rรผckstand
* Portfolio-Kanban
* Nicht-funktionale Anforderungen
* Epic und Enabler
* 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 Nachbereitung der PI-Planung (Programminkrement). * Vision
* Systemteam * Lรถsungsdemos * Roadmap
* Release-Management * Werkstatt prรผfen und รผbernehmen * Metriken
* Lรถsungsmanagement * Agile Release Train * Meilensteine
* UEX Architect * Verรถffentlichungen
* Value Stream Engineer (RTE) *Value Stream Epics
* Lรถsung Architekt/Ingenieur * Wertstrom-Kanban
* Geteilte Dienstleistungen * Wertstrom-Rรผckstand
* Kunde * Nicht-funktionale Anforderungen
* Anbieter * Gewichteter kรผrzester Job zuerst (WSJF)
* Wertstrom-PI-Ziele
* Fรคhigkeit
* Mรถglichmacher
* Lรถsungskontext
* Wertstromkoordination
* Wirtschaftsrahmen
* Lรถsungsabsicht
* MBSE
* Setbasiert
* 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.

Zusammenfassung

  • SAFe ist eine branchenerprobte, wertorientierte Methode zur Skalierung von Agile auf Unternehmensebene.
  • Es beantwortet Fragen wie โ€žWie planen wir?โ€œ, โ€žWie budgetieren wir?โ€œ und โ€žWie werden wir funktionsรผbergreifend in Architektur und DevOps?"
  • Das SAFe Agile-Framework hilft groรŸen Organisationsteams, die strategischen Ziele einer Organisation zu erreichen, nicht nur einzelne Projektziele.
  • Das Framework bietet die Mรถglichkeit, eine zentralisierte Strategie zur Wertschรถpfung aufrechtzuerhalten und zu erstellen.
  • Das SAFe-Modell verfรผgt รผber drei/vier Ebenen, die die strategischen Themen einer Organisation zentralisieren.
  • Zentralisierte Strategie, kombiniert mit der dezentralen agilen Entwicklungsausfรผhrung.

Referenzen: (Die Referenzliste bleibt in der wissenschaftlichen Zitierweise erhalten)

SAFe fรผr Lean Enterprises 5.0:

http://www.scaledagileframework.com

Fassen Sie diesen Beitrag mit folgenden Worten zusammen: