Prezentace z odborné snídaně v Profinitu 28. 11. 2018

1. Podívejte se nám do
softwarové kuchyně
Michal Petřík, Vlastimil Jinoch, Vít Kluganost 28. listopadu 2018

3. 3
Série odborných snídaní
› Pohled na projekty ze
strany dodavatele
› Připomenutí si
best practices vývoje
a údržby SW
› Relevance a jejich
zásadní význam
i v dnešním
„agilním světě“

4. 4
Témata
1. Odhady a práce s nimi
2. Architektura, design, implementace (Q1/2019)
3. Testování, základní principy pro testovací strategie (Q2/2019)

5. Odhady
Vlastimil Jinoch 28. listopadu 2018

6. 6
Proč metodika?
Q: Kolik bude stát ten nový portál?
A: 10 Milionů
Q: Bude tam vše co potřebujeme, prošli jste to s produkty?
A: … hmmm ne, ale je to jasný, bude to jako druhý brand…
Q: Dobře, kolik z toho bude stát část pro public a kolik pro BO?
A: No, takhle jsme to ještě nepočítali…
Q: Je v té ceně zahrnuta i následná údržba?
A: … hmmm asi ještě ne, podívám se…
Q: A co rizika?
A: Jo, nějaká rezerva tam je

7. 7
Jak na odhad pracnosti - příklad
› Vím, co odhaduji?
– Implementaci?
– Vše (co to znamená?)
› Mám definovány omezující podmínky?
› Metoda odhadu
– Dekompozice
• Dle funkčních celků
• Počitatelné věci (obrazovky, moduly, …)
– Expertní odhad (zkušenosti)
– …
› Rozsah, pravděpodobnost, rizika

8. 8
Doporučení pro tvorbu odhadu
› Rozdíl mezi odhadem, závaznou pracností a cenou
› Jasně definované okrajové podmínky
› Kužel nejistoty
› Metody odhadu
› Konzistence
› Nutnost revizí
› Checklisty
› Metodika

9. 9
Kužel nejistoty

10. 10
Metody odhadu
› Top  down / bottom  up
› Dekompozice
› Výpočet:
– business požadavky,
– funkční požadavky,
– případy užití,
– počty změnových řízení,
– stránky/obrazovky/dialogy,
– reporty, databázové tabulky/třídy,
– počet již napsaných řádků kódu,
– … vše relevantní k danému projektu.
› Odhad na základě historických dat (obdobný již realizovaný projekt, …)

11. 11
Standardizované metodiky
› Funkční body
› Řádky kódu
› Putnam Model 𝐸𝑓𝑓𝑜𝑟𝑡 = 𝐵 ∗
𝑆𝑖𝑧𝑒
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦∗𝑇𝑖𝑚𝑒
4
3
3
› COCOMO (basic, intermediate, detailed, COCOMO II)
𝐸𝑓𝑓𝑜𝑟𝑡 𝐴𝑝𝑝𝑙𝑖𝑒𝑑 𝐸 = 𝑎 𝑏 ∗ 𝐾𝐿𝑂𝐶 𝑏 𝑏
𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒 𝐷 = 𝑐 𝑏 ∗ 𝐸𝑓𝑓𝑜𝑟𝑡 𝐴𝑝𝑝𝑙𝑖𝑒𝑑 𝑑 𝑏
𝑃𝑒𝑜𝑝𝑙𝑒 𝑅𝑒𝑞𝑢𝑖𝑟𝑒𝑑 𝑃 =
𝐸𝑓𝑓𝑜𝑟𝑡 𝐴𝑝𝑝𝑙𝑖𝑑𝑒𝑑
𝐷𝑒𝑣𝑒𝑙𝑜𝑝𝑚𝑒𝑛𝑡 𝑇𝑖𝑚𝑒
Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

12. 12
Standardizované metodiky
› Vhodné pro „sériovou výrobu“ (platí ověřené koeficienty)
› Nejsou vhodné vždy
– Nové technologie
– Nové jazyky
– Nové oblasti
– Fáze projektu
– …
› Velmi vhodné kombinovat s jinými metodikami

13. 13
Historická data
› Z čeho vycházet
– Metriky realizace
– Okrajové podmínky
– Odhady
– Rizika
– Lessons learned
– Údržba
– …
› Jak využít
– Příprava odhadu
– Validace odhadu
Bez měření nelze
historii dobře využít

14. 14
Ukázka checklistu
Checklist analýzy
 Budeme v rámci analýzy vytvářet PoC?
 Budeme komunikovat s dalšími partnery mimo zákazníka?
 Jací partneři s námi budou v rámci analýzy spolupracovat (tzn. jaké
máme s danými partnery zkušenosti z předchozích analýz)?
 Předpokládáme v rámci analýzy nějaké schůzky (je nutné uvažovat
o času, cestě apod.)?
 Vlastní dokument nám zabere nemalý čas, například pokud
musíme vytvářet náhledy obrazovek, ukázky rozhraní, apod.
 Pokud budeme vytvářet rozhraní pro třetí strany, je nutné uvažovat
větší rizika analýzy.
 Nesmíme zapomenout na interní revize specifikace (to také stojí
další čas).
 Musíme uvažovat i případný čas na zapracování změn do
specifikace, které vyplynou v dalších částech projektu (v průběhu
implementace, v opravách, …).
 Budeme v rámci analýzy mimo specifikace vytvářet i další
dokumenty?
 Budeme muset v rámci analýzy řešit výkonové požadavky
systému/aplikace?
 Budeme muset v rámci analýzy řešit bezpečnostní požadavky
systému/aplikace?
Checklist testování
 Tvorba testovacích scénářů pro zákazníka
 Otestování na vývojovém prostředí, otestování na QA
prostředí. Zde musíme počítati s časem. Kdy je nutné seznámit
se s problematikou, abychom vůbec mohli testovat – dalším
aspektem může být:
• Musíme pro testování speciálně nastavit prostředí
(například instalace Selenium, SoapUI, jiný prohlížeč, …)?
• Musíme spouštět dávky nebo jinak modifikovat vývojové
prostředí (například specifické hodnoty v databázi, emulace
stavu aplikace, apod.)?
• Potřebujeme rozhraní třetí strany (s tím mohou souviset
certifikáty, přístupové údaje, …)?
 Budeme vytvářet nové regresivní testy/upravovat stávající?
 Testování finální objednávky před odesláním.
 Kvalifikační testování.
 Podpora akceptačního testování (testování na straně
zákazníka).
 Pokud výkonnostní požadavky uvádíme v analýze, musíme
se jimi zabývat i v rámci testování.
 Zde uvažujeme primárně testování nově přidané funkcionality,
dále se testování může objevit i ve vlastní dodávce.

15. 15
Ukázka okrajových podmínek
ID Předmět Popis
1 Testovací prostředí
Zákazník, poskytne již během fáze analýzy infrastrukturu pro zmíněná prostředí. Instalace testovacího prostředí musí proběhnout
nejpozději během kvalifikačního testování projektu.
Potřebný HW i licence zajišťuje projekt.
2 Vývojové prostředí
Vývojové prostředí se všemi potřebnými závislostmi na bankovním prostředí bude postaveno před začátkem vývoje a je součástí
této nabídky.
Pokud se ale závislosti v bance během realizace nabízeného systému změní a bude potřeba vývojové prostředí upravit, jedná se
o úpravy nad rámec této nabídky a budou vyčísleny samostatně. Dané změny mohou mít dopad na termíny uvedené
v harmonogramu.
3 Realizační tým Velikost i obsazení realizačního týmu bude řízena aktuálními požadavky v dané fázi projektu a bude volena maximálně efektivně.
4 Revize zdrojového kódu
Revize zdrojového kódu, jako požadavek zadavatele, bude probíhat průběžně, jelikož pro poptávané technologie ještě neexistují
standardy/předpisy. Zadavatel v rámci testů neodmítne systém z důvodu „technologického dluhu“.
5 Uživatelské rozhraní
Uživatelské rozhraní aplikace bude podřízeno zvolené technologii a tam, kde by požadavky na GUI znamenaly neadekvátní
pracnost, bude navrženo jiné řešení respektující požadovanou business funkcionalitou.
6 Změny požadavků
V případě změn ve funkční specifikaci, nebo identifikace nedořešených problematických momentů ve fázi analýzy mohou vést ke
změně pracnosti a výsledné ceny.
7 Testovací prostředí
Zákazník nejpozději do konce fáze implementace poskytne obchodní systém pro testovací prostředí včetně testovacích dat.
Předpokládáme, že datový model obchodního systému bude shodný s datovým schématem dodaným pro vývoj a čtení dat z db
bude moci probíhat naprosto stejným způsobem jako u vývojové obchodní databáze.
8
Testovací excelové
tabulky pro upload do
systému
Zákazník nejpozději do konce fáze analýzy dodá excelové tabulky s daty, na kterých bude možné testovat funkcionalitu systému.
Je potřeba, aby data v nich odpovídala datům v obchodním systému v příslušném prostředí.

16. 16
Základní charakteristika metodiky
› Členění odhadu do osmi kategorií, včetně definice obsahu:
– Analýza
– Design
– Implementace
– Testování
– Project management
– Tvorba dodávky
– Ostatní
– Záruka
› Odhad je vždy prezentován rozsahem (reprezentace rizik)
– Uvádíme minimum, maximum a expertní předpoklad

17. 17
Ukázky a literatura
› Literatura:
– Steve McConnell:
Software Estimation: Demystifying the Black Art
– Frederick P. Brooks:
The Mythical Man-Month: Essays on Software Engineering
– Barry W. Boehm:
Software Engineering Economics

18. 18
Best Practices
› Vývojáři jsou od přírody optimisté  revize nutná
› Někdo tvoří odhad, někdo realizuje
(ne vždy stejní lidé, spíše téměř vždy jiní…)
› Technicky správný odhad je nezbytnost
› Konzistentní odhady = snadné revize a poučení
› Vykázaný čas a reálně odpracovaný se mohou lišit
› Checklisty a metodika pomohou

19. Odhady v agilním světě
Vít Kluganost 28. listopadu 2018

20. 20
Osnova
1. Kontext Agile v praxi
2. Odhady v agilním světě – relevance, principy
3. Relativní jednotky
4. Techniky odhadů
5. Metriky
6. Shrnutí

21. 21
Kontext Agile v praxi

22. 22
Relevance odhadů v agilním světě
› Přidaná (business) hodnota?
#NO
Estimates
Estimate

23. 23
Odhady v agilním světě - principy
1. Rychlost je důležitější než přesnost
2. Týmová práce a zodpovědnost
3. Relativní jednotky

24. 24
Relativní jednotky
› Velké x Malé
› Story points
0 1/2 1 2 3 5
8 13 20 40 100 ?

25. 25
Techniky odhadů
› T-Shirt Sizes
› Planning Poker
› Ostatní
– Large/Uncertain/Small
– Ordering method
– Affinity Mapping
– TFB / NFC / 1 (Sprint)
– Divide until Maximum Size or Less
– Dot Voting
– User stories counting
– a další…….
XS
S
M
L
XL

26. 26
Metriky
Velocity
Burndown
Slack
Time
Planned
to Done
Focus
Factor
Cycle
Time
Happiness

27. 27
Velocity
› Počet relativních jednotek, které tým dokáže dodat (dokončit)
v rámci jedné iterace
› K čemu slouží?
› Focus Factor
› Na co si dát pozor

28. 28
Burn down

29. 29
Shrnutí
› Odhad může mít mnoho podob
› Lze výrazně redukovat časovou investici do jeho výroby
› Má smysl dělat jen to, co je efektivní a funguje ve vašem týmu
› Metriky jsou skvělý sluha, ale špatný pán
› Tým je to hlavní, co v agilním světě máte!

30. Závěr

31. 31
Dopady odhadů na vztah zákazník/dodavatel?

32. 32
Dopady odhadů na vztah zákazník/dodavatel?
› Schopnost vytvořit odhad pro dané zadání přímo implikuje
schopnost zadání reálně splnit
› U nových zadání se Velmi často se pohybujeme na (před) začátku
kužele nejistoty co nám to říká o přesnosti odhadu?
› Pro koho je tato nepřesnost výhodná?
– Místo dodání kvalitního SW často boj o rozsah
– Rozčarování z výstupů
(potřeby v čase T se neshodují s potřebami
v čase T + X)
– … neúspěch projektu, všeobecné zklamání
› Další analýza/upřesnění je nezbytná

33. 33
Přirozeným řešením je začít v malém
a postupně přidávat.
Nebo projekt ukončit, pokud na základě
výstupů nedává smysl.
Dopady odhadů na vztah
zákazník/dodavatel?

34. 34
Dopady odhadů na vztah zákazník/dodavatel?

35. Profinit EU, s.r.o.
Tychonova 2, 160 00 Praha 6 | Telefon + 420 224 316 016
Web
www.profinit.eu
LinkedIn
linkedin.com/company/profinit
Twitter
twitter.com/Profinit_EU
Facebook
facebook.com/Profinit.EU
Youtube
Profinit EU
Děkujeme
za pozornost