1. Komplexní projekty easy-way
“řízení komplexity SW projektů“
Ondřej Kavula
1

2. Kdo jsem…
• Prošel jsem od vývojáře,
architekta, projektového a
programového manažera, šéfa
vývoje až dnešnímu nezávislému
konzultantovi / agilnímu kouči…
• Více než 10 let řízení komplexních
vývojových a integračních projektů
• Agilní transformace korporací
i menších IT firem
2
… s řízením vývoje (SW) projektů.
Řeším problémy…
Stav povrchu organismu v létě 2015.

3. O čem budu dnes mluvit…
… často se setkávám s tím, že agilní přístup je vhodný na malé projekty…
… pro webíky, start-upy a jiné „hračky“ …
… hlavní výhodou pak je především rychlost, úspora zdrojů …
… naproti tomu velké a složité projekty je potřeba naplánovat, navrhnout architekturu a
detailně analyzovat před začátkem vývoje …
… jediný přístup, který může fungovat ve velkých korporacích je waterfall …
… výhodou jsou robustní řešení, dokumentace, a pevně naplánované dodávky …
3

4. Kapitola I.
VODOPÁDOVÝ MODEL
4

5. Winston W. Royce, Managing the Development of Large Software Systems, 1970
“I believe in this concept, but
the implementation described
above is risky and invites
failure.”
5

6. Funkční sila
6

7. Hand-over
7

8. Contract
Games
8

9. Detailní analýza
před začátkem
vývoje
9

10. Požadavky vs. “zákazník neví, co chce”
10

11. Změny business procesů a okolního prostředí
“Nemám nové požadavky, ať
to funguje jako předtím…“
“Přesně víme, co bude trh
potřebovat za rok a půl…“
„Je to regulatorní požadavek,
tam se scope změnit nemůže a
spustit se to musí k 1.1.20…“
11

12. Neporozumění psaným dokumentům
• Nejednoznačnost – nezamýšlená i zamýšlená (metoda ”CYA”)
• Různé jazyky a vyjadřovací prostředky
• Nevyslovené předpoklady
• Uvažování v technickém kontextu
• Nejasné, co je skutečně důležité
12

13. Jakkoli důkladná a dlouhá analýza neodhalí…
13
NEJEDNOZNAČNOST NEZNÁMÉ NEZNÁMÉ
SKRYTÉ
PŘEDPOKLADY
K O M P L E X I T A

14. Kapitola II.
KOMPLEXITA
14

15. 15

16. Kde leží komplexita v SW projektech?
• Požadavky
• Technologie
• Lidské interakce
16

17. Kapitola III.
AGILNÍ VÝVOJ
17

18. Jak agilní vývoj přistupuje ke snižování
rizik spojených s komplexitou?
• smyčky zpětné vazby
• průbězná analýza
• hypotézy  experimenty
• cross-functional teams
• self-organization
18

19. Smyčky zpětné vazby
19
Ověřování
předpokladů nad
reálným SW
Odhalování
neznámých
neznámých
Validace
vzájemného
porozumění
Funkční
prototypy jsou
používány

20. Iterativní budování řešení namísto plnění plánu
20
Plán
Úkol 1
Úkol 2
Úkol 3
Úkol 4
…
…
ZBÝVAJÍCÍPRÁCE
BUSINESSHODNOTA

21. Cross-functional Teams
21

22. Self-organization
22

23. Kapitola IV.
VÝCHODISKA PRO SW PROJEKTY
23

24. Jaký přístup je vhodný pro SW projekty?
Udělejme si malý experiment… Kam byste zařadili většinu vašich projektů?
Faktor 1/5: Tržní prostředí
24
A B
Potřeby zákazníků a možnosti
jejich řešení se často mění.
Tržní prostředí je stabilní
a předvídatelné.

25. Jaký přístup je vhodný pro SW projekty?
Udělejme si malý experiment… Kam byste zařadili většinu vašich projektů?
Faktor 2/5: Zapojení zákazníka
25
A B
Úzká spolupráce a rychlé smyčky
zpětné vazby jsou realizovatelné.
Zákazníci vědí tím lépe, co chtějí,
čím dále je implementace procesu.
Požadavky jsou jasné již na začátku
a zůstanou neměnné.
Zákazníci nejsou dostupní
pro konstantní spolupráci.

26. Jaký přístup je vhodný pro SW projekty?
Udělejme si malý experiment… Kam byste zařadili většinu vašich projektů?
Faktor 3/5: Typ inovace
26
A B
Problémy jsou komplexní, řešení neznámá a
scope není jasně definován. Specifikace produktu
se mohou měnit.
Kreativita a originalita řešení a
time-to-market jsou důležité.
Spolupráce mezi různými
disciplínami může být přínosná.
Podobné úkoly již byly řešeny v minulosti a
inovátoři věří, že řešení jsou jasná.
Detailní specifikace a plány mohou být
předpověděny s velkou přesností a měli
bychom se již držet.
Problémy jsou řešitelné sekvenčně ve
funkčních silech.

27. Jaký přístup je vhodný pro SW projekty?
Udělejme si malý experiment… Kam byste zařadili většinu vašich projektů?
Faktor 4/5: Modularita práce
27
A B
Vývojové inkrementy mají pro zákazníka hodnotu
a uživatelé je mohou používat.
Práce může být rozdělena a vykonávána v
rychlých iterativních cyklech.
Změny na poslední chvíli jsou
řiditelné a akceptovatelné.
Zákazníci nemohou začít testovat části
produktu, dokud není hotova
i nejposlednější součást.
Změny na poslední chvíly jsou velice drahé,
nebo dokonce nemožné.

28. Jaký přístup je vhodný pro SW projekty?
Udělejme si malý experiment… Kam byste zařadili většinu vašich projektů?
Faktor 5/5: Dopad chyb během vývoje
28
A B
Poskytují hodnotnou zpětnou vazbu a poučení. Mohou mít katastrofické následky

29. Jaký přístup je vhodný pro SW projekty?
Vyhodnocení…
Podmínky vhodné SPÍŠE pro:
29
A B
Agile Waterfall

30. Kapitola V.
ZÁVĚR
30

31. Co jsem Vám chtěl sdělit…
- Zaměřme se na fundamenty, poznejme naše prostředí a jeho kontext
- Nedělejme z toho náboženství - není to svatá válka Agile vs. Waterfall
- Oba přístupy jsou nástroji na snižování rizika spojené s dodávkou projektů
- Komplexitu analýzou neubijete…
- Většina SW projektů spadá do oblasti komplexních problémů, kde je agilní
přístup přirozenější a méně rizikový
31

32. Jaké nové otázky po dnešku máte?
32

33. Děkuji za pozornost.
33
www.projectman.cz/agile