In den letzten Jahren habe ich zu jeder einzelnen Aktivität im SAFe DevOps Health Radar einen Deep-Dive veröffentlicht. Dieser Beitrag ist die Tour rund um den Radar: eine einzige Seite, die Sie durch alle vier Aspekte und alle sechzehn Stages führt, mit dem Originalvideo zu jeder Aktivität und einem Link zum vollständigen Artikel. Nutzen Sie ihn als Karte — um Ihren Einstiegspunkt zu finden, um ihn mit Ihrem Team zu teilen oder um zu bewerten, wo Sie heute stehen und wohin Sie als nächstes wollen.
Bitte beachten Sie, dass alles hier auf dem Scaled Agile Framework basiert, das als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Was ist der SAFe DevOps Health Radar?#
Der SAFe DevOps Health Radar ist sowohl ein Assessment als auch ein Prozess. Als Assessment erlaubt er Ihnen, Ihr Team oder Ihren Value Stream von Sit bis Fly in sechzehn Aktivitäten zu bewerten und das Ergebnis als Spinnendiagramm zu visualisieren. Als Prozess beschreibt er die vollständige Continuous Delivery Pipeline, die eine Idee vom Kunden in validierten Wert zurück zum Kunden verwandelt.
Der Radar ist um vier Aspekte herum aufgebaut: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Jeder Aspekt umfasst vier Aktivitäten. Zusammen bilden sie den Kreislauf, der es Ihnen ermöglicht, das Richtige zu bauen, es richtig zu bauen und aus dem zu lernen, was Sie released haben. Vollständige Übersicht lesen
Continuous Exploration#
Der erste Aspekt ist dort, wo gute Ideen von Kundenseite und aus dem Business zu validierten Epics werden — mit einer klaren Hypothese, einem echten Kundenbedürfnis dahinter, einer minimalen Architektur zum Beweis und einem priorisierten Set an Features, das bereit für die Entwicklung ist. Das Ziel dieses Aspekts ist Alignment zwischen Stakeholdern, damit wir das Richtige bauen.
Hypothesize#
Eine Idee aufnehmen, in ein Epic mit einem Epic Hypothesis Statement verwandeln, das MVP definieren und die leading indicators identifizieren, die zeigen, ob die Hypothese hält. Mehr lesen
Collaborate and Research#
Markt- und Kundenforschung durchführen, echte Anwender interviewen und verifizieren, dass Sie das tatsächliche zugrundeliegende Problem lösen, anstatt das zu bauen, was jemand zufällig angefragt hat. Mehr lesen
Architect#
Die minimale Architektur definieren, die nötig ist, um die Hypothese zu beweisen. Nicht die finale Architektur — die einfachste, mit der validiert werden kann. Von Anfang an für Operability designen. Mehr lesen
Synthesize#
Alles zusammenführen: eine Vision, eine Roadmap und ein klares Set an priorisierten Features (plus Enabler Features für die architekturelle Runway), bereit für das Program Backlog. Mehr lesen
Continuous Integration#
Der zweite Aspekt nimmt priorisierte Features aus dem Backlog, bricht sie in User Stories herunter, entwickelt sie und produziert verifizierte deploybare Artefakte in einer Staging-Umgebung. Hier werden Built-in Quality, schnelle Feedback Loops und kleine Batchgrössen zu echter Engineering-Praxis. Vollständige Übersicht lesen
Develop#
Features in User Stories aufteilen, implementieren, Code in die Versionskontrolle committen und dabei pairen, peer-reviewen und testen, sodass Qualität eingebaut und nicht nachträglich angeflanscht wird. Mehr lesen
Build#
Jeden Commit kontinuierlich integrieren, Unit Tests laufen lassen, statische Code- und Security-Analyse ausführen und ein deploybares Artefakt produzieren. Gated Commits halten den Trunk grün. Mehr lesen
Test End-to-End#
Automatisierte funktionale und nicht-funktionale Tests über das gesamte System laufen lassen, um zu verifizieren, dass das Artefakt sich wie erwartet verhält, bevor es die Integrationsumgebung verlässt. Mehr lesen
Stage#
Das verifizierte Artefakt in eine produktionsähnliche Staging-Umgebung deployen für die letzte Validierungsrunde, bevor es in die Produktion darf. Mehr lesen
Continuous Deployment#
Der dritte Aspekt nimmt verifizierte Artefakte aus Staging und bringt sie kontinuierlich in die Produktion — mit dem Feature Toggle off. Hier wird Deployment vom Release getrennt: die Änderung ist in Produktion, bereit, aber für den Anwender unsichtbar, bis das Business entscheidet, dass die Zeit reif ist.
Verify#
Sobald das Artefakt in Produktion ist, eine Teilmenge der Integrationstests dagegen laufen lassen. Wenn etwas fehlschlägt, sofort auf die letzte stabile Version zurückrollen. Mehr lesen
Deploy#
Den kompilierten Code mit ausgeschaltetem Feature Toggle in die Produktion bringen. Das ermöglicht Dark Launches, bei denen neue Funktionalität live, aber noch nicht sichtbar ist. Mehr lesen
Monitor#
Mit dem in Architect und Develop eingebauten Logging und Telemetry Application Health, System Performance, Nutzerverhalten, Incidents und Business Value in Echtzeit beobachten. Mehr lesen
Respond#
Sorgfältig designte Schwellenwerte auf das Monitoring legen, Disaster Recovery rehearsen, teamübergreifend kollaborieren, wenn etwas passiert, und schnell fix-forward oder zurückrollen. Mehr lesen
Release on Demand#
Der vierte Aspekt ist das, was passiert, nachdem das Business sagt: “Die Zeit ist reif” und der Feature Toggle eingeschaltet wird. Hier schliesst sich auch der Kreis: wir stabilisieren, wir messen, wir lernen, und wir füttern alles zurück in die nächste Runde von Continuous Exploration.
Release#
Den Feature Toggle einschalten, sodass die Anwender tatsächlich auf die neue Funktionalität zugreifen können. Techniken wie Canary Releases, Blue-Green Deployments und progressive Rollouts halten das Risiko klein. Mehr lesen
Stabilize#
Geschäftskontinuität sicherstellen mit Disaster Recovery, Security Monitoring (SIEM), kontinuierlichem Monitoring nicht-funktionaler Anforderungen sowie SLIs, SLOs und SLAs. SRE spielt bei hohen Verfügbarkeitszielen eine Schlüsselrolle. Mehr lesen
Measure#
Sowohl qualitatives als auch quantitatives Feedback sammeln, um die Hypothesen von Epics und Features zu validieren. Vorsicht vor Vanity Metrics und Fokus auf leading indicators, die echten Wert reflektieren. Mehr lesen
Learn#
Die Pivot-or-Persevere-Entscheidung auf Basis von Daten treffen, Sunk Costs ignorieren, jedes Quartal Value Stream Mapping durchführen und Retrospektiven sowie Post-Mortems für relentless improvement zurück in die Pipeline füttern. Mehr lesen
Wie Sie diese Tour nutzen#
Wenn Sie den Radar noch nie gesehen haben, beginnen Sie oben mit dem Übersichtsbeitrag und arbeiten Sie sich nach unten. Wenn Sie den Radar bereits kennen und Ihr Team bewerten wollen, gehen Sie die vier Aspekte der Reihe nach durch, bewerten Sie sich in jeder der sechzehn Stages von Sit bis Fly und fügen Sie eine zweite Spalte hinzu, in der Sie in zwölf Monaten sein wollen. Die Lücke ist Ihr Transformations-Backlog.
In vielen Fällen müssen Sie nicht in jeder Aktivität ein Fly sein. Eine Drei oder sogar eine Zwei ist je nach Kontext völlig akzeptabel. Es geht nicht darum, jeden Score zu maximieren — es geht darum, die Engpässe zu identifizieren, die Ihren Flow of Value bremsen, und gezielt in das Schliessen der Lücken zu investieren, die wirklich zählen.
Wichtigste Erkenntnisse#
- Der Radar ist sowohl Assessment als auch Prozess. Nutzen Sie ihn, um Ihren aktuellen Zustand zu bewerten und um die vollständige Continuous Delivery Pipeline von der Idee bis zum Lernen zu verstehen.
- Sechzehn Stages, vier Aspekte. Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand enthalten je vier Aktivitäten, die jeweils auf der vorherigen aufbauen.
- Trennen Sie Deployment von Release. Dieses einzige Prinzip — Feature Toggles, Dark Launches, Release on Demand — macht hochfrequente Auslieferung mit niedrigem Risiko überhaupt erst möglich.
- Designen Sie früh für Operability. Logging, Telemetry, Feature Toggles und Recovery-Mechanismen müssen von Anfang an eingebaut sein; sie sind das, was Monitor, Respond und Stabilize funktionieren lässt.
- Schliessen Sie den Kreislauf mit Measure und Learn. Eine Änderung, die ohne validiertes Lernen in Produktion geht, ist nur ausgelieferter Code; der Radar ist so designt, dass Erkenntnisse zurück in die nächste Hypothese fliessen.
- Sie müssen nicht überall ein Fly sein. Wählen Sie die Lücken, die für Ihren Value Stream zählen, und nutzen Sie den Radar, um die Konversation zwischen Business, Engineering und Operations auszurichten.