So strukturieren Sie Ihren Release-Management-Prozess für eine bessere IT-Agilität

Sie können den Release-Management-Prozess Ihres Unternehmens niemals einer zu genauen Prüfung unterziehen.

Jegliche Schwachstellen führen zu Software, mit der der Endbenutzer nicht zufrieden ist und die er möglicherweise sogar ablehnt.

Aus diesem Grund haben so viele Unternehmen in das Hinzufügen agiler Komponenten zu diesem wichtigen Unternehmensprozess investiert.

Bevor Sie sich jedoch beeilen, das Gleiche zu tun, lassen Sie uns darüber sprechen, was Ihr Release-Management-Prozess unbedingt beinhalten muss und wie ein wichtiges Tool dazu beitragen kann, dass er agil wird.

Changemanagement vs. Release-Management

Changemanagement und Release-Management sind sich ebenso sehr ähnlich – miteinander verbunden – aber nicht dasselbe. Es ist wichtig, dass Sie die beiden nicht verwechseln, sonst wird Ihr Release-Management-Prozess unnötigerweise leiden.

Wie Sie bereits wissen, beziehen sich Release-Aktivitäten auf Dinge wie:

• Konfigurationsmanagement
• Release- und Deployment-Management
• Konzeption
• Planung
• Rollout-Planung
• Test-Kommunikation

Auf der anderen Seite würde die gleiche High-Level-Übersicht der Change-Aktivitäten Dinge umfassen wie:

• Änderungen bewerten
• Änderungen autorisieren
• Änderungen anfordern
• Änderungen überprüfen

Der Release-Management-Prozess befasst sich hauptsächlich mit der Bereitstellung eines Projekts mit seinem Zeitplan und seinen Ausführungsplänen.

Das Change-Management – in der Regel über ein Change-Approval-Board – konzentriert sich auf die Autorisierung von Änderungen für kontrollierte Umgebungen.

Werfen wir einen genaueren Blick auf beide, um besser zu verstehen, worin sie sich unterscheiden.

Changemanagement

Größtenteils sollten Ihre Changemanagement-Protokolle für die Überführung von brandneuen Initiativen und Verfahrensanpassungen konzipiert sein und diese von den Entwicklungsprozessen in den Betrieb bringen.

Das Hauptziel Ihres Changemanagement-Prozesses sollte darin bestehen, die von Ihrem Team verwendeten Methoden sowie die von Ihnen befolgten Verfahren zu standardisieren, so dass jede einzelne Veränderung effizient und zeitnah behandelt wird.

Wir werden etwas später auf die Standardisierung näher eingehen.

Durch die Standardisierung dieser Bemühungen können Sie die potenziellen Auswirkungen, die eventuell durch die Änderung entstehende Störungen auf die Servicequalität haben könnten, minimieren. Dadurch verbessern Sie zudem auch den täglichen Betrieb Ihrer Organisation.

In Ihrer Konfigurationsmanagementdatenbank werden Änderungen an den CIs (Configuration Items), welche Teil der Live-Produktionsumgebung Ihres Unternehmens sind, oder weitere Änderungen, die unter die Änderungskontrolle fallen, durch den Changemanagement-Prozess gesteuert und eingeführt.

Im Allgemeinen sind IT-Abteilungen für den Betrieb und den Schutz von Staging- und Produktionsumgebungen über die Änderungskontrolle verantwortlich. Diese Verantwortung endet jedoch normalerweise mit den Produktionsumgebungen.

Release-Management

Das Release-Management befasst sich hauptsächlich damit, wie Änderungen die Pre-Produktionsumgebungen durchlaufen. Das letztendliche Ziel besteht darin, dies zu gewährleisten und schließlich zu einem erfolgreichen Release und Deployment dieser Änderungen in die Produktions-IT-Umgebung zu führen. Zudem sollen dabei so wenig Unterbrechungen wie möglich verursacht werden.

Eine Reihe von Änderungen wird in einer Gruppe zusammengefasst, die als „Releases“ bezeichnet wird. Diese Gruppierungen basieren auf definierten gemeinsamen Merkmalen der Änderungen in der Gruppe.

Das Release-Management versucht, einen proaktiveren und vorhersagbareren Changemanagement-Prozess zu schaffen. Es ist absolut notwendig für die Bewältigung der Menge der gegenseitig abhängigen Änderungen innerhalb eines Unternehmens.

Pre-Produktionsumgebungen fallen nicht unter die Parameter eines IT-Betriebs für die Changemanagement-Kontrollen. Dies würde beispielsweise beinhalten:

• Akzeptanztests
• Entwicklungsprozesse
• Integrationstests
• Performancetests
• Systemtests

Aufgrund der Geschwindigkeit, mit der sich diese Arten von Umgebungen normalerweise während des Erstellens und Testens ändern, ist es wichtig, dass Sie das richtige Gleichgewicht zwischen Agilität, Kontrolle und Flexibilität finden.

In der Regel wählt der Projekt- oder Release-Manager die Richtlinien für das Management dieser Pre-Produktionsumgebungen aus.

Der Release-Management-Prozessablauf

Der Release-Management-Prozessablauf ist ziemlich unkompliziert, obwohl er in zahlreiche Unterabschnitte aufgeteilt werden kann.

So sieht der Ablauf für die Einführung von Änderungen in Ihrer IT-Umgebung aus:

• Genehmigte Änderung
• Release-Planung
• Release-Erstellung
• Akzeptanztests
• Release-Vorbereitung
• Release-Freigabe und Deployment

Der Job des Release-Managers

Der Ablauf des Release-Management-Prozesses muss von einem Manager überwacht werden, obwohl sie sich dazu entschließen könnten, einen Teil ihrer Aufgaben an Untergebene zu delegieren.

Dies ist normalerweise der Fall, wenn der Umfang des Projekts wächst.

Nichtsdestotrotz umfasst die Aufgabe des Release-Managers typischerweise folgende Aufgaben:

• Terminplanung, Koordination und Management von Releases im gesamten Unternehmen für mehrere Anwendungen über verschiedene Portfolio-Ströme hinweg
• Erstellung des IT-Release-Kalenders in enger Zusammenarbeit mit den IT-Release-Managern aus verschiedenen Portfolios in der gesamten IT sowie einer zentralisierten Übersicht aller Releases
• Unterstützung beim Management von Projekten und Wechselbeziehungen zur Einhaltung von Meilensteinen, um sicherzustellen, dass die Integrität des Releases gemessen werden kann
• Risiken bewältigen und Probleme beheben, die Auswirkungen auf Releaseumfang, -qualität und -zeitplan haben
• Durchführung von Release-Readiness-Reviews, Business-Go/No-Go-Reviews und Milestone Reviews
• Teilnahme an CAB-Meetings, um den Releaseumfang und/oder -hemmnisse zu besprechen
• Erstellen und Präsentieren von Berichten sowie Meeting-Protokollen für das Senior IT Management, wie den CIO und CTO sowie die Unternehmensführung

Die 3 größten Herausforderungen für den Release-Manager

Release-Manager zu sein bedeutet, sich allen Arten von Herausforderungen zu stellen. Viele von ihnen gibt es nur im jeweiligen Projekt, aber die drei, die am häufigsten vorkommen, sind:

• Mangel an Einblick in die Arbeit aller Beteiligten
• Governance und Regulierung (d. h. Sind alle Qualitätsmaßnahmen erfolgt?)
• Sicherstellen, dass jeder erforderliche Schritt durchgeführt wurde, um das gewünschte Ergebnis zu erzielen (d. h., habe ich das gebaut, wonach der Kunde gefragt hat?)

Ohne die mit diesen Herausforderungen verbundenen Risiken zu bewältigen, kann ein Manager seinen eigenen Release-Management-Prozess leicht sabotieren.

Managen Sie das Risiko und nicht die Routine

Viel zu oft besteht die Versuchung für Release-Manager darin, sich vollständig auf die von ihnen eingeführten Routinen zu konzentrieren.

Stattdessen sollten sie die Qualität und den Umfang ihrer Releases mithilfe von Dashboards und Berichten über mehrere Projektwellen hinweg bis hin zu den Anforderungen für das Erreichen des Fertigstellungsstatus visualisieren.

Die Echtzeit-Risikoanalyse und die intelligente Testplanvalidierung können zur Optimierung der Testressourcen und zur Senkung der Störungsraten in der Produktion eingesetzt werden.

Die Status-Bereitstellung in Echtzeit für alle beteiligten Stakeholder führt zu kürzeren Durchlaufzeiten ohne größere Kompromisse.

3 Möglichkeiten, Ihren Release-Management-Prozess für mehr Agilität zu strukturieren

Jetzt, da wir alle nach der gleichen Definition eines Release-Management-Prozesses arbeiten, schauen wir uns an, wie wir Ihren verbessern können, so dass er ein viel höhere Maß an Agilität bietet.

Dafür gibt es drei wesentliche Voraussetzungen:

1. Standardisierung der Governance

Egal, welche Art von Businessmethode Sie verbessern möchten, der erste Ansatzpunkt ist die Standardisierung der Governance.

Dies gilt insbesondere dann, wenn es um Ihren Release-Management-Prozess geht, bei dem es so wichtig ist, dass Ihre Workflows und Compliance-Anforderungen alle den Q-Gate-Standards entsprechen.

Das Schöne an der Standardisierung ist, dass sie eine Automatisierung ermöglicht. Wo immer Sie können, sollten Sie sich die Automatisierung im gesamten Release-Management-Prozess zunutze machen. Dadurch werden Sie nicht nur Einsparungen (sowohl in Bezug auf Zeit und Geld) sehen, sondern Sie können auch weniger Fehler erwarten, da die Plattformen nicht von menschlichem Versagen bedroht sind.

Natürlich verschafft dies Ihren Leuten auch die Zeit, sich auf die Release-bezogenen Aufgaben zu konzentrieren, die für ihre Vollendung deren jeweiligen Fähigkeiten erfordern.

Beispielsweise kann sich ein Unternehmen, dem es an Standardisierung fehlt, mit einem Entwicklungsteam abmühen, das seine Deployment-Pakete manuell bastelt.

Leider bedeutet dies, dass das neue Paket möglicherweise nicht mit dem vorherigen identisch ist. Es funktioniert möglicherweise nicht einmal richtig. Dies kann alle Arten von Problemen verursachen, nicht zuletzt eine unnötige Verzögerung, die den Rest des Lebenszyklus aufhält.

Die gute Nachricht ist, dass eine effektive Lösung nicht unnötig komplex sein muss. Sie können einfach Kriterien für Struktur und Akzeptanz für das betreffende Paket erstellen. Diese Kriterien müssen erfüllt sein, bevor das Paket deployt werden kann.

Wenn Sie zusätzlich mit Automatisierung arbeiten, werden Sie offensichtlich in der Folge sogar noch weniger Probleme haben, um die Sie sich sonst kümmern müssten. So können Sie den fertigen Code in kürzester Zeit und mit einem einzigen simplen Befehl packen, versionieren, testen und deployen.

Im Laufe der Zeit kann Ihr Team sogar Regressionstests mit jedem Entwicklungszyklus durchführen, um noch mehr Wege zur Verbesserung zu finden, indem mehr Governance implementiert wird.

2. Echtzeitüberwachung und Reporting

Einer der wichtigsten Grundsätze von Agile ist die Notwendigkeit, ein Projekt ständig zu überwachen und Berichte über seinen Fortschritt zu erstellen. Andernfalls könnten Sie viel Zeit und Geld in ein zwingend erforderliches Projekt investieren, nur um später zu erfahren, dass Sie das Ziel verfehlt haben.

Wie Sie vielleicht bereits wissen, wird ein Agile-Projekt in Sprints unterteilt. Jeder von diesen erfordert mindestens ein Ziel, obwohl es zwei oder mehr haben kann. Am Ende eines Sprints werden die erzielten Fortschritte an diesen Zielen gemessen.

Hier sind die besten Agile-KPIs, um Ihr Team auf Kurs zu halten:

• Abgeschlossene und committete Storys: Vergleichen Sie immer, wie viele Storys Sie während der Sprintplanung committet haben mit der Anzahl derer, die während der Sprint-Überprüfung als abgeschlossen identifiziert wurden. Dies wird es Ihrem Team erleichtern, zukünftig seine Fähigkeiten besser einzuschätzen.
• Mangement der technischen Schulden: Sie können dies auf verschiedene Arten messen, aber es beinhaltet normalerweise die Anzahl der gefundenen Bugs. Abhängig von Ihrem Projekt können auch andere bekannte Probleme enthalten sein.
• Teamgeschwindigkeit: Sie sollten wissen, wie konstant Ihr Team ist, so von einem Sprint zum nächsten. Ein einfacher Weg, dies zu tun, besteht darin, abgeschlossene Story-Punkte im aktuellen Sprint mit denen der vorherigen Sprints zu vergleichen.
• Kommunikation: Eine offene und ehrliche Kommunikation ist zwischen dem Scrum-Master, dem Product Owner, Mitgliedern Ihres Teams, Stakeholdern und Kunden unerlässlich. Sie müssen genau darauf achten, dass dies geschieht, und sofort einspringen, wenn dies nicht der Fall ist.
• Einhaltung von Best Practices: Hier geht es nicht nur um Scrum-Regeln, obwohl diese sicherlich wichtig sind. Sie sollten auch überwachen, um sicherzustellen, dass Ihr Team auch Entwicklungs-Best Practices einhält.
• Verständnis eines Jeden des Umfangs und des Zieles: Obwohl es kein Zweifel ist, dass es sich um eine subjektive Messung handelt (ähnlich wie bei der ehrlichen Kommunikation), ist es eine gute Idee, zu sehen, wie gut Ihre Produkt- und Entwicklungsteams und der Kunde die Sprint-Storys und das verstehen. Letzteres ist typischerweise auf den gewünschten Kundennutzen ausgerichtet, der für eine Continuous Delivery gedacht ist, und ist objektiv in den Abnahmekriterien der Storys definiert. Der beste Weg, dies zu ermitteln, ist der tägliche Kontakt und die Interaktion mit dem Team. Die Verarbeitung von Kundenfeedback wird ebenfalls helfen.

Wie bereits erwähnt, wird die Standardisierung Ihr Release-Prozess-Management enorm verbessern. Auch wenn Automatisierung nicht immer eine Option ist, hilft die Erstellung und Implementierung von Standards bei jedem der oben genannten Bereiche.

3. Nachverfolgbarkeit der Anforderungen

Die Nachverfolgbarkeit der Anforderungen ist die systematische Verknüpfung, die es ermöglicht, Business-Anforderungen und die damit verbundene Erfüllung und Validierung zu verfolgen. Dazu gehört, sie sowohl rückwärts als auch vorwärts nachzuverfolgen.

Sie können beispielsweise damit beginnen, Business-Anforderungen ganz von Anfang an zu folgen. Sie können ihnen durch den gesamten Entwicklungsprozess und die Spezifikation folgen und dies bis zu ihrem späteren Release und Deployment fortsetzen.

Wenn Sie damit fortfahren, können Sie ihre Verwendung und sogar die fortlaufende Verbesserung erreichen.

Dies wird sicherlich hilfreich sein, aber wenn Sie es manuell versuchen, werden Sie feststellen, dass diese Hilfe einen erheblichen Preis hat. Der arbeitsintensive Prozess kann sich sogar als zu kostspielig erweisen. Genau wie die Automatisierung ist dies ein weiteres Beispiel für einen Teil Ihres Release-Prozessmanagement-Prozesses, der zweifellos von einer hochwertigen Plattform wie der unseren profitieren würde.

Die Ergebnisse werden es sicherlich der Mühe wert sein. Stellen Sie sich vor, Sie stellen fest, dass eine Reihe von Tests plötzlich anfängt, Probleme zu verursachen. Dank der Rückverfolgbarkeit, die zwischen den Tests und den damit verbundenen Anforderungen besteht, haben Sie kein Problem, die betroffenen Funktionen oder Features zu identifizieren.

Durch die Kombination der drei oben beschriebenen Prozesse mit Echtzeitinformationen zu Qualität, Umfang und Zeit können Release-Management-Prozessmanager fundierte Entscheidungen treffen, bevor sie in Produktion gehen.

Ein Anwendungsfallbeispiel

Sehen wir uns ein Anwendungsbeispiel an, um besser aufzuzeigen, wie gängige Probleme mit unserer Release Dynamix (RDx)-Lösung behoben werden können. Sie wurde entwickelt, um Organisationen dabei zu helfen, großartige Innovationen voranzutreiben, indem sie die Continuous Delivery von Business-getriebenen Änderungen mit verbesserter Geschwindigkeit und Einfachheit unterstützt.

Die Use Case-Probleme

In diesem Anwendungsfall gibt es zwei Hauptherausforderungen.

Diese sind:

Overhead

• Wasserfall-Delivery gegenüber langsamen, teuren und zeitaufwendigen Release-Zeitrahmen.
• Verteilte und regionale Releases – keine einheitlichen Methoden für den Release-Management-Prozess
• „Leuten hinterherlaufen“, um die Einhaltung der Richtlinien zu gewährleisten, ohne echte Kontrolle der Ausführung

Langsame Markteinfühungszeit und Produktionsrisiken

• Schwierigkeiten bei der Aufrechterhaltung globaler Geschäftsprozessanforderungen aufgrund verschiedener Fenster und Varianten von regionalen Releases
• Beeinträchtigungen für Produktion und Business wegen fehlender Einblicke in regionale Releases
• Schwierigkeit, auf dringende Geschäftsanforderungen zu reagieren
• Business-Probleme in Bezug auf große Projektfenster
• Überregionale Geschäftsprozesse und globale Systeme vergrößern die technische Komplexität

Die Use Case-Ziele

Für diesen Anwendungsfall waren die Ziele der Neuordnung:

• Schnellere Delivery für eine bessere Reaktion auf Business-Anforderungen und schnellere Markteinführung
• Kosteneffizienz – niedrigerer Arbeitsaufwand im Vergleich gegenüber dem ROI mit ständiger Verbesserung der Produktivität
• Schnell erreichte Qualität bei weniger Risiken für die Produktion

Die Use Case-Lösungen

Hier sind die 11 verschiedenen RDx-Features und die Transformationspfade, die sie in ihren jeweiligen Bereichen zur Verfügung stellen:

• Portfolio Management: Anforderungsströme werden im Portfolio verwaltet
• Release Calendar Management: Globaler IT-Release-Kalender, der für ALLE Regionen definiert und anwendbar ist
• Requirements Schedule: Der Umfang bevorstehender und zukünftiger Releases ist für alle regionalen und globalen Stakeholder sichtbar.
• Release Risk Cockpit: Verwalten Sie globale Echtzeit-Exceptions in einem einzigen kollaborativen Framework
• Release Quality Progress: Release-Umfang, Testabdeckung, Readiness und Durchführung der Projekte werden in Echtzeit überwacht.
• Release Approval Readiness: Globale Release-Methodik mit einheitlichen Meilensteinen für die Bereitschaftsanforderungen.
• Requirements Structuring: Aufteilung der Lean-Anforderungen (Epics), über Sprints hinweg, basierend auf Minimal-Viable-Product-Konzepten. Enger Handshake mit Business-Ownern.
• Demand Efforts Assessment: Während eines Releases werden die agilen Anforderungen ständig verbessert. Aus diesem Grund ist die Verbesserung der Bestrebungen im Vergleich zur festgelegten Kapazität (SCRUM-Team ist festgelegt) entscheidend für einen geplanten Releasezeitplan.
• Requirements Design and Specs: Anforderungsdefinitions-, -design- und spezifikationsdokumente werden als Teil des Entity Lifecycle-Ablaufs gehandhabt – einheitliche Übersicht über Inhalte, Entwicklungsprozesse und Qualität.
• Risk Management: Im Agile-Bereich werden Testplanvalidierungen und Codequalitätskorrekturen vor dem Wechsel zur Testausführung bewältigt.
• Requirements Traceability Matrix: Testausführung und Defekte können im Projekt- und Release-Bereich nachvollzogen werden. Verwenden Sie den RTM-Report, um die schlechte Qualität eines Release-Umfangs für Durchführung weiterer Aktionen, wie z. B. das Herausnehmen aus dem Release oder das Verschieben in das nächste Release, zu identifizieren.

Wir haben RDx speziell dafür entwickelt, die Komplexität und Engpässe zu beseitigen, die fast immer verhindern, dass wichtige Änderungen stattfinden. Als Ergebnis kann jedes Unternehmen, egal wie groß, leicht agil werden.

Es priorisiert eine kollaborative Umgebung, aber keine, die ausschließlich die Zusammenarbeit zwischen Entwicklern erleichtern soll. RDx wird auch die Zusammenarbeit zwischen allen Stakeholdern in Ihrem Release-Management-Prozess fördern..

Dies bedeutet, dass Ihre Organisation stetig Änderungen in hoher Qualität schnell veröffentlichen kann. Sie werden die Erwartungen Ihrer Anwender konsequent erfüllen und Ihr Business voranbringen.

Verbesserte Agilität mit Panaya

Your release management process is too complex to go completely human. Even if this were not the case, you would still take unnecessary risks by not properly auditing it to find ways to improve.

Fortunately, this does not have to mean a massive investment of time or money. As you’ve already seen in the above example, RDx is an enterprise agile delivery platform that lets you handle your entire process of changing applications, from creation to validation.

Finally, to start using Agile in your enterprise-level release management process, start with a demo of RDx . You’ll soon find that every step of your process becomes more agile, which will make your customers and your team much happier.