Projekte Schneiden

Post on 13-Apr-2017

24 views 1 download

Transcript of Projekte Schneiden

Projekte schneiden

Nutzen und Ansatz

Michael Küsters

oder: Wie man ein Projekt in Epics zerlegt

Warum sollte man Projekte schneiden?

2

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ec

t X

Wir brauchen ein neues Kundenpflege-System. Hier ist die Anforderung.

Wird gemacht. Ich melde mich in 29 Jahren, wenn es fertig ist.

Große Projekte:

1. Langwierig2. Hohe Kosten3. Später Nutzen4. Gebundene

Kapazitäten5. Hohes Risiko

Was bringt das Schneiden von Projekten?

3

Wir brauchen ein neues Kundenpflege-System. Bitte liefert stückweise.

Wird gemacht.Wir planen quartalsweise, was wir liefern.

Geschnittene Projekte:

1. Schnelle Erfolge2. Jederzeit Einsparungen

denkbar3. Risikominimierung4. Kapazitäten leicht

umplanbar5. Früher Nutzen

Prog

ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ec

t X

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj

ect X

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ec

t X

Wie kann man Projekte schneiden?

4

Was brauchst Du, damit Du quartalsweise vorgehen kannst?

Das Projekt muss in einzeln lieferbare Epics geschnitten sein, von denen jede einzelne in einem Quartal machbar ist!

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ec

t X

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ect X

Prog ress

Re

p ort …. [ }

Dev . [ ]

Test

Proj ec

t X

Ein Projekt teilt sich in verschiedene EpicsEpic = Abstrakte High-Level Anforderung

5

Wir brauchen ein neues Kundenpflege-System

Projekt

Ich will Kundendaten nicht doppelt pflegen! Ich brauche eine

einheitliche Sicht auf den Kunden!

Ich hasse die lange Wartezeit im Altsystem.

Epics

Verantwortlicher Stakeholder

Wie komme ich an Epics?

Schritt 1: Business Epics

6

Was brauchen wir für das neue Kundenpflege-System?

Meeting mit Business Stakeholdern

Epic 1:Ich will Kundendaten nicht doppelt pflegen. Epic 2:

Ich brauche eine einheitliche Sicht auf den Kunden.

Epic 3: Ich hasse die lange Wartezeit im Altsystem.

Wie komme ich an Epics?

Schritt 2: Technische Enabler-Epics

7

Was ändert sich durch das neue Kundenpflege-System?

Prog

ress

Re

por

t …

.[ }

De

v . [ ]

Te

st

Enabler 1:Wir brauchen eine Continuous Delivery Pipeline.

Enabler 2:Wir brauchen eine neue Datenbank

Enabler 3: Wir brauchen Microservices.

Enabler 1:Wir brauchen Continuous Delivery Pipeline.

Epic 3: Ich hasse die lange Wartezeit im Altsystem.

Epic 2:Ich will einheitliche Sicht auf Kunden.

Was mache ich mit den Epics?

Schritt 3: Nutzen prüfen

8

Brauchen wir das Epic wirklich oder ist das ein Luxus-Problem?

Epic 1:Ich will Kundendaten nicht doppelt pflegen.

Das kann weg!

Das würde mir 20k pro Monat sparen!

Prog

ress

Re

por

t …

.[ }

De

v . [ ]

Te

st

Was mache ich mit den Epics?

Schritt 4: Aufwand schätzen

9

Epic 1:Ich will Kundendaten nicht doppelt pflegen.

Wie dick ist dieser Brocken? 10 Team-Sprints.

Was mache ich mit den Epics?

Schritt 5: Riesenblöcke aufteilen

10

Das dauert länger als ein Quartal. Kann man das sinnvoll in Teile spalten?

50

Epic 1.a:Egal wo ich die Daten pflege, sie werden automatisch übergeben.

Epic 1.b:Es gibt eine einheitliche Eingabemaske in allen Prozessen.

Epic 1.c: Der Kunde kann Daten selbst aktualisieren.

Epic 1: (50)Ich will Kundendaten nicht doppelt pflegen.

Für die neuen Epics wiederholen wir ab Schritt 3

Ein Backlog aufbauen

Schritt 6: Reihenfolge festlegen

11

In welcher Reihenfolge gehen wir das Ganze jetzt an?

E1c

E2

E3

En1

En2

Backlog

Offen

E1a E1

b

En3

Das Backlog besitzt eine eindeutige Reihenfolge.

Ein Release planen

Schritt 7: Roadmap planen

12

Das ist unser Backlog. Damit haben wir eine Epic-Roadmap! 12 3068

Q1 (20)

15 12 50

Q2 (20)

Q3 (20)

Später

Backlog

Die Roadmap-Planung betrifft alle verfügbaren Entwickler-Kapazitäten und somit alle Projekte, nicht nur ein Projekt!

Projekt 1

Projekt 2 7 25 8

Womit schneide ich Projekte kleiner?

13

Ich habe da ein paar Vorschläge gesammelt …

Beim fachlichen Schnitt geht es um Nutzen und Ziele. Dort kennen die Anwender sich am besten aus.

Man kann auch an der Technik entlang in machbare Blöcke

schneiden. Dabei können Leute aus der IT helfen.

Technik 1: Fachlich schneiden mit Impact Mapping

14

Beim Impact Mapping spalte fange ich mit den Zielen des Projekts an. (1)

Danach frage ich, welche User dazu beitragen, dass das Ziel erreicht wird. (2)

Und zuletzt,was diesen Leutendabei hilft. (3)

1 2 3

Technik 2: Fachlich schneiden mit

Story Mapping

15

Beim Story Mapping fange ich auch mit den Zielen des Projekts an (1).

Danach frage ich, welche Teile zum Ergebnis beitragen (2).

Und zuletzt,In welcher Reihenfolge die Epics benötigt werden (3).

1

2

3

Beim Epic Mapping bekommt man weniger Kärtchen als bei detailliertem Story Mapping - das Prinzip bleibt.

Technik 3: Technisch schneiden mit

technischem Splitting

16

Beim technischen Split fange ich mit dem Zielprodukt des Projekts an.

Dann stelle ich nacheinander bestimmte Fragen zu Aspekten der technischen Umsetzung.

Diese Fragen können am Besten die Leute beantworten, die sich mit der Technologie auskennen.

1

2

1

2

Technik 4: Technisch schneiden mit FURPS+

17

Bei FURPS+ fange ich mit einem zu großen fachlichen Epic an.

Die Entwickler denken über den technischen Hintergrund des Epics nach und teilen ihn auf.

FURPS+ beschäftigt sich ausschließlich mit der Technologie.

18

Danke fürs Zuhören.