GuidelinesRelease Management im FAST Kontext

Release-Management im FAST Kontext

Projektrelease versus IT-Release

Üblicherweise sind mit dem Begriff „Release“ technische Features beispielsweise eines Softwareprojekts verbunden.

FAST erweitert diesen Begriff gemäß 360° Requirement-Management um jegliche Art von Ergebnissen, die das Projekt erarbeitet hat:

  • Projekt-Setup

  • Dokumentationen wie Konzepte, Guidelines, Handbücher, Test Cases

  • Prozessbeschreibungen

  • Rollouts

  • usw.

Gleiche Versionsnummern für alle Ergebnisarten

Alle Ergebnisse durchlaufen eine Entwicklung. Bei Software ist dies im agilen Kontext mittlerweile Standard. Betrachtet man Projekte und Vorhaben aber mit der gleichen Perspektive, so durchlaufen nahezu alle Projektteile ebensolche „Versionsphasen“.

Aus diesem Grund haben wir in FAST ein einheitliches Konzept einer Versionierung geschaffen, die es den beteiligten Teams ermöglicht, sich über Versionen zu verständigen und zu synchronisieren – unabhängig davon, ob es ein Softwareteam oder eher ein Team ist, welches an Objectives arbeitet, die nicht im Softwarekontext stehen.

So werden alle Entwicklungsstufen mit einer Versionsnummer versehen.

Typische Versionsnummern

 

 

 

Nummer

 

Bedeutung

 

v0.0 (Start)

Die Voraussetzungen sind geschaffen, es kann begonnen werden.

v0.1 (Prototyp)

Ein Prototyp ist erstellt.

Beispiele für unterschiedliche Ergebnisarten:

  • Konzept: Dokument angelegt, Struktur erzeugt

  • Schnittstelle: Die ersten Daten können übertragen werden.

v0.5 (Proof of concept)

Alle wesentlichen Bestandteile sind grundsätzlich entwickelt.

Man kann das Endergebnis erkennen. Ein Proof-of-Concept ist möglich.

Beispiele für unterschiedliche Ergebnisarten:

  • Konzept: Wichtigste Kapitel sind erstellt.

  • Schnittstelle: Die wichtigsten Datenobjekte können übertragen und verarbeitet werden.

  • Gesamt IT-System: Zentrale Datenmodelle und Schnittstellen sind entwickelt.

v0.8 (Beta)

Alle Bestandteile sind fertig entwickelt.

Ein Review kann durchgeführt werden.

Beispiele für unterschiedliche Ergebnisarten:

  • Konzept: Das nahezu vollständige Dokument kann zum Review an einen größeren Teilnehmerkreis verteilt werden.

  • Schnittstelle: Die Schnittstelle kann getestet werden (entweder in einer Testumgebung, oder für einen Testzeitraum aktiviert und in realer Umgebung).

v1.0 (Nutzung)

Das Ergebnis kann genutzt werden.

Beispiele für unterschiedliche Ergebnisarten:

  • Konzept: Das Konzept wird „released“ als Fertig vorgestellt.

  • Schnittstelle: Die Schnittstelle wird aktiviert und in Liveumgebung eingebunden.

v1.x

Weiterentwicklungen, Optimierungen

 

v2.0

Wichtige und signifikante Neuerungen oder Änderungen

 

 

Anwendung des FAST Release-Managements in verschiedenen Umgebungen

Showcase

Ziel ist es, schnell einen ersten Eindruck über eine Lösung zu erhalten. Ein gut vorbereiteter Showcase ist in der Regel ausreichend für die Auswahl einer Standard-Softwarelösung aus einem größeren Kreis von Lösungen. Er ist besser geeignet als ein breit angelegter Proof-of- Concept mit mehr als 2 „finalen“ Lösungen.

#

Lieferobjekte (Beispiele)

V0.0 (Start)

Kurzes Lastenheft, Anforderungsbeschreibungen, Ausgewählte (wenige) Kundendaten und -anforderungen sind vorbereitet.

V0.1 (Prototyp)

Out of the box-System ist bereitgestellt, beim Anbieter gehostet.

V0.5 (Showcase)

Präsentation und „Durchspielen“ von UseCases am System durch das Kernteam

V0.8 (Beta)

ggf. Hinzunahme weiterer Userkreise für UAT

V1.0 (Abschluss)

Abschlusseinschätzung, ob Lösung für Anforderung nutzbar oder nicht

V1.x (MVP)

ggf. PoC und Vertiefung mit weiteren Usern, weiteren Prozessen oder Daten

Trash

Virtueller Meilenstein zur Klassifizierung von Anforderungen

Out-of-Scope, zukünftige Features, ….

 

 

Versionierung bei Softwareeinführung

Größere Softwarelösungen werden heute in der Regel aufgrund ihrer großen Komplexität nicht mit einem „Big Bang“, sondern iterativ eingeführt..

 

#

Lieferobjekte (Beispiele)

V0.0 (Start)

Vorbereitung abgeschlossen, z.B. Tools & Zugänge, Projekt-Setup geklärt, Ziele & Scope geklärt.

V0.1 (Prototyp)

Fachkonzepte sind erstellt, System ist installiert.

V0.5 (PoC)

Erste Implementierungen, Lasttest, UAT, Software und Integrator bestätigt

V0.8 (Beta)

Technische Implementierung abgeschlossen, UAT

V1.0 (GoLive)

Erste Inbetriebnahme, Schulungen

V1.x (RollOut)

Rollout und Erweiterungen im(!) Projektscope

Vx.y (Future)

Virtueller Meilenstein zur Klassifizierung von Anforderungen

Out-of-Scope, aber für Zukunft interessant (Future Scope)

Trash

Virtueller Meilenstein zur Klassifizierung von Anforderungen

Out-of-Scope, abgelehnte Anforderungen

 

 

Versionierung bei Konzeptionen, Analysen & Handlungsempfehlung

Im Vorfeld von Vorhaben kommt es häufig zu sogenannten Vorprojekten. Dies können vorgelagerte Untersuchungen, Konzeptionen oder auch eine Analyse & Handlungsempfehlung sein. Auch diese lassen sich dem Versionierungskonzept von FAST zuordnen.

 

#

Lieferobjekte (Beispiele)

V0.0 (Start)

Vorbereitung abgeschlossen, z.B. Tools & Zugänge, Projekt-Setup geklärt, Ziele & Scope geklärt

V0.5 (IST Review)

Interviews abgeschlossen, sonstige Objekte analysiert, Ergebnisse konsolidiert und präsentiert

V0.8 (Beta)

Projekt ausgearbeitet (Planung, Kosten, Scope)

Handlungsempfehlung im Projektteam abgestimmt

V1.0 (GoLive)

Handlungsempfehlung finalisiert und präsentiert

Vx.y (Future)

Virtueller Meilenstein zur Klassifizierung von Anforderungen

Out-of-Scope, aber für Zukunft interessant (Future Scope)

Trash

Virtueller Meilenstein zur Klassifizierung von Anforderungen

Out-of-Scope, abgelehnte Anforderungen

 

 

Fraktale Versionierung

Häufig setzt sich ein Ergebnis aus vielen Unterergebnissen zusammen. Diese wiederum können sich auch aus weiteren Unterergebnissen zusammensetzen. Diese Ergebnisse und deren Teile tragen auch alle Versionsnummern. Auf diese Weise entsteht eine fraktale Versionierung.

So sind zu einem Softwarerelease mehrere „Epics“ zu releasen, in denen mehrere User Stories fertiggestellt werden.

Dies bedeutet, dass Versionierungsprinzip in FAST kann auf verschiedenen Ebenen (fraktal) zur Anwendung kommen. Wie tief diese Versionierung angewendet wird, obliegt dabei den einzelnen Teams. Eine Versionierung auf Task-Ebene ergibt aber sicherlich keinen Sinn, da diese ja in der Timebox „Sprint“ verortet, also möglichst in einer Iteration erledigt sein sollte. Dies kann aber auch schon für die Ebene „UserStory“ gelten. Häufig startet daher die Versionierung auf Ebene der Epics.

Beispiel SAP Schnittstelle in PIM Projekt

Das Beispiel zeigt, dass die Versionierungen auf den einzelnen Ebenen zeitlich versetzt die Phasen und damit auch die Versionsnummern durchlaufen. Durch das gleiche „fraktale“ Prinzip aber wird die Transparenz geschaffen, welche Objectives sich in welcher Versionionierungsphase befinden, um beispielsweise für das übergeordnete Epic die Version 1.0 zu erreichen. Hierfür zeigen alle Objectives, die vorher schon den Status V1.0 erreicht haben, an, dass sie für das Gesamtrelease „ready“ sind.

Auf diese Weise bietet das fraktale Versionierungsprinzip in FAST eine gute Möglichkeit, auch in großen Vorhaben mit einer Vielzahl von Epics eine für alle gemeinsame verlässliche Basis zu liefern.