Elektronická skripta SI

Elektronická skripta SI A7B36SI2 Řízení SW Projektů Ing. Ondřej Macek Katedra počítačů ČVUT v Praze, FEL Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Plánování projektu - motivace, velikost projektu Odhady trvání a ceny projektu Harmonogram projektu https://sites.google.com/a/fel.cvut.cz/vystupy-oppa/ Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

SOFTWAROVÉ INŽENÝRSTVÍ Plánování projektu I Ing. Ondřej Macek 2012/2013 Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE

2 Plánování Čas ušetřený dobrým plánem 18 36% + Definice + Motivace + Oblasti + Work Breakdown Structure + Velikost SW - LOC - Funkční celky - COCOMO

3 Definice Plánování je proces, jehož cílem je získat představu o trvání, ceně, zdrojích a jejich využití a rizicích pro konkrétní zadání projektu. Protože se jedná o proces jde o kontinuální činnost, která se (na různých úrovních) odehrává během celého trvání projektu.

4 Motivace pro plánování Plánování také pomáhá předcházet nečekaným nebo nechtěným událostem, které by mohli v průběhu realizace projektu nastat. Plánování tedy snižuje pravděpodobnost výskytu některých rizik a změn. Kromě toho má dobře plánovaný projekt vetší šanci skončit včas.

5 Motivace pro plánování Proces plánování trvá podle velikosti projektu 1den - Několik měsíců Díky plánování dochází k: zvýšení porozumění projektu, snížení nejistoty v projektu, zvýšení efektivity práce.

6 Oblasti plánování 1. Rozsah (kvalita) projektu 2. Trvání projektu 3. Cena projektu 4. Zdroje projektu 5. Rizika projektu

7 Oblasti plánování Poznej co a jak dobře máš udělat 1. Rozsah (kvalitu) projektu je nutné definovat proto, aby bylo jasné co se má udělat a jaký je vhodný rozsah zpracování. Podle požadavků na rozsah a kvalitu je také možné určit proveditelnost projektu.

8 Oblasti plánování 2. Trvání projektu je nutné znát, abychom mohli plánovat využití zdrojů a případné navazující či souběžné projekty ve firmě a také proto abychom dokázali určit jestli projekt dokážeme dokončit ve chvíli, kdy ho zákazník potřebuje.

9 Oblasti plánování U SW projektů je cena většinou závislá na trvání 3. Cenu projektu je nutné stanovit, abychom dokázali určit zda se projekt vyplatí realizovat - vzhledem k předpokládaným ziskům

10 Oblasti plánování 4. Zdroje projektu a jejich využití vzhledem k návaznosti jednotlivých aktivit v projektu. Je nutné rezervovat či najmout zdroje, aby byl projekt proveditelný. Zdroje také samozřejmě ovlivňují cenu projektu a případně i kvalitu zpracování.

11 Oblasti plánování Buď připraven! 5. Nejistota (rizika) projektu - pokud existuje možnost, že se vyskytne nějaká událost, která by mohla ovlivnit projekt, je dobré se na ni připravit předem.

12 Veličiny a jednotky Úsilí kolik práce bude třeba ke splnění projektu: Man-month práce vykonaná jedním průměrným člověkem za měsíc, Man-day práce vykonaná jedním člověkem za den. Trvání jak dlouho bude projekt trvat s přidělenými zdroji: Měsíc, týden, rok

13 Plán rozsahu projektu Dekompozice projektu je důležitým nástrojem při plánování rozsahu projektu. Těžko lze odhadnout projekt bez znalosti (hrubé představě) o dílčích úkolech. Nástrojem pro poznání aktivit je myšlenková mapa (mind map) nebo Work Breakdown Structure (WBS). V následujícím textu se budeme zabývat WBS z těchto pohledů: - Definice - Postup tvorby - Význam

WBS 14 Poznej, rozděl a panuj! Work Breakdown Structure je hierarchický popis práce (aktivit), která musí být udělána, aby byly splněny požadavky zákazníka. WBS tvoří strom jehož kořenem je cíl celého projektu, na další patrech jsou pak jednotlivé dílčí funkce až konečně listy jsou tvořeny jednotlivými konkrétními úkoly. Souvislost mezi uzly je dekompozice (ke splnění kořene musí být splněny všechny uzly podstromu) nikoliv časová návaznost.

15 Budování WBS V rámci budování WBS je možné využít Requirements Breakdown Structure, což je strom požadavků. Na něj se dá navázat tak, že jednotlivé požadavky jsou rozpracovány pomocí aktivit, které je třeba vykonat pro realizaci požadavku.

16 Budování WBS WBS můžeme budovat podle: 1. fyzických nebo funkčních komponent systému, 2. aktivit projektu, 3. organizačních jednotek.

17 WBS podle komponent WBS je zaměřena na jednotlivé dodávky (deliveries) a v rámci budování WBS dochází i k fyzické či funkční dekompozici aplikace.

WBS podle aktivit 18 WBS reprezentuje úkoly jejichž splnění povede k realizaci projektu. Někdy je přístup označován jako navrhniimplementuj-testuj přístup

19 WBS podle organizace Tento přístup se hodí pokud na projektu pracuje více oddělení, některá oddělení jsou dislokovaná nebo je třeba dodržovat již nastavené business procesy.

20 Kompletnost WBS Při konstrukci WBS narazíte na problém jak poznat, že WBS už je kompletní. Nápovědou mohou být následující kritéria: Je možné určit stav plnění aktivity? Je určený začátek a konec aktivity? Má každá aktivita konkrétní přínos (deliverable)? Je pro každou aktivitu možné odhadnout její cenu? Je možné ke každé aktivitě přiřadit jednu zodpovědnou roli? Vzhledem ke změnám v projektu se i WBS bude v průběhu projektu měnit, přesto by stále měla splňovat výše uvedená kritéria.

21 Význam WBS Než je možné začít plánovat projekt, musí být alespoň zčásti jasné jaké aktivity mají během projektu proběhnout. Dekompozice projektu na dílčí aktivity zpřesňuje odhady spojené s projektem. Další využití: Plánovací nástroj. Reportovací nástroj. Myšlenková mapa projektu. Pomocník při návrhu aplikace.

22 Podoby WBS Obsah je důležitější než forma! WBS může být vytvářena ve formě stromu, sticky notes, excelového seznamu, backlogu apod. Konkrétní podobu WBS rozhodněte podle předpokládané míry změn. Grafické (či jinak náročně udržitelné formy WBS) není vhodné používat tam, kde se předpokládají značné změny v zadání (či rozsáhlé postupné zpřesňování), je to z toho důvodu, že pak dochází ke změnám v mnoha větvích stromu. Naopak tam, kde je zadání od začátku jasné je WBS dobrým nástrojem.

23 Velikost SW projektu Ve všech projektech je třeba odhadnout rozsah práce, která má být udělána. Specifikem SW projektů je odhadování rozsahu softwaru. Na rozdíl od stavby domu nemůžeme provádět odhady typu: na zeď o rozměrech Z x Y budeme potřebovat zhruba takové a takové množství cihel konkrétní velikosti, nicméně potřebujeme odhadnou rozsah SW kvůli nacenění, plánování kapacit apod. Nyní se na odhad velikosti projektu podíváme z hlediska kódu, ostatní aktivity a jejich odhadování si necháme na později.

24 Metody odhadů velikosti SW Všechny metody potřebují historická data V rámci odhadování velikosti projektu se nejčastěji mluví o odhadech: počtu řádek kódu (line of code (LOC)) funkčních bodů pomocí metody COCOMO

25 Odhad LOC Předpoklad: Odhad trvání projektu (programátorské fáze) bude u projektu B podobný jako u projektu A, pokud odpovídá počet řádků kódu obou projektů. Jedná se o velmi populární techniku odhadu velikosti projektu. Důvody jsou: - snadné zjištění pro minulé projekty, - snadné porovnání mezi projekty, - podobná výkonost vývojářů (LOC/den).

26 Argumenty proti LOC Použití LOC pro odhad velikosti projektů má i svá úskalí, nejčastěji zmiňovaná jsou: Statistiky LOC/den jsou špatně aplikovatelné pro různé typy a velikosti (složitosti) systémů. LOC neříká nic o neprogramátorských aktivitách v projektu - analýza, čas na vykazování, meetingy apod. Různá definice LOC (např. Je komentář LOC? Je test LOC?). Nepřenositelnost mezi jazyky. Odhad LOC se často změní na odhad pomocí zástupce - viz dále.

27 Odhad a Funkční celky FC jsou lépe představitelné než LOC Odhad pomocí funkčních celků (Function point FP) se snaží o poskytnutí lepší představy o velikosti projektu v raných fázích vývoje (jsou známy požadavky, ale není implementace). Je založen na výpočtu pomocí odhadu počtu funkčních celků a jejich složitosti. Stránky komunity: http://www.ifpug.org/

28 Co je funkční celek? Funkčními celky se rozumí: Externí vstupy - formuláře, řídící signály atp. měnící data v systému Externí výstupy - obrazovky, soubory atp., které zobrazují data v systému koncovému uživateli (tím je i jiná aplikace) Externí dotazy - podobné výstupům nicméně data nejsou procesovány (může se jednat o našaptávač na webu apod.)

29 Co je funkční celek? - Vnitřní logika - reprezentují logiku navázanou kolem jedné tabulky, business funkce - Externí rozhraní - rozhraní na externí systémy (jiné aplikace) Poslední dva body se v knize jmenují Interní logické soubory a Externí soubory rozhraní, pro snadnější uchopení vývojáři jsem se pokusil o jiný překlad a přiblížení těmto čtenářům

30 Počítání s FP FP se dělí do tří tříd složitosti, každá skupina a třída má svůj koeficent (viz tabulka) Charakteristika Malá složitost Střední složitost Externí vstupy X 3 X 4 X 6 Externí výstupy X 4 X 5 X 7 Externí dotazy X 3 X 4 X 6 Vnitřní logika X 4 X 10 X 15 Externí rozhraní X 5 X 7 X 10 Velká složitost

31 Počítání s FP Následně se provede korekce pomocí koeficentu vlivu (zohledňuje např. složitost nasazení, způsoby datové komunikaci apod.) Konečně lze přímo odhadnout přímo velikost (a případně i cenu) SW nebo je možné převést na LOC (na základě statistiky a hstorických dat).

32 COCOMO Metodika vytovřená v roce 1981 a postupně upravovaná je empirická metoda založena na LOC a statistických údajích o historii projektů. Metoda umožňuje určit: Effort (úsilí) v person-months Duration (trvání) v měsících

33 COCOMO 81 Jedná se o nejstarší variantu výpočtů: Effort = A * (KLOC) B Durration = C * (Effort) D Velikost týmu = Effort / Duration Koeficienty A, B, C, D vysvětleny na dalším slidu

34 Parametry COCOMO 81 Projekt A B C D Organic 2,4 1,05 2,5 0,38 Semidetached 3,0 1,12 2,5 0,35 Embeded 3,6 1,20 2,5 0,32 Organic projects - malý tým, tvořený zkušenými pracovníky pracuje s pružnými požadavky. Semi-detached projects - střední tým, kde každý má jinou úroveň zkušenosti, některé požadavky jsou pevně dané, jiné se mohou měnit. Embedded projects - jsou vyvýjeny v pevně daných podmínkách

35 COCOMO II Nová verze metodiky COCOMO přináší zpřesnění statistického modelu, který je nyní založen na 15 atributech (počet se liší podle varianty modelu), které hodnotí projekt, projektový tým, produkt a hardware. Oba modely COCOMO si můžete vyzkoušet on-line: http://diana.nps.edu/~madachy/tools/ COCOMOSuite.php http://sunset.usc.edu/research/cocomoii/ expert_cocomo/expert_cocomo2000.html

36 Argumenty proti COCOMO Je založeno na LOC. Kromě LOC je třeba odhadnout i další parametry (typ projektu, další charakteristiky projektu). Konstanty jsou založeny na statistikách - jak byly zjištěny? Odpovídaly sledované projekty tomu našemu?

37 Otázky 1. Co je to plánování a jaké jsou jeho přínosy? 2. Které oblasti projektu je třeba plánovat? Proč? 3. Je plánování jednorázová aktivita? 4. Porovnejte přístup k plánovnání u tradičních a u agilních metodik. 5. Popište postup plánování rozsahu projektu. 6. Jaký je význam WBS - k čemu primárně slouží? 7. Jaká je závislost mezi aktivitami ve WBS? 8. Dá se podle WBS určit trvání projektu?

Otázky II 9. Jaké jsou způsoby budování WBS, kdy je který výhodný a proč? 10. Jak určíte, že aktivita ve WBS je dobře definovaná? Proč jsou důležitá právě tyto kritéria? 11. Jaké jsou další možnosti využití WBS, blíže vysvětlete. 12. Jaké jsou formy zachycení WBS? Kdy je která vhodná? 13. Proč je nutné odhadovat velikost projektu? V čem je SW projekt specifický? 14. Jak se dá WBS využít k odhadu velikost SW projektu?

39 Otázky III 15. Jaké metody odhadu velikosti SW projektu znáte? 16. Co je to LOC? Proč je definice LOC problematická? 17. Na jakém předpokladu je založena technika odhadu pomocí LOC? 18. Jaké jsou problémy s odhadem velikosti SW pomocí LOC? 19. Co jsou to funkční celky aplikace? 20. Jak lze funkční celky využít k odhadu velikosti SW? 21. Jaké jsou nevýhody odhadu pomocí funkčních bodů?

40 Otázky IV 22. Co je to metoda COCOMO? Na čem je založená? 23. Je vhodné používat metodiku COCOMO 81? Proč? 24. Jaká jsou nebezpečí s použitím metodiky COCOMO?

SOFTWAROVÉ INŽENÝRSTVÍ Odhady projektů Ing. Ondřej Macek 2012/2013 Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE

2 Osnova + Motivace + Přesný odhad + Rezervy v odhadech + Metodiky odhadů - Analogie - Historická data - Rada experta - Pomocí zástupce - Tříbodový odhad - Široká Delfská technika + Chyby v odhadech + Odhad trvání vs. vykonaná práce

3 Odhady v řízení projektů V minulé části jsme se zabývali odhadem SW, nyní se zaměříme na odhady obecně. Popsané techniky se dají využít pro odhad trvání aktivit jejich ceny nebo vzájemnému porovnání složitosti. Kromě odhadu aktivit jdou metodiky použít i na celý SW.

4 Motivace pro odhady Aby bylo možné vytvořit plán musíme mít představu o tom, jak dlouho ta která aktivita trvá. U softwarových projektů je problém tuto představu získat, protože zde panuje značné množství nejistoty a i malé změny v technologii či týmu mohou mít zásadní dopad na trvání aktivity. Proto mluvíme o odhadech.

5 Motivace pro odhady Pro provedení odhadů jsou výhodou nějaká pevná data o která se můžete opřít, pokud takovými daty nedisponujete, pak odhady budou jen tipy (kterými se zde nebudeme zabývat). Pokud máte data o která můžete své odhady opřít budou vaše odhady pravděpodobně přesnější.

6 Přesný odhad Vzhledem k tomu, že veškeré hodnoty na kterých budete zakládat harmonogram projektu i rozpočet jsou odhady, měli byste se snažit o co největší přesnost těchto odhadů. Jak přesný může odhad být a jak zařídit přesnější odhad?

7 Jak přesné jsou odhady? Přesnost odhadu u dobře řízených projektů +/- 10% C. Jones uvádí, že přesnost odhadu může být až +/- 10% u dobře řízených projektů. U chaotických projektů nelze mluvit o přesném odhadu, protože aktivity jsou příliš variabilní, a tak je případný přesný odhad dílem náhody. Další autoři uvádějí, že přesný odhad je takový, který pro 75% případů dá odhad +/- 25% oproti skutečné hodnotě.

8 Podmínky pro přesný odhad Existují procesní postupy pro vývoj, takže se ví co, kdy a jak se bude dělat. Existují historické záznamy o projektech a aktivitách, které v jejich rámci byly zpracovány. Nejistota ohledně rozsahu zadání a úrovni kvality je malá.

9 Zpřesnění odhadu Možným krokem k zpřesnění odhadů je rozdělit úkol na podúkoly (např. pomocí WBS), nejen že dostanete přesnější představu co se má všechno udělat, ale zároveň může dojít i k vyrušení některých chyb v globálním pohledu (nadhodnocená aktivita vyruší podhodnocenou).

10 Vývoj odhadů v čase Na začátku projektu, když je celá funkčnost aplikace daná jen jako webový server pro rezervaci jízdenek je velmi těžké (až nemožné) udělat jakýkoli odhad - nejistota ohledně zadání je příliš velká.

11 Vývoj odhadů v čase Proces zpřesňování ilustruje kužel nejistoty.

12 Vývoj odhadů v čase Důležité je si při studiu kužele nejistoty uvědomit, že: Osa času není lineární - milníky jsou různě daleko od sebe co se týče dní. Jedná se o nejlepší odhady pro danou fázi projektu - tedy většina lidí bude odhadovat hůře a lepší odhady jsou spíš dílem štěstí než nějaké metody odhadu. Kužel nejistoty se nebude zužovat sám od sebe, jeho zúžení je vázáno na snižování nejistoty ohledně projektu (tedy na řízení).

13 Vývoj odhadů v čase Interpretace kužele nejistoty: Odhad projektu je v určitém intervalu. Tento interval se v řízeném projektu má tendenci zužovat, takže může dojít ke zpřesňování odhadu. Odhad bude vždy v nějakém intervalu ohraničeném pod a nad skutečnou hodnotou, kde ale reálně je není možné určit. Není vhodné odhadovat a přijímat závazek hned na začátku projektu, kdy není dostatek informací.

14 Výhody přesných odhadů Projekt bude lépe sledovatelný - pokud jsem aktivity odhadl přesně dokážu určit jak na tom projekt (vzhledem k dokončení) reálně je. Včasná informace o riziku - pokud se na svůj odhad můžete spolehnout, tak jakoukoliv odchylku můžete považovat za riziko a přikročit k obraným krokům. Vyšší kvalita - stres v důsledku časového tlaku vede lidi k tomu, že produkují chyby a každá chyba (její náprava) stojí peníze. Navíc pokud je projekt zpožděný pak se typicky přikročí ke krácení testů, které jsou naplánovány na konci projektu.

15 Výhody přesných odhadů Lepší koordinace aktivit - pokud jsou aktivity dobře odhadnuty je snazší je vzájemně koordinovat a přidělovat jim zdroje. Přesnější rozpočet - přesnější odhad spolu s lepší koordinací aktivit vede k přesnějšímu rozpočtu. Vyšší kredit týmu / firmy - pokud dodáváte včas a v kvalitě, tak kredit vaší firmy roste.

16 Rezervy v odhadech Při čtení o odhadech jste se jistě zamysleli nad tím, že by bylo rozumné odhady nadhodnotit, aby vznikla rezerva pro případ, že se něco pokazí (viz Parkinsonův zákon).

17 Nadhodnocování odhadů Proti vytváření rezerv nadhodnocením aktivity mluví dva argumenty: Pokud má zaměstnanec na zpracování úkolu o den více než je potřeba, stráví druhý den prací na zbytečnostech (různé zbytečné vychytávky apod.), ačkoliv by se jinak mohl věnovat už další aktivitě. Pokud má zaměstnanec na zpracování úkolů více času než je potřeba, začne prokrastinovat, tedy odkládat práci na později a později.

18 Podhodnocování odhadů Motivací pro podhodnocení je například: Snaha o vyvolání pocitu naléhavosti (projekt s krátkým časem zpracování je důležitý projekt, který musí být rychle dodán na trh) Snaha o urychlení vývoje (produkt potřebuji za 6 měsíců, když řeknu, že na to jsou 3 měsíce, tak produkt vznikne za 4 5 měsíců). Optimismus, že tentokrát to půjde lépe (neodejde zaměstnanec, nebude tolik změn)

19 Podhodnocování odhadů Jakkoliv jsou motivy pro podhodnocení pochopitelné, přináší s sebou i nebezpečí: 1. Nižší efektivita plánování, pokud zakládám plán projektu na chybných datech nikdy nedostanu dobrý plán. U podhodnocených aktivit je větší šance, se sestaví menší tým než je potřeba. Dalším záporným efektem jsou problémy s integrací při spolupráci více skupin.

20 Podhodnocování odhadů 2. Nižší šance na včasné dokončení pramenící z toho, že vývojáři podhodnocují své odhady, pokud se ještě jedno podhodnocení provede na úrovni plánu (kvůli vytvoření pocitu naléhavosti) je jasné, že projekt skončí se zpožděním.

21 Podhodnocování odhadů 3. Bude nedostatek času na důležité aktivity, jako je např. analýza a design. Pokud je zanedbáte je výrazné riziko, že projekt nedodá požadovanou funkčnost a kvalitu nebo jej budete muset prodloužit, abyste udělali dobrou analýzu a design.

22 Podhodnocování odhadů 4. Kumulace zpoždění - pokud se projekt dostane do problémů s plněním plánu, jsou rozjety aktivity, které mají projekt vrátit do rozsahu určeného plánem (porady, přepracování plánu apod.), které projekt zase zpomalují.

23 Metody odhadů Odhady je možné získat na základě předchozích zkušeností nebo empirickými technikami. V této prezentaci zmíníme následující techniky odhadů: Analogie Historická data Rada experta Široká Delfská technika (Wideband Delphi Technique) Pomocí zástupce Tříbodový odhad

24 Analogie - metodika odhadu Odhad pomocí analogie předpokládá, že jste již někdy řešili podobný problém. Na základě podobnosti dokážete odhadnout i stávající aktivitu. Příklad: Máme implementovat diskuzní fórum, dříve jsme již realizovali twitter. Zkušenost s vývojem twitteru (trvání aktivit, množství kódu, cenu apod) využijeme při plánování vývoje fóra.

25 Analogie - postup Aby se odhad pomocí analogie stal efektivní je vhodné ho provádět v krocích: 1. Získání co nejdetailnější představy o velikosti, práci a ceně podobného projektu. 2. Srovnejte velikost projektů, nejlépe na menších pod-úkolech. 3. Odhad postavte na procentním poměru mezi starým a novým projektem. 4. Zkontrolujte, že pro starý i nový projekt platí stejné předpoklady (velikost týmu, jazyk vývoje apod.) a ty zohledněte ve svém odhadu.

26 Analogie - problém Problémem odhadu pomocí analogie je značný rozptyl odhadovaných hodnot a možný rozdíl oproti skutečnosti. To je způsobeno tím, že každý má tendenci vyhodnocovat analogii různým způsobem a předpokládat, že technologie či změny v organizaci vyřešili některé problémy z minula.

27 Historická data - metodika odhadu Pro odhad pomocí historických dat můžete využít data, která shromažďuje vaše firma, vy sami nebo jsou dostupné přes nějakou statistickou firmu či v odborném tisku. Důležité je, že tato (obzvláště přejatá data) je nutné kalibrovat. Historická data se musí týkat stejných typů projektů. Jen těžko použijete data o tvorbě e- shopu k plánování vývoje softwaru pro pobřežní stráž.

28 Která data uchovávat? Data, která je vhodné sbírat za účelem budoucího odhadování projektu: Velikost (jedno v jakých jednotkách, ale použitá jednotka by měla být stejná přes všechny projekty) Vykonaná práce (v mandays) Trvání (v měsících) Chyby (hodnocené podle závažnosti)

29 Historická data - kalibrace dat Žádné dva projekty nejsou stejné, proto je třeba historická data aktualizovat pro stávající projekt. Pro kalibraci dat můžeme použít následující otázky, kterými zjišťujeme vztah mezi daty a aktuálním projektem: Je projekt větší či menší? Jak se změnilo procesní řízení? Jakou prioritu dává projektu vedení firmy? Je tým zkušenější?

30 Problém optimismu Při práci s historickými daty se často dopouštíme optimismu, který je ale neopodstatněný, proto je nutné držet se co nejvíce dat a snažit se minimalizovat dopad přání na odhad. Příklad: ( tento projekt půjde lépe než ty předchozí, protože už nepřipustíme odchody členů týmu je dobrá vize, ale bohužel těžko naplnitelná)

31 Historická data - zlepšení odhadů Možným vylepšením tohoto druhu odhadů je vytvoření pokročilého modelu, který bude založen na dalších datech, a který povede k zlepšování přesnosti odhadu Příklad: jeden programátor vyprodukuje X práce za měsíc, tři programátoři 2,75 * X apod.)

32 Odhad experta Tato technika založená na úsudku jednoho odborníka, je dle průzkumů nejčastěji používaná v praxi. A to i přes to, že přináší mnohá rizika: Je expert opravdu expertem v oboru? Jak odhaduje? Jejich přesnost je závislá na jedinci. Někteří argumentují, že odhad pomocí experta je stejně dobrý jako kterákoli jiná metoda.

33 Wideband Delphi Technique Technika odhadu je založená na shodě členů týmu nebo expertů, pro její realizaci je tedy třeba více účastníků.

34 Wideband Delphi Technique Postup probíhá v následujících krocích: 1. V prvním kole každý z účastníků ohodnotí aktivitu dle svých zkušeností, nezávisle na ostatních účastnících ohodnocování. 2. Ve chvíli kdy mají všichni ohodnocení aktivity připravené, je ohodnocení zveřejněno. 3. Ti co odhadovali extrémy vysvětlí důvody, které je vedli k těmto odhadům.

35 Wideband Delphi Technique Následují další (doporučeno dvě) kola, během kterých účastníci aktualizují své odhady na základě přednesených argumentů. Odhad skončí shodou na trvání aktivity nebo po určitém počtu kol, pak se jako finální bere nejčastěji zmiňovaný odhad.

36 Delfská technika Původní delfská technika byla založena jen na sejití expertů a jejich domluvě. Ukázalo se však, že tato sejití jsou často politicky ovlivňována, takže výsledky se nijak nelišili od odhadů jednoho experta. Proto byl zaveden kolový přístup, kde se vyjadřují jen někteří experti.

37 Odhad pomocí zástupce Při odhadování velikosti SW, často narazíme na problém jak odhadnou LOC nebo jak odhadnout počet testů apod. Tyto problémy pomáhá řešit odhad pomocí zástupce. Odhad pomocí zástupce vychází z předpokladu, že některá projektová veličina koreluje s velikostí software. Často je používán tam, kde je třeba odhadnou celý projekt nebo jeho velké celky.

38 Odhad Fuzzy logikou Metoda využívá historických dat o projektech a schopnosti člověka kategorizovat funkcinolitu. Používá se 5 kategorií rozsahu, pro které máme z historických dat spočítán průměrný počet řádků. Jednotlivé funkcionality zařadíte do kategorie a následně vynásobíte počtem řádků.

39 Fuzzy logika - výhody Na podobných projektech může být poměrně přesná. Kategorie lze změnit z velikosti vlastností např. na komponenty (statická web stránka, načítání obsahu, formulář s validací apod.) systému a umožnit tak jiný pohled na SW a přesnější/srozumitelnější kategorizaci

40 Fuzzy logika - problémy Pokud kategorizaci provádí někdo jiný než osoba, která nastavovala kategorie (a počítala průměrný LOC), může dojít ke značným odchylkám, proto je třeba hodnotitele školit v jednotné metodice kategorizace. Je třeba sbírat a aktualizovat data o projektech. Technika je založena na statistice, proto se doporučuje používat až od 20 vlastností.

41 Story points Jedná se o metodu hojně používanou v agilním prostředí, která je podobná fuzzy logice. Jedná se o ohodnocování vlastností (use case, user stories...) pomocí nějaké číselné řady (mocniny 2, fibonacci). Výsledkem je tak porovnání celků z hlediska obtížnosti.

42 Story points - výhody Při plánu iterace můžu vzít výstup minulé iterace (kolik bodů bylo splněno) a použít tento údaj jako strop pro vlastnosti realizované v příští iteraci. Porovnání mezi úlohami probíhá v jeden okamžik, takže by mělo být poměrně přesné. Jdou použít k plánování iterací

43 Story points - Nevýhody Story points neříkají nic o trvání a složitosti úloh. Má-li A ohodnocení 2 a B má 4, pak to neznamená, že B bude trvat dvakrát tak dlouho jako A, ale to, že B je o něco těžší než A. Story points jsou bezrozměrné a nejdou převádět na čas, nehodí se tedy k prezentaci a detailnímu plánování práce (ty máš vlastnost ohodnocenou 1, takže budeš ve 12 hotový)

44 Konfekční velikost Podobně jako story points pochází z agilního prostředí a většinou slouží k odhadu větších celků (ale dá se použít i na user stories). Využívá hodnocení pomocí konfekčních velikostí (S, M, L...), programátoři, tak ohodnotí složitost vývoje a zákazník přidanou hodnotu, která mu vznikne. Kombinací obou hodnocení vznikne prioritizace požadavků.

Tříbodový odhad 45 Odhad je založen na průměrování odhadů. Jednotlivec nebo skupina určí optimistickou, pesimistickou a nejpravděpodobnější dobu trvání. Následně se průměruje.

46 Chyby v odhadech Kromě nedostatku zkušeností a podcenění variability projektu je dalším zdrojem chybných odhadů i fakt, že se zapomíná na aktivity jako je nasazení, instalační program, účast na meetinzích apod. Dalším zdrojem chyb je chaotické řízení a produkce nekvalitních výstupů v průběhu projektu - pak je nutné vynaložit úsilí na jejich zlepšení (opravu či přepracování) a není možné se věnovat dalším aktivitám.

47 Chyby v odhadech Častým zdrojem chyb jsou i změny. Změny požadavků by měly podléhat procesu řízení změn a jejich dopady by měly být zapracovány i do odhadů. Změny ve zdrojích (např. ve složení týmu) se do odhadů také promítnou a je nutné na toto myslet. Dalšími zdroji chyb v odhadech může být neznalost technologie, změny legislativy, velikost projektu, velikost a distribuovanost týmu nebo pocit, že máme tzv. silver bullet.

48 Odhad trvání vs. vykonaná práce Každému je jasné, že člověk není schopen pracovat nepřetržitě (na rozdíl od stroje) a tak i při nejlepší vůli pracovníka využít pracovní dobu na 100%, není tento cíl naplněn. Navíc během pracovní doby dochází ke kolísání pracovního výkonu. Svůj dopad na trvání aktivity také bude mít i sestavení a velikost týmu. Mají se tyto jevy objevit i v odhadech a pokud ano jak?

49 Trvání nebo skutečná práce? Pro plánování harmonogramu a doby dokončení projektu odhadujte trvání aktivit bez ohledu na možnosti týmu. Pro plánování/vykazování rozpočtu využijte odhad provedené práce.

50 Příklad - Trvání nebo práce? Naším projektem je přestěhovat židli z místnosti do chodby - náš plán práce je tedy následující: 1. Zvednout židli. 2. Přinést ji ke dveřím z místnosti. 3. Položit židli. 4. Otevřít dveře. 5. Držet dveře otevřené, zvednout židli. 6. Odnést židli na chodbu.

51 Příklad - Trvání nebo práce? Aby byl příklad názornější řekněme, že odhad trvání projektu je 1 hodina pro jednoho pracovníka (hrozně dlouhá místnost a těžko otvírající se dveře). Pokud do týmu přidáme dalšího člověka, může dojít k zlepšení času např. na 45 minut - jeden ponese židli a druhý půjde napřed a bude otvírat dveře.

52 Příklad - Trvání nebo práce? S přidáním dalších pracovníků už ke zrychlení nedojde, naopak přibude doba potřebná k provedení úkolu růst - na začátku se budou muset pracovníci domluvit, kdo ponese židli a kdo bude otvírat dveře, takže nějaký čas spotřebují domluvou na organizaci. Doba trvání je 1 hodina, ale spotřebovaná práce se bude odvíjet od počtu pracovníků, který se na ní podílí - pro 4 pracovníky budu muset zaplatit 4 hodiny.

53 Důvody rozdílů trvání a práce Různé úrovně dovedností. Neočekávané události. Efektivita v pracovní době. Chyby a nedorozumění.

54 Otázky 1. Proč nelze na začátku projektu s jistotou říci jak dlouho bude projekt trvat a kolik bude stát? 2. Jak by se měl odhad vyvíjet v čase? 3. Jaké jsou přínosy dobrých odhadů? 4. Jaké musí panovat podmínky, aby se dal odhad postupně zpřesňovat? Jaké jsou naopak překážky? 5. Jak souvisí WBS s odhady? 6. Jaké jsou argumenty pro a proti nadhodnocování projektů? Ke které variantě se přikláníte?

55 Otázky II 7. Jaké jsou argumenty pro a proti podhodnocování projektů? Ke které variantě se přikláníte? 8. Na jakém principu je založena metodat odhadu pomocí analogie? Jaký je postup? 9. Jaké jsou problémy s odhady založenými na analogii? 10. Jaká data je vhodné sledovat u projektů pro pozdější využití při odhadech? 11. Proč je optimismus překážkou při odhadech na základě historických dat? 12. Jaké jsou výhody a nebezpečí odhadu expertem?

56 Otázky III 13. Jak probíhá odhad pomocí Wideband Delphi? 14. Proč se neosvědčila původní Delphi technika? 15. Co je principem Wideband Delphi Technique? 16. Co je principem odhadů pomocí zástupce? Jaké techniky odhadů sem patří? 17. Jak probíhá odhad pomocí fuzzy logiky? 18. Jak lze odhad pomocí fuzzy logiky modifikovat tak, aby nemusela být známa celá funkčnost?

57 Otázky IV 19. Co jsou to Story points? Jaké nabývají hodnoty a jak se dají použít pro plánování? 20. Co je výhodou a co nevýhodou plánování pomocí Story points? 21. Jaký je rozdíl v odhadu pomocí konfekční velikosti oproti ostatním technikám odhadu? Jaký je přínos pomocí této odlišnosti? 22. Jaký průměr používá tříbodový odhad? Proč právě tento? 23. Co způsobuje chyby v odhadech? 24. Jaký je vztah mezi odhadem a reálnou prací? Kterou z nich zohlednit při plánování?