Nachdem wir uns im ersten Teil mit dem „Warum“ eines lokalen Releasemanagements in großen Transformationsprojekten beschäftigt haben, werfen wir nun ein paar Schlaglichter auf zentrale Fragen des „Wie“.
Das Projekt-Release dient als Klammer für eine Momentaufnahme zusammengehöriger Artefakte – von Java-Anwendungen über Datenbank-Strukturänderungen bis hin zu Host-Komponenten. Diese „Buchführung“ hat mehrere Facetten:
- Delta-Betrachtung:
Nur wer die exakte Änderung am Gesamtsystem kennt, bleibt jederzeit auskunftsfähig über den Reifegrad und die Abhängigkeiten. - Status der Umgebungen:
Die „Buchführung“ sichert die lückenlose Auskunftsfähigkeit darüber, welche Softwarestände und Artefakt-Versionen aktuell auf welchem System Under Test aktiv sind. Das eliminiert zeitraubenden Blindflug bei der Fehlersuche im Testbetrieb. - Kumulierte Sicht:
Die Ergebnisse mehrerer Entwicklungsiterationen lassen sich so zu einer verlässlichen Basis für die spätere Einführungsplanung verdichten.
Enabler für das Testmanagement
Erst wenn das Releasemanagement mit seinem Input für die vollständige und konsistente Bestückung der Testumgebungen gesorgt hat, kann die fachliche Testphase einer Iteration beginnen. Das Releasemanagement schafft somit die stabile Bühne, auf der das Testmanagement die fachliche Abnahme effizient durchführen kann.
Das „schlüsselfertige“ Paket für den Go-Live
Kurz vor dem finalen Rollout schlägt die Stunde dieser akribischen Vorarbeit. Statt Informationen mühsam zusammenzusuchen, übergibt das Releasemanagement dem konzernweiten Einführungsmanagement ein schlüsselfertiges Paket. Da alle Installationsschritte, Abhängigkeiten und Konfigurationen über Monate hinweg in den Projektumgebungen erprobt und kumuliert dokumentiert wurden, wandert eine technisch geprüfte Blaupause direkt in das Einführungsdrehbuch. Das Risiko für den realen Produktions-Rollout wird drastisch reduziert.
Fazit: Die Rolle des technischen Releasemanagements als Vermittler zwischen den Welten ist nicht zu unterschätzen. Es ist der Enabler, der sicherstellt, dass externe Standardsoftware und interne Innovationen zu einem stabilen Produkt verschmelzen.
Wie moderieren Sie das Zusammenspiel zwischen externen Produktzyklen und interner Entwicklung in Ihren Programmen? Wir freuen uns auf Ihre Erfahrungen!
Nutzen Sie gerne die Schaltfläche, um direkt auf LinkedIn zu kommentieren.