Software Produktbereitstellung Prozess: Ein phasenweiser Leitfaden für Technologie-Führungskräfte

Was ein Software-Produktentwicklungsprozess eigentlich ist

Ein Software-Produktbereitstellungsprozess ist der strukturierte Weg, der ein Produkt von einer validierten Idee zu einem Live-Release und einem messbaren Geschäftsergebnis führt. Es definiert die Phasen, Übergaben, Rollen und Entscheidungspunkte, die die Aktivität über den gesamten Lebenszyklus der Software Delivery leiten.

Dieser Artikel enthält eine kurze Definition, um die Diskussion zu begründen. Wenn Sie genauer wissen möchten, was Software-Produktbereitstellung ist und warum es so wichtig ist, lesen Sie Was ist Software-Produktbereitstellung? Der vollständige Leitfaden. Hier konzentrieren wir uns darauf, wie der Prozess in der Praxis funktioniert - Phase für Phase.

Dies ist ein organisatorischer Prozess, nicht nur eine Softwareentwicklung. Dies umfasst:

• Produktentscheidungen
• Quality ownership
• Release Koordination
• Messung des Ergebnisses

Es verbindet das Produktteam, die Technik und das Management durch eine gemeinsame Arbeitsweise.

Das Ziel eines starken Software Delivery-Prozesses ist es, die Dinge klar und einfach zu halten. Es unterstützt den Flow, schnelles Feedback und bessere Entscheidungen, ohne sich in bürokratische Kontrollpunkte zu verwandeln.

Die fünf Phasen der Software-Produktbereitstellung

Der Prozess der Software-Produktbereitstellung folgt einer klaren Abfolge. Jede Phase beginnt mit definierten Einstiegskriterien und endet mit einem Entscheidungspunkt, der die Bereitschaft zum Weitermachen bestätigt.

Diese Phasen sind flexibel. Die Teams können sie je nach Reifegrad der Organisation komprimieren oder überlappen. In hochleistungsfähigen Continuous-Delivery-Umgebungen können die Phasen 3 bis 5 mehrmals am Tag ablaufen und sich überschneiden.

Dies funktioniert, wenn es eine klare, kontinuierliche Lieferung Governance gibt, mit definierten Verantwortlichkeiten, automatisierten Kontrollen und vereinbarten Kriterien, die Entscheidungen leiten, ohne die Teams zu bremsen.

Die Phasenstruktur dient hier nur der Übersichtlichkeit. Sie können es als Leitfaden verwenden und es dann an die Lieferkadenz Ihres Teams anpassen.

Phase 1: Entdeckung & Strategische Ausrichtung

Das Ziel der ersten Phase ist es, zu bestätigen, dass die Initiative ein echtes Kundenproblem anspricht und mit den strategischen Prioritäten übereinstimmt, bevor eine ernsthafte Softwareentwicklung beginnt.

Zu den wichtigsten Aktivitäten gehören:

1. Kunden-/Benutzerforschung und Problemvalidierung
2. Stakeholder-Ausrichtung auf Problemumfang und Erfolgskriterien
3. Entwicklung eines Business Case mit messbaren Ergebnissen (nicht nur Outputs)
4. Definition von Erfolgsmetriken in Verbindung mit Kunden- und Geschäftsergebnis
5. Abhängigkeitsdiagramm und erste Machbarkeitsbewertung

Der 2024 Accelerate State of DevOps Report von DORA zeigt, dass nicht die Performance, sondern die Verbesserung der Schlüssel zu den besten Ergebnissen ist. Das funktioniert nur, wenn der Erfolg frühzeitig definiert wird.

Das Produktmanagement leitet diese Phase.

Zu den Nebenrollen gehören:

• PMO- oder Portfoliomanagement für initiativübergreifende Transparenz, Ressourcenprognosen und Abhängigkeitsdiagramm im gesamten Portfolio
• Technische Leitung für den Beitrag zur Machbarkeit
• Design für die Entdeckungsforschung

Bevor Sie weitermachen, brauchen die Teams einige klare Antworten. Ist das Problem validiert? Ist der Business Case mit messbaren Erfolgskriterien genehmigt? Ist die Lösung machbar? Wenn nicht, bleiben Sie bei der Entdeckung. Wenn ja, gehen Sie zur Planung über.

Phase 2: Planung & Engagement

In der Phase 2 geht es darum, eine validierte Idee in einen Lieferungsplan mit festgelegten Meilensteinen, zugewiesenen Kapazitäten und geordneten Abhängigkeiten im gesamten Software Delivery-Prozess umzusetzen.

Hier legen die Teams auch die Gates für die Lieferphasen fest. Dabei handelt es sich um klare Kontrollpunkte mit vereinbarten Kriterien, die die Teams erfüllen müssen, bevor die Arbeit weitergeht.

Zu den wichtigsten Aktivitäten gehören:

1. Verfeinerung des Umfangs und Backlog-Priorisierung
2. Sprint-/Iteration Planung oder Release Trains Planung
3. Zuweisung von Teamkapazitäten und Engagement
4. Reihenfolge der Abhängigkeiten zwischen Teams
5. Definition von "fertig" für Entwicklung und Qualitätsvalidierung festgelegt
6. Ausrichtung der Interessengruppen auf Meilensteintermine und Kompromisse beim Umfang

In dieser Phase ist ein transformatorisches Management unerlässlich, nicht nur um die Beteiligten mit Ergebnissen zu verbinden, sondern auch um diese Ergebnisse zu optimieren. Wenn ein Unternehmen die transformationale Management um 25% erhöht, verbessert sich die Teamproduktivität um 9% (Quelle: DORA's 2024 Accelerate State of DevOps Bericht). Das beginnt hier.

Der Produktmanager und der technische Leiter sind gemeinsam verantwortlich. Das Produkt setzt Prioritäten. Das Engineering bestätigt Kapazität und Machbarkeit.

Zu den Nebenrollen gehören:

• PMO / Portfoliomanagement für teamübergreifende Koordination von Abhängigkeiten, Meilensteinverfolgung und Vor- und Nachteile-Modellierung
• QS-Führer für die Festlegung von Qualitätskriterien in einer frühen Phase 2, und nicht erst zu einem späteren Zeitpunkt
• Release Manager für die Koordination der Release-Fenster

Bevor Sie weitermachen, brauchen die Teams einen Plan. Ist die Kapazität bestätigt? Sind Qualitätskriterien definiert? Sind die Interessengruppen aufeinander abgestimmt? Wenn nicht, beseitigen Sie die Lücken. Wenn ja, gehen Sie zur Entwicklung über.

Phase 3: Entwicklung & Integration

Hier wird die Aktivität gemacht. Dazu gehört das Erstellen, Überprüfen und Integrieren des Codes anhand des festgelegten Umfangs, wobei die Softwarequalität ständig überprüft wird.

Zu den wichtigsten Aktivitäten gehören:

1. Ausführung von Sprints/Iterationen
2. Code-Review und kollaborative Entwicklungspraktiken (z.B. Pair Programming, wo anwendbar)
3. Ausführung der Pipeline für die kontinuierliche Integration
4. Automatisierte Tests (Unit- und Integrationstests), während der Code zusammengeführt wird
5. QA-Engagement während des gesamten Prozesses, wie explorative Tests und Entwicklung von Testautomatisierung
6. Regelmäßige Produktüberprüfung von Arbeitssoftware

Der technische Leiter leitet diese Phase.

Zu den Nebenrollen gehören:

• Produktmanager für die Überprüfung funktionierender Software anhand von Abnahmekriterien und für Entscheidungen über Vor- und Nachteile beim Umfang
• QA-Leiter für die Qualitätsvalidierung und Testentwicklung

Bevor Sie weitermachen, überprüfen die Teams alles. Hat der zugesagte Umfang die Überprüfung, die Tests und die Produktabnahme bestanden? Wenn nicht, beheben Sie die Probleme. Wenn ja, gehen Sie zur Release-Bereitschaft über.

In Umgebungen mit kontinuierlicher Lieferung kann der Code in dieser Phase hinter Feature-Flags in die Produktion überführt werden. Der Fokus wird dann einfach. Ist es bereit für Benutzer?

Phase 4: Release-Readiness & Validierung

In dieser Phase soll sichergestellt werden, dass das Produkt die Erwartungen in Bezug auf Funktionalität, Performance und Compliance erfüllt, bevor die Benutzer es sehen. Zu diesem Zeitpunkt sollte sich nichts unsicher anfühlen.

Zu den wichtigsten Aktivitäten gehören:

1. Endgültige Validierung anhand der Akzeptanzkriterien
2. Performance- und Belastungstests (falls zutreffend)
3. Compliance- und Sicherheitskontrollen (falls zutreffend)
4. Defekt-Selektionierung und -behebung
5. Release-Kandidatenbestätigung
6. Überprüfung des Rollback-Plans

Die Verantwortlichen für diese Phase sind der QA-Lead für die Qualitätsfreigabe und der Release Manager für die Koordination.

Zu den Nebenrollen gehören:

• Technische Leitung bei der Behebung von Fehlern und Unterstützung des Software-Release-Prozesses
• Produktmanager für Entscheidungen über den Umfang und die Qualität von Vor- und Nachteile

Bevor Sie weitermachen, brauchen die Teams eine Bestätigung. Hat die Release die Qualitätsanforderungen erfüllt? Ist der Rollback-Plan verifiziert? Wenn nicht, kehren Sie zur Entwicklung zurück. Wenn ja, gehen Sie zum Release über.

Bei der kontinuierlichen Lieferung kann diese Phase kürzer oder automatisiert sein. Der Grad der Validierung sollte Ihrem Risikoprofil entsprechen.

Phase 5: Release & Geschäftsergebnismessung

In der Phase 5 besteht das Ziel darin, das System mit klarer Transparenz über den Zustand des Systems einzusetzen und dann zu bestätigen, dass das Produkt die zuvor definierten Geschäftsergebnisse erreicht.

Zu den wichtigsten Aktivitäten gehören:

1. Stufenweise Einführung (Kanarienvogel, prozentuale oder ringbasierte Deployment)
2. Überwachung des Deployments und Bereitschaft zur Reaktion auf Vorfälle
3. Rollback der Ausführung, wenn die Fehlerrate den Schwellenwert überschreitet
4. Merkmalsverwaltung (progressive Belichtung)
5. Post-Release Gesundheitsüberwachung
6. Messung der Ergebnisse anhand der Erfolgskriterien der Phase 1 (so schließt sich der Kreis)

Die Verantwortlichen für diese Phase sind der Release Manager für das Deployment und der Produktmanager für die Ergebnismessung.

Zu den Nebenrollen gehören:

• Engineering und SRE für die Verwaltung von Deployment-Strategien und die Reaktion auf Vorfälle
• QA-Leitung für die Validierung der Produktion

Nach dem Release überprüfen die Teams zwei Dinge.

• Ist das System auf der Grundlage von DORA-Metriken wie der Ausfallrate von Änderungen und der mittleren Zeit bis zur Wiederherstellung (MTTR) stabil?
• Hat der Freigabeprozess die in Phase 1 definierten Erfolgskennzahlen verbessert?

Diese Überprüfung sollte immer stattfinden. Es hilft den Teams zu verstehen, was funktioniert hat und woran es gescheitert ist. DORA-Metriken sind nicht nur für das Tracking von Releases gedacht. Sie spiegeln die Gesundheit des gesamten Lieferprozesses wider. Nutzen Sie sie, um Schwachstellen zu erkennen, den Flow zu verbessern und Probleme frühzeitig zu beheben, und nicht nur, um zu berichten, was nach dem Release passiert ist.

Verantwortungsmodell: Rollen im gesamten Software-Produktentwicklungsprozess

Woran scheitern Übergaben normalerweise?

Oft geht es um unklare Eigentumsverhältnisse. Ein Team schließt ab, ein anderes kommt hinzu, und niemand ist voll verantwortlich für das, was als nächstes passiert.

Ein einfaches Verantwortungsmodell löst das Problem. Es macht die Verantwortlichkeit klar, bevor die Aktivität beginnt, und nicht erst, wenn Probleme auftreten.

Dies ist kein vollständiger RACI. Es ist einfacher und entspricht eher der Arbeitsweise von Teams.

Jede Phase umfasst drei Rollentypen:

• Eigentümer: Verantwortlich für das Geschäftsergebnis und die endgültigen Entscheidungen.
• Unterstützend: Trägt Aktivität und Input bei.
• Informiert: Sie bleiben auf dem Laufenden und können Bedenken äußern.

Nachfolgend finden Sie eine Tabelle, in der die Rollen in allen fünf Phasen dargestellt sind:

Denken Sie jedoch daran, dass das PMO bzw. das Portfoliomanagement nicht für die Lieferphasen zuständig ist. Produkt und Technik leiten die Ausführung, während das PMO initiativübergreifend arbeitet. Sie verfolgen Abhängigkeiten, gleichen Kapazitäten ab und unterstützen das Governance Berichte.

Wie Galorath erklärt, legt die Governance fest, wie Entscheidungen getroffen werden, wer rechenschaftspflichtig ist und wie Informationen über den gesamten Lebenszyklus der Lieferung fließen. An dieser Stelle kommt der Beitrag des PMO ins Spiel.

In größeren Organisationen verbindet das PMO die Produkt-, Technik- und Geschäftsmanagement durch ein gemeinsames Betriebsmodell. Ihr Wert liegt in der Verknüpfung der Aktivität zwischen den Teams und im Aufdecken von Problemen, bevor sie sich auf die Lieferung auswirken, und nicht in der Verwaltung der Ausführung auf Phasenebene.

Anpassen dieses Frameworks an Ihren Kontext

Keine zwei Organisationen gehen die Lieferung auf die gleiche Weise an. Das Framework bleibt konsistent, aber wie Sie es anwenden, hängt von Ihrem Kontext, Ihrer Teamzusammensetzung und Ihren Beschränkungen ab.

• Große Unternehmen: Mehr Teams bringen mehr Abhängigkeiten mit sich. PMO oder Portfoliomanagement verbindet die Aktivität über Initiativen hinweg, sorgt für Transparenz, zeigt Risiken frühzeitig auf und unterstützt eine sichere Entscheidungsfindung. Das Ziel ist eine vorhersehbare Lieferung in der gesamten Organisation.
• Startups und kleine Teams: Die Rollen können sich überschneiden. Eine Person kann für das Produkt und die Technik zuständig sein, und es gibt möglicherweise keine dedizierte QS. Die Phasen gelten nach wie vor.
• Regulierte Branchen: Die Phase 4 umfasst häufig formale Abnahmen, Prüfpfade und Compliance-Kontrollen. Definieren Sie diese im Voraus als Teil Ihrer Qualitätskriterien.
• Continuous Delivery Teams: Die Phasen 3-5 können mehrmals am Tag laufen. Die Schritte können sich komprimieren oder überschneiden, aber die Eigentumsverhältnisse müssen an jedem Punkt klar bleiben.

Dieses Framework ist ein Ausgangspunkt. Passen Sie die Rollen an Ihre Struktur an, aber halten Sie die Verantwortlichkeiten klar. Es sollte toolübergreifend funktionieren.

Ob Sie nun Entwicklungstools wie Jira, Azure DevOps, GitHub oder eine Mischung davon verwenden, der Prozess sollte nicht von den Tools abhängen. Sie unterstützen die Ausführung, aber Koordination und Transparenz müssen auf der Organisationsebene definiert werden und dürfen nicht den Tools selbst überlassen werden.

Häufige Fehlerquellen bei der Software-Produktbereitstellung

Wo kommt es normalerweise zu Problemen bei Lieferungen?

• Verwechslung der Eigentümerschaft: Koordination wird mit Eigentum verwechselt. Das PMO oder die Governance übernimmt die Kontrolle, und die Verantwortlichkeit wird unklar. Produkt und Technik sollten sich um den Lieferprozess kümmern, während das PMO die Transparenz und Koordination der Abhängigkeiten zwischen den Initiativen unterstützen sollte.
• Späte Qualitätskriterien: "Fertig" wird nach Beginn der Entwicklung definiert. Dies führt zu Unstimmigkeiten bei der Release darüber, was fertig ist.
• Unbestätigte Kapazität: Die Pläne sehen solide aus, aber die Teams waren nicht vollständig aufeinander abgestimmt. Die Arbeit gerät mitten im Sprint ins Stocken, und die Verpflichtungen fallen auseinander.
• Keine Geschäftsergebnismessung: Das Produkt wird ausgeliefert, aber niemand überprüft die Ergebnisse. Es gibt keinen Feedback-Loop und kein Lernen.
• Keine Validierung der Entdeckung: Teams verpflichten sich, bevor sie das Problem bestätigt haben. Die Aktivität geht schnell, aber in die falsche Richtung.

Bauen Sie einen funktionierenden Lieferprozess auf

Ein Software-Produktentwicklungsprozess funktioniert nur, wenn jede Phase klar definiert ist. Sie brauchen definierte Verantwortlichkeiten, klare Einstiegskriterien und eine ausdrückliche Entscheidung, bevor die Aktivität voranschreitet.

Zum Beispiel:

• Das Produktmanagement ist für das "Was" und "Warum" verantwortlich.
• Technik liefert das "Wie"
• QA validiert Qualität
• Release koordiniert Deployment
• Das PMO bietet eine portfolioübergreifende Transparenz, die es den Führungskräften ermöglicht, mit Zuversicht zu steuern und frühzeitig zu handeln, wenn Risiken auftreten.

Verwenden Sie dieses Framework als Ausgangspunkt. Passen Sie es an Ihre Struktur und Ihren Arbeitsrhythmus an, aber halten Sie die Verantwortlichkeit klar.

Die Geschäftsergebnismessung schließt den Kreis. Es bestätigt, ob der Release echte Ergebnisse geliefert hat, nicht nur Output. Ohne sie liefern Teams immer wieder neue Funktionen aus, ohne zu erfahren, was sie bewirken.

Auf Unternehmensebene entsteht Vorhersehbarkeit durch die Verknüpfung von Strategie und Ausführung über Teams und Toolchains hinweg, nicht durch erzwungene Standardisierung.

Hier finden Sie eine einfache Checkliste für die Bereitschaft zur Lieferung, die Sie verwenden können, bevor Sie weitermachen.

Sehen Sie, wie Planview Technologieführern dabei hilft, die Strategie mit der Ausführung über Teams und Toolchains hinweg zu verbinden. Sie erhalten die Transparenz, um schneller zu liefern, das Vertrauen, um genaue Zusagen zu machen, und die Beweise, um die Wirkung zu belegen. On-Demand-Demos ansehen