Gegeben: Ein Unternehmen, das das Scaled Agile Framework (SAFe) verwendet, um die agile Entwicklung im gesamten Unternehmen zu skalieren. 10 Entwicklungsteams, die zu einem großen Team zusammengefasst sind (Agile Release Train gemäß SAFe-Terminologie) und ein gemeinsames Produkt liefern; die Notwendigkeit einer zweitägigen vierteljährlichen Planung (PI-Planung) zur Festlegung des Arbeitsplans der IT-Teams für die nächsten 3 Monate *; drei Entwicklungsbüros, die Entfernung zwischen den entferntesten übersteigt 6.000 Kilometer mit einer entsprechenden Differenz von 5 Stunden Arbeitszeit; Vorherige Planungserfahrung, einschließlich der physischen Anwesenheit wichtiger Kollegen im selben Raum und der Verwendung von analogen Tafeln / Whiteboards / Markern / Haftnotizen.
* Das Schwergewichtskonstrukt „IT-Team-Arbeitsplan für die nächsten 3 Monate“ droht das Textvolumen ernsthaft zu erhöhen. Daher plane ich, in Zukunft einfach zu schreiben - stattdessen „Kommentar“. Erstellen und verabschieden Sie dementsprechend einen Arbeitsplan - „Commit“.
Warum wird das benötigt?
1) Ermüdung durch analoge Arbeitsmethoden. Während Raumschiffe offene Räume pflügen und Elon Musk Tunnel gräbt, schreiben wir, IT-Spezialisten, beharrlich mit Markierungen auf klebrigen Papierstücken und formen sie auf die Bretter - dies ist eine Art Dissonanz. So sah unser Kommentar vor einiger Zeit aus:
Ja, dies ist ein Stück Papier mit einer Größe von etwa 2 x 5 Metern. Nach der Planung sollte jedes Stück Papier im Jira zu einer Aufgabe werden ...
2) Die Müdigkeit der Nomadenkollegen. Trotz der Tatsache, dass sich unser Hauptsitz in einem eher einladenden, warmen Land befindet, stellte ich zu meiner Überraschung im letzten Jahr fest, dass sie mit einem solchen Nomadenleben überhaupt nicht zufrieden waren, und meine Argumente im Stil von „Komm schon, geh zur See, du wärst dich in der Sonne auf “, was ich unklugerweise ausdrücken durfte, wurde nicht sehr herzlich aufgenommen - nicht jeder ist bereit für häufige Geschäftsreisen, seine Haushalte begrüßen dies nicht immer, jemand reagiert nicht sehr gut auf häufige Flüge.
3) Weitere Kollegen aus der IT in den Planungsprozess einbeziehen. Wie aus dem vorhergehenden Absatz hervorgeht, konnten wir es uns nicht leisten, das gesamte Büro zur Planung zu schicken, daher schickten wir nur die Auserwählten, wodurch der Rest vom Prozess ausgeschlossen wurde, der der allgemeinen Moral keine Pluspunkte hinzufügte.
4) Optimierung der finanziellen Kosten. Ja, dies ist ein heikler Moment - es gibt viele Schlüsselpersonen, und es ist ein Aufwand, sie viermal im Jahr hin und her zu tragen.
Part Zero oder Portfolio-Backlog
Und alles beginnt viel früher - um während der Planung fruchtbar an dem Kommentar arbeiten zu können, muss etwas festgelegt werden. Um dies sicherzustellen, muss ich Geschäftsinhaber so früh wie möglich mit der Arbeit an den vorgeschlagenen Initiativen (oder, in der SAFe-Terminologie, Epicam, aber ich werde den mir vertrauten Begriff verwenden) „beladen“. Idealerweise sollte dieser Prozess vollständig von der zyklischen Natur der vierteljährlichen Planung getrennt sein und seinen eigenen Kanban-Weg gehen. Als Basis haben wir das SAFe-Portfolio Kanban genommen:
Wir haben ein separates JIRA-Projekt mit drei Arten von Aufgaben: Epen, Geschäftsinitiativen und Architekturinitiativen; sowie das entsprechende Kanban-Board. Der Algorithmus für den Geschäftsinhaber der Initiative ist einfach: Er fügt die Aufgabe diesem Projekt hinzu und fällt standardmäßig in das Backlog - dies ist der erste Status unseres Kanban -
Trichters:
Es speichert Initiativen, die noch nicht zur Überprüfung bereit sind. Der Geschäftsinhaber arbeitet am Inhalt der Initiative, bis er sich für den nächsten Schritt bereit fühlt. Das in dieser Phase erforderliche Minimum sind die ausgefüllten Felder Problemstellung, Gewünschtes Ergebnis und Erfolgsmaß sowie eine etwas detailliertere, aber einfachere und klarere Darstellung. In dieser Phase ist es wichtig, keine technischen Lösungen zu erwähnen und sich auf Geschäftsparameter zu konzentrieren. Wenn alle Daten erfasst sind, versetzt der Eigentümer die Aufgabe in den nächsten Status -
Überprüfen.Wir führen wöchentlich eine Überprüfung durch, sowohl für Geschäftsinitiativen als auch für Architekturinitiativen. Im Idealfall handelt es sich um eine fünfminütige Präsentation mit anschließenden Antworten auf Fragen. Das Ergebnis der Überprüfung ist eine Entscheidung über das Schicksal der Initiative. Sie kann:
- Gehen Sie zur Überarbeitung zurück zum Rückstand
- ohne Chance auf weiteres Leben abschaffen (dafür verwende ich einen separaten Veralteten Status, der auf dem Kanban-Brett versteckt ist)
- Holen Sie sich die Genehmigung und fahren Sie mit der nächsten Stufe fort - Analysieren.
In dieser Phase sind wir Prost! - Wir können Mitarbeiter aus der IT gewinnen: Analysten, Architekten, Leads, alle. Mit „wir“ meine ich mich als Release Train Engineer, aber im Idealfall Unternehmer, die bereits einige Erfahrungen und die Unabhängigkeit gesammelt haben, um die richtigen Teams zu gewinnen und den Analyseprozess selbst zu starten. Ich schreibe über einen Idealfall, weil der Grad der Selbstorganisation unserer Kollegen schwankt und sie in einigen Fällen in Form eines speziell ernannten Moderators um Hilfe bitten, aber ich versuche, ein wenig von dieser Praxis zurückzutreten.
Der Zweck dieser Phase ist die vorläufige Analyse oder, wie wir es nennen, die Vorentdeckung. Am Ausgang sollten wir das Minimum erhalten, das es uns ermöglicht, uns zu verpflichten: die vorgeschlagenen Lösungen, Risiken und Abhängigkeiten, nicht funktionale und infrastrukturelle Anforderungen, Benutzerkarten, Architekturschemata. Darüber hinaus bitten wir die Teams, eine vorläufige Bewertung der Story-Punkte auf der Ebene der Features vorzunehmen. Auf diese Weise können wir die Prioritäten am Ende des Quartals festlegen.
Für jede Initiative wird ein persönliches Kanban-Board erstellt, in dem Sie beim Erstellen Features und Storys mit einer anfänglichen Bindung an eine bestimmte Iteration anzeigen können, die durch einen separaten Workflow in Form zukünftiger Iterationen bereitgestellt wird. In Boards werden benutzerdefinierte Teams entsprechend den Entwicklungsteams konfiguriert. Da das JIRA-Ökosystem ziemlich kompliziert ist, erstellen wir während der Vorerkennung und Erkennung Aufgaben in separaten Projekten, um die Rückstände von Befehlen nicht zu überladen:
In der Phase der Analytik sind Architekten an diesem Prozess beteiligt, oder, wie in jüngster Zeit üblich, sind ihre vertrauenswürdigen Mitarbeiter „Botschafter“ (EA Ambassadors). Ihre Aufgabe ist es, den Teilnehmern des Prozesses die Vision der Architekturabteilung zu vermitteln, die beste Lösung zu finden und diese Entscheidung letztendlich mit dem Chefarchitekten des Unternehmens (Leiter Unternehmensarchitektur) zu koordinieren.
Wenn Teams glauben, dass die Initiative gut entwickelt und für den nächsten Schritt bereit ist, verschieben sie sie in den nächsten Status -
Portfolio Backlog.
In dieser Phase besteht ein wichtiger Schritt darin, die WSJF-Priorisierung (
Weighted Shortest Job First ) durchzuführen. Zu diesem Zweck halten wir 3 Wochen vor der Planung ein großes Meeting ab, das leider viele Stunden dauert. Während dieses Meetings bewerten die Vorstandsmitglieder anhand des Fibonacci-Poker-Scores den Geschäftswert und die Zeitkritikalität ( Zeitkritikalität), potenzielle Risikominderung und Chancenförderung:
Um die Geschichte der Initiativen verfolgen zu können, füge ich jedem von ihnen ein Etikett mit Daten zum Quartal hinzu: 2018Q4, 2019Q1 usw.
Mit Blick auf die Zukunft werde ich die folgenden möglichen Status beschreiben. Nach dem
Festschreiben wechseln die Initiativen, die erfolgreich zur Arbeit ergriffen wurden, in den
Implementierungsstatus , während die „Nicht-Fit“ den Status „
Geparkt “ erhalten und in Zukunft die Möglichkeit haben, für die nächsten Quartale in Betracht gezogen zu werden. Gelieferte Initiativen gehen zu
Fertig .
Als Ergebnis haben wir ungefähr das folgende Bild auf der Kanban-Tafel:
Natürlich sind wir noch nicht einmal mitten auf der Reise, aber im Moment kann ich dies bereits feststellen, da Kanban auf Portfolio-Backlog-Ebene eingesetzt wird
- Unternehmer begannen, Initiativen im Detail auszuarbeiten und sich ernsthaft auf eine Überprüfung vorzubereiten
- Die Überprüfung ist in guter Weise akribischer geworden
- Teams haben mehr Zeit vor der Entdeckung
- Ich verliere keine alten Initiativen - Sie können jederzeit zu geparkten, nicht zugestellten oder vergessenen Initiativen zurückkehren und weiter daran arbeiten
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Farben für das Jira-Plugin - zur Hervorhebung von Geschäfts- und Architekturinitiativen
- Plugin 'Struktur - Projektmanagement im Maßstab' - zur Visualisierung der Struktur von Initiativen mit damit verbundenen Funktionen und ihrer WSJF-Priorisierung
- Atlassian Confluence - Quelle der internen Dokumentation
- Lucidchart und seine Plugins für Jira und Confluence - zum Charting
Teil I. Vorbereitung für die Planung
Etwa einen Monat vor der Planung ist es eine heiße Zeit für die Vorbereitung. Es gibt zu viel zu beachten, und um nichts zu vergessen, müssen Sie eine mehrseitige "logistische" Google-Tabelle erstellen. Ich werde versuchen, die wichtigsten Registerkarten aus dieser Tabelle und die damit verbundenen Aktivitäten zu beschreiben.
Rückkopplung. Einige Tage nach jeder Planung führen wir eine Retrospektive durch. Um den Kurs anzupassen, ist es wichtig, nicht zu vergessen, zu welchen Schlussfolgerungen wir gekommen sind und wie wir den Kurs anpassen müssen. Dies ist ein wichtiger Bestandteil im Zusammenhang mit der kontinuierlichen Prozessverbesserung.
Technische Ausbildung. Mit dem Übergang zur Fernplanung ergaben sich spezifische Anforderungen wie die Qualität der Internetverbindung (Priorisierung und Routenoptimierung für JIRA und Confluence) sowie die Fernseh- und Audiopräsenz (wir verwenden Kits der Logitec Group, Jabbra-Mikrofone und persönliche Kopfhörer in verschiedenen Kombinationen, Webcams, Zoom-Software für Videokonferenzen).
Moderatoren. Hier finden Sie eine Liste der Mitarbeiter, die für die Moderation in jeder Arbeitsgruppe verantwortlich sind, sowie deren Standort und einen Link zum permanenten Zoomkanal der Arbeitsgruppe.
Das Publikum. Dementsprechend eine vollständige Liste aller eingeladenen Personen.
Checkliste. Eine vollständige Liste wichtiger Aufgaben mit Fristen und Verantwortlichen. Zum besseren Eintauchen werde ich einige Beispiele für die charakteristischsten und wichtigsten Aufgaben geben, die für jede Planung wiederholt werden: Schulung der Moderatoren (Für Schulungsleiter wurde ein Schulungshandbuch mit allen erforderlichen Schritten von der Organisation eines Arbeitsteams über die zeitliche Planung von Besprechungen zur Prüfung von Optionen für technische Lösungen bis hin zur Zerlegung der Initiative in eine Liste von Funktionen erstellt.) ;; Aktualisierung der Standortpläne der Arbeitsgruppe für jedes Büro; Kontrolle der Aktualisierung von Velocity für alle Entwicklungsteams; Bestellung zum Mittagessen; Berichterstattung über frühere Quartale; Ausdrucke von Initiativlisten (zur Hand) und Zeitplänen.
Teil II Planen und Kommentieren
Nach all den vorbereitenden Vorbereitungen kommt endlich dieser Moment - der Beginn der vierteljährlichen Planung. In zwei Tagen sollten wir Zeit haben, alle Initiativen zu sortieren, sicherzustellen, dass genügend Informationen vorhanden sind, und uns zu engagieren. Nach ein paar kurzen, aber brandaktuellen Reden zerstreuen sich die Arbeitsgruppen an ihren Plätzen und machen sich an die Arbeit. Derzeit wird die Anzahl der Gruppen gemäß der 4x4x4-Formel auf die drei Büros verteilt, und Remotebenutzer werden über einen dedizierten Zoomkanal mit der erforderlichen Tabelle verbunden.
Am Ende der Entdeckung jeder der Initiativen markiert der Moderator, der sicherstellt, dass alle erforderlichen Daten - wie Akzeptanzkriterien, eine Beschreibung der technischen Lösung, Risiken, Abhängigkeiten, die Notwendigkeit einer neuen Infrastruktur - vorhanden sind, die Initiative mit dem Kontrollkästchen IT-Sitzung beendet für Transparenz des Fortschritts und der Arbeitsgruppe kann zum nächsten übergehen.
Nach einem Dutzend Plänen hat sich das Gefühl ständiger nervöser Anspannung und vorübergehenden Zeitdrucks, das von Anfang an bei uns war, deutlich aufgelöst, und jetzt ist die Atmosphäre eher eine ruhige Arbeit. In der zweiten Hälfte des ersten und zweiten Tages ist die Zeit für eine gemächliche Stellungnahme gemäß den Prioritäten gekommen. Um das Commit auszuführen, habe ich mehrere separate Strukturen. Die erste davon ist eine Struktur, die eine Liste von Features und Pfaden enthält, die für einen Kommentar geplant sind:
Leider enthält diese Struktur Materialreste, die nicht in die Kommentare des aktuellen Quartals passten, sodass die Stichprobe nicht repräsentativ ist. In jedem Fall kann ich bei der Suche die Initiative, die mich interessiert, in der Prioritätsreihenfolge nach Nummer auswählen, die während des Erkennungsprozesses für jedes Feature und jede Story in ein separates Feld gestellt wird, den Status der erforderlichen Aufgaben von "Geplant" in "Festgeschrieben" ändert und sie in die richtige Iteration versetzt, wodurch sie sich selbst festlegt:
Infolgedessen verschwindet die Aufgabe aus dieser Struktur und erscheint in einer neuen, was den wachsenden Kommentar widerspiegelt:
Wie Sie im Screenshot sehen können, werden die Storys in dieser Struktur in den Ordner des Entwicklungsteams verschoben, zu dem sie gehören, und nach Iteration gruppiert. Hier sehe ich die Geschwindigkeit des gesamten Teams im Ordnernamen sowie in der Spalte Commitment. Unter Verwendung der Formel wird der Überkommentar für jede Gruppe automatisch ermittelt und signalisiert uns rot.
Wenn die ersten und vorrangigsten Initiativen ohne Probleme bald kommentiert werden und die ersten Teams auftauchen, die ihren Rückstand zum Scheitern gebracht haben, beginnen natürlich Probleme, und einige Initiativen sind nicht ohne Debatte, aber sie müssen verschoben werden.
Am Ende dieses einfachen Prozesses schwören die Teams auf der Firmenflagge feierlich, einen Kommentar (einen Witz) abzugeben und nach Hause zu streuen (auch ein Witz - alle streuen durch Balken).
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Plugin 'Struktur - Projektmanagement im Maßstab' - zur Überwachung des Erkennungsprozesses und während der Ausführung eines Commits.
Teil III. Klonen von Aufgaben in ein funktionierendes JIRA-Ökosystem eines Unternehmens
Während jeder Wodka trinkt, arbeitet RTE daran, einen Kommentar in der Form zu erstellen, in der er an die Rückstände des Entwicklungsteams verteilt und während des gesamten Quartals überwacht werden kann. Dazu verwende ich das Plugin 'Bulk Clone Professional für Jira' - es fügt ein Element hinzu, das das kollektive Klonen im Menü "Massenänderung" ermöglicht, und verfügt über die für mich erforderlichen Funktionen wie das Klonen von Links, das Aktualisieren von Links zwischen frisch erstellten Klonen, das Aktualisieren epischer Links und das Hinzufügen Präfix in der Kopfzeile und automatisch eine Verknüpfung hinzufügen:
Ich füge den Status als Präfix hinzu, da die Status in der Planungsphase die geplante Iteration der Fertigstellung widerspiegeln. Daher sehe ich in der Kopfzeile sofort, wann wir ein Feature oder eine Story fertigstellen möchten.
Zuerst klone ich absolut alle Aufgaben in ein separates Global Backlog-Projekt, da wir darin Epen speichern, und ich muss relevante epische Story-Verbindungen in frisch geklonten Aufgaben haben. Und als zweiten Schritt stelle ich Anfragen für jedes Entwicklungsteam separat und verschiebe die Geschichten zu den endgültigen Projekten der Teams.
Als Ergebnis erstelle ich eine Struktur, die den aktuellen Kommentar widerspiegelt und aus endgültigen Aufgaben besteht, die ich dann zur Überwachung verwende:
Im Allgemeinen ergeben sich aus diesem Ansatz folgende Vorteile:
- Es mag kitschig klingen, aber für eine Person aus der IT ist es einfacher, neue Funktionen und Geschichten zu drucken, als mit einem Marker auf ein klebriges Stück Papier zu schreiben.
- Viele Dinge, wie die Kapazitätsbilanz und das WSJF-Update, werden abhängig von den Bewertungen automatisch mithilfe von Formeln berechnet.
- Dank des Klonens bleibt die ursprüngliche Besetzung des Commits für die Story erhalten, und Sie können jederzeit darauf zurückgreifen.
- Bei der Vorbereitung der Planung wird viel Zeit und Energie gespart - die Arbeit mit Papier erfordert Kraft.
- Es ist natürlich großartig, dass Sie keine Puzzles mehr in eine Gira stecken müssen.
In dieser Phase verwendete Werkzeuge:
- Atlassian Jira Software Server
- Plugin 'Bulk Clone Professional für Jira' - zum Klonen von Funktionen und Storys in endgültige JIRA-Projekte.
- Plugin 'Struktur - Projektmanagement im Maßstab' - um die endgültige Struktur zu erstellen.
Nachwort
Freunde, natürlich verstehe ich, dass die Beschreibung recht oberflächlich ist und viele Dinge detaillierter enthüllt werden könnten - Überwachung der Kapitalverteilung zwischen geschäftlichen und architektonischen Initiativen und operativen Aufgaben, Berechnung von Formeln in Strukturen, Risikomanagement und vielem mehr. Mir ist jedoch noch nicht klar, ob dieses Thema für das Publikum interessant ist und wenn ja, was genau. Wenn ich Interesse sehe, bin ich bereit, die notwendigen Themen zu enthüllen.
Und noch etwas - es ist kaum zu glauben, dass dies möglich ist, aber ich möchte alle Probleme mit Edge, Frameworks, effektiven und „effizienten“ Managern vermeiden. Bitte denken Sie daran, dass ich den gesamten Prozess in der Hoffnung interessanter Menschen beschrieben habe, die ihm mit seiner technischen Umsetzung nahe stehen, und ich freue mich sehr auf relevante Diskussionen.
Wir sehen uns in den Kommentaren!