Dieser Vortrag zeigt, wie man in agilen Projekten einfach und effizient Releases und Iterationen plant, ohne durch diese Planung an Flexibilität und Geschwindgkeit einzubüßen. Er zeigt, wie die kurzen Iterationen und die rollierende Planung aus Methoden wie Scrum gerade in Embedded und Systems Engineering Projekten helfen kann, die Welt der Software, der Elektronik und der Hardware gemeinsam zu planen und zu synchronisieren.
Der Vortrag behandelt dazu kurz die Grundlagen und Stufen agiler Planung, zeigt wie man die Stufen der agilen Planung auf Embedded Projekte umlegt, wie man mit unterschiedlichen Backlogs für SW, HW und dem gemeinsame Produktbacklung die Produktentwicklung synchronisiert voranbringt. Den Abschluss bilden die wichtigsten Learnings aus der Praxis rund ums Thema Planen und Schätzen.
1. Wie man in agilen Projekten richtig plant. Und wie falsch.
Markus Unterauer
Berater, Trainer
Man kann nicht nicht planen
2. www.software-quality-lab.com | improve your quality
Agile Software-Entwicklung
Was ist agile Software-Entwicklung?
- 2 -
Product
Backlog
Sprint
Backlog
Potentially
Shippable
Product
Value
$$$
3. www.software-quality-lab.com | improve your quality
Agil heißt ohne Plan einfach drauf los?
Grundprinzipien der Planung in der agilen Software-Entwicklung
- 3 -
4. www.software-quality-lab.com | improve your quality
Agile Planung erfolgt in mehreren Stufen
Grundprinzipien der Planung in der agilen Software-Entwicklung
- 4 -
Product Vision
Roadmap
Release
Iteration
Daily Stand-Up
1
2
3
4
5
[AgileTestingFramework, Torak]
5. www.software-quality-lab.com | improve your quality
Je näher die Umsetzung, desto genauer der Plan
Grundprinzipien der Planung in der agilen Software-Entwicklung
- 5 -
Bis 6
Monate
6 bis 12
Monate
Weiter als
ein Jahr
Ferne
Zukunft
.
Req
R
Req
R
...
.
..
RR
. .
R R
Req
Req
.
.
.
.
.
..
.
.
R
R
R
R
R
R
R
R
.
Req
Req
Req
Req
Req Req
.
Idee
Idee
Ungefähre
Idee
Wenn‘s so
weitergeht,
…
6. www.software-quality-lab.com | improve your quality
Stufe 1: Product Vision
High-Level Planung
Gemeinsames Bild des
Produktes
Ziel und Orientierung
Die Vision beantwortet …
Wie macht das Produkt die
Welt besser?
Für wen?
Was sind die wesentlichen
Funktionen?
Wie unterscheidet es sich
vom Mitbewerb?
- 6 -
Quelle:www.pixabay.com
7. www.software-quality-lab.com | improve your quality
Stufe 2: Product Roadmap
High-Level Planung
Langfristige zukünftige Entwicklungen
Sehr grobe Themen und Pläne
Stark aus Kundensicht (das Richtige zur richtigen Zeit bauen)
- 7 -
2015 2016 2017 2018
10. www.software-quality-lab.com | improve your quality
Stufe 4: Planung der nächsten Iteration
Feinplanung der Umsetzung
Am Beginn jeder Iteration wird
geplant.
Product Owner entscheidet, was
wichtig ist.
Team entscheidet, wieviel gemacht
werden kann.
Stories aus Release Backlog in
Iteration Backlog schaufeln
Stories in Tasks herunterbrechen
- 10 -
Task Aufwand
Außenhülle berechnen 8 h
Simulation durchführen 4 h
Prototyp bauen 12 h
Lasttest 6 h
Hülle erstellen 36 h
…
12. www.software-quality-lab.com | improve your quality
Schätzungmethoden
Praktiken in der agilen Planung
- 12 -
Features, Epics
Stories
Tasks
S M L
1
3 5 8
Cone of Uncertainty
[AgileTestingFramework, Torak]
13. www.software-quality-lab.com | improve your quality
Und Hardware, Elektronik, …?
Agile Planung im Systems Engineering Umfeld
- 13 -
Quelle:www.pixabay.com
14. www.software-quality-lab.com | improve your quality
Software und Hardware parallel hochziehen
Agile Planung im Systems Engineering Umfeld
SW startet nicht erst, wenn HW fertig ist
Nur SW Anforderungen, die auf HW angewiesen sind, müssen warten
- 14 -
[Grenning, 2008]
15. www.software-quality-lab.com | improve your quality
Gemeinsames Backlog als Basis
Agile Planung im Systems Engineering Umfeld
- 15 -
http://joachim-pfeffer.com/kanban-in-der-embedded-entwicklung/
16. www.software-quality-lab.com | improve your quality
Planstufen im agilen Systems Engineering
Grundprinzipien der Planung in der agilen Software-Entwicklung
- 16 -
Product Vision
Roadmap
Release
Iteration
Daily Stand-Up
1
2
3
4
5
[AgileTestingFramework, Torak]
• Vision für das Gesamtprodukt
• Gemeinsam entwickelt
• Sehr grobe Items für das gemeiname Backlog
• Gemeinsamer Workshop HW+SW Teams
• Aufbau gemeinsames Backlog und Teil-Backlogs
• Jedes Team plant nächste Iteration für sich
• Abhängigkeiten HW/SW berücksichtigen
• Jedes Team für sich
• Danach gemeinsames Standup aller Teams
17. www.software-quality-lab.com | improve your quality
Software und Hardware häufig integrieren
Agile Planung im Systems Engineering Umfeld
- 17 -
Feedback
http://joachim-pfeffer.com/kanban-in-der-embedded-entwicklung/
21. Markus Unterauer
Berater und Trainer
[m] markus.unterauer@software-quality-lab.com
Software Quality Lab
[w] www.software-quality-lab.com
Danke für Ihre Aufmerksamkeit!
Fragen?
Hinweis der Redaktion
Mit dem initialien Product Backlog gehen wir in eine erste grobe Planung
In der Release Planung verfeinern wir die Roadmap
Wir Überarbeiten die Aufteilung auf Releases
Wir planen dazu das nächste Release genauer
Ergebnis ist eine erste grobe Iterationsplanung für das nächste Release
Dazu brechen wir die bisher sehr groben Roadmap Items in feinere Stories
Planung der täglichen Arbeit
Was möchte ich heute fertig bekommen?
Was hält mich auf?
Je feiner wir voranschreiten, desto feiner auch die verwendeten Schätzmethoden
Für die Roadmap reichen T-Shirt Sizes, je feiner wir in der Planung werden, desto genauere Schätzmethoden setzen wir ein
Man beginnt mit einem groben gemeinsamen Backlog
Daraus werden abgeleitet (3 Teil-Backlogs)
Reine SW Items
Reine HW Items
Items, wo die SW von der HW abhängig ist (kommen ins Puffer Backlog)
Reine SW und HW items werden unabhängig voneinander geplant und umgesetzt und regelmäßig synchronisiert
Gemeinsame Items warten im Puffer Backlog. Sobald HW so weit ist, werden sie von dort ins SW Backlog übernommen
Nach jedem Sprint -> Testphase und Integration
Vertreter aus HW, Elektronik und Mechanik bei Sprint Abnahme dabei
Synchronisation im Release Planning planen
Gemeinsamer Heartbeat
Botschaft: Synchronisation zwischen Teams über Taktung. Viel Zusammenarbeit, nicht „Über-den-Zaun-Werfen“
Kapazität der Teams ist wie ein Glas Wasser
Vorgehensweise
Kapazität ermitteln (Urlaub, sonstige Aktivitäten, Meetings berücksichtigen)
Epics schätzen (T-Shirt-Sizes)
Epics in Release füllen, bis das Glas voll ist
Epics in Stories zerlegen, diese schätzen und grobe Iterationsplanung machen
Mit Ergebnissen der groben Iterationsplanung den geplanten Release Scope aus (3) prüfen und gff. anpassen