Gemeinsam mit meiner Kollegin Nadine habe ich eine aktualisierte Version unseres partizipativen Budgetierungsansatzes vorgestellt. Wir hatten bereits die erste Version an einem früheren Event geteilt, aber seither haben wir einiges verändert, das wir natürlich nicht vorenthalten wollten. Ein kurzer Disclaimer: Wir haben Participatory Budgeting nicht erfunden. Wir haben auf den Vorlagen des SAFe (Scaled Agile Framework) aufgebaut, daher findet ihr auch das Copyright auf den relevanten Folien. Wenn ihr selbst Participatory Budgeting bei euch einführen wollt, sind wir gerne bereit, unsere Erfahrung zu teilen, und verweisen dabei immer auf die Originalpräsentation und Originalunterlagen von SAFe.
In diesem Artikel erkläre ich, was Continuous Deployment innerhalb des SAFe® DevOps Health Radars ist und warum es für die schnelle und sichere Wertlieferung unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Wie erkennt und behebt man proaktiv Produktionsprobleme, bevor sie zu einer Geschäftsunterbrechung führen? Respond ist die Aktivität im SAFe DevOps Health Radar, die genau diese Frage beantwortet. In diesem Video erkläre ich, was Respond umfasst und warum es für die Aufrechterhaltung einer stabilen Produktionsumgebung unverzichtbar ist.
Sobald unsere Features in der Produktion deployed und verifiziert sind, müssen wir genau beobachten, wie sie sich verhalten. Monitor ist die Aktivität im SAFe DevOps Health Radar, die sich darauf konzentriert, Systemleistung, Endnutzerverhalten, Incidents und den Geschäftswert zu verfolgen. In diesem Video erkläre ich, was Monitoring umfasst und warum es für die richtigen Entscheidungen über unsere Features unverzichtbar ist.
In diesem Artikel erfahren Sie, was genau der SAFe® DevOps Health Radar ist und wofür Sie ihn einsetzen können.
Der DevOps Health Radar ist ein Assessment, um Ihren aktuellen Stand zu bewerten und herauszufinden, wo Sie sich momentan in Bezug auf DevOps befinden. Er besteht aus vier Dimensionen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand. Jede dieser Dimensionen umfasst wiederum vier Aktivitäten. Bei Continuous Exploration sind das beispielsweise Hypothesize, Collaborate, Research & Architect und Synthesize.
Verify ist ein entscheidender Schritt im SAFe for DevOps Health Radar. Nachdem wir unser Paket in die Produktionsumgebung deployed haben, müssen wir sicherstellen, dass die neue Funktionalität korrekt funktioniert und die Integrität und Robustheit des bestehenden Systems nicht beeinträchtigt. Erst nach dieser Verifikation können wir die neuen Features bedenkenlos für die Endbenutzer freigeben. In diesem Video erkläre ich, was der Verify-Schritt umfasst und wie er sich in die gesamte Continuous Delivery Pipeline einfügt.
Viele Unternehmen setzen nach wie vor auf jährliche Planungszyklen mit grossen Vorab-Budgets, Meilenstein-Gates im Wasserfall-Stil und Business Cases, die nur geschrieben werden, um Budgets zu sichern. Das Ergebnis ist häufig eine massive Überladung an Initiativen, schlechte Qualität, Projektverzögerungen und eine fundamentale Diskrepanz zwischen Output und tatsächlichem Business Impact. In diesem Vortrag zeigen mein Kollege und ich, wie wir bei Zühlke Engineering Lean Portfolio Management eingeführt haben, was wir in unserem ersten MVP nach sechs Monaten erreicht haben und wo wir als Nächstes hinwollen.
Wie kann Strategie transparent, lean und skalierbar in Umsetzung übersetzt werden?
Worum es geht # In dieser Session teilen wir, wie Zühlke Lean Portfolio Management (LPM) basierend auf SAFe eingeführt und an den organisatorischen Kontext angepasst hat. Wir zeigen, wie wir ein MVP für LPM aufgebaut haben, indem wir Portfolio-Kanban, transparentes Epic- und Roadmap-Management und gruppenweite OKRs kombiniert haben, um strategische Ausrichtung und Entscheidungsfindung zu verbessern.
Deploy ist ein kritischer Schritt im SAFe for DevOps Health Radar. Nachdem wir ein deploybare Paket erstellt und es in einer Staging-Umgebung getestet haben, wollen wir nun unsere Änderungen kontinuierlich in die Produktionsumgebung deployen. Das Ziel ist es, mit hoher Frequenz und niedrigem Risiko zu deployen. In diesem Video erkläre ich, wie wir das erreichen und welche Praktiken Continuous Deployment ermöglichen.
Stage ist der Schritt im SAFe for DevOps Health Radar, in dem wir die finale Validierung vor dem Produktionsgang durchführen. In der Staging-Umgebung führen wir User Acceptance Tests durch, zeigen System Demos für unsere Stakeholder und verifizieren, dass alles wirklich produktionsbereit ist. In diesem Video erkläre ich, was der Stage-Schritt umfasst und warum er für eine zuverlässige Delivery Pipeline unverzichtbar ist.
In diesem Artikel erkläre ich, was Test End to End innerhalb des SAFe® DevOps Health Radars bedeutet und warum es für die Lieferung hochwertiger Software unverzichtbar ist. Bitte beachten Sie, dass alles hier Besprochene unter der Lizenz von Scaled Agile steht und dass das Scaled Agile Framework als Toolbox zu verstehen ist. Nehmen Sie daraus, was zu Ihren Bedürfnissen passt und Ihre Probleme löst.
Build ist der Schritt im SAFe for DevOps Health Radar, in dem committed Code kontinuierlich integriert, getestet und zu einem deploybaren Artefakt mit eingebauter Qualität verarbeitet wird. In diesem Video erkläre ich, was der Build-Schritt umfasst, warum Continuous Integration wichtig ist und wie Techniken wie Gated Commits und statische Sicherheitsanalyse helfen, Qualität bei hoher Geschwindigkeit aufrechtzuerhalten.
