Vom Versionsmanagement zum Releasemanagement mit JIRA · Vom Versionsmanagement zum Releasemanagement mit JIRA 21.06.2017 11 Fachliche Anforderungsliste: 1. Abbildung von zentralen

21.06.2017 1

Vom Versionsmanagement zum Releasemanagement mit JIRA

Anja Koerber, Frank Wollert, Rolf Lader

AGENDA1. Über Otto (GmbH & Co. KG)2. Herleitung der Anforderungen aus dem (zentralen) Releasemanagement3. Lösungsansatz & Umsetzung4. Vom Projekt zum Produkt

21.06.2017Vom Versionsmanagement zum Releasemanagement mit JIRA 2

1. Über Otto (GmbH & Co. KG)2. Herleitung der Anforderungen aus dem (zentralen) Releasemanagement3. Lösungsansatz & Umsetzung4. Vom Projekt zum Produkt


AGENDA

Vom Katalogversender zumE-Commerce-Profi


MultimediaHaushalt

Küche

Möbel

Heimtextilien

BaumarktSpielzeug

Sport

WäscheBademoden

SchuheHerrenmode Damenmode

Große Bandbreite an Produkten und Marken

OTTO – die Nr.1 in Fashion & Lifestyle*


*Distanzhandel, B2C, GFK-Zahlen 2014

6.600Marken (Eigenmarken und viele Premium Fremdmarken)

Über 2,4 Mio. Artikelpositionen online

Riesiges Produkt-Portfolio, von Mode, Lifestyle, Fashion über weiße Ware und Multimedia, bis hin zu Baumarkt, Küche, Möbel, Spielzeug120

Spezialkataloge

Schaffte als einzige Bigbook-Company den Sprung in die digitale Welt

8 Spezialshops

Großer und treuer Kundenbestand


Über 6 Millionenaktive Kunden

20 MillionenBestellungen pro Jahr

fast 2 MillionenVisits pro Tag



AGENDA

Status Quo


➢ 700+ Anwendungen➢ 3000+ Schnittstellen

Hoch automatisierter Order2Cash-Prozess liefert zyklisch alle 6 Wochen in einem zentralen Release

➢ Parallel werden pro Release zwischen 15-30 Projekte geliefert

➢ 50% davon betreffen mehr als eine Anwendung

➢ Alle anderen Anwendungen liefern dezentral

➢ JIRA wird beim Großteil der Anwendungen als Tool zur Unterstützung der Entwicklung eingesetzt

➢ Treiber für Veränderungen Reduzierung „Time to Market“ und Feedbackzeiten

➢ dezentrale Lieferfähigkeit stärken

Gewachsene Systemlandschaft der zentralen Abwicklungssysteme

Überblick über Interessen unterschiedlicher Stakeholder


Es erfolgt ein kontinuierlicher Strom von Softwarelieferungen in die Praxis

(zentrales) Releasemanagement

Projektleiter Produktmanager (Anwendung)

IT-Management

• Muss Releases des Projektes auf den unterschiedlichen Produkten managen

• Muss Projekte für zentrale Releases melden und managen

• Interesse an allen Releases der Produkte, zu denen er Abhängigkeiten (SST) hat

• Muss Abhängigkeiten, der auf seinem Produkt laufenden Projekte, managen

• Verkürzung Time to Market bei konstanter Stabilität• Shift von projektorientierter zu produktorientierter

Entwicklung

• Enabling der Produkte für dezentrale Lieferwege, bei gleicher Stabilität

• Managen des zentralen Releases und Durchsetzung gemeinsamer Standards

Abhängigkeiten von Release- und Projektplanung


Pipeline zentrales Release

Pipeline Produkt-release xy

Durchführung zentraler Releases folgen einem strikten Timeboxing

Praxisstrang

Teststrang

Entwicklungsstrang

• Zentrale Releases haben einen hohen Abstimmbedarf und werden auf Jahresbasis geplant und kommuniziert

• Produkte haben unterschiedliche Lieferzyklen und nehmen wahlweise am zentralen Release teil

Releaseplanung:

• Releases und Projekte sind zunächst unabhängige Planungselemente

• Projekte zielen im Verlauf auf bestimmte Releases. Verschiebungen in Projekten verschieben keine zentralen Releases

Projektplanung:

Ziele des Projektes


Fachliche Anforderungsliste:

1. Abbildung von zentralen Releases als Planungselement in JIRAa) Unabhängige Planung von Release und Projektenb) Automatisierte Statusübergänge von Releases zu den Zeitpunkten Scopefreeze,

Codefreeze, Release und Archivierungc) Zuordnung von Releases zu Entwicklungsprojektend) Verknüpfung auf Storyebene mit dem Entwicklungsprojekt zugeordneten

Releasese) Identifikation aller Storys, welche einem Release zugeordnet sind (Releasenotes)

2. Darstellung verschiedener Releases (zentral & dezentral) in einem individualisierbarem Releasekalender



AGENDA

Lösungsansatz & Umsetzung


Technischer Lösungsansatz:

1. Releases werden als JIRA-Vorgänge umgesetzt a) Dadurch können JIRA-Versionen vom JIRA-Projekt entkoppelt werden. Das

Versionsmanagement Plugin von CatWorkX wurde als Ausgangsbasis verwendet und weiterentwickelt

b) Durch die Nutzung des Automation Plugin von Atlassian haben wir die automatischen Statusübergänge umgesetzt

c) Die Zuordnung von Releases zu Entwicklungsprojekten übernimmt ebenfalls das Versionsmanagement Plugin von CatWorkX

d) Durch die Versorgung der JIRA-Projekte mit zentralen Releases bleibt der Standard-Mechanismus für Versionen erhalten. Es entfällt lediglich die Versionspflege in den einzelnen JIRA-Projekten



Technischer Lösungsansatz:

e) Die Identifikation aller Storys, welche einem Release zugeordnet sind (Releasenotes), wurde aus dem Projektscope ausgeklammert

2. Die Visualisierung der einzelnen Releasekalender wurde auf Basis des Otto Release Calendar Plugins ebenfalls durch CatWorkX umgesetzt



Versionsmanagement Workflow:



Automation Plugin (Atlassian):



Versionsmanagement Plugin (CatWorkX):



Versionsmanagement Plugin (CatWorkX):



Otto Release Calendar (CatWorkX):



Otto Release Calendar (CatWorkX):



AGENDA

Vom Projekt zum Produkt


Produkt-Backlog:

e) Die Identifikation aller Storys, welche einem Release zugeordnet sind (Releasenotes), wurde aus dem Projektscope ausgeklammert

23

VIELEN DANK ☺

24

BACKLOG

Der Lebenszyklus eines Release

27.06.2017 25

PLANNED PRODUKTIONBEREIT ARCHIVIERTENTWICKLUNG IN TEST

Mit dem Arbeitsablauf für diesen Vorgangstyp wird der Lebenszyklus eines Release abgebildet. Die Grafik zeigt die verschiedenen Phasen die das Objekt in Jira durchläuft.

Im diesem Zustand wird ein Release noch mit den verantwortlichen Abteilungen abgestimmt.

Im diesem Zustand wird der geplante Funktionsumfang entwickelt.

Im diesem Zustand wird der umgesetzte Funktionsumfang qualitätsgesichert

Nach der Qualitätssicherung wird das Release in Produktion ausgerollt.

Nach der Ablösung durch ein Nachfolgerelease wird ein Release archiviert.

Status für Vorgänge im Jira-Releaseprojekt

Attribute eines Release

In diesem Zustand wurde das Release offiziell bereitgestellt und der Funktionsumfang geplant werden kann.

FeaturefreezeDatum, zu dem der Lieferumfang eines Release fertig geplant ist und die Entwicklung beginnt

Codefreeze: Datum, zu dem die Entwicklung des Release abgeschlossen ist und die Testphase beginnt

Rolloutdatum: Datum, zum dem das Release in Produktion ausgerollt wird

Archive Date: Dies wird automatisch durch das Rolloutdatum des Nach-folgereleases vorgegeben.

Folgende Attribute steuern den Lebenszyklus eines Release (Version):

• Zusammenfassung• Beschreibung• Featurefreeze• Codefreeze• Rollout• Archive Date

Releasekalender in Jira

27.06.2017 26

• Der Produktionszeitraum eines Release, errechnet sich automatisch aus dem Rolloutdatum des aktuellen Releases und dem Rolloutdatum des folgenden Releases.

• In Jira können die verschieden Phasen eines Releases über mehrere Kalender abgebildet werden.

Kombination mehrere Objekte (Releases) einer Phase in kalendarischer Darstellung

Documents

Vom Versionsmanagement zum Releasemanagement mit JIRA · Vom Versionsmanagement zum Releasemanagement mit JIRA 21.06.2017 11 Fachliche Anforderungsliste: 1. Abbildung von zentralen