Was ist SAFe?
Was agil ist, wissen viele. Eine noch größere Anzahl von IT-Mitarbeitern verwendet Terminologie. Mehr über Agile zu hören.
Nicht jeder, der den Begriff Agil sicher für Kommunikation, Kritik oder dafür verwendet; Um ihr Team oder Unternehmen besser zu präsentieren, verstehen sie beispielsweise, was der Unterschied zwischen SCRUM und Agile ist. und oft ein Gleichheitszeichen zwischen diesen beiden unterschiedlichen Konzepten setzen. Vor nicht allzu langer Zeit, im Jahr 2015, erschien auch SAFe. Was ist das und warum wird es benötigt?
Einer der wichtigsten Vor- und Nachteile von SCRUM ist meiner Meinung nach die vorgeschriebene Befehlsgröße 7 + -2 (oder 3-9 neuere Daten aus dem Scrum-Handbuch ) einschließlich Product Owner.
Natürlich sind 9 gehobene und gut motivierte Profis zu viel fähig, aber manchmal ist es notwendig, am Ende etwas mit einer großen Anzahl von Händen, Köpfen, Augen und Gehirnen zu bauen. Das Aufblasen von Teams ist schlecht, daher muss ihre Anzahl erhöht werden. Hier tritt das Problem der Kommunikation zwischen Teams auf. Die Synchronisierung von Arbeit und SCRUM selbst bietet keine Lösung für diese Aufgaben. Es gibt Versuche, SCRUM auf der Ebene der SCRUM-Befehlsverwaltung zu verwenden (wie Jeff Sutherland, einer der Autoren des Agile-Manifests, empfiehlt), es gibt Large Scale Scrum, es gibt Disciplined Agile Delivery, es gibt viel mehr, aber es gibt auch SAFe - Scaled Agile Framework.
SAFe ist ein Unternehmensmanagement-Framework, das die Koordination der Arbeit an einem bestimmten Projekt oder verwandten Projekten für 5 oder mehr SCRUM-Teams erfordert. Das heißt, Dies ist ein Überbau über SCRUM, mit dem Sie Teams mit 100 oder mehr Personen verwalten können
Nutzen?
Zuallererst wird die Methodik natürlich von denen benötigt, die sie verkaufen und an Schulungen teilnehmen. Dave Thomas (einer der Autoren des Agile Manifests) sprach auf der GOTO 2015 in seiner Präsentation Agile is Dead recht gut zu diesem Thema
Zweitens Programmmanagementabteilungen. Diejenigen, die zuvor am Projektmanagement beteiligt waren, erhielten die PMP-Zertifizierung, zeichneten Gantt-Diagramme und implementierten das Konzept des Hard-Soft-Managements (die weiche Seite der Führung und die harte Seite der Ausführenden). Tatsache ist, dass es in einem typischen SCRUM keine Funktion für sie gibt, in SAFe ist es. Gleiches gilt für alle Arten von Architekten. In SCRUM gibt es für sie keine Funktion in SAFe - es gibt einen Karriereweg.
Darüber hinaus kann dies für Geschäftsinhaber von Vorteil sein, bei denen Manager an großen Projekten arbeiten, die eine große Anzahl von Arbeitsstunden verschlingen, und diese Projekte (manchmal aus objektiven Gründen) nicht unabhängig machen können.
Viele Entwickler mit unterdurchschnittlichen Qualifikationen Um etwas zu tun, müssen sie oft exponentiell mehr sein als die erfahrensten und motiviertesten Fachleute.
Die ganze Branche. Weil Die Anzahl der Entwickler verdoppelt sich alle 5 Jahre (siehe Onkel Bobs Zukunft der Programmierung ), was dazu führt, dass zu einem bestimmten Zeitpunkt mindestens die Hälfte der Entwickler weniger als 5 Jahre Berufserfahrung hat. Wenn sich der Trend nicht ändert, sich aber anscheinend nicht ändert, sind Prozesse erforderlich, die ihre Arbeitsfunktionen, Interaktionsmechanismen zwischen den Teilnehmern und dem gesamten Prozess vorschreiben und formalisieren.
Essenz
SAFe ist eine Torte aus verschiedenen agilen Techniken. Auf der untersten Ebene befindet sich das fast traditionelle SCRUM mit typischen zwei- bis dreiwöchigen Sprints, Teams von 3 bis 9 Personen, einschließlich Product Owner. Alle typischen Rituale, angefangen von der täglichen Planung - Aufstehen bis hin zur Nachbesprechung bei der Rückschau. Obwohl es einen wesentlichen Unterschied gibt. Der Befehl ist kein voll funktionsfähiges unabhängiges Modul mehr. Und der Sprint hört auf, eine unabhängige Zeitspanne mit einem vollen Lebenszyklus zu sein. Sprints werden zu Programminkrementen kombiniert, die normalerweise aus 5 Sprints bestehen. Das heißt, Wenn wir im klassischen SCRUM nicht das erstellt haben, was dem Kunden gefällt, nehmen wir die Kurskorrektur im nächsten Sprint vor. In SAFe gehen wir bis zum Ende des Programminkrements weiter an den Rand, im schlimmsten Fall auf die nächsten 4 Sprints (natürlich übertreibe ich).
Auf der nächsten Ebene haben wir Züge - den sogenannten Agile Release Train. Es gibt neue Funktionen für die Verwaltung von 5 Sprint-Segmenten: einen Systemarchitekten (derjenige, dem die Architektur gehört - das heißt, er ist kein Team mehr), den Produktmanager (derjenige, der das Produkt kontrolliert, nicht den Product Owner, letzterer geht zur Beratung an PM) und RTE - das gleiche PMP aus der fernen Welt der Wasserfälle. Hier werden einige Entwicklungen von Kanban angewendet, insbesondere ein Board, eine Methode zur Zuweisung von Prioritäten und insgesamt das Prinzip der Messung der historischen Leistung von Teams (Geschwindigkeit) und der Projektion dessen, was am Ende des Zeitintervalls erstellt wird, im Gegensatz zum Ansatz mit Schätzungen und Zuweisung von Fristen für eine bereits festgelegte Funktion ( Geltungsbereich). Eine der Neuerungen ist, dass der letzte Sprint von 5 als organisatorisch deklariert wird und währenddessen große Meetings abgehalten werden (alle Teams zusammen - und das sind 100 oder mehr Personen), eine Analyse der technischen Schulden durchgeführt wird, Pläne für die Entwicklung der Architektur erstellt werden und die Arbeit aller Teams synchronisiert wird.
Über der Zugstufe haben wir eine Koordination zwischen Abteilungen, Direktoren und dem Kunden. Lean Agile leiht sich mehr aus, aber die gleichen Tools von Kanban bleiben erhalten. Dies ist eine Analyse der wirtschaftlichen Machbarkeit von Veränderungen. Im Idealfall werden alle Änderungen einer vorläufigen Analyse unterzogen, bei der eine messbare Hypothese über die bevorstehende Änderung aufgestellt wird (wenn wir beispielsweise einen Online-Shop von einem Rechenzentrum in die Cloud erstellen und dann die Kapazitäten auf dem Höhepunkt des saisonalen Umsatzes schnell erhöhen, können wir die Anzahl der Transaktionen um 10% erhöhen), und diese Hypothese wird entweder bestätigt Nein. Für Unternehmen mit weniger als einer Milliarde Dollar ist dies möglicherweise die letzte Etage. Hier werden Arbeitspläne für 12-36 Monate erstellt (Hallo Fünfjahrespläne für Qualität, Quantität usw.)
Über dem Niveau großer Systeme liegt das Portfoliomanagement. Die Mittel werden verschiedenen Geschäftsbereichen zugeordnet. Lean Portfolio Management wird unter Verwendung der Entwicklungsstrategie des Unternehmens verwendet. Es werden Bereiche ausgewählt, aus denen Sie eine Rendite erzielen können. Hier werden Entscheidungen über den Kauf oder die Fusion mit anderen Unternehmen getroffen. Schaffung neuer Geschäftsbereiche, Schließung alter. Das Budget wird regelmäßig angepasst und neu zugewiesen (im Gegensatz zu vierteljährlichen oder jährlichen Plänen). Für jede Komponente des Portfolios wird ein Satz mehr oder weniger standardisierter Metriken erstellt und anschließend werden alle danach bewertet. Ebenso wie in den vorherigen drei Stufen gibt es (normalerweise) alle zwei Wochen spezielle Rituale für die Synchronisation - es findet ein Austausch von Status und Schlüsselindikatoren statt.
Angeführt von der gesamten Strategie. Die Art und Weise, wie es definiert wird, wird vom Framework nicht beschrieben.
Vorteile
- Eine bedeutende Anzahl sehr guter Werkzeuge (WSJF, Kanban, Gemba usw.)
- Formalisierte und vorgeschriebene Schritte für SDLC, angefangen beim Schreiben von Code (von TDD vorgeschrieben) bis hin zum statischen Scannen und CI / CD- und Feature-Toggle. Ob jede der Praktiken gut ist oder nicht, ist eine andere Frage, aber zumindest gibt es einen Plan und jeder folgt ihm.
- Der Prozess kann verstanden, erklärt und implementiert werden.
- Jede Person im Rahmen dieses Prozesses erhält eine ziemlich genau definierte Funktion.
- Erhöht die Transparenz des Unternehmens für diejenigen, die darin arbeiten.
Nachteile
- Lange genug Zeit, um auf eine Nichtübereinstimmung der Realität mit den Erwartungen zu reagieren
- Eine große Menge Geld und Geld wird für Kommunikation und Besprechungen ausgegeben
- Oft sind empfohlene Lösungen innerhalb des Frameworks veraltet
Vorstellen oder nicht? Ich glaube, wenn es eine Wahl gibt, dann nein, ist es besser, die Abhängigkeit zwischen Abteilungen und Projekten zu verringern. Und wenn es keine andere Wahl gibt und Sie ein großes Projekt verwalten müssen, ist dies durchaus möglich.