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 2.1 Projekt... 3 2.2 Životní cyklus projektu... 4 2.3 Projektové řízení... 5 2.4 Odlišnosti ICT projektů... 5 3 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 Rational Unified Process... 17 3.4.1 Dynamický pohled... 18 3.4.2 Statický pohled... 19 4 Standardy projektového řízení... 21 4.1 Standard PMBOK... 22 4.1.1 Procesní skupiny... 22 4.1.2 Znalostní oblasti... 24 4.2 Standard PRINCE2... 25 4.2.1 Principy... 25 4.2.2 Témata... 26 4.2.3 Procesy... 27 5 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řípadu 1 [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 1 Obchodní případ (Business Case) popisuje zdůvodnění projektu, oprávněnost jeho zahájení a pokračování. 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
Nástroje metodiky Podrobnost metodiky Kvalita Předvídatelnost Změny Participace zákazníka na projektu Specializace lidí Rigorózní metodiky Procesy se zaměřují na formálnost a dokumentovatelnost, lidé jsou sekundární faktor Podrobný popis činností a procesů Zaměření na kvalitu procesů, které povedou ke kvalitnímu výsledku Sběr požadavků a plánování předem Snaha změny minimalizovat a řízení změn Jen v počátečních a koncových fázích Vyžaduje specializaci pro týmové role Agilní metodiky Praktiky vychází ze znalostí jednotlivců, lidé jsou klíčovým faktorem úspěchu Pouze základní struktura Zaměření na priority zákazníka Přírůstkové shromažďování požadavků, plánování po iteracích Snaha změny umožnit s ohledem na nové znalosti Po celou dobu projektu 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 Převážně písemná Osobní komunikace 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 Lidé Kultura Vhodné pro často se měnící prostředí. Vyžaduje přítomnost SW expertů po celou dobu projektu. Vhodné pro stabilní prostředí. Přítomnost SW expertů při definování projektu, později specialisté nejsou vyžadováni. Pocit komfortu + podpora Pocit komfortu + jasně definované volnosti. 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) Organizace (Organization) Kvalita (Quality) Plány (Plans) Rizika (Risk) Změna (Change) 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ý. 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. 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í. 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. Úč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. 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. Proč? Kdo? Co? Jak? Kolik? Kdy? Co když? 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. Tabulka 3: PRINCE2 témata (Autor dle [29]) Kde jsme? Kam směřujeme? Máme pokračovat? 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