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

SOF TWA ROV INŽE É N Ý Plán R S ován T V í pro Í jek Ing. Ondř e

j Mac

ek

tu I

2012

Evropský sociální fond

Praha & EU: Investujeme do vaší budoucnosti

/201

3 ČES K UČE É VYSO K N V PR Í TECHN É AZE ICKÉ

2 Plánov ání Čas uš

etřený

dobrým

18 – 36

plánem

%

+ Definice + Motivace + Oblasti + Work Breakdown Structure + Velikost SW - LOC - Funkční celky - COCOMO

3 Definic e

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 Motiva ce 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 Motiva ce pro plánov ání Proces p velikos lánování trvá ti proje podle ktu

1 den - 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 Oblast i plánov ání

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


Poznej co a ja k 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.


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.


U SW projekt ů cena v ětšinou je 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


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 Oblast i 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čin ya jednot ky Ú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 ro zsahu projek tu

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ě la 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í WB S 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í WB S

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 p odle kompo nent

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.

18 WBS p odle aktivit 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 p odle organi zace

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 Kompl etnost 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ýzna m 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 Podob y WB

S

Obsah je důležit ě j ší n e ž 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 Veliko st SW projek tu

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 Metod y odha dů velikos ti SW Všechn y meto dy potřebu jí histo rická 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 Argum enty proti L OC 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í celk y FC jso u lépe předsta vitelné 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 f unkč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 f unkč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

Střední složitost

Malá složitost

Velká složitost

Externí vstupy

X3

X4

X6

Externí výstupy

X4

X5

X7

Externí dotazy

X3

X4

X6

Vnitřní logika

X4

X 10

X 15

X7

X 10

Externí rozhraní X 5

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 COCO MO

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 COCO MO 8

1

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

Param e tr y COCO MO 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 COCO MO 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 Argum enty proti C OCOM O 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?

SOF TWA ROV INŽE É N Ý Odh R ady S T proje V Í ktů Ing. Ondř e

j Mac

ek 2012



/201


2 Osnov a + 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 Odhad y v říze ní projek tů

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 Motiva ce pro odhad y 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 Motiva ce pro odhad y 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ý odha

d

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 o dhady ? Přesno st řízenýc odhadu u do h proje bře ktů

+/- 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 pr o 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í odhad u

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ýhod y přes ný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ýhod y přes ný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 Rezerv yv odhad ech

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

Nadho dnoco vá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

Podho dnoco vá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


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


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


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


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 Metod y odha dů 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

Analog ie metod ika od hadu

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 Analog ie 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 Analog ie 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

Histor ická da ta metod ika od hadu

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ě eshopu k plánování vývoje softwaru pro pobřežní stráž.

28

Která d a ta uchov á v a t?

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

Histor ická da ta kalibra ce 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 optimi sm

u

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

Histor ická da ta zlepše ní odh adů

•  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 expe

rta 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

Wideb and De lphi Techni que

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

34


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


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 á techni ka 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ástup ce

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 logiko u 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ýhod y

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 p oints 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 p oints výhod y 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 p oints Nevýh ody

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í velikos t

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ů.

45 Tříbod ový odhad

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 odhad ech 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 odhad ech Č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. vykon aná 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 p í rá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


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


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ůvod y rozd ílů trvání a prác e

•  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í?

SOF TWA ROV INŽE É N Ý Plán R S ován T VÍ í III Ing. Ondř e

j Mac

ek 2012



/201


2

Osnov a

+ Harmonogram projektu + Kritická cesta + Optimalizace harmonogramu - Brooksův zákon

+ Rezerva projektu

Úvod

3

Až do teď jsme řešili pouze trvání jednotlivých úloh bez ohledu na jejich okolí (co jim předchází, co následuje, jaké zdroje jsou využívány v rámci aktivit apod.), abychom mohli sestavit harmonogram projektu, tak musíme vzít tyto souvislosti v potaz.

4

Harmo nogram projek tu

Harmonogram projektu ukazuje návaznost projektových aktivit a jejich zasazení v kontextu: –  ostatních aktivit (časová souvislost) a –  zdrojů (personální souvislost).

5

Vizuali zace harmo nogram u

Harmonogram projektu se dá vyjádřit slovně, ale pro názornost je lepší využít některé z grafických znázornění. Ukážeme si dvě možné zobrazení:

– Ganttův model – Síťový model

6 Ganttů v mod el Ganttův model je jedním z nejstarších modelů pro vizualizaci harmonogramu projektu. Jeho výhodou je značná jednoduchost a přehlednost (s využitím barev se dají znázornit zdroje).

7 Ganttů v mod el

Nevýhodou to, že není vidět návaznost jednotlivých aktivit.

8 Ganttů v mod el

Může být použít v prezentacích, kde se uplatní jeho jednoduchost. Může být využit pro prezentování pokroku v projektu (míra progresu jednotlivých aktivit).

9 Síťový model

Síťový model se snaží zbavit problému ganttova modelu a zavádí propojení mezi aktivitami a stává se tak klasickým grafem (viz teoretická informatika). V případě mnoha závislostí a velkém počtu aktivit se může stát nepřehledným.

10

Aktivit av síťové m mod el

u

To že jsou aktivity mezi sebou provázány nám dává možnost sestavit harmonogram projektu. Kromě informací o délce aktivity (D - duration) a jejích předchůdcích a následnících můžeme určit i některé další charakteristiky aktivit.

11


u

Odhadovaný začátek (ES - estimated start) tedy čas kdy aktivita začne v závislosti na svých předchůdcích. Odhadovaný konec (EF - estimated end) předpokládaná doba ukončení aktivity, kterou spočítáme jako EF = ES + D – 1.

Korekce +/- 1, která se ve výpočtech objevuje reflektuje skutečnost, že aktivita, která trvá jeden den (D = 1), začne ráno a skončí večer, takže její ES i EF musí být stejné.

12


u

Krajní konec aktivity (LF - latest finish) určuje, kdy nejpozději může aktivita skončit aniž by ohrozila trvání projektu. Tento údaj získáme při zpětném průchodu grafem (viz dále). Krajní začátek aktivity (LS - latest start) určuje, kdy nejpozději může aktivita začít, aby nedošlo k jejímu zpoždění, určíme ji jako LS = LF - D + 1. Korekce +/- 1, která se ve výpočtech objevuje reflektuje skutečnost, že

aktivita, která trvá jeden den (D = 1), začne ráno a skončí večer, takže její ES i EF musí být stejné.

Návaz

13 nost a ktivit

Aktivity na sobě navzájem můžou záviset různými způsoby, síťový model umožňuje modelovat čtyři z nich: –  Finish - Start (FS): pokud A skončí, může začít B –  Finish - Finish (FF): pokud A skončí, může skončit i B –  Start - Start (SS): pokud začne A, může začít i B –  Start - Finish (SF): pokud začne A, může B skončit

Nejpoužívanější je návaznost FS, ostatní druhy návazností oceníme hlavně při optimalizaci harmonogramu projektu.

Návaz

14 nost a ktivit

1.

Finish - Start (FS): pokud A skončí, může začít B

Návaz

15 nost a ktivit

2.

Finish - Finish (FF): pokud A skončí, může skončit i B

Návaz

16 nost a ktivit

3.

Start - Start (SS): pokud začne A, může začít i B

Návaz

17 nost a ktivit

4.

Start - Finish (SF): pokud začne A, může B skončit

Návaz

18 nost a ktivit

Mezi aktivitami v projektu existují i jiné závislosti než závislosti časové, v průběhu přípravy harmonogramu je dobré přemýšlet i nad nimi. Jde například o:

–  –  –  – 

Technická omezení Datové závislosti Omezení uvnitř projektu Omezení managementu

19

Harmo nogram dokon čení

Ve chvíli, kdy je připraven harmonogram projektu (tzn. známe návaznosti aktivit) je čas zapracovat do harmonogramu i potřebné zdroje.

Přidání zdrojů do harmonogramu vytvoří další druh závislosti, který je třeba brát v potaz při další práci (optimalizaci) harmonogramu.

20 Kritick á ces

ta Při plánování projektu je důležité vědět, jak dlouho bude projekt trvat a také které aktivity mohou způsobit zpoždění projektu. U některých aktivit se dá očekávat “okénko” (ES < LS), takže je možné, aby se práce na aktivitě zpozdili až o rozdíl LS - ES. V případě, že je ES = LS, tak je tato aktivita kritická - její zpoždění pak povede ke zpoždění celého projektu. Takové aktivity tvoří kritickou cestu

21 Kritick á ces

ta Kritická cesta: je posloupnost aktivit, kde zpoždění jedné z nich povede ke zpoždění celého projektu.

22

Kritick á cesta určení -

23


24


25


26


27


28


29


30


31


32


33


34


35

Optim alizace harmo nogram u

Vytvoříme-li si harmonogram projektu může se stát, že jeho dokončení bude trvat příliš dlouho. V takovém případě je třeba přikročit k jeho optimalizaci. Optimalizačními kroky mohou být: –  Můžeme využít síťový model a některé vazby FS nahradit SS závislostí - tedy řešit některé úkoly paralelně.

–  Nasadit na aktivitu zkušenější pracovníky a tím ji zrychlit nebo alespoň docílit toho, že se aktivita nezpozdí.

36


Optimalizačními kroky mohou být: –  Přesunout zdroje z aktivit mimo kritickou cestu nebo z jiných projektů do aktivit na kritické cestě. –  Rozdělit aktivitu na několik dílčích a tím určit konkrétní rizikové místo. –  Outsourcovat aktivity.

37


Optimalizace jsou funkční pokud jsou optimalizace prováděny na kritické cestě nebo v aktivitách s vysokou pravděpodobností výskytu rizik. Jakákoli optimalizace si vyžádá vyšší náklady na řízení projektu.

38 Brook sův zákon

Brooksův zákon: přidání nových pracovníků do zpožděného projektu tento projekt ještě více zpozdí. –  Proč? –  Vždy?

39 Rezerv a projek tu

V části o odhadech jsme se zabývali nadhodnocováním a podhodnocováním aktivit a pro oba případy jsme ukázali jejich nežádoucí efekty. Jak tedy nastavit rezervu projektu, tak aby nějaká byla, ale zároveň nebyl v ohrožení plán projektu?

40

Stanov ení rezerv y proje k tu

1. Podle plánu (harmonogramu) určete kolik hodin je potřeba projektu věnovat. K tomuto odhadu přičtěte ještě X% z odhadovaného času jako rezervu, kde velikost X závisí na organizaci projektu, množství předpokládaných rizik apod. Pokud nenastanou komplikace bude produkt hotový dřív, v případě komplikací je tu záchranná síť o velikosti X dní.

41

Stanov ení rezerv y proje k tu

2. Na konec projektu přidejte ještě “dokončovací” aktivitu, které se bude věnovat jen část týmu (korektura uživatelských příruček apod.). V případě, že dojde ke zdržení může část týmu řešit problémy, zatímco druhá skupina se bude věnovat dokončení.

42 Práce se skluze m

V každém případě platí, že pokud se objeví problémy je třeba je hned reportovat manažerům a případně i sdělit zákazníkovi. Je lepší, když je zákazník srozuměný s prodlením, než aby se v den, kdy si přišel pro finální produkt dozvěděl, že bude až za tři měsíce.

43 Plánov ání zdrojů

+ Plánování zdrojů + Resource Breakdown Structure + RACI matice

44 Plánov ání zdrojů V rámci plánování zdrojů dochází k plánování: – zaměstnanců – vybavení – místností – materiálu Z hlediska SW projektů jsou nejdůležitějším zdrojem zaměstnanci, proto jim bude věnováno nejvíce pozornosti.

45

Plánov ání zdr ojů - využi tí WBS

Zdroje jsou přiděleny ke každé aktivitě, která v projektu (jeho WBS) existuje. Tak vznikne Resource Breakdown Structure (RBS), která může být využita nejen pro projekt, ale i pro tvorbu profilu zaměstnanců.

RBS

46

Resource Breakdown Structure (RBS) určuje jaké zaměstnance (s jakým profesním profilem) potřebujeme k dokončení projektu.

Pokud vytváříme RBS pro všechny firemní projekty, pak můžeme průniky z RBS využít při náboru nových zaměstnanců.

47 RACI m atice R (Responsible): ten kdo vypracovává úkol A (Approver): jedna osoba schvalující vypracování C (Consulted): ten kdo konzultuje s R I (Informed): ten kdo je pravidelně informován o průběhu vývoje

48 Jak dlo uho plánov at?

Každý projekt je specifický a specifická proto bude i doba strávená plánováním. Někdy se může stát, že plánováním projektu strávíte příliš mnoho času, případně že zpracujete mnoho různých plánů, které se nakonec ukáží jako zbytečné nebo nepoužitelné po té co se objeví první nečekaná událost. Proto je třeba věnovat plánům a plánováním přiměřené úsilí vzhledem k velikosti projektu a možným změnám.

49 Jak dlo uho plánov at?

Velikost projektu

Doba plánování

Velmi malý

< 1/2 dne

Malý

< 1 den

Střední

2 dny

Velký

3-4 dny

Velmi velký

?

Čísla uvedená v tabulce nelze brát jako absolutní, doba plánování bude záležet na mnoha dalších faktorech např. na velikosti možných rizik nebo návaznosti aktivit v projektu.

50 Plánov ací meetin g

Plánovacího meetingu by se měl účastnit: zákazník, projektový manažer a tým. Všichni účastníci měli být seznámeni s POS, aby bylo všem jasné kam projekt směřuje a proč.

51 Plánov ací meetin g

V rámci plánovaného meetingu by měl(a) být: –  sestavena co nejkompletnější WBS, –  odhadnuto trvání aktivit a jim přiřazeny potřebné zdroje, –  vytvořen síťový graf projektu a určena kritická cesta, –  rozhodnuto, zda je projekt možné dokončit včas, –  schválen plánu (harmonogram) projektu.

Výstupem meetingu je Project Definition Statement (PDS)

52

Role k lienta při plánov ání

Validace požadavků a POS Prioritizace požadavků (MoSCoW) Spolupráce a validace WBS Potvrzení a plánování zdrojů na straně zákazníka Potvrzení plánu projektu

53

Co je p otřeba k plánov ání?

Kromě mnoha sofistikovaných nástrojů je možné použít třeba i lepící štítky (sticky notes), barevné fixy a tabuli nebo flipchart.

54

Sticky notes jako nástro j pláno vání

Každý štítek by měl obsahovat následující informace: ID úlohy, název, trvání, předmět úkolu, potřebné zdroje, zodpovědnou osobu, odhady začátku a konce trvání (ES, EF, LS a LF) a případně i informaci, zda leží na kritické cestě. Pomocí fixů, lze nakreslit závislosti mezi úkoly (různé barvy pro různé typy závislostí a kritickou cestu).

55

Otázky

1.  2.  3.  4.  5.  6.  7.  8.  9. 

Co je to harmonogram? Co harmonogram znázorňuje? Jaké informace můžeme do harmonogramu zanést navíc? Co je to ganttův model? Jaké jsou výhody ganttova modelu? Jaké jsou nevýhody ganttova modelu? Kdy je vhodné použít ganttův model? Jaké jsou výhody síťového modelu oproti ganttovu? Jaké infromace o aktivitě v harmonogramu je dobré zjistit?

56

Otázky

10.  Jak se dá určit předpokládaný začátek aktivity? 11.  Jak se dá určit předpokládaný konec aktivity? 12.  Jak se dá určit časová rezerva pro aktivitu? 13.  Jaké existují závislosti mezi aktivitami v harmonogramu? 14.  Které závislosti aktivit lze zachytit v síťovém modelu? 15.  Jaký je vliv zdrojů na harmonogram projektu? 16.  Co je to kritická cesta? 17.  Jak se pozná, že je aktivita na kritické cestě? 18.  Jak se dá určit kritická cesta?

57

Otázky

19.  Jak se dá určit kritická cesta? 20.  Jak se dá optimalizovat kritická cesta? 21.  Jaké problémy přináší optimalizace harmonogramu? 22.  Co říká Brooksův zákon? 23.  Jak stanovit rezervu projektu? 24.  Jak pracovat s problémy při plnění harmonogramu? 25.  Co všechno jsou “zdroje” projektu? 26.  Co je to resource breakdown structure? 27.  Jaké jsou možnosti použití resource breakdown structure? 28.  Co je to RACI matice?

58

Otázky

29.  Jaký je optimální čas plánování? 30.  Co je cílem plánovacího meetingu a kdo se ho účastní? 31.  Co je prioritizace pomocí MoSCoW

Elektronická skripta SI

Recommend Documents