Softwareprojekte werden immer komplexer. Die Ursachen hierfür sind zum einen in der immer höheren IT-technischen Abdeckung der Geschäftsprozesse, bei steigender Anforderungsdynamik zu suchen. Zum anderen werden die Softwareproduktionsumgebungen, Technologien und Infrastrukturen und somit auch die Anforderungen an die Qualifikation aller Projektbeteiligter immer umfassender.
Das Management von Projekten muss der Komplexität gerecht werden. Dies bedeutet, Komplexität zu minimieren und über geeignete Prozessrahmen, Praktiken, Methoden und Technologien beherrschbarer zu machen. Dies bedeutet aber auch Risiken zu reduzieren durch Fokussierung auf das Wesentliche, insbesondere im Bereich der Planung, des Anforderungs- und Qualitätsmanagements.
Dieser Vortrag stellt die Herausforderungen der modernen Softwareentwicklung dar und gibt Antworten auf die Fragen, wie Komplexität z.B. durch agile Prozessrahmen und Methoden beherrschbarer gemacht werden kann und mit welchen Mitteln und Wegen eine hohe Qualität, sowohl in den Prozessen als auch im Produkt, trotz der Risiken, erreicht werden kann.
8. Komplexität - Cynefin
Einfach
Best Practice
Sense Categorize Respond
Verwirrung
!
Kompliziert
Good Practice
Sense Analyze Respond
Komplex
Emergent Practice
Probe Sense Respond
Chaotisch
Novel Practice
Act Sense Respond
Dave Snowden
11. DAS AGILE QUIZ
Auf komplexe Sachverhalte mit komplexen
Methoden zu reagieren ist falsch, weil...
DAS
AGILE
QUIZ
???...sich dadurch die Komplexität
weiter erhöht!
18. Was muss ich wann tun?
1. Handlungsschritt
2. Handlungsschritt
3. Handlungsschritt
4. …
Was brauch ich?
1. Mittel
2. Menschen
3. Geld
4. …
Was will ich erreichen?
Vision Produkt
E N T S C H E I D U N G S G R U N D L A G E
26. VisionZiel des Projektes
Erstellung eines Produktes
Ergebnis des Produktes
Welche Veränderung soll erzielt werden?
Nutzen des Produktes
Welche Verbesserung soll aus
Ergebnis resultieren?
Zielgruppe
Wer soll mit dem Produkt arbeiten?
Business
Case
28. Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7
Epos 2
User Story 4 User Story 33
User Story 14User Story 13User Story 3
User Story 1
User Story 6
User Story 2
User Story 5
PRODUCT BACKLOG
Status Ready
K O M P L E X I TÄT R E D U Z I E R E N
35. Das ist mir viel zu
unsicher. Dann müssen
wir genauer schätzen.
Gib mir mal einen
Daumen.
Wir haben grob geschätzt!
Das Projekt hat nen
Aufwand von 15 bis 240
Tagen.
40. Bin ich schlecht!
1. Ich schätz nur meine
idealen Nettozeiten.
2. Große Mengen kann ich gar
nicht und komplexe Dinge
krieg ich auch nicht auf die
Reihe.
3. Und eigentlich kann ich eh
nur vergleichen.
41. 1
2
3
5
8
13
20
40
K O M P L E X I TÄT B E H E R R S C H E N
100 Meter sind 100 Meter
egal wer sie läuft
42. Team
Estimation
Game
1
2
3
5
8
13
20
40
Epos 31
Epos 19
Epos 12
Epos 9
Epos 4
Epos 7Epos 2
User Story 4
User Story 33
User Story 14
User Story 13
User Story 3
User Story 5
User Story 6
User Story 2
User Story 1
K O M P L E X I TÄT R E D U Z I E R E N
43. …
OK und weiter? Wie geht jetzt
die Releaseplanung?
Wir gehen erstmal davon
aus, dass wir so 12 Story
Points pro Sprint schaffen
und messen was wir
wirklich hinkriegen.
53. Und was soll das kosten?
𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑃 =
𝐾𝑜𝑠𝑡𝑒𝑛 𝑆𝑝𝑟𝑖𝑛𝑡
𝑉𝑒𝑙𝑜𝑐𝑖𝑡𝑦
54. Projektbudget und -dauer (Soll)
Wartungsbudget (Soll)
Projektbudget und -dauer mit Puffer (Soll)
Zeit
Kosten
Anforderungen
Entwurf
Programmierung
Test