Masarykova univerzita Fakulta informatiky
Agilní a tradiční metodiky v projektovém řízení Diplomová práce
Ing. Jakub Pejchal Brno, 2015
Prohlášení o autorství Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
V Brně dne 8. 1. 2015
Ing. Jakub Pejchal
Vedoucí práce: RNDr. Jaroslav Ráček, Ph.D.
Poděkování Děkuji panu doktorovi Ráčkovi za vedení diplomové práce, poskytnutí odborných rad a připomínek a za vstřícný přístup při konzultacích.
Shrnutí Diplomová práce se zabývá problematikou projektového řízení. Představuje vybrané zástupce metodik používaných při vývoji softwaru a zástupce standardů projektového řízení. Uvádí způsoby, kterými lze zvolené standardy a metodiky kombinovat při zachování jejich výhod a na reálném projektu aplikuje jednu z možných kombinací.
Klíčová slova Projekt, projektové řízení, metodika, standard, metriky.
Obsah 1
Úvod ..................................................................................................................................... 1
2
Principy projektového řízení ............................................................................................ 3
3
2.1
Projekt .......................................................................................................................... 3
2.2
Životní cyklus projektu ............................................................................................. 4
2.3
Projektové řízení ......................................................................................................... 5
2.4
Odlišnosti ICT projektů ............................................................................................. 5
Metodiky budování ICT projektů .................................................................................... 8 3.1
Srovnání tradičních a agilních metodik .................................................................. 9
3.2
Výběr vhodné metodiky.......................................................................................... 11
3.3
Scrum ......................................................................................................................... 13
3.3.1
Role ..................................................................................................................... 14
3.3.2
Artefakty ............................................................................................................ 15
3.3.3
Činnosti ve Scrumu .......................................................................................... 16
3.4
4
3.4.1
Dynamický pohled ........................................................................................... 18
3.4.2
Statický pohled ................................................................................................. 19
Standardy projektového řízení ....................................................................................... 21 4.1
Standard PMBOK ..................................................................................................... 22
4.1.1
Procesní skupiny .............................................................................................. 22
4.1.2
Znalostní oblasti ............................................................................................... 24
4.2
5
Rational Unified Process ......................................................................................... 17
Standard PRINCE2................................................................................................... 25
4.2.1
Principy .............................................................................................................. 25
4.2.2
Témata................................................................................................................ 26
4.2.3
Procesy ............................................................................................................... 27
Kombinace standardu a metodik ................................................................................... 29 5.1
Kombinace PMBOK a Scrum .................................................................................. 29
5.2
Kombinace PRINCE2 a Scrum ............................................................................... 32
5.3
Kombinace PMBOK a RUP ..................................................................................... 35
5.4
Kombinace PRINCE2 a RUP ................................................................................... 38
6
Pilotní projekt.................................................................................................................... 41 6.1
Předprojektová fáze ................................................................................................. 42
6.2
Iniciační fáze.............................................................................................................. 44
6.2.1
Nastavení projektu ........................................................................................... 44
6.2.2
Řízení přechodu mezi etapami ....................................................................... 47
6.3
Realizační fáze .......................................................................................................... 48
6.3.1
Dodání produktu .............................................................................................. 49
6.3.2
Kontrola etapy .................................................................................................. 50
6.3.3
Směrování projektu .......................................................................................... 53
6.4
Fáze ukončení ........................................................................................................... 53
7
Návrh metrik..................................................................................................................... 55
8
Závěr .................................................................................................................................. 59
9
Bibliografie ........................................................................................................................ 60
1 Úvod Potřeba koordinovat a řídit jednotlivé činnosti se pojí se vznikem společenské dělby práce a historicky ji lze dokumentovat například na složitých stavbách typu egyptských pyramid nebo starořeckých staveb, kdy vznikala potřeba plánovat a organizovat veškeré práce, které s realizací staveb souvisely. Toto období lze považovat za základ oboru, který byl později nazván projektovým řízením a který postupem času nabýval na významu v různých odvětvích. Na konci 20. století se teoretické přístupy integrovaly a aplikovaly v praxi a proces řízení se stal široce používanou metodou, která efektivně zajistí dodání a vývoj nových produktů a služeb. Projektové řízení dnes představuje ověřené a stanovené postupy, které vychází z praktických zkušeností, definují konkrétní činnosti a v nich stanovují jednotlivé kroky. Označují se jako projektové metodiky. Ty mohou být specializované pro jeden obor nebo jsou použitelné pro vedení různých typů projektů a z některých se staly de facto standardy projektového řízení. V oblasti ICT prošly v posledních letech zásadním vývojem. Zde můžeme rozlišit tradiční metodiky, které jsou procesně orientované, formalizované, nutí používat řadu předepsaných dokumentů a agilní metodiky, které charakterizuje jednoduchost a flexibilita, která umožňuje rychle reagovat na změny v projektu. Přestože agilní metodiky vznikly jako reakce na nevýhody metodik tradičních, ne vždy je jejich zavedení vnímáno pozitivně. Výhody jednotlivých metodik lze využít při jejich kombinování, které se stále častěji v korporacích prosazuje. Na danou oblast je také zaměřena diplomová práce, jejímž cílem je prezentovat možné kombinace procesně orientovaných standardů projektového řízení a metodik vývoje softwaru a jejíž částí je také návrh na řešení projektu průmyslového partnera. Druhá kapitola Principy projektového řízení uvádí do problematiky projektového řízení, vymezuje základní pojmy jako projekt, životní cyklus projektu, projektové řízení a představuje hlavní odlišnosti ICT projektů. Rozdělení metodik budování ICT projektů, srovnání tradičních a agilních metodik a výběru vhodné metodiky se věnuje třetí kapitola Metodiky budování ICT projektů. Tato kapitola také představuje metodiky Scrum a Rational Unified Process jako typické zástupce dvou odlišných kategorií. Čtvrtá kapitola pojednává o procesních standardech projektového řízení A Guide to the Project Management Body of Knowledge (PMBOK) a PRojects IN Controlled Environments (PRINCE2).
1
V páté kapitole autor na základě mapování vybraných procesů vzájemně kombinuje výše zmíněné standardy a metodiky se záměrem procesy zefektivnit a optimalizovat. Šestou kapitolou je Pilotní projekt zpracovaný pro partnerskou organizaci. Na reálném projektu webového portálu aplikuje standard PRINCE2 propojený s metodikou Scrum. Závěrečný Návrh metrik je přehledem nástrojů používaných při měření vlastností projektů, ke kterým patří rozsah, čas, náklady a kvalita projektu.
2
2 Principy projektového řízení Projektové řízení lze obecně charakterizovat jako proces, jehož záměrem je naplánovat a realizovat řadu činností, které slouží k dosažení požadovaných cílů. Při nich je nutné dodržet stanovené termíny, kvalitu a nepřekročit plánované náklady. Význam projektového řízení jako disciplíny roste s tím, jak v podnikatelském prostředí dochází ke změnám, zvláště při zavádění nových produktů a procesů, které vyžadují také změny v manažerských strategiích. V úvodu diplomové práce je vhodné vymezit základní pojmy, které souvisí s problematikou projektového řízení obecně. Cílem první kapitoly je představit definice základních pojmů tak, jak je uvádějí významné organizace a autoři.
2.1 Projekt Základním pojmem, který se používá při řízení projektů, je termín projekt. Byla pro něho vytvořena řada definic, z nichž většina projekt charakterizuje obdobným způsobem.
Project Management Institute ve standardu A Guide to the Project Management Body of Knowledge (PMBOK) definuje projekt jako „dočasné úsilí vynaložené na vytvoření unikátního produktu, služby nebo určitého výsledku“ [1].
Standard PRojects IN Controlled Environments (PRINCE2) britské Office of Government Commerce (OGC) charakterizuje projekt jako „dočasnou organizaci, která je vytvořena za účelem dodání jednoho nebo více produktů na základě odsouhlaseného obchodního případu1“ [2].
Dle Společnosti pro projektové řízení, která je členem evropské organizace International Project Management Association (IPMA), je projekt „jedinečný časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupů (naplnění projektových cílů) v požadované kvalitě a v souladu s platnými standardy a odsouhlasenými požadavky“ [3].
Ke třem hlavním charakteristikám projektu patří čas, rozsah a náklady – veličiny, které mají limity a vymezují tak prostor, ve kterém se projekt vytváří podle projektového plánu. Vztah výše uvedených a vzájemně provázaných charakteristik se označuje jako
Obchodní případ (Business Case) popisuje zdůvodnění projektu, oprávněnost jeho zahájení a pokračování. 1
3
„projektový trojimperativ“ nebo „trojí omezení“, přičemž cílem projektového manažera je dosáhnout jejich optimální kombinace.
2.2 Životní cyklus projektu Projekt je v čase realizován v postupných a na sebe navazujících krocích, definovaných v zadání projektu, které umožní dosáhnout cíle. V průběhu realizace se dostává do různých fází, tedy z hlediska řízení projektů do skupin logicky vzájemně souvisejících činností, které tvoří životní cyklus projektu.
PMBOK definuje životní cyklus projektu jako „sérii fází, kterými projekt prochází od jeho zahájení po jeho ukončení“ [1].
Dle PRINCE2 se za životní cyklus projektu považuje „období od zahájení projektu do akceptace jeho produktu“ [2].
Podle IPMA se jedná o „skupinu sekvenčně za sebou jdoucích fází vyjadřujících průběh života daného projektu“ [3].
Obecně lze říci, že životní cyklus projektu určuje, jaká práce má být v určité fázi provedena, jaké výstupy a kdy je nutné dodat, které osoby se konkrétní fáze účastní a jak budou kontrolovány a schvalovány výsledky z jednotlivých fází. Projektové fáze se liší podle typu projektu, jeho velikosti, komplexnosti a dle oboru, ve kterém projekt vzniká. Obecná struktura, kterou lze aplikovat u všech projektů, rozlišuje fáze zahájení, organizace a přípravy, realizace projektových prací a dokončení projektu.
Obrázek 1: Obecný životní cyklus projektu [4]
4
2.3 Projektové řízení Řízení projektu umožňuje prostřednictvím projektu efektivně vykonávat řadu činností: stanovit cíl, vymezit časovou náročnost, definovat materiální, lidské, finanční zdroje a všechny potřebné činnosti v projektu koordinovat.
PMBOK označuje projektové řízení za “uplatnění znalostí, dovedností, nástrojů a technik při realizaci projektových aktivit za účelem dosažení požadavků projektu“ [1].
PRINCE2 považuje za projektové řízení „plánování, delegování, monitorování a kontrolu všech stránek projektu a motivování všech zúčastněných k dosažení cílů projektu v předepsaném čase, nákladech, kvalitě, rozsahu, výhodách a rizicích“ [2].
IPMA charakterizuje projektové řízení jako „aplikaci znalostí, dovedností, nástrojů a technik na činnosti v projektu tak, aby projekt splnil požadavky na něj kladené. Zahrnuje plánování, organizování, monitorování a předávání zpráv o všech aspektech projektu a motivaci všech zúčastněných dosáhnout cílů projektu“ [3].
Řízení projektu je zaměřeno na řízení jednoho projektu. Lze se setkat také s pojmy řízení programů a řízení portfolia, které slouží k řízení skupiny projektů. Rozdíl mezi nimi spočívá v tom, že v portfoliu nemají projekty a programy společný cíl a jsou seskupené za účelem řízení, kontroly a koordinace cílů; naopak program je skupina věcně souvisejících projektů a organizačních činností řízených společně.
2.4 Odlišnosti ICT projektů ICT projekt je projekt v oblasti informačních a komunikačních technologií „využívající k vytvoření produktu, služby či výstupu hardwaru, softwaru a/nebo sítí“ [5]. ICT projekty se od ostatních projektů liší především v následujících charakteristikách [6]:
Jejich produkty jsou převážně nehmotné povahy, tedy obtížněji definovatelné a mentálně uchopitelné. Tato vlastnost může být i jedním z důvodů stále nepříliš velkého procenta úspěšných projektů ICT.
Nemají většinou jasně definované zadání, cíle, uživatelské požadavky, obsah jednotlivých výstupů. Tyto obsahové náležitosti projektu se objasňují až v průběhu projektu. 5
Podporují podnikové procesy a jsou jedním z nástrojů dosahování reálných potenciálů zlepšení podnikových procesů. Tato skutečnost ale současně významně ovlivňuje množství projektových změn, které musí být v průběhu projektu zpracovávány a integrovány do řešení.
Terminologie, metodiky, metody a techniky související s řízením projektů ICT a budováním ICT nejsou jednotné.
Obrázek 2: Obecný životní cyklus ICT projektu [4]
ICT projekty se vyznačují jedinečností, neopakovatelností, dočasností, časovým vymezením projektu, jeho rozsahem, náklady, neurčitostí spojenou s riziky, postupným upřesňováním řešení, identifikací zadavatele a uživatele a interdisciplinárním charakterem. Odlišují se také v požadavcích na zdroje, které ve srovnání s běžnými projekty dosahují maxima přibližně ve 40 % délky životního cyklu projektu.
6
Obrázek 3: Odlišné nároky na zdroje ICT projektů (Autor dle [7])
7
3 Metodiky budování ICT projektů Metodika obecně představuje souhrn metod a postupů určených k realizaci konkrétního úkolu. V oblasti řízení ICT projektů je terminologie nejednoznačná, protože někteří autoři do definice zařazují činnosti vázané na vývoj ICT, zatímco jiní do ní zahrnují také oblast provozování ICT.
Podle Voříška [8] je metodika budování ICT tvořena obecně uznávanými postupy a návody, které popisují činnosti při analýze, návrhu, vývoji, nasazování software stejně jako činnosti spojené s řízením projektu. Cílem metodiky je formalizovat postupy, definovat zodpovědnosti a pravidla komunikace.
Bruckner a kol. [6] uvádí, že metodika budování ICT „definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení“. Tato definice odpovídá spíše tradičním metodikám, agilní definují jen principy a praktiky. Slovo budování vystihuje jak tvorbu informačních systémů, tak nasazení hotových řešení a rozšiřování a integrování stávajících systémů.
Existuje řada metodik budování ICT. Je tomu tak proto, že odlišné technologie vyžadují odlišné metodiky, že se metodiky přizpůsobují organizacím a týmům nebo projektům. Každá metodika zdůrazňuje jiné aspekty, např. vývoj, některé fáze životního cyklu, přístup k řešení, velikost týmu apod. a metodiky je proto obtížné vzájemně srovnávat. Metodiky lze členit podle následujících kritérií [9]:
Zaměření metodiky – hodnotí se, zda se jedná o metodiku zaměřenou na jednotlivý projekt nebo budování ICT celé organizace (projektové a globální metodiky).
Rozsah metodiky – je dán počtem fází životního cyklu informačního systému pokrytých metodikou (metodiky pokrývající celý životní cyklus tvorby a metodiky dílčí).
Váha metodiky – váha metodiky je součin velikosti (počet kontrolních prvků v metodice) a hustoty metodiky (podrobnost a konzistence prvků). Toto kritérium vymezil A. Cockburn a dělí metodiky na lehké a těžké (rigorózní).
Typ řešení – rozlišuje vývoj nového řešení, integrace řešení, rozvoj a rozšíření, customizace, implementace a užití.
Doména – představuje oblast, pro kterou je systém vytvářen (Business Intelligence, Customer Relationship Management, obecný software, Content Management, Enterprise Application Integration, e-commerce, Enterprise Resource Planning).
8
Přístup k řešení – rozlišuje paradigma vývoje (strukturovaný vývoj, rychlý vývoj aplikací, objektový vývoj, komponentový vývoj, vývoj orientovaný na služby).
3.1 Srovnání tradičních a agilních metodik Metodiky je možné na základě kritéria váha metodiky, které zohledňuje podrobnost a přesnost metodiky, členit na „těžké“ tradiční (rigorózní) a „lehké“ agilní. Tradiční metodiky jsou velmi podrobné, formální, direktivní a společně s referenčními modely procesů, různými modely životního cyklu, posuzováním zralosti a způsobilosti procesů jsou součástí tradičních přístupů budování informačních systémů [6]. Přesně stanovují procesy, všechny požadavky a produkty, předpokládají, že tvorbu IS lze přesně definovat, popsat a opakovaně realizovat. Většina těchto metodik je založena na vodopádovém modelu životního cyklu, ve kterém jednotlivé fáze vývoje softwaru následují po sobě, např. Structured Systems Analysis and Design Method (SSADM). Některé mohou vycházet z iterativního modelu životního cyklu, který rozkládá celý projekt na řadu iterací, přitom každá iterace obsahuje všechny fáze vývoje, např. Rational Unified Process. Tradiční metodiky je vhodné použít u standardních a velkých projektů. Agilní přístupy jsou opakem tradičních. Vychází z předpokladu, že proces tvorby informačního systému nelze přesně popsat, má být pružný a má nabízet rychlá řešení. Nedefinují procesy, ale popisují jen principy a praktiky a jsou tak zbaveny byrokratické zátěže. Vychází ze zkušeností získaných během vývoje, kdy je třeba projekt přizpůsobovat aktuální situaci a reagovat na změny a na požadavky zákazníka. Tyto metodiky je vhodné použít pro projekty s nejasným nebo měnícím se zadáním, pro menší týmy. Myšlenky a principy agilních metodik jsou obsaženy v Manifestu agilního vývoje software, který je jejich základním dokumentem. Principy agilních metodik tak, jak jsou uvedené v Manifestu, vychází ze čtyř základních myšlenek, které preferují [10]:
Jednotlivce a interakce před procesy a nástroji.
Fungující software před vyčerpávající dokumentací.
Spolupráci se zákazníkem před vyjednáváním o smlouvě.
Reagování na změny před dodržováním plánu.
Protože tradiční a agilní metodiky vychází z odlišných předpokladů a z jiného pohledu na vývoj softwaru, jsou jinak zaměřené a vhodné pro jiný typ projektu.
9
Rigorózní metodiky
Agilní metodiky
Nástroje metodiky
Procesy se zaměřují na formálnost a dokumentovatelnost, lidé jsou sekundární faktor
Praktiky vychází ze znalostí jednotlivců, lidé jsou klíčovým faktorem úspěchu
Podrobnost metodiky
Podrobný popis činností a procesů
Pouze základní struktura
Kvalita
Zaměření na kvalitu procesů, které povedou ke kvalitnímu výsledku
Zaměření na priority zákazníka
Předvídatelnost
Sběr požadavků a plánování předem
Přírůstkové shromažďování požadavků, plánování po iteracích
Změny
Snaha změny minimalizovat a řízení změn
Snaha změny umožnit s ohledem na nové znalosti
Participace zákazníka na projektu
Jen v počátečních a koncových fázích
Po celou dobu projektu
Specializace lidí
Vyžaduje specializaci pro týmové role
Sdílení znalostí a spolupráce v týmu
Dokumentace
Rozsáhlá dokumentace
Minimální dokumentace, podstatné je pochopení
Způsob vývoje
Vodopádový, iterativní s dlouhými iteracemi
Přírůstkový vývoj s velmi krátkými iteracemi
Forma komunikace
Převážně písemná
Osobní
Tabulka 1: Porovnání rigorózních a agilních metodik (Autor dle [11])
Tradiční a agilní metodiky se dále liší v proměnných trojimperativu. Tradiční projektové řízení na začátku definuje množinu požadavků (rozsah), kterou považuje za neměnnou. Dle nich odhaduje čas a náklady potřebné na realizaci, které jsou proměnnými veličinami. Naopak agilní řízení projektů považuje za neměnné čas a zdroje a proměnnou veličinou je rozsah, který je přizpůsobován prioritám zákazníka.
10
Obrázek 4: Porovnání trojimperativu u rigorózních a agilních metodik (Autor)
S ohledem na velký rozvoj agilních metodik v posledních deseti letech by se dalo usuzovat, že se jedná o univerzální metodiky, které by mohly nahradit tradiční přístupy, což byla i myšlenka jejich vzniku. Realita je však jiná. Ne vždy jsou agilní metodiky nejlepším přístupem, např. když je třeba zvažovat řadu parametrů charakteristických pro projekt. Vhodná může být kombinace obou přístupů, kdy lze odlehčit rigorózní metodiky obohacením o agilní prvky.
3.2 Výběr vhodné metodiky Volba vhodné metodiky není jednoduchou záležitostí. Návrh ovlivňuje řada faktorů, které různí autoři definovali a použili při výběru.
Charvat [12] používá jednoduché měřítko pro volbu mezi agilními a tradičními metodikami. Kombinuje délku trvání projektu s jeho složitostí a pro takto získanou velikost projektu doporučuje použít příslušnou metodiku.
Alistair Cockburn [13] u agilních metodik Crystal vychází z faktoru počet lidí zapojených do projektu a z důležitosti projektu. Počet lidí udává velikost pracovní skupiny, důležitost je vztažena k velikostem ztrát při selhání projektu (od diskomfortu po ohrožení života).
Boehm a Turner [14] formulovali pět základních faktorů: Faktor
Agilní
Tradiční
Velikost
Malé produkty a týmy.
Velké produkty a týmy.
Kritičnost
Nedostatečně ověřené u životně důležitých projektů, možné potíže kvůli jednoduchému návrhu a omezené dokumentaci.
Přizpůsobené pro životně důležité projekty, pro malé projekty zbytečně složité.
11
Dynamika
Vhodné pro často se měnící prostředí.
Vhodné pro stabilní prostředí.
Lidé
Vyžaduje přítomnost SW expertů po celou dobu projektu.
Přítomnost SW expertů při definování projektu, později specialisté nejsou vyžadováni.
Kultura
Pocit komfortu + podpora volnosti.
Pocit komfortu + jasně definované role a procedury.
Tabulka 2: Faktory v agilních a tradičních metodikách [14]
Jejich kritéria doplnil Taylor [15] o faktor zapojení zákazníka do projektu, kdy rozlišuje jeho přímou účast při řešení projektu a zohledňuje důvěru zákazníka v agilní principy.
Hecksel [16] patentoval systém výběru a hodnocení metodik. Ohodnotil projekt, tj. definoval Projektový kontext složený ze tří částí Lidé, Proces, Technologie. V každé části definoval vlastnosti typické pro projekt (název, popis, hodnocení, stupnice hodnot). V modelu metodik stanovil jednotlivé metodiky a zvolil pro ně hodnocení. Pomocí statistik, simulací a predikcí porovnával hodnoty atributů Projektového kontextu s hodnotami metodik obsažených v modelu a hledal mezi nimi shodu.
Buchalcevová [9] v systému hodnocení metodik METES (Methodology Evaluation System) používá čtyři skupiny kritérií: Proces (skupina hodnotí rozsah, model životního cyklu, role, podrobnost popisu procesu, dokumenty, metriky, řízení kvality), Podpora (hodnotí celistvost zdrojů, dostupnost, podporu metodiky softwarovými nástroji, podporu zavedení metodiky, přizpůsobení, výuku na vysokých školách, školení a certifikace, lokalizaci), Produkt (důležitost produktu, délku projektu, stálost požadavků, znovupoužitelnost, velikost řešení), Lidé (zkušenost manažera projektu, kvalifikace a motivace členů týmu, velikost týmu, rozmístění, dostupnost uživatelů).
Z uvedeného přehledu je zřejmé, že volba kritérií je individuální záležitostí. Cílem práce je vybrat vhodnou agilní a rigorózní metodiku pro kombinaci se standardem projektového řízení pro partnerskou organizaci. Tato partnerská organizace má zkušenosti s metodikami Scrum a RUP, které doposud při vývoji softwaru používala. Toho využívá také autor, který ve své práci vychází z těchto dvou metodik jako typických a propracovaných představitelů svých kategorií. Scrum je procesní rámec pro vývoj a údržbu produktů postavený na iterativním a inkrementálním vývoji. Zdůrazňuje spolupráci v týmu, komunikaci se zákazníkem a je flexibilní vůči změnám v projektu. V současné době je nejpoužívanější agilní metodikou, kterou dle průzkumu z roku 2013 používá 73 % organizací [17] a mnohými autory je také synonymem pro „agile“ [18]. Někteří považují výběr Scrumu za nejlepší volbu pro řešení jakéhokoliv projektu [19]. RUP lze 12
charakterizovat jako deskriptivní, podrobně popisující procesy a činnosti během vývoje softwaru. Obsahuje nástroje, postupy a techniky, které se používají při vývoji softwaru a je téměř standardem mezi těžkými metodikami [20]. Výhodou je možnost nastavení na míru danému projektu. Nabízí také možnost využít i předem připravené varianty řešení, které lze snadno a ihned začít používat. Díky své složitosti se více hodí na projekty většího rozsahu.
3.3 Scrum První informace o Scrumu sahají do roku 1986, kdy byly popsány nové možnosti při řízení týmů. V názvu (skrumáž) se využívá metafora s ragbyovým zápasem, tedy označení pro rychlý a adaptivní proces, jehož cílem je postupovat po určitých částech až k zamýšlenému bodu, podobně jako je tomu v ragbyovém zápase. Metodika se dokáže vyrovnat s měnícími požadavky a vylepšit produktivitu procesu vývoje softwaru [21]. K tomu užívá každodenní přezkoumání realizovaných požadavků, stanovení dalších kroků a maximální spolupráci uvnitř týmu i intenzivní komunikaci se zákazníkem. Scrum je procesní rámec vhodný především pro malé týmy o několika členech, který pomáhá zvládnout složité adaptivní úkoly, do projektu však umožňuje zapojit i více týmů. Životní cyklus produktu ve Scrumu zahajuje Vlastník produktu (Product Owner), který definuje cíle projektu. Vytvoří Product backlog, tedy seznam požadavků seřazených podle priority. Celý vývoj probíhá v iteracích označovaných Sprinty. Pro každý Sprint si Vývojový tým naplánuje množství práce, kterou během Sprintu stihne dokončit. Ta je obsahem Sprint backlogu a je detailním popisem úkolů vybraných z Product backlogu pro nejbližší období. Součástí Sprintu je několik povinných schůzek [22]: Plánovací schůzka (Sprint Planning), Denní schůzka (Daily Scrum), Vyhodnocení sprintu (Sprint Review) a Retrospektiva sprintu (Sprint Retrospective), na nichž probíhá plánování činností, odhady práce, zpětná kontrola vykonané práce, přezkoumání a vyhodnocení přírůstku – dokončené práce, úprava backlogu, návrhy na zlepšení. Po určitém počtu Sprintů, kdy jsou stanovené cíle splněny, je produkt dokončen.
13
Obrázek 5: Životní cyklus produktu v metodice Scrum (Autor dle [23])
3.3.1 Role Role definují funkce, ve kterých vystupují lidé zapojení do Scrumu. Metodika definuje tři základní role: Vlastník produktu, Vývojový tým a Scrum master, kteří společně tvoří Scrum tým. Scrum tým je sebeorganizující, sám si volí, jak provede práci a je zcela soběstačný. Vlastník produktu Je autoritou, která reprezentuje zájmy zákazníka a zodpovídá za návratnost jeho investice. Je odpovědný za zadání projektu, za rozhodnutí o rozsahu, rozpočtu a termínech projektu. Definuje požadavky, vybírá řešení a stanovuje prioritní vlastnosti projektu tak, aby byl Vývojový tým seznámen s dalším postupem. Je také klíčovou osobou při plánování, definuje akceptační kritéria pro každou položku backlogu a ověřuje jejich splnění, spolupracuje se všemi účastníky projektu. Scrum master Zodpovídá za dodržování pravidel Scrumu. Působí jako agilní kouč pro obě další role, kterým napomáhá ve vzájemné komunikaci a udržuje jejich činnost v mantinelech Scrumu. Pomáhá týmu dosáhnout cílů, odstraňuje problémy, motivuje tým k lepším výsledkům, chrání ho před vnějšími vlivy. Měl by usnadnit práci týmu a směrovat ho ke schopnosti samostatně se řídit. Je autoritou, snaží se zavést hodnoty, principy a zvyklosti Scrumu.
14
Vývojový tým Tým je multifunkční jednotka, která obsahuje všechny potřebné profese. Je složený z profesionálních členů, kteří jsou schopni během jednoho Sprintu vytvořit přírůstek produktu. Každý vývojový tým je autonomní, sám se spravuje, kolektivně rozhoduje, jeho práci (přeměnu Product backlog v přírůstek produktu) nikdo jiný neorganizuje. Vyvíjí a testuje produkt, předkládá zlepšovací návrhy, plánuje Sprinty, prezentuje výsledky své práce Vlastníkovi produktu. V rámci jednoho Sprintu se tým plně věnuje pouze zadané práci a jeho složení se nemění.
3.3.2 Artefakty Artefakty označují entity, které ve Scrumu vznikají, mění se nebo se používají a které jsou užitečné pro zajištění transparentnosti a kontroly. Patří k nim Product backlog, Sprint backlog a přírůstek. Product backlog Jedná se o seznam všech vlastností, funkcí, požadavků včetně jejich průběžné aktualizace, rozšíření, technických zlepšení, oprav a dalších prací, které budou vyžadované a vhodné pro následujícího vývoj produktu. Seznam má být dostatečně detailní, pohotový, dynamický. Položky backlogu jsou zaznamenány ve formě uživatelských příběhů (user stories) a mají stanovenou prioritu, popis a odhad. Jsou rozdělené tak, aby každá položka mohla být dokončena během jednoho Sprintu. Priorita položek v seznamu se odvíjí od přínosu, míry rizika a naléhavosti zpracování. Sprint backlog Definuje práci vývojového týmu, která je nutná pro vytvoření přírůstku a pro splnění Sprintu a která přinese uživateli očekávanou hodnotu. Je velmi detailně rozpracovaným souborem položek vybraných z Product backlogu, které mají být v průběhu Sprintu zpracovány. Změny ve Sprint backlogu provádí pouze vývojový tým, který denně položky sleduje, aktualizuje a jejich seznam upravuje podle probíhajícího vývoje. Sprint backlog pomáhá vývojovému týmu orientovat se v úkolech a aktualizovat odhad práce, kterou má během iterace vykonat. Přírůstek Je to součet všech položek z Product backlogu, které byly dokončeny v průběhu minulých Sprintů a v současném Sprintu. Po dokončení musí být použitelný pro nasazení a také musí být Scrum týmem odsouhlasený jako „hotovo“. Definici hotového přírůstku 15
si generuje každý tým individuálně, aby posoudil, zda je práce ve Sprintu dokončena a splněna v odpovídající kvalitě. Přírůstky se doplňují, testují a sleduje se jejich kompatibilita.
3.3.3 Činnosti ve Scrumu Scrum je založený na dodržování předepsaných činností. Je tím zajištěna transparentnost procesů a jejich kontrola, sledování nákladů a je umožněna adaptace na změny. Scrumem předepsané činnosti mají základ v pravidelnosti a v dodržování pro ně stanovených časových limitů. Nedochází tak k prodlevám a ztrátám času v průběhu plánování. Sprint Označuje iteraci ve Scrumu. Je to časově limitované období, jehož výstupem je přírůstek produktu. Všechny Sprinty by měly trvat stejnou dobu. Sprinty mají stanovený začátek i konec a vzájemně na sebe navazují, nový Sprint vzniká hned po dokončení předcházejícího. Každý Sprint se skládá z Plánovací schůzky, Denních schůzek, vlastních vývojových prací, Vyhodnocení sprintu a Retrospektivy. Obsahem Sprintu je návrh cílového produktu, plán k realizaci cíle, dále samotná práce a výsledný produkt. Během Sprintu nelze provádět změny ovlivňující cíl Sprintu. V situaci, kdy tým časově nezvládá práci, konzultuje Vlastníka produktu, zda a které položky Product backlogu mohou být odstraněny ze současného Sprintu. Naopak pokud je tým schopný zpracovat větší objem práce, Sprint se doplní o nové položky z backlogu. Plánovací schůzka Na plánování činností v průběhu Sprintu se podílí celý Scrum tým. Plánovací schůzka je časově limitovaná záležitost, na které se ujedná, jaký přírůstek ve Sprintu vznikne a jaká práce se vykoná pro jeho vytvoření. Denní schůzka Je pravidelná každodenní schůzka vývojového týmu, na které tým vyjedná plán na dalších 24 hodin. Kontroluje na ni práci vykonanou od poslední Denní schůzky a odhadne a naplánuje práci pro následující den.
16
Vyhodnocení sprintu Jedná se o neformální schůzku Scrum týmu s ostatními stakeholdery, jejímž cílem je přezkoumat přírůstek a v případě potřeby upravit Product backlog. Retrospektiva sprintu Je příležitostí ke zpětné kontrole práce Scrum týmu. Pomáhá naplánovat kroky, které pomohou zlepšit činnost týmu v následující iteraci. Všímá si použitých procesů, nástrojů, mezilidských vztahů.
Další informace jsou dostupné z [21] nebo [22].
3.4 Rational Unified Process Za počátek metodiky je možné považovat Ericssonův model z roku 1967, který rozděluje složité systémy z pohledu vzájemné komunikace do menších propojených bloků. Model byl postupně upravován a rozšiřován tím způsobem, že byl iterativní vývoj uspořádán do po sobě jdoucích fází a výsledkem těchto inovací byla metodika Rational Objectory Process, která byla v roce 1998 přejmenována na Rational Unified Process [20]. K vyjádření této metodiky byl použitý jazyk UML. Metodika je procesním rámcem pro vytvoření vhodné kombinace modelů a procesů v konkrétním projektu. Je variabilní, zobecňuje řadu procesů, lze ji přizpůsobit jakémukoliv projektu a konfigurovat na míru potřebám konkrétní organizace. Metodika vychází z praxí ověřených postupů a zkušeností, které vedou k úspěchu projektu. Opírá se o šest nejlepších praktik [24]:
Iterativní vývoj softwaru (Develop software iteratively), který umožňuje předvídat rizika v každé fázi životního cyklu a reagovat na ně, usnadňuje správu změn, spolupráci se zákazníkem, testování aj.
Správa požadavků (Manage requirements), která znamená udržovat kontakt se zákazníkem, získávat, organizovat a dokumentovat požadavky a dynamicky reagovat na jejich změny tak, jak k tomu dochází v průběhu vývoje.
Použití komponentové architektury (Use component-based architectures), kdy komponenty jsou netriviální části systému, zajišťují určitou funkcionalitu, jsou nezávislé a nahraditelné jinými komponentami. Opakované použití hotové komponenty zvyšuje efektivitu vývoje a úsporu zdrojů. 17
Vizuální modelování softwaru (Visually model software), které zjednodušuje pohled na systém, umožňuje lépe systému porozumět: graficky znázornit procesy, závislosti, strukturu, chování komponent, zlepšit komunikaci.
Kontrolování kvality softwaru (Continously verify software quality), které předpokládá průběžné hodnocení požadavků na kvalitu, jakými jsou např. funkcionalita, spolehlivost a výkon v rámci každé iterace
Řízení změn (Control changes to software), které nabízí postup změnového řízení pro optimální vývoj. Zajišťuje, aby změny byly přijatelné, aby proběhlo jejich otestování a v případě problému byla možnost vrátit se k původní verzi softwaru
Na RUP lze nahlížet ze dvou pohledů [24]: dynamického, kterým se rozumí životní cyklus projektu složený z cyklů, fází, iterací a milníků a statického, který člení metodiku na role, aktivity, artefakty a pracovní procesy.
3.4.1 Dynamický pohled Životní cyklus RUP se skládá ze čtyř na sebe navazujících fází, kdy každá fáze je zakončena milníkem, tj. byly splněny cíle, které umožnily zahájit další fázi. Ke čtyřem fázím patří [24] fáze Zahájení (Inception), Rozpracování (Elaboration), Konstrukce (Construction) a Nasazení (Transition). Součástí každé fáze jsou iterace, počet iterací závisí na velikosti projektu. Fáze vytvářejí vývojový cyklus, při jehož ukončení vznikne první verze softwaru. Pokud není vývoj produktu ukončený, může vznikat několik generací softwaru. Čtyřgenerační cyklus je zobrazený na obrázku níže.
Obrázek 6: Životní cyklus produktu v metodice RUP (Autor dle [24])
Ve fázi zahájení je vytvořen obchodní případ a vymezen rozsah projektu. Musí být podchyceny všechny externí entity, se kterými systém komunikuje, identifikovány případy 18
užití, vyčísleny náklady, odhadnuta rizika. Výstupem této fáze je vize projektu, klíčových vlastností a rozsah požadavků, počáteční model případů užití, počáteční obchodní případ, projektový plán a odhad rizik. Ve fázi rozpracování je během jedné nebo více iterací vytvořený spustitelný prototyp. Jedná se o kritickou fázi, která je jako základ v dalších fázích rozpracována do definitivního a plnohodnotného systému. Výstupem fáze jsou: spustitelný architektonický prototyp, popis architektury softwaru, use case model, revidovaný seznam rizik a obchodní případ, plán projektu včetně iterací aj. Cílem konstrukční fáze je vyvinou konečnou verzi systému a otestovat ji. Důležité je zachovat integritu systému a rovnováhu mezi náklady, časovým harmonogramem a kvalitou systému. Výstupem fáze je produkt, který je provozně způsobilý, otestovaný a připravený k předání zákazníkovi společně s manuálem. Cílem fáze nasazení je předat produkt uživatelům. Současný produkt je pouze betaverzí, kterou je třeba ještě vyladit a dále testovat, přizpůsobit software pracovišti uživatele, školit uživatele a poskytovat podporu a údržbu produktu.
3.4.2 Statický pohled Metodika popisuje proces pomocí čtyř základních elementů, které odpovídají na následující otázky: Role – „Kdo?“, Aktivity – „Jak?“, Artefakty – „Co?“, Pracovní procesy – „Kdy?“ [24]. Role určují chování a odpovědnosti jedinců nebo týmu uvnitř projektu, přitom jednotlivec může zastávat různé role. Aktivitou je jednotka práce nebo činnost, která je přidělena určité roli a která má jasný účel, výstup aktivity je označovaný jako artefakt. Ten představuje část informace, která je vytvořena, modifikována a používána v procesu vývoje. Artefakty jsou vstupem i výstupem aktivit. Pracovní procesy jsou sekvence aktivit, které vykonávají jednotlivé role, zachycují interakce mezi rolemi a vytvářejí pozorovatelný výsledek. Nejvýznamnější pracovní procesy se společnou oblastí zájmu se označují jako disciplíny, kterých je devět: Obchodní modelování (Business Modeling), Požadavky (Requirements), Analýza a návrh (Analysis and Design), Implementace (Implementation), Testování (Test), Nasazení (Deployment), Konfigurační a změnový management (Configuration and Change Management), Projektový management (Project Management), Správa prostředí (Environment).
19
Další informace jsou dostupné z [24] nebo [20].
Při srovnání metodik je RUP objektově orientovanou iterativní metodikou, dodávanou jako sada HTML stránek. Tato robustní, rozsáhlá a propracovaná metodika, provázaná s UML notací, vychází z potřeb praxe. Detailně instruuje celý tým, jak má postupovat v průběhu realizace projektu. Pro potřeby řízení a vývoje obsahuje množství kvalitních a podrobných návodů včetně podpůrných prostředků. Metodiku lze přizpůsobit celé řadě projektů, díky rozsáhlosti však vyhovuje spíše realizaci větších projektů. Její šíře a mohutnost se může stát nevýhodnou, protože její detailnost, kdy popisuje desítky rolí, aktivit a artefaktů, nutí tým metodiku podrobně prozkoumávat a předepsaný postup se tak stává časovou zátěží. Scrum je adaptabilní metodika využívající periodicky se opakující činnosti, často se používá v kombinaci s dalšími metodikami. Metodika je jednoduchá, schopná rychle reagovat na změny a přizpůsobovat se novým požadavkům, stejně jako rychle odstraňovat chyby a šetřit tak náklady. Vývoj projektu lze graficky monitorovat a kontrolovat a eventuálně neúspěšný projekt zavčas zastavit. Metodika vyžaduje sehraný, motivovaný a flexibilní tým, který je schopný se samostatně organizovat. Předpokládá odlišný způsob zapojení zákazníka do projektu, když očekává pravidelné vzájemné konzultace a dobrou spolupráci.
Obrázek 7: Srovnání metodik z pohledu životního cyklu SW [25]
Jinými používanými dokumenty, které obsahují obecná doporučení, požadavky, pokyny a návody i specifikace, které byly vytvořeny na základě best practices a slouží jako norma pro srovnávání a hodnocení, jsou standardy. Oproti metodikám budování ICT nacházejí širší uplatnění; lze je aplikovat na projekty různých odvětví, nejen při vývoji softwaru. Svou strukturou se podobají tradičním metodikám budování ICT. 20
4 Standardy projektového řízení Standardy v projektovém řízení jsou souhrnem nejlepších poznatků a zkušeností, které získali během svého profesního života zkušení manažeři působící v dané oblasti. Standardy však nejsou technickým návodem, jak řídit projekt, ale zohledňují řadu proměnných, které jsou součástí projektového řízení a mají být inspirací pro vedoucí pracovníky pří řízení projektů. Jejich přínos spočívá v usnadnění a zefektivnění komunikace a spolupráce projektových týmů. „Standard popisuje nejlepší praktiky vztahující se k tomu, co by se mělo v rámci řízení projektu udělat. Metodika pak popisuje, jak by to mělo být uděláno“ [5]. K nejznámějším standardům patří A Guide to the Project Management Body of Knowledge (PMBOK), PRojects IN Controlled Environments (PRINCE2) a IPMA Competence Baseline (ICB) a normy ISO 10 006 a ISO 21 500. Ke dvěma základním orientacím standardů patří jejich zaměření kompetenční a procesní. 1. Cílem kompetenčně pojatého standardu je definovat kompetence manažerů a členů týmů při řízení projektů, tj. zaměřit se na jejich schopnosti a dovednosti, zda je umí uplatnit v praxi a na jejich osobní vlastnosti. Standard nepředepisuje procesy, ale doporučuje účastníkům projektu určité postupy při řešení konkrétních situacích. Neomezuje je, ale ponechává jim prostor pro jejich tvořivý přístup. Příkladem takového standardu je IPMA Competence Baseline [3], která vychází z tzv. oka kompetencí, ve kterém jsou integrované všechny složky projektového řízení důležité pro projektového manažera. 2. Procesní přístup řízení projektů umožňuje řídit projekt jako proces a aplikovat na něj veškerá pravidla obecně platná pro procesy. Norma ISO 10006:2003 definuje proces jako „soubor vzájemně propojených zdrojů a činností, které přeměňují vstupy na výstupy“ [26]. Projekt by měla provázet prokazatelná dokumentace, všechny zainteresované strany by o něm měly mít znalosti a informace, procesy by měly být efektivně vyhodnocované, na projekt by měly být aplikované zásady systému managementu jakosti [6]. Příkladem procesního pojetí standardů projektového řízení jsou PMBOK a PRINCE2.
21
4.1 Standard PMBOK Vznikl v roce 1987 podle standardů US Army. Standard je využitelný nejen v projektech z oblasti IT a softwaru, ale i v průmyslu, stavebnictví a jiných sférách. Vytvořilo ho největší profesní sdružení projektových manažerů na světě Project Management Institute [27]. Představuje procesní rámec, který definuje projektové řízení z různých hledisek, přitom vychází z osvědčených postupů dlouhodobě používaných při úspěšném řízení projektu. Těžiště standardu spočívá v definování procesu jako souboru vzájemně souvisejících činností, jejichž cílem je vykonat stanovenou práci, vytvořit specifikovaný produkt, službu nebo výsledek [1]. Každý proces je definován vstupy, nástroji a technikami a výstupy. Do standardu je zahrnuto 47 procesů rozdělených do 5 procesních skupin a 10 znalostních oblastí. Každý proces spadá jak do procesní skupiny, tak do určité znalostní oblasti. V úvodu standardu [1] je definován projekt, vymezeno projektové řízení, stanovena role projektového manažera, vysvětleny vztahy mezi projektem, programem a portfoliem. Druhá kapitola popisuje životní cyklus projektu a vliv organizace na projekt. Zabývá se kulturou, organizační strukturou, způsobem komunikace, vztahy se zainteresovanými osobami, popisuje složení projektového týmu a fáze projektů. Třetí kapitola se zabývá procesními skupinami, ke kterým patří: Zahájení (Initiating Process Group), Plánování (Planning Process Group), Realizace (Executing Process Group), Monitorování a kontroly (Monitoring and Controlling Process Group) a Uzavření (Closing Process Group). Zbývající kapitoly se věnují znalostním oblastem: Integrovanému řízení projektu (Project Integration Management), Řízení rozsahu projektu (Project Scope Management), Řízení času projektu (Project Time Management), Řízení nákladů projektu (Project Cost Management), Řízení kvality projektu (Project Quality Management), Řízení lidských zdrojů projektu (Project Human Resource Management), Řízení komunikace projektu (Project Communications Management), Řízení rizik projektu (Project Risk Management), Řízení dodávek projektu (Project Procurement Management), Řízení zainteresovaných stran v projektu (Project Stakeholder Management).
4.1.1 Procesní skupiny V průběhu životního cyklu projektu současně probíhá, spolupracuje a na sebe navazuje celá řada vzájemně propojených a souvisejících procesů, které se mohou opakovat. Tyto aktivity jsou logicky seskupené do procesních skupin podle jejich povahy, vývojového stupně projektu a způsobu ovlivňování celkového procesního toku. Jednotlivé procesní 22
skupiny se vzájemně ovlivňují, překrývají se, mohou probíhat opakovaně nebo souběžně, nemusí na sebe navazovat a všechny se mohou odehrát během jedné fáze životního cyklu projektu. Procesní skupiny se tak neshodují s fázemi projektu [28]. Procesy obsažené v Zahajovací procesní skupině iniciují nový projekt nebo novou fázi stávajícího projektu. Jsou určeny ke schválení a povolení projektu. Procesy v Plánovací procesní skupině navazují na výstupy předchozí fáze a detailně plánují činnosti zasahující do všech znalostních oblastí. Stanovují rozsah a cíle projektu, definují činnosti potřebné k dosažení cíle včetně vypracování projektových plánů. Do Realizační procesní skupiny patří procesy, které je nutné vykonat; patří k nim práce s lidskými zdroji, koordinace zdrojů, plnění očekávání zainteresovaných stran a realizace činností v souladu s projektovým plánem. Činnosti cílené na ověřování reálného postupu projektu ve srovnání s jeho plánem jsou obsažené v procesní skupině Monitorování a kontroly. Používané procesy jsou potřebné ke sledování probíhajících činností a k vyhodnocování pokroku projektu a jeho dalšího směrování. Uzavření je poslední procesní skupinou, kam jsou zařazeny procesy nutné pro dokončení všech běžících procesů v projektu nebo jeho fází. Jejich účelem je zhodnotit projekt nebo fázi, zaznamenat dopady změn, zpracovat výsledky a získané zkušenosti, získat akceptaci projektu zákazníkem, archivovat dokumentaci projektu.
Obrázek 8: Procesní skupiny PMBOK s hlavními procesy (Autor dle [1])
23
4.1.2 Znalostní oblasti Znalostní oblast představuje soubor konceptů, pojmů a aktivit, které náleží určité oblasti, oboru nebo specializaci [1]. V každé znalostní oblasti se používají nástroje a techniky projektového řízení, specifické pro danou kategorii. Znalostní oblasti obsahují klíčové kompetence projektového manažera, které rozhodují o úspěchu projektu.
Integrované řízení projektu spočívá v koordinaci ostatních znalostních oblastí v životním cyklu projektu a zajišťuje, že se všechny elementy projektu ve vhodnou dobu propojí a projekt bude úspěšně dokončený. Řízení rozsahu projektu zahrnuje procesy, které definují a kontrolují, jaké práce budou obsaženy v projektu, tj. které jsou potřebné k jeho úspěšnému dokončení. Řízení času projektu obsahuje procesy nutné k tomu, aby byl projekt včas dokončený. Řízení nákladů projektu zajišťuje, aby byl projekt dokončený v mezích schváleného rozpočtu. Řízení kvality projektu sleduje, zda projekt splňuje požadavky v definované kvalitě. Řízení lidských zdrojů projektu umožňuje co nejefektivněji využívat lidský kapitál zainteresovaný na projektu. Řízení komunikace projektu má zajistit včasné plánování, sběr, distribuci, dokumentování, archivování, řízení, kontrolu a monitorování informací v projektu. Řízení rizik projektu je cílené na snížení dopadu nežádoucích vlivů a naopak na využití působení pozitivních vlivů. Řízení dodávek projektu znamená pořizování zboží, služeb nebo výsledků od externích zdrojů. Řízení zainteresovaných stran v projektu identifikuje osoby, skupiny nebo organizace, které mohou projekt ovlivnit nebo mohou být ovlivněny projektem, analyzuje jejich požadavky a vytváří pro ně strategii řízení.
Další informace jsou dostupné z [1].
24
4.2 Standard PRINCE2 PRINCE2 je považován za univerzální standard založený na procesním pojetí projektového řízení, který může být použitý při řízení projektu jakéhokoliv typu a velikosti [2]. Původní metodika britské společnosti Simpact Systems Ltd. byla postupně upravována a od roku 1989 se používá jako doporučený standard pro realizaci vládních projektů v oblasti IT. Jeho poslední revize proběhla v roce 2009. Standard se člení do 4 elementů, k nimž patří:
Sedm principů,
Sedm témat,
Sedm procesů a
Přizpůsobení PRINCE2 prostředí projektu.
4.2.1 Principy Všechny principy mají společnou charakteristiku: Jsou univerzální, lze je aplikovat při každém projektu, jsou samovalidovatelné, byly ověřeny opakovaným používáním na projektech. Pokud není aplikováno všech sedm principů, nejedná se o PRINCE2 projekt [2]. Neustálé zdůvodňování opodstatněnosti projektu dokládá jeho odůvodnění a podložení Obchodním případem (Business Case). Ten musí být zdokumentovaný a schválený, řídí se podle něj rozhodování a zajišťuje, že je projekt přínosný. Učení se ze zkušeností předpokládá, že všichni zapojení do projektu budou čerpat ze zkušeností a znalostí jak na počátku projektu, tak v jeho průběhu a při ukončení projektu. Definované role a odpovědnosti je nutné stanovit pro úspěšný průběh projektu. Každý člen týmu musí znát své odpovědnosti a musí být seznámen také s odpovědnostmi ostatních. Mezi členy týmu musí probíhat efektivní komunikace. Řízení po etapách rozděluje projekt na etapy, jejichž počet závisí na velikosti a komplexnosti projektu a na souvisejících rizicích. Podrobně je naplánovaná pouze nejbližší etapa, která se po dokončení spolu s dalšími aktualizovanými dokumenty schvaluje. Řízení na základě výjimky definuje několik úrovní rozhodování v projektu, přitom je důležité, aby rozhodnutí byla činěna na odpovídajícím stupni řízení.
25
Zaměření standardu na produkty a jejich identifikaci vychází z toho, že úspěšné projekty jsou zaměřené na výsledek, nikoli na průběh projektu. Takto standardem definované produkty potom určují rozsah projektu a vychází z nich plánování a kontrola průběhu projektu. Přizpůsobení PRINCE2 prostředí a okolí projektu umožňuje flexibilita standardu. Podmínkou je, aby úprava vyhovovala v oblasti prostředí, velikosti, komplexity a rizika a cílem je zajistit, aby byl projekt vedený vzhledem k jeho rozsahu, složitosti a významu.
4.2.2 Témata Témata popisují projekt z různých hledisek, vzájemně spolu souvisí a jsou integrována do projektu. Mají společnou strukturu, a to cíl, definici, přístup a odpovědnosti. Téma
Popis
Odpověď na otázku
Obchodní případ (Business Case)
Projekt je založený na nápadu, který by měl být pro organizaci přínosný. Téma rozpracovává, jakým způsobem je tento nápad realizován a prověřuje, zda je projekt i nadále žádoucí, životaschopný a jeho cíl dosažitelný.
Proč?
Organizace (Organization)
Po dobu trvání projektu jsou definovány role, odpovědnosti a vztahy mezi zapojenými pracovníky. Role mohou být podle velikosti projektu kombinovatelné, sdílené nebo přiděleny jednotlivci.
Kdo?
Kvalita (Quality)
Představuje způsob vzniku produktu a hlediska pro kontrolu jeho kvality. Stanovuje normy a metody kontroly kvality, které mají být použitelné a způsob jejich dodržování.
Co?
Plány (Plans)
Plánování projektu je prováděno pro nastavení kontroly komunikace a prováděných prací se zaměřením na produkty. Definuje kdo, kdy, kde a jak dodá produkty. Probíhá na třech úrovních: Plán projektu, Plán etapy a Plán týmu.
Jak? Kolik? Kdy?
Rizika (Risk)
Účelem je identifikovat, vyhodnotit a kontrolovat nejistotu. Na začátku projektu identifikovat rizika, provést jejich hodnocení, stanovit vlastníky rizik, způsob ošetření a monitorování rizik.
Co když?
Změna (Change)
Uvádí postupy jak posuzovat a reagovat na události s možným dopadem na plány projektu a produkty. Řízení změny: postupy, jak změny identifikovat a řešit. Řízení konfigurací: identifikovat, sledovat a ochraňovat produkty projektu.
Jaký je dopad?
26
Progres (Progress)
Soubor řídících prvků, které umožní kvalifikovaně posoudit vývoj projektu a určí jeho další směr, systém pro schvalování plánů a pro řešení odchylek od plánu.
Kde jsme? Kam směřujeme? Máme pokračovat?
Tabulka 3: PRINCE2 témata (Autor dle [29])
4.2.3 Procesy Procesy chronologicky popisují průběh projektu. Obsahují jednotlivé kroky řízení projektu, tedy řízený začátek, realizaci a ukončení [2]. Procesy jsou složeny z aktivit, které mohou probíhat paralelně nebo na sebe navazovat. Obsahem aktivit jsou doporučené činnosti, jejichž pomocí lze dosáhnout kýžených výsledků. Projekt PRINCE2 probíhá v několika na sebe navazujících etapách. V předprojektové etapě se zpracovává myšlenka či potřeba a ověřuje a dokumentuje se užitečnost a proveditelnost projektu. V navazující iniciační etapě se projekt detailně plánuje, získávají se zdroje k jeho financování a definují se kontrolní mechanismy. V realizační etapě probíhají vlastní práce na produktu. Ve fázi ukončení jsou produkty dodány, zhodnoceny výsledky, proběhlé události a dosažené cíle a jsou posouzené skutečné termíny a náklady vůči plánovaným.
Obrázek 9: PRINCE2 procesy (Autor dle [2])
Zahájení projektu předchází projektu, má stanovit cíle, popsat projekt a rozhodnout o přístupu, který se použije při realizaci, odsouhlasit kvalitu připraveného plánu, definovat role a odpovědnosti.
27
Směrování projektu popisuje od počátku do ukončení projektu kroky, které jsou důležité pro řízení projektu autoritami. Účelem je vykonávat celkové řízení projektu a přijímat příslušná rozhodnutí. Nastavení projektu obsahuje postupy, které slouží ke kontrole, zda je projekt v souladu s nastavenými cíli a strategiemi. Kontrola etapy monitoruje a řídí aktivity, které jsou nutné ke sledování postupu projektu a zajistí korekci neočekávaných situací. Řízení dodání produktu zajišťuje realizaci úloh, které probíhají do dokončení požadovaného produktu, jeho odevzdání a dokumentování, včetně získání souhlasu s uspokojivým vykonáním práce. Řízení přechodu mezi etapami dokumentuje průběh právě skončené etapy, sumarizuje časové požadavky, požadavky na zdroje, posuzuje rizika, přezkoumává schopnost projektu pokračovat dále, plánuje následující etapu a získává pro ni schválení. Ukončení projektu sleduje naplnění cílů projektu, ověřuje spokojenost zákazníka s produkty, potvrzuje opatření na údržbu a podporu produktu, zaznamenává všechna ponaučení z projektu a doporučení pro další práci.
Další informace jsou dostupné z [2].
Při porovnání obou standardů je evidentní, že PMBOK je soubor doporučení a osvědčených postupů, jak řídit projekty, který nemá normativní charakter. Je pro něj charakteristická komplexnost, kdy popisuje řadu nástrojů a technik, které mohou poskytnout projektovému manažerovi obecný návod při řízení projektů, obsahuje také oblasti zaměřené na měkké dovednosti. V praxi je možné řídit se pouze částí standardu. PRINCE2 je standard zaměřený na produkt projektu. Poskytuje ucelený, jasně definovaný a předepsaný seznam vzájemně provázaných principů, procesů a témat, přitom nepopisuje konkrétní nástroje a techniky pro jednotlivé činnosti. Při jeho adaptaci na podmínky konkrétního projektu při zachování principů standardu je možné projekt ihned vést. V oblasti kompetencí není cílený na osobu projektového manažera, ale na všechny role projektového týmu. Klade důraz na projektovou dokumentaci.
28
5 Kombinace standardu a metodik Odvětví vývoje softwaru patří k dynamicky se vyvíjejícím se oblastem a tomu se také přizpůsobuje vývoj používaných metodik. Původně široce používané tradiční metodiky jsou nahrazované nebo se kombinují s některými prvky metodik agilních. Na druhé straně je možné v určitých situacích agilní metodiky více formalizovat; je tomu tak například u velkých významných projektů. Přínosná může být také kombinace metodik se standardy, protože umožní začlenit principy softwarového inženýrství do postupů používaných při řízení projektů. Toto je oblast, která je v současné době intenzivně diskutovaná. Řada firem s americkým kapitálem používá standard PMBOK, který je součástí jejich směrnic; naproti tomu PRINCE2 je rozšířený především v Evropě. Pokud firmy mají zájem inovovat přijaté postupy a zavést moderní prvky, které by přinesly lepší spolupráci se zákazníkem a větší flexibilitu při vývoji a dodání softwaru, mají možnost zkombinovat stávající standard s některou z metodik vývoje softwaru. Podobně firmy s některou zavedenou metodikou mohou tuto metodiku rozšířit o principy standardu. Kombinovat lze na základě mapování procesů, tedy disciplíny, která poskytuje nástroje k identifikaci používaných procesů a návod k zlepšování a optimalizaci těchto procesů. Mapování je subjektivní záležitostí, proto se jeho výsledek může lišit z pohledu dvou jedinců. V následující části autor uvádí možné propojení standardů projektového řízení PMBOK a PRINCE2 s metodikami budování ICT tak, jak je on sám považuje za vhodné kombinovat.
5.1 Kombinace PMBOK a Scrum V úvodní části PMBOK je uvedeno „this standard is a guide rather than a specific methodology. One can use different methodologies and tools to implement the project management framework“ [1]. Těmito větami standard připouští možnost jeho použití v kombinaci s některou z metodik. Toho využívá autor v této části práce a jeho snahou je aplikovat jedinečné aktivity Scrumu na strukturu PMBOK. Kombinace je výhodná, protože umožní lépe se orientovat ve strukturách obou a přináší možnost dohledat odpovídající postupy v PMBOK k jednotlivým aktivitám Scrumu. Tak je možné doplnit rámec Scrumu např. o Ganttův diagram, o registr rizik nebo o nástroje a techniky pro odhad nákladů nebo pro kontrolu kvality. Po provedení mapování aktivit Scrumu, které byly zařazeny do procesních skupin a znalostních oblastí PMBOK, vypadá kombinovaná struktura následovně: 29
Procesní skupiny Zahájení
Vymezení rolí Definování cílů Autorizace projektu
Plánování
Vytvoření Product backlogu Vytvoření Sprint backlogu Naplánování a definování cílů a činností ve fázi projektu (Sprintu) Naplánování práce pro jednotlivé členy týmu během Denní schůzky
Realizace
Plnění stanovených úkolů v rámci Sprintu Vytvoření přírůstku na konci každého Sprintu
Monitorování a kontrola
Vytvořit a aktualizovat Burndown chart Přezkoumání přírůstku během Vyhodnocení sprintu Kontrola práce za posledních 24 hodin na Denní schůzce
Uzavření
Revidování práce týmu včetně návrhů na zlepšení na Retrospektivě sprintu Tabulka 4: Mapování Scrum aktivit na procesní skupiny PMBOK (Autor)
Znalostní oblasti Integrované řízení projektu Na počátku projektu sestaví celý tým vizi projektu, která definuje cíle a záměry projektu včetně seznamu požadavků. Plánování probíhá na úrovni Sprintů, kdy jsou Sprinty pro nejbližší období naplánované detailněji než Sprinty vzdálenější. Veškeré aktivity tým řeší jako celek, event. za přítomnosti dalších zainteresovaných stran, na pravidelných schůzkách. Základem činnosti týmu je jeho sebeorganizující schopnost, která přispívá k udržení výkonosti týmu a jeho harmonické práci a přitom nechává zodpovědnost na jednotlivých členech. Hnacím motorem, který týmu pomáhá zlepšovat procesy, reagovat na změny a poučit se ze zkušeností, jsou výstupy z týmových schůzek. Při změně požadavků ze strany zákazníka se provádí změny, které se promítají do backlogu. O změnách v procesech tým jedná a rozhoduje na Retrospektivě sprintu. Zakončením projektu je předání produktu zákazníkovi a administrativní uzavření projektu.
30
Řízení rozsahu projektu Změny v backlogu umožňují pružně reagovat na skutečné potřeby zákazníka a rozsah projektu není fixován tak, jak je tomu u plánem řízeného přístupu. Nevyžaduje vznik plánu pro realizaci projektu, meze a cíle projektu jsou vymezeny v přijaté vizi a Vlastník produktu je transformuje do položek backlogu, které jsou dále upravované pro potřeby týmu. Aktualizace backlogu probíhá průběžně podle požadavků týmu a stran zainteresovaných na projektu. Aktivní řízení backlogu umožňuje provádět kontrolu rozsahu projektu Řízení času projektu Je nutné definovat aktivity, které jsou vyžadovány pro splnění jednoho Sprintu o fixní délce. Aktualizaci činností provádí tým na Plánovací schůzce. Tým na základě zkušeností odhaduje, jaký soubor funkcí bude schopný dodat, v jakém čase a jakým způsobem vytvoří plánovaný přírůstek. Veškerá ujednání jsou dokumentována ve Sprint backlogu. Kontrola plnění úkolů probíhá v rámci Vyhodnocení sprintu a Retrospektivy sprintu. K monitorování postupu prací na projektu se využívá graf zpracovaných požadavků Burndown chart. Řízení nákladů projektu Odhad nákladů se vypočítá podle množství celkové práce obsažené ve všech Sprintech a podle jejího rozdělení a probíhá v různých fázích projektu. Vychází z empirických zkušeností, z abstraktních měřítek jako jsou story pointy nebo z funkcionality produktu. Podílí se na něm tým spolu se zákazníkem a na konci Sprintů se odhad upřesňuje a aktualizuje také s ohledem na přijaté změny. Při kontrole nákladů může pomoci také Burndown chart. Řízení kvality projektu Na řízení kontroly kvality se podílí všichni členové Scrum týmu, protože se jedná o multifunkční skupinu. Sledování kvality je součástí každého Sprintu, posuzuje se podle splnění stanovených kritérií přírůstku produktu (stav hotovo). Provází celý projekt, především formou automatizovaných a předem připravených testů. Zodpovědnost za kvalitně provedenou práci nese celý tým, ke kontrole kvality mohou být přizváni také externí auditoři. Průběžnou kontrolu týmu poskytují schůzky Vyhodnocení a Retrospektiva sprintu i Burndown chart.
31
Řízení lidských zdrojů projektu Tým se vytváří cíleně tak, aby jeho členové disponovali všemi potřebnými kompetencemi a nebyli závislí na externistech (multifunkční charakter týmu) a aby sami rozhodovali o provedení práce a byli soběstační (sebeorganizující tým). To jim umožňuje role Scrum mastera, který tým motivuje a pomáhá mu dosáhnout cílů. Zájmy zákazníka reprezentuje role Vlastníka produktu. Optimálně veliký tým by měl mít pět až devět členů. Řízení komunikace projektu Vychází z přímé a osobní komunikace členů týmu. Diskuze a distribuce informací jsou zaměřené na plánování a předávání informací a probíhají na neformálních a pravidelných schůzkách, bez nadměrné administrativní zátěže. Řízení rizik projektu Do identifikování, analýzy a reakcí na rizika je zapojený celý tým. Ošetření rizik, řešení neočekávaných problémů a přezkoumání rizik tak, jak se objevují v různých fázích iterace, probíhá neformálně na pravidelných schůzkách, které jsou součástí každého Sprintu. Řízení dodávek projektu Scrum danou oblast nezmiňuje a proto je vhodné použít postupy dle PMBOK. Řízení zainteresovaných stran v projektu Role účastníků projektu jsou stanoveny na jeho počátku. Požadavky zainteresovaných stran jsou řešeny v rámci pravidelných schůzek ve Scrumu a pro jejich plnění je vytvořena vhodná strategie. Jsou zakomponované a průběžně aktualizované v Produkt backlogu, jehož položky musí být srozumitelné a dostupné všem stranám.
5.2 Kombinace PRINCE2 a Scrum Podobně jako standard PMBOK, také PRINCE2 připouští kombinaci s metodikou budování ICT projektů. PRINCE2 ve svém manuálu Managing Successful Projects with PRINCE2 [2] zmiňuje kompatibilitu s agilními principy a odkazuje na konkrétní příklad, a to na metodiku Dynamic Systems Development Method. Jejich hlavní odlišnost spočívá v tom, že Scrum se zaměřuje na dodání produktu-softwaru, zatímco PRINCE2 na dohled a kontrolu nad projektem. PRINCE2 neinformuje vývojový tým, jak má pracovat a které úkoly vykonat jako první, vývojový tým si sám stanovuje, jak bude postupovat 32
a jak budou Balíky práce zpracovány. Scrum by mohl strukturu standardu vhodně doplnit o způsob, jakým by tým rychle reagoval na požadavky a změny a přitom dodal produkt v termínu. Mapování jednotlivých aktivit metodiky Scrum na jejich ekvivalenty v PRINCE2 není jednoduché. Je tomu tak proto, že se jedná o propojení dvou rozsahem a podrobnostmi zcela odlišných postupů. Komplikací také je, že standard PRINCE2 je nutné použít jako celek a není možné čerpat z jeho jednotlivých oblastí nezávisle na ostatních oblastech na rozdíl od standardu PMBOK, který také nemá tak direktivní charakter. Vhodným způsobem pro kombinování Scrumu s PRINCE2 je nahradit proces Řízení dodání produktu metodikou Scrum, která je na dodávku produktu zaměřena tak, jak je zobrazeno na následujícím obrázku.
Obrázek 10: Kombinace PRINCE2 a Scrum (Autor)
Toto řešení však vyžaduje určité úpravy standardu v bodech průniku s metodikou. K nim patří např. oblasti rolí, schvalování a délky etap, plánování produktu. Následující text informuje o možných úpravách. 33
První oblastí, která vyžaduje změny, je oblast rolí. V PRINCE2 odpovídá za úspěch projektu a nese za něj odpovědnost Projektový výbor (Project Board). Jeho členy jsou Hlavní uživatel (Senior User), Sponzor projektu (Project Executive) a Hlavní dodavatel (Senior Supplier). Zodpovědnosti Vlastníka produktu lze rozdělit mezi Hlavního uživatele, který zastupuje zájmy a požadavky koncových uživatelů a Sponzora projektu, který zajišťuje, aby byl projekt dokončený v rámci dohodnutých tolerancí pro rozpočet a harmonogram a aby byly peníze efektivně vynaložené. U malých projektů lze tyto role sloučit do jedné. Roli Scrum mastera může zastoupit Projektový manažer v PRINCE2 za předpokladu, že svou úlohu přizpůsobí způsobu práce Scrum mastera. Pokud se nedokáže na roli Scrum mastera adaptovat, tak lze zachovat obě role, přitom role Scrum mastera bude v PRINCE2 vnímána jako Podpora projektu (Project Support). Další úpravy při kombinování se týkají přizpůsobení fází projektu a seznamu úkolů. PRINCE2 podobně jako Scrum klade význam na tvorbu produktů a inkrementální přístup (principy Orientace na produkty a Řízení po etapách). Vznik produktu tak začíná jeho definicí a končí až nasazením otestovaného produktu (analogie stavu „hotovo“). Každodenní aktivity jsou řízeny po etapách, které představují milníky pro přijímání dalších rozhodnutí a poskytují kontrolu nad projektem a zdroji. Snahou je, aby délka etapy odpovídala délce Sprintu. Pokud etapa obsahuje více Sprintů, Projektový výbor musí schválit všechny tyto Sprinty, např. na Plánovací schůzce. Produktově orientované plánování v PRINCE2 vede k sestavení Kontrolního seznamu produktů (Product Checklist), který obsahuje aktuální seznam produktů, které mají být vytvořeny včetně klíčových termínů. Tento seznam lze nahradit Product backlogem. Jednotlivé Balíky práce pak odpovídají položkám backlogu. Úpravou by měla projít také oblast trvalého zlepšování procesů, kdy jedním z principů PRINCE2 je získávat poznatky a zkušenosti z průběhu projektu, dokumentovat je v Přehledu získaných poznatků (Lessons Log) a Zprávě o získaných poznatcích (Lessons Report) a používat je v dalších etapách a projektech. K tomu je možné využít Scrum schůzky Vyhodnocení sprintu, na které se prezentuje hotový přírůstek a okolnosti jeho vytvoření a Retrospektiva sprintu, na níž tým hodnotí odvedenou práci. Po těchto uvedených modifikacích je možné standard PRINCE2 doplnit o metodiku Scrum v části Řízení dodání produktu.
34
5.3 Kombinace PMBOK a RUP V projektovém řízení v RUP jde o nalezení rovnováhy mezi opačnými cíli projektu, zvládnout řízení rizik a překonávat omezení v projektu proto, aby vznikl produkt splňující očekávání zákazníka. Cílem RUP je dle [24] poskytnout rámec pro řízení softwarových projektů, návod pro plánování, realizaci a kontrolu projektů a nástroj pro řízení rizik. Během vývoje byla metodika ovlivněna praktikami Project Management Institute, ale vzhledem k zaměření na vývoj softwaru je v některých oblastech nepřijala. Prvky projektového řízení obsahuje více disciplín metodiky RUP, avšak zásadní význam při řízení projektů má disciplína Projektový management. Do této disciplíny je možné převzít některá doporučení PMBOK. Best practices PMBOK se tak stanou součástí každé iterace ve všech čtyřech fázích RUP: zahájení, přípravy, konstrukce a zavedení.
Obrázek 11: Kombinace PMBOK a RUP (Autor)
Záměrem autora je mapovat aktivity, které používá metodika, na procesy standardu. Dále porovnat obsah jednotlivých aktivit a procesů a zhodnotit, zda je vhodné přizpůsobit vstupní artefakty vstupům procesu, kroky nástrojům a technikám a výsledné artefakty výstupům procesu. Tímto způsobem by bylo možné obohatit metodiku o osvědčené kroky standardu. Mapování všech aktivit by bylo náročné, protože jich metodika obsahuje více než sto padesát a k tomu dalších osmdesát artefaktů [30], proto jako příklad mapování autor zvolil aktivitu Vytvoření plánu řízení rizik (Develop Risk Management Plan) z disciplíny Projektový management a procesy znalostní oblasti Řízení rizik projektu standardu PMBOK.
35
Aktivita obsahuje jeden vstupní artefakt Seznam rizik (Risk List), dále kroky Definovat postupy a nástroje (Define risk management procedure & tools), Vytvořit počáteční seznam rizik (Create initial risk list), Sestavit tým (Assign risk management team), Stanovit strategii (Decide strategies for managing top 10 risks), Definovat indikátory rizik (Define risk indicators for top 10 risks), Sestavit harmonogram oznamování a přezkoumání rizik (Set schedule for risk reporting and reviews) a výsledný artefakt Plán řízení rizik (Risk Management Plan).
Vstupní artefakt Seznam rizik představuje systematický, průběžně aktualizovaný soupis rizik, ve kterém jsou rizika přehledně řazena podle závažnosti a který uvádí také opatření k jejich zmírnění a ošetření. Dle RUP by měla být rizika uvedena s ohledem na jejich identifikaci, popis, pravděpodobnost vzniku, dopad, varovné signály výskytu, postoje k riziku a plány kontingenčních opatření. Tento artefakt lze mapovat v PMBOK na Registr rizik (Risk register), který je vstupem pro více procesů: Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Control Risks. PMBOK ve vstupu Registr rizik doporučuje provádět popis rizik strukturovaným způsobem, při kterém využívá termíny z managementu rizik, např. ve formulaci DOPAD je výsledkem změny CÍLE v důsledku RIZIKA.
Kroky V úvodním kroku Definovat postupy a nástroje jsou při vytváření plánu řízení rizik stanoveny postupy pro identifikování potenciálních rizik, jejich analyzování a prioritizaci, pro volbu strategií na snížení rizik a k revidování rizik. Tyto postupy však nejsou obsahem mapované aktivity, ale přísluší jiné aktivitě (Identify and Assess Risks) a při mapování by odpovídaly nástrojům a technikám procesu Plan Risk Management. Dalším krokem je Vytvořit počáteční seznam rizik. Pomáhá získat úvodní představy o zdrojích rizik a je výsledným artefaktem aktivity Identify and Assess Risks. Při mapování by odpovídal nástrojům a technikám procesů Identify Risks, Perform Qualitative Risk Analysis a Perform Quantitative Risk Analysis. V kroku Sestavit tým se rozhoduje, kteří členové projektového týmu budou odpovědní za rizika projektu. Zastoupeny by měly být jak manažerské, tak technické funkce. RUP považuje za osvědčené jmenovat jednu osobu, která garantuje správný postup pří řízení rizik, manažerem rizika. 36
V dané oblasti PMBOK nevyžaduje vytvoření zvláštního týmu pro řízení rizik, nabízí nástroje a techniky ze znalostní oblasti Project Human Resource Management, např. Matici RACI z procesu Plan Human Human Resource Management. Tato matice rozlišuje čtyři odpovědnosti označené písmeny: R – zodpovědný za provedení úkolu, A – zodpovědný za výsledek, C – konzultující, I – informovaný a ukazuje, jakým způsobem se tyto odpovědnosti jednotlivých účastníků mění v různých fázích procesu managementu rizik.
Manažer projektu
Manažer rizika
Vlastník rizika
Členové projektového týmu
Identifikace rizik
R
A
I
R
Analýza rizik
R
A
R/I
R
Ošetření rizik
A
C
R
C
Řízení rizik
A
R
R
R
R
A
C
C
Vyhodnocení rizik
Tabulka 5: Matice Raci (Autor dle [1])
Postupy, jak udržet riziko pod kontrolou a jakým způsobem řešit rizikové situace, jsou náplní kroku Stanovit strategii. K nástrojům pro snižování rizika patří obejití, přesunutí, snížení, přijetí rizika. Tyto strategie, které umožní vyhnout se, přesunout, snížit nebo přijmout riziko jsou blíže popsány v aktivitě Identify and Assess Risks, která by mohla být mapována na nástroje a techniky procesu Plan Risk Responses v PMBOK. V kroku Definovat indikátory rizik se stanoví pro každé riziko měřitelná podmínka, která informuje o rizikovosti situace. Kritérii používanými pro měření rizika obvykle bývají finanční ukazatelé kvantitativní povahy. Používají se pravděpodobnosti překročení, rozptyl, směrodatná odchylka těchto kritérií nebo se riziko slovně vyjádří. PMBOK oblast definování kritérií rizika nerozvádí. Krok Sestavit harmonogram oznamování a přezkoumání rizik pojednává o řízení rizik, které je nejúčinnější, pokud je prováděno kontinuálně. Plán řízení rizik by měl stanovit harmonogram kontrol a schůzek zaměřených na monitorování rizik, přitom by jejich frekvence měla vycházet z praktických potřeb a zkušeností týmu. Nástroje a techniky procesu Control Risks v PMBOK, který je paralelní tomuto kroku, poskytují stejné informace k tématu monitorování rizik, navíc nabízejí techniky měření výsledků, např. analýzu odchylek a trendů, měření technické výkonnosti, analýzu rezerv. 37
Výsledný artefakt Plán řízení rizik dokumentuje postupy pro identifikaci, analýzu, zabezpečování, monitorování a kontrolu rizik. Dle RUP obsahuje kromě úvodní části stručný popis projektu a souvisejících rizik, způsoby jejich identifikace, hodnocení a analýzy, strategie pro nejzávažnější rizika. Dále identifikuje vlastníky rizika, rozpočet pro řízení rizik a odkazuje na Seznam rizik. Pro menší projekty není třeba Plán řízení rizik vytvářet, může být součástí Plánu vývoje softwaru. Artefakt lze v PMBOK mapovat na Plán řízení rizik (Risk management plan), který je výstupem procesu Plan Risk Management. Z položek, které by měly být dle PMBOK součástí plánu řízení rizik, lze do RUP doplnit dvě:
Matice hodnocení rizik je expertním posouzením rizika, která využívá hledisko pravděpodobnosti výskytu a intenzity negativního dopadu rizika. Kombinace těchto hledisek umožní členit rizika do skupin dle jejich významnosti.
Hierarchická struktura rizik je podrobný rozpis rizik, ve kterém jsou rizika tříděna podle oblastí, ke kterým se vztahují. Umožní snáze identifikovat vztahy a závislosti mezi riziky, přiřadit rizika vlastníkům a kategorizovat je.
5.4 Kombinace PRINCE2 a RUP Poslední kombinací standardu projektového řízení a metodiky budování ICT je integrace PRINCE2 a RUP. Tato kombinace umožňuje řídit a dozorovat projekt pomocí standardu a iterativní vývoj a dodání softwaru pomocí RUP. Přínosem je snadná implementace, flexibilita takového řešení a spojení výhod obou přístupů. Přitom se udrží odděleně technické prvky specializované oblasti vývoje softwaru od obecných požadavků na řízení projektu. Metodika RUP nahradí proces Řízení dodání produktu; přitom zůstane zachováno řízení projektu dle standardu PRINCE2, pouze tým dodávající software bude využívat jako metodiku RUP. Fázím RUP přibližně odpovídají etapy PRINCE2 v rozsahu iniciace–realizace produktu, jak je vidět na následujícím obrázku.
38
Obrázek 12: Kombinace PRINCE2 a RUP (Autor)
Rozdělení rolí odpovídá struktuře integrovaného řešení a zachovává jak funkci projektového manažera PRINCE2, který je pověřený řízením celého projektu a plněním jeho cílů, tak funkci projektového manažera metodiky RUP, který zodpovídá za činnost týmu vyvíjejícího software a podle standardu PRINCE2 plní roli Týmový manažer. Příslušné instrukce pro vznik produktu předává projektový manažer manažerovi týmu formou Balíků práce. Manažeři se dohodnou na práci, která se má vykonat, na požadavcích na kvalitu, způsobu informování, postupech apod. Pro danou úlohu bude dle RUP vypracován Plán vývoje softwaru (Software Development Plan), který bude tvořit základ Plánu týmu. Realizace Balíků práce probíhá dle metodiky RUP, kdy Týmový manažer kontroluje postup probíhajících prací, množství zbývající práce, monitoruje rizika, kvalitu a informuje Projektového manažera o průběhu realizace až do odevzdání hotového produktu. RUP definuje velké množství rolí, ale ne všechny mají odpovídající protějšek v PRINCE2. Kromě již uvedené role projektového manažera lze mapovat například RUP roli Change Control Manager na roli Change Authority v PRINCE2, roli Project Reviewer na roli Project Assurance nebo roli Configuration Manager na Project Support. Ostatní role a jejich odpovědnosti, jako např. Software Architect, Tester, Code Reviewer, zůstávají specializované pod RUP. Autoritou odpovědnou za celkový úspěch projektu je i nadále Projektový výbor.
39
V průběhu projektu vzniká řada dokumentů k předávání informací, které RUP označuje jako artefakty a PRINCE2 jako produkty. Produkty PRINCE2 se vztahují k celému projektu a jeho etapám, artefakty RUP vznikají na úrovni vývojového týmu. Protože RUP disciplína Projektový management má podobné zaměření jako standard PRINCE2, dokumenty obou se svým obsahem shodují. Aby se při kombinování standardu s metodikou zabránilo vytvoření duplicitních dokumentů, je vhodné nahradit artefakty této disciplíny jejich ekvivalentem v PRINCE2. Mapování odpovídajících dokumentů je uvedené v následující tabulce
RUP Disciplína PM
PRINCE2
Software Development Plan
Plan (Team Plan)
Business Case Status Assessment Problem Resolution Plan Risk Management Plan Risk List Work Order
Business Case Checkpoint Report Plan Risk Management Strategy Risk Register Work Package
Product Acceptance Plan Quality Assurance Plan Issues List Measurement Plan Iteration Plan Iteration Assessment
Project Product Description Quality Management Strategy Issue Register Plan (Team Plan) Plan (Stage Plan) Checkpoint Report / Lessons Log
Review Record
Quality Register Tabulka 6: Mapování dokumentů PRINCE2 a RUP (Autor)
Mapovat by bylo možné i jiné dokumenty. Protože jsou však specifické pro vývoj softwaru a v PRINCE2 pro ně není odpovídající produkt, je vhodné je ponechat v rámci RUP.
40
6 Pilotní projekt Cílem kapitoly je představit kombinaci standardu a metodiky na reálném projektu, který řeší partnerská organizace. Projektem je Webový portál historických fondů zámeckých knihoven s důrazem na tisky 16. století, který má zpřístupnit digitální kulturní obsah široké veřejnosti a který jako veřejnou zakázku malého rozsahu na služby zadal Národní památkový ústav. Portál je součástí projektu, jehož cílem je provést výzkum historických sbírek knihoven a výsledky využít pro uchovávání, prezentaci a edukaci v dané oblasti. Projekt byl v době psaní diplomové práce ve svých počátcích. Pro řešení projektu autor zvolil kombinaci standardu PRINCE2 a metodiky Scrum proto, že se jedná o dva nejrozšířenější přístupy používané při řízení projektů v Evropě: PRINCE2 umožňuje rychlou a jednoduchou implementaci, je prakticky zaměřený a přitom se jedná o standard doporučený pro ICT projekty ve veřejném sektoru. Scrum je vysoce úspěšná metodika vhodná i pro projekty menšího rozsahu, která umožňuje rychle reagovat na změny v prioritách projektu a zajišťuje včasné dodání produktu. Životní cyklus projektu se odehrává ve čtyřech fázích: předprojektové, iniciační, realizační a ukončení.
Obrázek 13: Životní cyklus projektu (Autor)
41
6.1 Předprojektová fáze Fáze je tvořena procesem Zahájení projektu, který by měl definovat cíle projektu, navrhnout a jmenovat tým a připravit popisy práce, stanovit, jaká práce má být realizovaná a jaké techniky k tomu mají být použity, rozhodnout o použitém přístupu. Podnětem pro vznik projektu byl Mandát projektu, kterým byla veřejná zakázka. Na jeho základě Projektový manažer zorganizoval pracovní schůzku, jejímž cílem bylo vytvořit Chartu projektu, která byla předložena ke schválení Projektovému výboru a stala se základem, na kterém bylo možné projekt začít stavět. Na základě informací, které byly uvedeny v mandátu projektu, vytvořil Sponzor projektu ve spolupráci s Projektovým manažerem Obchodní případ. Jeho účelem bylo dokumentovat důvody, proč má být projekt realizován. V této fázi také byla navržena organizační struktura projektu tak, aby vyhovovala potřebám projektu a vyčlenila pro projekt příslušné lidské zdroje. Životaschopnost projektu bude po celou dobu trvání projektu sledována projektovým výborem a srovnávána s obchodním případem.
Charta projektu Cílem projektu byla tvorba webového portálu, který by byl novým nástrojem pro zpřístupnění výsledků analýzy tisků 16. století ve fondech zámeckých knihoven. Portál je určený k užívání pro odbornou i laickou veřejnost, které umožní přístup k bibliografickým datům o titulech jednotlivých fondů knihoven ve správě zadavatele i v jiných externích zdrojích s vlastními databázemi. Rozsah takto integrovaných dat, která budou zpřístupněná prostřednictvím portálu, předpokládá dostupný bibliografický popis dokumentů včetně odkazů na vlastníka záznamu, odkazu na plný text a bude se lišit pro registrované nebo anonymní uživatele portálu. Realizace zahrnuje vytvoření portálu a jeho provoz po dobu pěti let. Existence portálu vyžaduje vytvoření nástrojů pro shromažďování dat, datového úložiště, webové prezentace, nástrojů pro správu uživatelských kont. Bude dodán webový portál jako zcela nový projekt, při jeho vzniku nebudou osloveni externí dodavatelé.
Obchodní případ Důvodem pro realizaci projektu byla snaha, aby zájemci o historickou literaturu měli přístup k informacím o fondech zámeckých knihoven z jednoho místa. Tím by byla uživatelům snadno dostupná bibliografická data o titulech nejen knihovních, ale také katalogových a ze specializovaných databází a informačních zdrojů v takovém rozsahu, 42
o který projeví uživatelé zájem. Portál by byl přínosem pro zájemce o historickou literaturu, protože jim nabídne uživatelsky komfortní způsob vyhledávání v katalozích různých institucí a pomůže jim čerpat potřebné informace z různých elektronických zdrojů; portál bude vstupní branou do fondů historických knihoven. Projekt byl zahájen 1. 10. 2014 a předpokládané datum jeho ukončení je 20. 7. 2015, portál má být provozovaný ještě pět let po skončení projektu. Náklady na projekt byly odhadnuty ve výši 1 350 000 Kč, přičemž nejvyšší nákladovou položku tvoří mzdové náklady.
Organizace
Obrázek 14: Organizační struktura (Autor)
Za úspěch projektu odpovídá Projektový výbor, který zajišťuje nastavení projektu tak, aby splňoval požadavky zákazníka. Členy Projektového výboru jsou Vlastník produktu a Sponzor projektu, přitom na roli Vlastníka produktu jsou delegované povinnosti Hlavního uživatele. Jménem Projektového výboru má pravomoc řídit projekt Projektový manažer, který současně zastává pozici Scrum mastera. Vývojový tým je sedmičlenný. S ohledem na menší rozsah projektu a zajištění jeho realizace vlastními silami a zdroji bylo možné sloučit osoby Hlavního dodavatele a Sponzora projektu. Také role Scrum mastera a Projektového manažera je společná, vykonává ji osoba s certifikacemi PRINCE2 Practitioner a Certified ScrumMaster, která se plně věnuje pouze tomuto projektu. Odpovědnosti osob zůstávají nezměněné v dikci standardu a metodiky. 43
Přehled získaných poznatků V této fázi byl Projektovým manažerem založený Přehled získaných poznatků, který dokumentuje důležité informace využitelné v projektu a který je průběžně aktualizován a doplňován o zásadní informace získané během Vyhodnocení sprintu a Retrospektivy sprintu. Po ukončení projektu se důležitá sdělení zdokumentují pro možné další využití ve Zprávě o získaných poznatcích.
6.2 Iniciační fáze Do této fáze vstupují dva procesy, proces Nastavení projektu a proces Řízení přechodu mezi etapami. První proces je základem projektového řízení, když nastavuje parametry projektu a definuje co, v jaké kvalitě a v jakém čase bude prováděno. Druhý proces pojednává o přechodu z jedné etapy projektu do etapy následující, informuje o výsledcích aktuální etapy a plánuje další etapu.
6.2.1 Nastavení projektu Řízení kvality Pro posouzení kvality projektu byla vytvořena počáteční definice stavu „hotovo“, tedy informace o tom, co je potřeba uskutečnit, aby bylo možné konstatovat, že byl úkol splněný. K tomuto bylo možné použít hodnocení, že byl kompletní a zrevidovaný kód, prošly jednotkové, integrační a akceptační testy, Vlastník produktu vyjádřil svou spokojenost s přírůstkem, byla vytvořena relevantní dokumentace. Pro hodnocení kvality provozu portálu byla použita kritéria požadovaná zákazníkem: zabezpečení nepřetržité dostupnosti a funkčnosti portálu minimálně 96 % běžného času v roce a plnění časového harmonogramu pro řešení chyb v provozu portálu. Podle závažnosti dopadu těchto chyb na užívání portálu lze vady členit do tří kategorií, například u doby požadované na dočasnou nápravu zprovoznění portálu se jedná o obnovení jeho funkčnosti do 8 hodin / 2 pracovních dní / 5 pracovních dní. V průběhu realizace je možné zvolená kritéria rozšířit. Případné problémy související s kvalitou budou zaznamenány do Registru otevřených bodů, jehož přílohou budou také výsledky provedených testů.
44
Registr rizik Registr rizik definuje rizika, kvalitativně posuzuje jejich závažnost a stanovuje opatření k jejich řešení. K rizikům analyzovaným na počátku projektu patří:
Vysoce závažné riziko, že odstranění vad, které by ovlivnily funkčnost nebo možnost použití portálu, nebude provedeno ve sjednané době. Tomu lze předejít zajištěním dostatečné servisní kapacity pro rychlý zásah.
Riziko výpadku poskytovaných služeb střední závažnosti, k jehož zmírnění je možné použít monitorovací dohledový systém, který umožní problém okamžitě zaregistrovat, lokalizovat a řešit.
Nedodržení harmonogramu vývoje lze ohodnotit jako středně závažné riziko, které by měla pomoci snížit použitá agilní metodika vývoje Scrum díky začlenění pravidelných schůzek týmu.
Riziko odchodu člena týmu a neshod v týmu ohrožuje jako riziko s nízkou závažností celou realizaci projektu. Měly by mu předcházet aktivity role Scrum mastera, který má napomáhat týmu k jeho motivaci a řešení problémů.
Řízení komunikace Komunikace probíhá na pravidelných schůzkách, které metodika Scrum definuje a na kterých se řeší plánování práce, hodnotí se její postup, představují se výsledky a retrospektivně se hodnotí průběh.
Úvodní plán projektu Začátek
Konec
Zahájení projektu
1. 10. 2014
3. 10. 2014
Nastavení projektu (včetně analýzy projektu – rozpadu na user stories, prioritizace a estimatice)
6. 10. 2014
17. 10. 2014
Sprint 0 (architektura a návrh řešení)
20. 10. 2014
24. 10. 2014
Sprint 1
27. 10. 2014
21. 11. 2014
Sprint 2
24. 11. 2014
19. 12. 2014
Sprint 3
5. 1. 2015
30. 1. 2015
Sprint 4 (buffer)
2. 2. 2015
13. 2. 2015
45
Agregace, finální otestování, školení
16. 2. 2015
27. 2. 2015
Pilotní provoz a úpravy konfigurací
2. 3. 2015
20. 7. 2015
Tabulka 7: Harmonogram projektu (Autor)
Backlog Požadavky na řešení portálu byly Vlastníkem produktu sumarizované ve formě user stories a byly seřazené podle priority v počátečním Product backlogu. Následně tým u jednotlivých položek zhodnotil časovou náročnost na realizaci. Požadavky jsou obsahem následující tabulky. Id
Popis
Odhad
1
Jako uživatel chci vyhledávat v interních zdrojích Národního památkového ústavu
13
2
Jako uživatel chci vyhledávat v externích zdrojích Národní knihovny ČR
13
3
Jako uživatel chci vyhledávat v externích zdrojích Památníku národního písemnictví
5
4
Jako uživatel chci vyhledávat v externích zdrojích České akademie věd
5
5
Jako uživatel chci vyhledávat v externích zdrojích Knihovny národního muzea
5
6
Jako uživatel chci vyhledávat v externích zdrojích Karlsruhe Virtual Catalog
13
7
Jako uživatel chci vyhledávat v externích zdrojích Moravského zemského muzea
5
8
Jako uživatel chci vyhledávat v externích zdrojích Slezského zemského muzea
5
9
Jako uživatel chci vyhledávat v externích zdrojích Manuscriptoria
5
10
Jako uživatel chci vyhledávat v externích zdrojích Europeany
5
11
Jako uživatel chci vyhledávat pomocí všech nebo vybraných kritérií
40
12
Jako uživatel chci vyhledávat pomocí speciálních znaků včetně použití booleovských operátorů
13
13
Jako uživatel chci řadit výsledky vyhledávání dle relevance, abecedy a roku
5
14
Jako uživatel chci, aby údaje z různých zdrojů byly jednotně zobrazeny
8
15
Jako uživatel chci, aby bylo možné záznam uložit, tisknout nebo exportovat
5
16
Jako administrátor chci zaregistrovat uživatele, spravovat a vymazat jeho účet
20
17
Jako administrátor chci měnit nabídku vyhledávacích kritérií a rozsah zobrazených údajů bez nutnosti zasahovat do zdrojového kódu
20
46
18
Jako uživatel chci zvolit rozhraní v češtině, angličtině nebo němčině
20
19
Jako registrovaný uživatel chci mít přístup do digitálního uložiště NPÚ
13
20
Jako uživatel chci mít možnost posunu po dokumentu, zvětšení a zmenšení
0
21
Jako uživatel chci přehlednou strukturu formulářů a portálu, včetně mapy stránek s výstižnými popisky odkazů
13
22
Jako registrovaný uživatel chci vytvořit a uložit seznam dokumentů včetně poznámek
20
23
Jako administrátor chci mít možnost zapojit další externí zdroje pro vyhledávání
13
24
Jako uživatel chci využít možnosti se zaregistrovat
13
25
Jako uživatel chci, aby byl přístupný odkaz na původní zdroj dat
5
26
Jako uživatel chci mít k dispozici textovou alternativu ke všem prvkům netextovým a multimediálním
20
27
Jako uživatel chci moderní, barevně kontrastní grafické řešení s možností měnit velikost písma
13
28
Jako administrátor chci zobrazit výpis uživatelů
8
29
Jako administrátor chci měnit nápovědu zobrazovanou uživatelům
8
30
Jako registrovaný uživatel chci zobrazit historii hledání
13
Tabulka 8: Product backlog (Autor)
6.2.2 Řízení přechodu mezi etapami Úvodní Sprint byl zahájen ihned po zpracování Dokumentace o nastavení projektu, kterou schválil Projektový výbor. Po ukončení každého Sprintu podléhá přechod do další etapy schválení Projektovým výborem, k tomu dochází na Plánovací schůzce. Pokud je třeba, aktualizuje se Registr rizik, Obchodní případ a provádí se změny ve složení projektového týmu. Hodnocení aktuální etapy se odehrává na Vyhodnocení sprintu, kde je na základě připomínek zákazníka upravován backlog. Před plánováním prvního Sprintu proběhla nultá iterace. V ní byl projednán návrh a architektura aplikace. Volba technologií připadla na jazyky Java EE, HTML, CSS a JavaScript, aplikační server GlassFish, databázové řešení MySQL, framework pro objektově relační mapování Hibernate a další rozšíření, se kterými má již tým zkušenosti z vývoje předchozích portálových řešení. Komunikace mezi nezávislými knihovnami a vyhledávání v jednotlivých knihovních fondech probíhá pomocí protokolů Z39.50, OAI-PMH nebo referencí na cílový zdroj, jak znázorňuje následující obrázek.
47
Obrázek 15: Návrh architektury aplikace (Autor)
Plánování prvního Sprintu trvalo přibližně šest hodin. Vlastník produktu při něm týmu představil nejdůležitější položky backlogu, které byly dále rozpracovány a ohodnoceny pomocí metody plánovací poker. Cílem prvního Sprintu bylo vytvořit prvotní podobu portálu, který by umožnil vyhledávat v lokálních zdrojích.
6.3 Realizační fáze Fázi vytvářejí tři části: Dodání produktu, proces Kontrola etapy a proces Směrování projektu. Iterativní vývoj dle metodiky Scrum probíhá ve třech Sprintech, jejichž výsledkem by měl být hotový portál. Kontrola etapy obsahuje činnosti, které je nutné vykonat proto, aby realizace etapy proběhla úspěšně, a přitom zajišťuje pravidelnou kontrolu nad postupem prací. Směrování projektu probíhá po celou dobu trvání projektu, Projektový výbor schvaluje spuštění projektu a jeho nastavení, schvaluje přechody do dalších etap a ujišťuje se o životaschopnosti projektu.
48
6.3.1 Dodání produktu Sprint 1 – OAI-PMH Cílem prvního Sprintu bylo vytvořit prvotní podobu portálu, který by umožnil vyhledávat v lokálních zdrojích. Sprint 1 se skládal z následujících user stories: Jako uživatel chci vyhledávat v interních zdrojích Národního památkového ústavu. Jako uživatel chci vyhledávat pomocí všech nebo vybraných kritérií. Jako uživatel chci vyhledávat pomocí speciálních znaků včetně použití booleovských operátorů. Jako uživatel chci řadit výsledky vyhledávání dle relevance, abecedy a roku. Jako uživatel chci, aby údaje z různých zdrojů byly jednotně zobrazeny. Jako uživatel chci přehlednou strukturu formulářů a portálu, včetně mapy stránek s výstižnými popisky odkazů. Jako uživatel chci využít možnosti se zaregistrovat. Protože OAI-PMH neumožňuje vyhledávání, ale pouze sběr metadat, bylo navrženo schéma relační databáze. V ní se shromažďují metadata stažená harvesterem z interního repozitáře a nad ní probíhá vlastní vyhledávání. Harvester periodicky kontroluje stav zdrojů a lokální databázi doplňuje a aktualizuje. Harvester komunikuje s repozitářem pomocí protokolu HTTP. Požadavek se zasílá na URL serveru a obsahuje upřesňující parametry, serverem vrácené informace jsou ve formátu XML (záznamy MARC ve formátu XML). Na základě dotazu uživatele ve vytvořeném formuláři pro vyhledávání jsou sestaveny požadavky na získání dat z datové vrstvy. Vyhodnocené výsledky hledání jsou následně prezentovány uživateli skrze šablony pro výpis výsledků.
Sprint 2 – Z39.50 Cílem druhého Sprintu bude rozšířit portál o vyhledávání v knihovních systémech, se kterými bude komunikovat pomocí protokolu Z39.50. Podle rychlosti práce vývojového týmu ve Sprintu 1 by se druhý Sprint měl skládat z následujících user stories: 49
Jako uživatel chci vyhledávat v externích zdrojích Národní knihovny ČR. Jako uživatel chci vyhledávat v externích zdrojích Památníku národního písemnictví. Jako uživatel chci vyhledávat v externích zdrojích České akademie věd. Jako uživatel chci vyhledávat v externích zdrojích Knihovny národního muzea. Jako uživatel chci vyhledávat v externích zdrojích Moravského zemského muzea. Jako uživatel chci vyhledávat v externích zdrojích Slezského zemského muzea. Jako administrátor chci zaregistrovat uživatele, spravovat a vymazat jeho účet. Jako administrátor chci měnit nabídku vyhledávacích kritérií a rozsah zobrazených údajů bez nutnosti zasahovat do zdrojového kódu. Jako registrovaný uživatel chci mít přístup do digitálního uložiště NPÚ. Jako uživatel chci mít k dispozici textovou alternativu ke všem prvkům netextovým a multimediálním. Jako administrátor chci měnit nápovědu zobrazovanou uživatelům.
Sprint 3 – odkazy Cílem třetího Sprintu bude propojit portál s dalšími externími zdroji formou odkazů. V případě, že by se ve Sprintu 3 nepodařilo doručit zbývající user stories, dle dohody se zákazníkem by se zvolil další postup. Ten by umožňoval přesunout rozpracované úkoly do Sprintu 4, který by plnil funkci časové rezervy pro dokončení prací, nebo by chybějící funkcionalita nebyla dodána. Jiným řešením by bylo rozšířit vývojový tým o nové členy s vědomím, že může dojít k dalšímu zdržení projektu (tzv. Brooksův zákon).
6.3.2 Kontrola etapy V průběhu celého projektu projektový manažer průběžně monitoruje vykonávání práce a o aktuálním stavu informuje Projektový výbor. Sleduje dodržování časového harmonogramu prací, náklady, kvalitu práce dle kritérií definovaných pro stav „hotovo“, rizika. Při nedodání některých položek zjistí příčinu, zrealizuje příslušná nápravná opatření a záležitost zdokumentuje ve Zprávě o výjimce.
50
Meetingy Projektový manažer každodenně svolává Denní schůzku, na které se upřesňují aktivity, které mají jednotliví členové vykonat v daném dni. Kontroluji se na ní vykonané činnosti a sledují překážky, které by mohly zkomplikovat dosažení stanovených cílů. Jedná se o informativní schůzku, která všem poskytne přehled o průběhu projektu a případných problémech. Na konci prvního Sprintu byl Vlastníkovi produktu v rámci Vyhodnocení sprintu představen výsledek Sprintu. Vlastník produktu byl s výsledky, které mu představil tým, spokojený, protože tým splnil všechny stanovené cíle. Projektový manažer shrnul stav Sprintu ve Zprávě o stavu etapy, kterou předložil Projektovému výboru. Vlastník produktu upozornil na možný problém se záznamy z různých digitálních knihoven. Informace o stejném dokumentu nemusí být uloženy v jednotlivých prohledávaných knihovních fondech zcela identicky, např. když více autorů má shodné jméno, autoři mají vícečlenná jména, autor píše pod více jmény, jedná se o dílo více autorů, nebo když při digitalizaci došlo k chybám, například v důsledku překlepů. Problém by mohl být řešený přidáním podobnostní funkce do vyhledávacího algoritmu a vytvořením přídatné tabulky v databázi, která by obsahovala jména autorů a podle které by se hledaný výraz před vlastním vyhledáváním upravil. Poté následovala schůzka, která retrospektivně zhodnotila průběh Sprintu. Na ní se většina členů týmu shodla na tom, že počáteční práce brzdily činnosti na jiných projektech, že by bylo vhodné některé user stories rozdělit na menší části a také nevyhovovaly termíny denních schůzek. Naopak si tým pochvaloval vzájemnou komunikaci a stávající postup prací.
Metriky Pravidelný update životaschopnosti projektu se provádí pomocí metrik. Před tím, než byl projekt schválený, Vlastník produktu vypočítal návratnost investice (ROI), která je nejčastěji používaným ukazatelem ekonomického hodnocení ICT projektů [31]. 𝑅𝑂𝐼 =
𝑣ý𝑛𝑜𝑠 − 𝑖𝑛𝑣𝑒𝑠𝑡𝑖𝑐𝑒 𝑥 100 [%] 𝑖𝑛𝑣𝑒𝑠𝑡𝑖𝑐𝑒
Projekt by měl dosáhnout zisku ve výši 22 % investice.
51
K monitorování postupu prací týmu, tedy jak rychle se bude celková funkcionalita v backlogu spalovat, se jako metrika používá rychlost. Zjistí se jako součet dokončených user stories za Sprint, přitom v úvodu projektu je nutné počítat s pozvolným náběhem.
Obrázek 16: Velocity Plan projektu (Autor)
Pro zobrazení stavu projektu a predikci jeho dokončení byl zvolený Burndown graf produktu. Zobrazuje aktuální stav projektu po prvním Sprintu. Podává přehled o množství již hotové práce a práce zbývající. Práce zatím postupují podle předpokladu, a pokud by nastala změna, bylo by nutné manipulovat s položkami backlogu.
52
Obrázek 17: Product Burndown (Autor)
Posledním nástrojem, který slouží týmu ke sdílení informací a který pomáhá informovat, kdo na čem pracuje, co je již hotové a co zbývá dokončit, je Scrum tabule. Tabule je rozdělena do tří sloupců: backlog, nesplněné úkoly a hotovo. Jednotliví členové týmu každodenně zaznamenávají do příslušných sloupců aktuální stav úloh.
6.3.3 Směrování projektu Projektový výbor schválil na počátku projektu Chartu projektu, popis produktu projektu, existenci Obchodního případu a Dokumentaci o nastavení projektu. Průběžně reviduje postup při vývoji portálu, připomínkuje a kontroluje dodávané přírůstky a dle potřeby poskytuje poradenskou činnost. Při rizikových situacích na ně Projektový výbor reaguje a také rozhoduje o nutných změnách v projektovém týmu. Informuje zainteresované strany o stavu projektu. Hotovou práci při odevzdání zkontroluje, schválí seznam získaných poznatků, oznámí ukončení projektu a rozpustí projektový tým.
6.4 Fáze ukončení Proces je zaměřený na kontrolu dodání a schválení požadovaného produktu a doporučuje Projektovému výboru ukončit projekt.
53
V jeho průběhu se zaznamená, zda a do jaké míry byly splněny požadavky zákazníka na vytvoření portálu. Celá aplikace se otestuje, provede se kontrola splnění všech požadavků a zhodnocení, zda nezůstávají nevyřešené problémy. Pokud se potvrdí zákazníkova spokojenost, výsledný produkt mu bude po implementaci a konfiguraci řešení formálně předán včetně uživatelské a administrátorské dokumentace a zaškolení. Dokumentují se důležité poznatky z průběhu realizace, které by bylo možné dále využít, uzavřou se registry a projektový tým se rozpustí. Po prvním Sprintu projekt postupuje předpokládaným směrem, a pokud nenastanou nepředvídané události a tým bude pracovat stejným tempem jako doposud, měl by být projekt dokončený v termínu se splněnými požadavky zákazníka i s očekávanými náklady. Portál bude ve zkušebním provozu po dobu šesti měsíců, během kterých bude ověřena funkčnost systému, budou prováděny nezbytné úpravy konfigurací, řešeny dodatečné požadavky zákazníka a odstraňovány vzniklé problémy.
54
7 Návrh metrik Úspěch při dosažení stanovených cílů, procesů, aktivit a tedy efektivnost a výkonnost oblastí řízení ICT projektů je možné hodnotit a měřit. Za nástroje měření se považují míry, metriky a indikátory. Nejvíce používaným nástrojem je metrika, od níž lze odvodit také oba zbývající nástroje. Přitom míra je považována za aplikaci metrik [32] a indikátor, který je často s metrikou zaměňován, porovnává metriky k očekávanému výsledku [33] nebo je chápán jako vizualizace metrik [34]. Metriku můžeme definovat jako kritérium posuzující vybrané charakteristiky softwarového projektu; umožňuje hodnotit vytvořený produkt a proces, který se použil při jeho vývoji [35]. Různí autoři člení velké množství metrik různými způsoby, např. podle objektu měření, opakovatelnosti použití, úrovně řízení, časového intervalu apod. Ke dvěma základním kategoriím patří metriky produktu a metriky procesu. K obvykle měřeným atributům patří velikost, kvalita, dokumentace, složitost produktu a úsilí, kvalita, náklady, doba trvání a efektivita procesu. Pro účely této práce byly za měřené oblasti zvoleny veličiny, které charakterizují každý projekt a které jsou součástí trojimperativu: rozsah, čas a náklady. Pro posouzení, do jaké míry byly splněny původní požadavky projektu, byla měřena kvalita.
Měření rozsahu Normalizovanou metrikou, která definuje rozsah ICT projektu je výpočet funkčních bodů [33]. Princip výpočtu funkčních bodů je poměrně složitý, ale při srovnání s často používanou metrikou výpočtu řádků zdrojového kódu (LOC) je přesnější, umožňuje provést odhad i na začátku projektu a není závislý na programovacím jazyku. Tato metrika definuje v prvním kroku pět funkcí [33]: externí vstupy, externí výstupy, externí dotazy, interní logické soubory a soubory vnějšího rozhraní. Za externí vstupy se považují uživatelská data z externího rozhraní, která mění data v interním souboru aplikace. Externí výstupy jsou souborem dat, která opouští hranice aplikace a poskytuje informace uživatelům nebo jiným aplikacím. K externím dotazům se řadí všechny odpovědní reakce na vstupní data. Interní logické soubory obsahují data a informace uživatelů uspořádané do logicky seřazených skupin. Soubory externího rozhraní představují uživateli identifikovanou skupinu logicky souvisejících dat a informací, která jsou udržována jinou aplikací. Každá funkce je podle složitosti ohodnocena určitým počtem bodů a celkový počet bodů je označený jako Počet neupravených funkčních bodů. V následujícím kroku se tyto 55
body násobí faktorem, který zohledňuje technickou složitost systému a který se vypočte jako součet hodnocení čtrnácti charakteristik. 𝑃𝑜č𝑒𝑡 𝑓𝑢𝑛𝑘č𝑛í𝑐ℎ 𝑏𝑜𝑑ů = [0,65 + (0,01 × 𝑠𝑜𝑢č𝑒𝑡 ℎ𝑜𝑑𝑛𝑜𝑐𝑒𝑛í 𝑐ℎ𝑎𝑟𝑎𝑘𝑡𝑒𝑟𝑖𝑠𝑡𝑖𝑘 𝑠𝑦𝑠𝑡é𝑚𝑢)] × [𝑃𝑜č𝑒𝑡 𝑛𝑒𝑢𝑝𝑟𝑎𝑣𝑒𝑛ý𝑐ℎ 𝑓𝑢𝑛𝑘č𝑛í𝑐ℎ 𝑏𝑜𝑑ů] Získaná hodnota pomůže kategorizovat projekt do různých velikostních skupin, vypočítané body je možné převést pomocí převodních tabulek na počty řádků kódu nebo na člověkoměsíce.
Vývoj nového řešení Velikost projektu (uFP)
Úprava stávajícího řešení (uFP)
Velmi malý
0-150
0-60
Malý
150-300
60-120
Střední
300-600
120-240
Velký
600-1 200
240-480
Velmi velký
1 200-5 000
480-2 000
Extrémně velký
> 5 000
> 2 000
Tabulka 9: Velikostní kategorie projektu (v neupravených funkčních bodech) [36]
Měření kvality Cílem monitorování kvality je zjistit, zda byly splněny stanovené požadavky a očekávání zákazníka. Kvalita může být jak metrikou produktu, tak metrikou procesu. Kvalita produktu je typicky měřena hustotou chyb (počet chyb na velikost produktu) nebo časem mezi výskytem chyb (střední doba mezi poruchami, tento způsob je využívaný především v bezpečnostně kritických systémech) [37]. Kvalita procesu, která sleduje přírůstek chyb řešených v průběhu testování, je typicky měřena počtem chyb za jednotku času nebo fázi projektu. Kvalitu lze dále posuzovat například z pohledu závažnosti chyb, spokojenosti zákazníka, nebo zda je hodnocena zákazníkem nebo vývojovým týmem. 𝐻𝑢𝑠𝑡𝑜𝑡𝑎 𝑐ℎ𝑦𝑏 =
𝑃𝑜č𝑒𝑡 𝑐ℎ𝑦𝑏 𝑃𝑜č𝑒𝑡 𝑓𝑢𝑛𝑘č𝑛í𝑐ℎ 𝑏𝑜𝑑ů
56
Měření nákladů Měření nákladů je populární především v souvislosti s posuzováním investičních variant v počáteční fázi projektu, i když metriky např. průměrné roční náklady a diskontované náklady nejsou tak často používané jako doba návratnosti nebo čistá současná hodnota. Další uplatnění nachází při kontrole nákladových položek, které se na nákladových účtech porovnávají s plánovanými hodnotami. 𝑂𝑑𝑐ℎ𝑦𝑙𝑘𝑎 𝑛á𝑘𝑙𝑎𝑑ů = 𝑃𝑙á𝑛𝑜𝑣𝑎𝑛é 𝑛á𝑘𝑙𝑎𝑑𝑦 − 𝑆𝑘𝑢𝑡𝑒č𝑛é 𝑛á𝑘𝑙𝑎𝑑𝑦 V následujícím textu bude představena metoda Earned Value Management (EVM), která sleduje všechny tři oblasti projektového trojimperativu a která využívá stanovenou odchylku nákladů. Cílem EVM je učit hodnotu vykonaného úsilí na projektu v okamžiku kontroly, aby bylo možné posoudit časový postup projektu ve vazbě na vynaložené náklady [27]. Metoda používá několik základních ukazatelů, ke kterým patří: PV
Plánovaná hodnota (Finanční vyjádření, kolik práce má být k danému datu udě-
láno) EV
Hodnota rozpracovanosti (Finanční vyjádření, kolik práce je k danému datu udě-
láno) AC
Skutečné náklady (Skutečně vykázané náklady k danému datu)
EAC
Prognóza celkových nákladů projektu při jeho ukončení (Očekávané celkové ná-
klady při dokončení projektu) ETC
Odhad nákladů pro dokončení (Odhad nákladů na dokončení projektu od oka-
mžiku měření) BAC
Původní celková výše rozpočtu (Součet všech plánovaných nákladů)
Od těchto ukazatelů se odvozují další veličiny, např.: CPI
Index výkonu podle nákladů 𝐶𝑃𝐼 = 𝐸𝑉⁄𝐴𝐶
SPI
Index výkonu podle časového rozvrhu 𝑆𝑃𝐼 = 𝐸𝑉⁄𝑃𝑉
CV
Odchylka od rozpočtu 𝐶𝑉 = 𝐸𝑉 − 𝐴𝐶
SV
Odchylka od časového rozpisu 𝑆𝑉 = 𝐸𝑉 − 𝑃𝑉
57
Obrázek 18: Grafické znázornění hodnot z EVM [27]
Metoda je vhodná pro projekty různé velikosti, pokud je jejich rozsah stabilní. Univerzálně lze použít metriku používající poměr nákladů vůči funkčním bodům.
Měření času K vyhodnocování stavu projektu a průběhu prací lze použít srovnání s plánem ve zvoleném čase. Toho využívá výše zmíněná metoda EVM, které používá jako veličinu odchylku od časového rozpisu. Jiný způsob nabízí Ganttův diagram, který lze doplnit o procentuální plnění daného úkolu. Milníková metoda [27] patří k rozšířeným způsobům vyhodnocováním stavu projektu a jejím principem je stanovení velkého počtu milníků, označujících dokončení významné události v projektu, vůči kterým se porovnává současný stav, který se dokumentuje a na základě kterého lze odhadnout i další vývoj.
Bližší informace o softwarových metrikách lze získat ze zdrojů [37] a [38].
58
8 Závěr Projektové řízení je dynamicky se rozvíjející obor, který jako nástroj realizace potřebných změn využívají podniky k uskutečňování svých cílů. Trendem moderního managementu je přechod od funkčního pojetí řízení, které souvisí s klasickou liniovou hierarchickou organizační strukturou, k řízení projektovému, které umožňuje řídit a sledovat efektivitu jednotlivých procesů v organizaci a tyto činnosti měřit, hodnotit a rychle reagovat na změny. K podobným změnám dochází také v oblasti softwarového inženýrství, kde je tendence nahradit tradiční způsob vývoje moderními agilními metodikami. Diplomová práce představila vybrané zástupce agilních a tradičních metodik budování ICT projektů, které vzájemně srovnávala. Současně uvedla dva nejznámější procesně orientované standardy projektového řízení a prezentovala možnosti vzájemného kombinování a koexistence metodik a standardů s předpokladem, že moderní principy softwarového inženýrství doplní a obohatí tradiční postupy řízení projektů. O to se v poslední době snaží organizace, které mají zájem změnit způsob manažerského řízení a mohou si takovou změnu dovolit a prosadit ji ve svých podmínkách. Kombinace standardu PRINCE2 a agilní metodiky Scrum byla aplikována na konkrétní projekt partnerské organizace, který byl v době psaní práce rozpracovaný a úspěšně se vyvíjel. Standard byl v některých částech upravený, přitom byly dodrženy všechny jeho povinné prvky. Změny se dotkly vytvářené dokumentace a produktů, které byly přizpůsobené potřebám projektu. Metodika Scrum byla použita při vývoji portálového řešení a nahradila ve standardu proces Řízení dodání produktu. Výhody jejího zavedení byly zřejmé: intenzivnější spolupráce v týmu i při komunikaci se zákazníkem, vyšší motivace týmu a jeho soudržnost jako kolektivu, průběžné předkládání výsledků práce zákazníkovi a rychlá reakce na jeho připomínky, včasné opravy chyb, trvalé zlepšování procesů, kontrola projektu pomocí jednoduchých metrik. Modifikace vyžadovala propojení rolí, vytvoření backlogu v iniciační fázi projektu a začlenění Scrum schůzek do rámce standardu. Práce se zabývala otázkou výběru a hodnocení metodik a poskytla návod, jak vybrat vhodnou metodiku. Ukázala, jakým způsobem lze vybrané metodiky a standardy kombinovat tak, aby byly využity výhody obou přístupů. Představila také možnosti měření a kontroly vývoje projektu pomocí základních veličin, a to rozsahu, času, nákladů a kvality. To vše lze považovat za přínos práce.
59
9 Bibliografie
[1] A guide to the project management body of knowledge (PMBOK® guide). 5th ed. Newtown Square: Project management institute, c2013, xxi, 589 s. ISBN 978-1935589-67-9. [2] PRINCE2, Best Management Practice. Managing successful projects with PRINCE2. 5th ed. London: TSO, 2009, 342 s. ISBN 978-011-3310-593. [3] Národní standard kompetencí projektového řízení verze 3.2: National competence baseline of project management 3.2 - web [online]. Vyd. 3. Brno: Společnost pro projektové řízení, 2013, 288 s. [cit. 2014-10-19]. ISBN ISBN 0-9553213-0-1. Dostupné z: http://www.ipma.cz/web/files/narodni-standard-kompentenci-projektovehorizeni.pdf. [4] A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute, 2000, x, 216 s. ISBN 18-804-1023-0. [5] SCHWALBE, K. Řízení projektů v IT: kompletní průvodce. Vyd. 1. Brno: Computer Press, 2011, 632 s. ISBN 978-80-251-2882-4. [6] BRUCKNER, T., et al. Tvorba informačních systémů: principy, metodiky, architektury. 1. vyd. Praha: Grada, 2012, 357 s. ISBN 978-80-247-4153-6. [7] BRIAND, L. C. a WIECZOREK, I. Resource Estimation in Software Engineering. In: Encyclopedia of Software Engineering [online]. 2002 [cit. 2014-12-19]. Dostupné z: http://squall.sce.carleton.ca/pubs/other/Encyclopedia-SE.pdf. [8] VOŘÍŠEK, J. Strategické řízení informačního systému a systémová integrace. Vyd. 1. Praha: Management Press, 1997, 323 s. ISBN 80-859-4340-9. [9] BUCHALCEVOVÁ, A. Metodiky budování informačních systémů. Vyd. 1. Praha: Oeconomica, 2009, 205 s. ISBN 978-80-245-1540-3. [10] BECK, K., et al. Manifest Agilního vývoje software [online]. 2001 [cit. 2014-10-18]. Dostupné z: http://agilemanifesto.org/iso/cs/.
60
[11] BUCHALCEVOVÁ, A. Metodiky vývoje a údržby informačních systémů: kategorizace, agilní metodiky, vzory pro návrh metodiky. 1. vyd. Praha: Grada, 2005, 163 s. ISBN 80-247-1075-7. [12] CHARVAT, J. Project management methodologics: selecting, implementing and supporting methodologies and processes for project. Vyd. 1. New Jersey: John Wiley, 2003, 264 s. ISBN 04-712-2178-3. [13] COCKBURN, A. Crystal clear: a human-powered methodology for small teams. Boston: Addison-Wesley, c2005, xxii, 312 s. ISBN 0-321-18612-5. [14] BOEHM, B. a TURNER, R. Balancing agility and discipline: a guide for the perplexed. 3. print. Boston: Addison-Wesley, 2003, 304 s. ISBN 03-211-8612-5. [15] TAYLOR, P. S., et al. Applying an Agility/Discipline Assessment for a Small Software Organisation. In: JÜRGEN MÜNCH, Matias Vierimaa (eds. Productfocused software process improvement 7th international conference, PROFES 2006, Amsterdam, the Netherlands, June 12-14, 2006: proceedings [online]. Berlin: Springer, 2006, s. 290 [cit. 2014-10-18]. ISBN 9783540346838. Dostupné z: http://link.springer.com/10.1007/11767718_25. [16] HECKSEL, D. System and method for software methodology evaluation and selection [patent]. Sun Microsystems, Inc., US20040243968 A1. Uděleno 2. prosinec 2004. Dostupné z: http://www.google.com/patents/US20040243968. [17] 8th Annual State of Agile Survey. In: Versionone [online]. 2014 [cit. 2014-10-19]. Dostupné z: http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf. [18] Has Scrum Become the Face of Agile?. In: Scrum Methodology [online]. 2014 [cit. 2014-10-19]. Dostupné z: http://scrummethodology.com/has-scrum-become-theface-of-agile/. [19] WILSON, N. Best Practices in Transitioning to Agile: Picking a Methodology. In: Gartner [online]. 2012 [cit. 2014-10-19]. Dostupné z: https://www.gartner.com/doc/1957529.
61
[20] GIBBS, R. Project management with the IBM rational unified process: lessons from the trenches. Upper Saddle River: IBM Press, 2006, 287 s. ISBN 03-213-3639-9. [21] SCHWABER, K. Agile project management with Scrum. Redmond, Wash.: Microsoft Press, c2004, xix, 163 s. ISBN 07-356-1993-X. [22] SUTHERLAND, J. a SCHWABER, K. The Scrum Guide [online]. 2013 [cit. 2014-1221]. Dostupné z: http://www.scrumguides.org/scrum-guide.html. [23] LAYTON, M. Agile project management for dummies. Hoboken, N.J.: Wiley, c2012, xiv, 346 s. ISBN 978-111-8235-850. [24] KRUCHTEN, P. The rational unified process: an introduction. 3rd ed. Upper Saddle River: Addison-Wesley, 2004, xviii, 310 s. ISBN 03-211-9770-4. [25] RÁČEK, J. Agilní metodiky vývoje SW [online]. 2013 [cit. 2014-12-19]. Dostupné z: https://is.muni.cz/el/1433/podzim2013/PA017/um/SWE2_07_agilni.pdf. [26] ČSN ISO 10006:2003. Systémy managementu jakosti - Směrnice pro management jakosti projektů. Praha: Český normalizační institut, 2004. [27] DOLEŽAL, J., MÁCHAL, P. a LACKO, B. Projektový management podle IPMA. 2., aktualiz. a dopl. vyd. Praha: Grada, 2012, 526 s. ISBN 978-80-247-4275-5. [28] SVOZILOVÁ, A. Projektový management. 2., aktualiz. a dopl. vyd. Praha: Grada, 2011, 380 s. ISBN 978-80-247-3611-2. [29] BENTLEY, C. Základy metody projektového řízení PRINCE2. Bratislava: INBOX SK s.r.o., 2010, 312 s. ISBN 978-0-9576076-2-0. [30] KROLL, P. a KRUCHTEN, P. The rational unified process made easy: a practitioner's guide to the RUP. Boston: Addison-Wesley, c2003, xxxv, 416 s. ISBN 03-211-6609-4. [31] SILVIUS, A. J. G. Does ROI Matter? Insights into the True Business Value of IT. In: The Electronic Journal of Information Systems Evaluation [online]. Volume 9, Issue 2. 2006 [cit. 2014-11-22]. Dostupné z: http://www.ejise.com/issue/download.html?idArticle=768.
62
[32] IEEE Std 1061-1998. Standard for a Software Quality Metrics Methodology. NY: IEEESA Standards Board, 1998. Dostupné z: http://ieeexplore.ieee.org/servlet/opac?punumber=6061. [33] BUNDSCHUH, M. a DEKKERS, C. The IT measurement compendium: estimating and benchmarking success with functional size measurement. Berlin: Springer, c2008, xxxv, 643 s. ISBN 35-406-8187-6. [34] PUNTER, T. Software Messen und Bewerten mit GQM-Light. Software-Messung in der Praxis [online]. 2003 [cit. 2014-12-19]. Dostupné z: http://publica.fraunhofer.de/documents/N-21222.html. [35] BIELIKOVÁ, M. Softvérové inžinierstvo: Princípy a manažment. Bratislava: Vydavateľstvo STU, 2000, 220 s. ISBN 80-227-1322-8. [36] NATALE, D., et al. Proposals for project collection and classification from the analysis of the ISBSG Benchmark 8. 14th International Workshop on Software Measurement [online]. 2004IWSM 2004 [cit. 2014-12-09]. Dostupné z: http://www.dpo.it/resources/papers/2004-iwsm-gufpi.pdf. [37] KAN, S. Metrics and models in software quality engineering. Vyd. 2. Boston: AddisonWesley, 2004, 528 s. ISBN 0-201-72915-6. [38] PRESSMAN, R. S. a MAXIM, B. Software Engineering: A Practitioner's Approach. 8 edition. New York: McGraw-Hill Education, 2014, 976 s. ISBN 00-780-2212-6.
63
