Metodika řízení víceletých studentských týmových projektů

Transkript

1 České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství Magisterská práce Metodika řízení víceletých studentských týmových projektů Bc. Jan Matoušek Vedoucí práce: Ing. Jiří Chludil 10. května 2012

2

3 Poděkování rodině a přátelům za vytrvalost a podporu. vedoucímu a oponentovi za rady a praktické postřehy. členům projektového týmu Terra Incognita za jejich spolupráci.

4

5 Prohlášení Prohlašuji, že jsem tuto práci vytvořil samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některý zákonů (autorský zákon), nemám závažný důvod proti užití tohoto školního díla a k užití uděluji svolení. V Chomutově dne 10. května 2012

6 České vysoké učení technické v Praze Fakulta informačních technologií 2012 Jan Matoušek. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora. Odkaz na tuto práci Jan Matoušek. Metodika řízení víceletých studentských týmových projektů: Magisterská práce. Praha: ČVUT v Praze, Fakulta informačních technologií, 2012.

7 Abstract This thesis covers the topic of project management with a special regard to projects that are complex or attractive to students. The thesis presents commonly used project management methods and typical student team project characteristics and proposes a suitable long-term student team project management method. The method is then applied to the ongoing computer game project Terra Incognita. Keywords project management, PMBOK, PRINCE2, Scrum, Kanban, extreme programming, video game development, student team projects, longterm projects, Terra Incognita Abstrakt Tato práce rozebírá problematiku projektového řízení, zvláště pak řízení projektů, které jsou rozsáhlé nebo přitažlivé pro studenty. Práce představuje používané metodiky a specifika studentských projektů a navrhuje vhodnou metodiku pro řízení víceletých studentských týmových projektů. Tuto metodiku aplikuje na studentský týmový projekt počítačové hry Terra Incognita. Klíčová slova projektové řízení, PMBOK, PRINCE2, Scrum, Kanban, extrémní programování, vývoj počítačových her, studentské týmové projekty, dlouhodobé projekty, Terra Incognita

8

9 Obsah 1 Úvod Motivace Rozbor zadání Struktura práce Využití mé práce Problematika řízení projektu Projekt Řízení projektu Úvodní studie Cíle projektu SWOT analýza Rizika Projektový tým Skupinové role Organizace práce Odpovědnosti Návaznost úkolů, projektový plán Metodiky řízení projektu Tradiční metodiky PMBOK PRINCE Agilní metodiky Scrum Kanban Extrémní programování Shrnutí Nástroje řízení projektu Podoby nástrojů Nástroj jako software Nástroj jako služba Funkce nástrojů ix

10 4.3 Komunikační nástroje Nástroje pouze k hlášení chyb MantisBT Bugzilla Další systémy Datová úložiště Verzovací systémy Microsoft SharePoint Sourceforge Google Code Project Hosting Github Basecamp Komplexní nástroje Microsoft Project Redmine JIRA Assembla Springloops Shrnutí Atraktivní projekty Vývoj počítačových her Ekonomická stránka vývoje počítačových her Role při vývoji počítačových her Průběh vývoje počítačových her Předprodukční fáze Produkční fáze Poprodukční fáze Shrnutí herních projektů Řízení víceletých studentských týmových projektů Rysy studentských týmových projektů Východiska Hypotézy Ověření hypotéz Metodika řízení VSTP Obsah metodiky Struktura řízení, role Aspekty - dílčí cíle projektu Průběh projektu Hodnoty, filozofie Uplatnění metodiky Projekt Terra Incognita 61 x

11 7.1 Popis projektu SWOT analýza Silné vnitřní stránky Slabé vnitřní stránky Příležitosti Hrozby Rizika Řízení projektu Projektový tým pro první rok Plán pro další roky Závěr Rekapitulace práce Shrnutí prvního roku projektu Terra Incognita Výhled do budoucnosti Literatura 73 A Seznam použitých zkratek 75 B Průzkum rysů studentských projektů 77 B.1 Ing. Jiří Chludil B.2 Ing. Jiří Hunka C Obsah přiloženého CD 79 xi

12

13 Seznam obrázků 2.1 Tabulkové rozložení SWOT analýzy Grafické vyjádření návazností Příklad Ganttova diagramu s vyznačenou kritickou cestou Příklad aplikace algoritmu k nalezení kritické cesty Procesní schéma metodiky PRINCE Příklad vizualizace procesního toku v Kanbanu Mantis, ukázka přehledu chyb Github, zobrazení větvení repozitářů MS Project, ukázka časového a Ganttova diagramu JIRA, ukázka Kanbanu v pluginu GreenHopper Navržená metodika řízení VSTP v kostce Stručné shrnutí SWOT analýzy projektu Vztahy jednotlivých aspektů Terra Incognita C.1 Adresářová struktura přiloženého CD xiii

14

15 Seznam tabulek 3.1 Procesy PMBOK zasazené do skupin a znalostních oblastí Rozdělení aspektů Terra Incognita mezi řešitele xv

16

17 KAPITOLA 1 Úvod Řízení projektu je jednou z pracovních činností, která se očekává od vysokoškolsky vzdělaného člověka. Vystudoval-li na FIT ČVUT magisterský program se zaměřením na softwarové inženýrství, získal mj. potřebné teoretické ekonomické a manažerské dovednosti nutné pro vedení velkých softwarových projektů Motivace Většina dnešní vědecké práce je mnohaletým soustředěným úsilím méně či více rozsáhlých týmů 2 vědců, mnohdy napříč celým světem. Stejně tak víceleté studentské týmové projekty se rády stávají náplní závěrečných absolventských prací na vysokých školách. 3 Tyto projekty se stávají předmětem řízení a touto problematikou se má práce zaobírá, ač je značně ovlivněna oblastí vývoje softwaru, což je pochopitelné vzhledem k povaze mé alma mater a nejčastějšího předpokládaného využití výsledků mé práce. 1 viz popis studjního oboru na webových stránkách fakulty: student/magistersky-program/softwarove-inzenyrstvi 2 Ano, zcela správně to připomíná definici projektu, protože to projekt je. 3 Ostatně na jednom takovém jsem se úspěšně podílel v rámci své bakalářské práce na KP FEL ČVUT v roce 2009/2010 1

18 1. Úvod 1.2 Rozbor zadání Má práce si vytyčila několik cílů, jež jsou obsaženy v zadání. Jednotlivé cíle nejsou samoúčelné a souvisejí s dalším využitím mé práce. Shrnout problematiku řízení projektu, a to tak, aby i laický čtenář získal dobrou orientaci v problematice. Tento cíl se snaží naplnit hned následující kapitola. Představit používané postupy v oboru řízení projektů, zejména softwarových. Tato část představuje dvě kapitoly, jež prezentují vybrané metodiky řízení projektů a nástroje, které se nejčastěji používají při řízení a správě zejména softwarových projektů. Rozbor jednotlivých metodik představuje rozšíření předtím shrnuté problematiky projektového řízení. Společně s rozborem nástrojů jsou tyto kapitoly návodem pro ty, kteří chtějí realizovat vlastní projekt, ale nemají téměř žádný rozhled v problematice. Poskytnout vhled do problematiky studentsky atraktivních projektů. K tomu slouží celá kapitola, která se převážně věnuje vývoji počítačových her, neb toto téma považuji za studentsky atraktivní. Důvodem je také fakt, že tato práce byla řešena při řízení herního projektu. Shrnout problematiku studentských týmových projektů, včetně zkušeností pedagogů. Tato část je přípravou k jádru mé práce, představuje východiska pro mnou navrženou metodiku řízení uvedených projektů. Navrhnout metodiku pro řízení víceletých studentských týmových projektů. Zde je těžiště mé práce, v níž navrhuji metodiku řízení uvedených projektů respektující jejich povahu. Představit projekt Terra Incognita a aplikovat na něj vzniklou metodiku. V této části tkví praktické jádro mé práce a je hlavním důvodem vypracování předcházejících částí. V této části ověřím smysluplnost mé metodiky aplikací na konkrétní studentský projekt, který zde zároveň představím. Shrnout získané zkušenosti z prvního roku projektu Terra Incognita a z aplikace metodiky. Zároveň nastíním výhled do dalších let. Tím svou práci uzavřu. 2

19 1.3. Struktura práce 1.3 Struktura práce Diplomová práce má kombinovaný charakter převážně rešeršní a návrhové práce. Z uvedených cílů mé práce je patrné, že práce je v podstatě rozdělena na tři části: Teoretická a rešeršní část, v níž shrnu získané znalosti, dovednosti a existující informace týkající se obecně řízení projektů. Návrhová část, v níž získám podklady k řízení studentských projektů a sestavím a popíšu vhodnou metodiku, jejich řízení. Aplikační část, v níž tuto metodiku aplikuji na řízení projektu Terra Incognita. 1.4 Využití mé práce Má práce razí cestu dalším podobným projektům. Vzhledem k existenci víceletých studentských týmových projektů je nějaká metodika jejich řízení, která by byla takovým projektům šita na míru, potřeba. Doufám, že se tento cíl sestavení takové metodiky podaří naplnit a doufám, že i zjištěné zkušenosti budou při řízení dalších projektů nápomocny. 3

20

21 KAPITOLA 2 Problematika řízení projektu Problematika řízení projektu je neustále rozebírána z mnoha úhlů pohledu. V prvé řadě jde zejména o problém ekonomický a manažerský. Podle domény projektu se k problematice připojují i požadavky konkrétních technických oborů (jako např. softwarové inženýrství, stavebnictví, strojírenství, elektrotechnika ). Řízení projektu se dále opírá o znalosti z psychologie i taktické a strategické dovednosti. S rozvojem zmíněných technických disciplín, ale i s rozvojem společnosti, se mění požadavky na projektové řízení a jeho problematika se rovněž vyvíjí. 2.1 Projekt K pochopení problematiky projektového řízení je nejdříve nutno pochopit problematiku projektu. Nevíme-li, co je projekt, nevíme, co řídit. Projekt bývá v manažersko-ekonomické oblasti definován jako časově ohraničené úsilí, směřující k vytvoření unikátního produktu nebo služby. Projekty se vyskytují všude kolem nás a jsou nedílnou součástí organizované lidské činnosti. Existence každé věci či služby v našem okolí, není-li přirozeného původu, je výsledkem lidského úsilí. Dle výše uvedené definice může být výstupem uskutečněného projektu. Potřeba projektu je reakcí na potřebu nového produktu nebo služby. Projekt tedy obvykle vzniká na základě objednávky - ať už vnitřní nebo vnější. Kromě definovaného výstupu potřebuje projekt zdroje různých druhů. Výstupem a těmito zdroji je každý projekt ohraničen. Projekt je v podstatě proces, který přetváří přidělené zdroje v definovaný výstup. Mezi zdroje patří tyto: 5

22 2. Problematika řízení projektu Čas 4, který představuje termín dokončení projektu. Lidské zdroje, tedy lidé podílející se na uskutečnění projektu. Znalosti a zkušenosti 5 získané z předchozích projektů a/nebo vzdělání lidí zapojených do projektu. Pracovní prostředky, tedy hmotné i nehmotné statky, jichž lidé užívají k realizaci projektu. Finanční prostředky, které umožní využití ostatních zdrojů. Čím rozsáhlejší a složitější produkty či služby jsou výsledkem projektu, tím více zdrojů je potřeba k jeho uskutečnění. V průběhu realizace projektu se množství i povaha zdrojů mění. Mění se rovněž jistota dosažení cíle. 2.2 Řízení projektu Rozmanitost problematiky, rozsáhlost projektu i množství zdrojů vyvolávají potřebu tyto zdroje efektivně využívat, vhodně je spravovat, přidělovat a organizovat a zajistit splnění vytyčených cílů. Tomuto procesu se v souvislosti s projektem říká řízení projektu. Předmětem řízení projektu je konkrétní projekt. Základní cíle projektového řízení vycházejí z ohraničení projektu: Zajistit dosažení cílů projektu. Jde o nejzákladnější cíl řízení, a v podstatě hlavní důvod, proč je potřeba projekt řídit. Dosažení cíle projektu není jisté a ani samozřejmé. Je zapotřebí vložit jisté úsilí. Efektivně využít přidělené zdroje. Do tohoto cíle se promítá ekonomický rozměr problematiky. Zdroje jsou omezené, správné řízení projektu by mělo zajistit jejich nejlepší využití a zamezit jejich plýtvání. K dosažení těchto cílů využívá projektové řízení velké množství nástrojů a postupů. Již z dřívějších odstavců vyplývá, že řízení projektu může být (a je) náročný proces pokrývající mnoho činností. Mlhavost a rozlehlost problematiky i množství specifických technických disciplín (domén), v nichž se mohou projekty realizovat, daly vzniknout mnoha metodikám, které tyto nástroje a postupy konkrétně vymezují a případně přizpůsobují konkrétní doméně. Mnoho věcí je však společných a ve větší či menší míře se s nimi lze setkat při řízení každého projektu. 4 Čas bývá ze zdrojů projektu vyčleňován a uváděn samostatně, aby spolu s definovaným výstupem a ostatními zdroji utvořil tzv. projektový trojimperativ. Sám však považuji čas za jeden ze zdrojů. 5 V manažerštině se objevuje termín know-how. 6

23 2.3. Úvodní studie 2.3 Úvodní studie Úvodní studie projektu představuje startovní bod pro jeho započetí. Smyslem této studie je identifikovat řešený problém, cíle projektu, potřebné zdroje (čas, finance, lidé), rizika a posoudit realizovatelnost a návratnost. Úvodní studie by měla poskytnout zájmovým osobám (vedení firmy, zákazníkovi...) představu o potřebě realizovat daný projekt. V případě dobrého projektu by měla nadřízené přesvědčit k přidělení zdrojů, a tedy k zahájení projektu. Existence úvodní studie není univerzální konstantou a ne každá metodika ji vyžaduje. Vytyčení alespoň nějakých cílů a alespoň nějaký odhad realizovatelnosti a potřeby zdrojů se však koná vždy, protože projekt je realizován jen díky přiděleným zdrojům Cíle projektu Cíle projektu vycházejí ze zadání projektu, kterým bývá přání zákazníka, některé součásti firmy, nebo vize snílka, který zatouží je realizovat 6. Cíle projektu by měly toto přání popsat, měly by definovat konečné aspekty zamýšleného produktu či služby. Smyslem cílů je nastavení směřování vývoje a tvoří podklad ke kontrole ucelenosti a kvality výsledného produktu. Projekt bez cílů neví, co má dělat a neví, co je jeho smyslem. Cíle lze rozdělit do několika skupin: Funkční požadavky. Definují funkci výsledného produktu či služby. Odpovídají na otázky typu Co to bude dělat? a Jaký to má účel? Je dobré tyto požadavky (u komplikovanějších produktů či služeb) členit podle funkčních celků. Nefunkční požadavky. Definují okolnosti, za kterých produkt či služba budou pracovat. Odpovídají na otázky typu Kde to bude fungovat?, Kdo (a jak) to bude používat?, Jaký to má vztah k ostatním nasazeným produktům?, Kdo (a jak) se bude starat o provoz? apod. Vizionářské. Definují budoucnost, opakovatelnost nasazení. Odpovídají na otázky typu Budeme výsledek používat i jinde?, Ulehčí nám to v budoucnu práci? nebo Jak to zlepší renomé naší firmy? Aby šlo projekt řídit, je třeba každý cíl přesně stanovit, abychom mohli detekovat jeho dosažení i míru úspěšnosti jeho dosažení. K tomu slouží různé metriky. Smyslem posuzování dosažení cílů je získání zkušeností pro další projekt (poučení se z chyb). 6 To je případ velké části drobných nebo kreativních projektů. 7

24 2. Problematika řízení projektu Protože každý cíl je jinak důležitý, stanovujeme rovněž priroty cílů. To umožňuje zaměřit se při řízení projektu nejprve na důležitější cíle, usnadňuje to řešení krizových situací, ale také plánování prací. Oblíbenou metaforou je stavba domu - i když je cílem dobré bydlení, z počátku je důležité mít vůbec nějaké bydlení. Podrobnost, formálnost cílů a schopnost projektu reagovat na změny stanovených cílů závisí na použité metodice řízení SWOT analýza SWOT analýza je stručný analytický nástroj používaný v dnešní praxi, který je oblíbený, protože poskytuje přehled o realizovatelnosti projektu jednoduchou tabulkovou formou. SWOT analýza je užitečná také v tom, že nabízí základní body k vypracování dalších specifických analýz (např. analýza rizik, dopadová studie...). Realizovatelnost projektu podle SWOT je definována čtyřmi faktory, které tvoří i název této analýzy a v podstatě ji samy popisují: Silné stránky (Strengths). Vlastnosti společnosti a realizačního týmu, které povedou k úspěšné realizaci projektu. Slabé stránky (Weaknesses). Vlastnosti společnosti a realizačního týmu, které mohou zmařit úspěšné dosažení cílů projektu. Příležitosti (Opportunities). Souhrn vnějších faktorů, které mohou přispět k úspěchu projektu nebo vlastní zájmy, které mohou být úspěchem projektu povzbuzeny. Hrozby (Threats). Souhrn vnějších faktorů, které mohou zmařit úspěšnou realizaci projektu nebo vlastní zájmy, které mohou být realizací projektu poškozeny. Z výše uvedného přehledu je patrné, že pojmy SWOT lze členit dle dvou hledisek do dvou skupin. Toto členění vytváří tabulku 2x2, jejíž pomocí se SWOT analýza prezentuje. (Viz obr. 2.1) Součástí SWOT analýzy je krom rozboru existujících poiztivních (resp. negativních) faktorů i rozbor opatření, která je využijí (resp. omezí). 2.4 Rizika Rizika představují ohrožení dosažení vytyčených cílů a jsou příčinou nejistoty výsledku projektu. Nastalý rizikový stav může mít značné dopady na úspěch celého projektu, přeneseně pak i na ekonomiku firmy, její pozici na trhu i její personální obsazení. Řešením dopadů rizik poté, co nastanou, se zabývá krizový management. 8

25 2.4. Rizika Vnější Vnitřní Pozitivní Negativní S W Síly O Slabiny T Příležitosti Hrozby Obrázek 2.1: Tabulkové rozložení SWOT analýzy Rizika členíme podle jejich závažnosti, kterou obvykle stanovujeme podle důležitosti cílů, jež jsou těmito riziky dotčeny. Dále členíme rizika podle pravděpodobnosti, zda nastanou příslušné rizikové stavy. Protože jsou rizikové stavy nežádoucím vlivem, je třeba přijmout opatření, která povedou k odvrácení rizik, či snížení jejich pravděpodobnosti. A protože ne všechna rizika se musí podařit odvrátit, musí být projekt připraven i na eventualitu, že riziko nastane - je třeba stanovit opatření vedoucí k minimalizaci dopadu rizika. Některá rizika mají tak nízkou pravděpodobnost nebo tak zanedbatelný dopad, že se jimi nezabýváme. Tato rizika nazýváme zbytková rizika. Obvyklými riziky jsou např.: Nedodržení termínu. Předchází se mu sledováním pracovního postupu (v případě potřeby i zákazníkem), správnou organizací práce a nakládáním se zdroji. Dopady se minimalizují (včasnou) úpravou smlouvy. Nefunkčnost konkrétní části. Předchází se jí sledováním pracovního postupu, vhodným řízením prací, správnou alokací zdrojů a správně odhadnutým realizačním plánem. Minimalizují se dobře sepesanou smlovou. Změny požadavků zákazníka. Předchází se jim delší přípravou projektu a dobrou komunikací požadavků se sákazníkem. Dopady se minimalizují vhodnou priroritizací požadavků (komunikovanou se zákazníkem), iteračními vývojovými cykly a dobře sepsanou smlouvou. Nespokojenost zákazníka s výsledkem. Předchází se jí pravidelnou komunikací se zákazníkem, jasnou specifikací zadání, testovacími scénáři, předávacími protokoly. Dopady se minimalizují dobře sepsanou smlouvou. 9

26 2. Problematika řízení projektu Formálnější metodiky požadují analýzu rizik jako součást úvodní studie a zavádějí i proces řízení rizik. Jiné metodiky rizika vůbec neřeší, nebo části z nich předchází svou podstatou. Základní koncept rizik je však vždy stejný a liší se pouze jeho formalizace - při řízení projektu je vždy důležité předcházet problémům a případně minimalizovat jejich dopady. 2.5 Projektový tým Vzhledem k rozsáhlosti projektů a velkému množství specializovaných činností potřebných k jeho realizaci pracuje pro projekt jedna nebo více skupin lidí, kterým říkáme týmy. Týmy představují živou sílu projektu, která jej přímo realizuje. Důležitou činností při řízení projektu je vedení projektového týmu, kterou různé metodiky řízení postihují různě a mohou je delegovat různým způsobem na různé osoby; v podstatě však vždy někdo tým řídí a udává směr. Základem řízení týmu jsou organizační a psychologické dovednosti manažera a jeho znalost kvalit jednotlivých členů týmů a umění je motivovat Skupinové role Každý člen týmu má vlastní osobnost, z níž se odvíjí nejen jeho odborná specializace, ale také to, jak se projevuje ve skupině. Existuje několik typizací a způsobů určení jednotlivých rolí, nejznámější systém vytvořil britský odborník na řízení týmů Meredith Belbin, který identifikoval 9 rolí a sestavil tzv. Belbinův test, který určuje role podle priorit reakcí jedince na určité situace. Test je ale tak dobrý, jak je upřímná testovaná osoba. Devět Belbinových rolí je těchto: 10 Specialista (Specialist) disponuje cennými znalostmi v určitém úzkém oboru, v jiných oborech však nemá co říci a zbytek týmu jde mimo něj. Myslitel (Plant) je tvůrčí jedinec, který přináší nové nápady a neotřelá řešení, ale někdy se jimi nechává unést a opomíjí podružnosti. Monitor/vyhodnocovač (Monitor/Evaluator) vnáší do týmové práce logický pohled, umí zhodnotit různé možnosti a vybrat některou z nich. Na druhou stranu může mít problém inspirovat ostatní k další činnosti a může mít pomalé reakce. Usměrňovač (Shaper) dokáže popohnat tým, je průbojný, ale může být kritický a urážející. Realizátor (Implementer) je spolehlivý a aktivní vykonavatel práce, může však obtížně reagovat na změny.

27 2.6. Organizace práce Dotahovač (Finisher) je pečlivý, hledá a opravuje nedostatky a dokončuje práci v termínu. Na ostatní může působit uzavřeně a majetnicky, nerad pustí jiné ke své práci. Koordinátor (Coordinator) působí sebejistě, vyjasňuje cíle a dává lidi dohromady. Někdo jej může vnímat jako manipulátora, který svaluje práci na ostatní. Týmový pracovník (Team Worker) je ochotný a spolupracující, dokáže zahladit spory a šířit v týmu dobrou náladu, ale bývá nerozhodný. Vyhledávač zdrojů (Resource Investigator) je komunikativní a extrovertní jedinec, který hledá příležitosti a navazuje kontakty. Jeho optimismus a nadšení pro projekt však může po čase opadnout Každá skupinová role má určité předpoklady k plnění určitých činností a dobrý manažer by je měl správně a všechny využít. 2.6 Organizace práce Veškerá práce je organizována pomocí procesů a úkolů. Úkoly představují atomické časové rámce, během nichž je realizována určitá zadaná práce. Procesy jsou dlouhodobější časové rámce, které zastřešují vytváření a plnění podřízených procesů a úkolů. Jako proces lze chápat i projekt a jeho řízení. Jak procesy, tak jednotlivé úkoly mají svůj definovaný vstup (např. zadání, podklady zákazníka...) a výstup (např. jiné podklady, zdrojové kódy...). Postup prací na projektu často členíme do tzv. milníků, které značí dosažení významěnjších cílů. S milníky bývá spojeno dokončení vývojové iterace nebo vydání vývojové verze produktu Odpovědnosti Žádná práce se neudělá sama, existují lidé, kteří jsou za její vykonání odpovědní či s jejím vykonáním souvisí. K vymezení konkrétních vztahů osob k práci existuje metodika RA(S)CI, která definuje 4 (resp. 5) rolí, v nichž se může osoba vůči dané práci vázat: Responsible. Ten, kdo přímo vykonává danou činnost. Accountable. Vlastník činnosti, který je zodpovědný za její výsledek; v praxi se při předávání výsledku pod něj podepisuje. Každá činnost musí mít právě jednoho vlastníka. Často bývá vlastník identický s tím, kdo činnost vykonává, ale jde o různé vztahy. 11

28 2. Problematika řízení projektu Support. Podporovatel je ten, kdo vykonavatelům umožňuje vykonávat danou činnost. Consulted. Konzultant přispívá cennými radami k průběhu činnosti. Informed. Informován o průběhu a dokončení dané činnosti. S pomocí těchto vztahů lze vytvořit tabulku, tzv. matici odpovědnosti, která uvádí vztahy (buňky) všech osob (řádky nebo sloupce) ke všem pracím (sloupce nebo řádky) v projektu. Jednotlivé vztahy se v tabulce vyjádří jednopísmennou zkratkou podle jejich počátečních písmen. Existence jednoznačných odpovědností dává projektu řád, umožňuje komukoliv identifikovat osoby, se kterými je potřeba řešit určitý problém a odstraňuje situaci nikdo za nic nemůže Návaznost úkolů, projektový plán Jednotlivé úkoly tvořící dohromady projekt spolu vzájemně souvisí prostřednictvím svých vstupů, výstupů a sdílených zdrojů. Existují 4 druhy návazností mezi dvěma souvisejícími úkoly (viz obr. 2.2): Dokončení-Zahájení. Závislý úkol (Y) nelze zahájit, dokud úkol, na kterém závisí (X), není dokončen. Příklad: Máte dva úkoly, Vykopat základy a Zalít betonem. Úkol Zalít betonem nelze zahájit dříve, než dokončíte úkol Vykopat základy. Zahájení-Zahájení. Závislý úkol (Y) nelze zahájit, dokud úkol, na kterém závisí (X), není zahájen. Příklad: Máte dva úkoly, Zalít betonem a Uhladit beton. Úkol Uhladit beton nelze zahájit, dokud není zahájen úkol Zalít betonem. Dokončení-Dokončení. Závislý úkol (Y) nelze dokončit, dokud úkol, na kterém závisí (X), není dokončen. Příklad: Máte dva úkoly, Zabudovat elektroinstalaci a Provést inspekci elektroinstalace. Úkol Provést inspekci elektroinstalace nelze dokončit, dokud není dokončen úkol Zabudovat elektroinstalaci. Zahájení-Dokončení. Závislý úkol (Y) nelze dokončit, dokud úkol, na kterém závisí (X), není zahájen. Příklad: Střešní trámy pro vaši budovu se vyrábí mimo staveniště. Máte dva úkoly projektu, Dodat trámy a Postavit střechu. Úkol Postavit střechu nelze dokončit, dokud není zahájen úkol Dodat trámy. 7 resp. k tomu nemám kompetence 12

29 2.6. Organizace práce úkol X úkol X úkol X úkol X úkol Y úkol Y úkol Y úkol Y (a) D-Z (b) Z-Z (c) D-D (d) Z-D Obrázek 2.2: Grafické vyjádření návazností Obrázek 2.3: Příklad Ganttova diagramu s vyznačenou kritickou cestou Ganttův diagram Ganttův diagram (též ganttogram) je přehledným grafickým vyjádřením jednotlivých úkolů zaměřeným na jejich časové vymezení a sled. Dále zobrazuje jejich vzájemné vazby a tabulkovou formou další údaje (názvy, vlastníky atd.) Síťový diagram a kritická cesta Síťový diagram je grafické vyjádření úkolů zaměřené na vazby mezi nimi vycházející z tradičního matematického pojetí grafů. V praxi se příliš nepoužívá, protože neukazuje přehledným způsobem všechny obvykle požadované aspekty úkolů. Je však užitečný při chápání a hledání tzv. kritické cesty. Kritická cesta je řetěz (posloupnost) na sobě závislých úkolů, u nichž platí, že pokud některý selže (opozdí se či jinak zkomplikuje jeho splnění), selže (při zachování časového plánu) i poslední úkol tohoto řetězu a dojde k ohrožení projektu. Projekt může obsahovat i více než 1 kritickou cestu, pokud jsou všechny stejně dlouhé. Ke stanovení kritické cesty se používá algoritmus odvozený z teorie grafů (pro příklad viz obr. 2.4): Sestrojíme orientovaný ohodnocený graf reprezentující projekt. Každý vrchol představuje milník projektu, má své označení a dvě prázdné proměnné (levá a pravá, obě zpočátku rovny nule) pro zápis časových hodnot cest. Každá hrana je orientovaná a představuje přechod od jednoho milníku k druhému, jehož doba trvání je jejím ohodnocením. 13

30 2. Problematika řízení projektu Obrázek 2.4: Příklad aplikace algoritmu k nalezení kritické cesty Ze vstupního vrcholu (představujícího začátek projektu) provedeme klasický průchod do šířky, přičemž nastavujeme levé proměnné následníků na součet levé proměnné výchozího vrcholu a ohodnocení hrany, jíž procházíme, ale pouze pokud je tento součet vyšší než aktuální hodnota levé proměnné daného následníka. Levá proměnná posledního vrcholu určuje nejkratší čas jeho dosažení. Nastavíme pravou proměnnou všech vrcholů na hodnotu levé proměnné posledního vrcholu. Z posledního vrcholu provedeme zpětný průchod do šířky, přičemž nastavujeme pravé proměnné předchůdců na rozdíl proměnné pravé proměnné výchozího uzlu a odhodnocení hrany, jíž se vracíme, ale pouze pokud je tento rozdíl menší než aktuální hodnota pravé proměnné daného předchůdce. Vrcholy se shodnými levými a pravými proměnnými leží na kritické/ých cestě/ách. Identifikace kritických cest je velmi důležitá a při řízení projektu (resp. procesu) je potřeba počítat s riziky spojenými s kritickými cestami. Díky znalosti kritických cest lze stanovit i (minimální) délku projektu. Kritické cesty a úkoly se na Ganttově a síťovém diagramu obvykle znázorňují červenou barvou (viz obr. 2.3). Ostatní úkoly, které nejsou součástí kritických cest, nazýváme podkritické. 14

31 KAPITOLA 3 Metodiky řízení projektu Metodiky podrobně stanovují způsob projektového řízení; představují ověřené postupy i celé filozofie. Mnohé metodiky se staly standardem, jsou spravovány k tomu určenými organizacemi a jsou prováděny školení a certifikace. V této kapitole rozeberu některé z nich, standardizované i nestandardizované. Při výběru jsem se soustředil na obecně používané metodiky i na speciální metodiky používané v softwarových projektech. 3.1 Tradiční metodiky Tradiční metodiky představují formalistický přístup k projektovému řízení. Přesně rozčleňují projekt do oddělených etap a procesů, zavádí koloběh formálně strukturovaných dokumentů a stanovují konkrétní metody a postupy řízení. Tyto tradiční metodiky jsou nutné pro řízení velkých projektů, jejichž rozsáhlost je tak velká, že všechny podklady musí být podrobné a přesné. Formálnost dokumentů ale svazuje ruce v případě potřeby je měnit 8. Tradiční metodiky jsou tedy vhodné pro řízení stabilního jednoznačně zadaného projektu PMBOK The Project Management Body of Knowledge (zkráceně PMBOK 9 ) je souhrnem procesů a znalostních oblastí, které představují osvědčenou praxi projektového řízení nezávisle na oboru lidské činnosti, jíž se řízený projekt týká. 8 zejména, pokud jde o fundamentální změny v zadání 9 Vyslovujte jako Pim Bock s mírným skotským přízvukem.[1] 15

32 3. Metodiky řízení projektu Historie PMBOK[1] Historie PMBOK oficiálně začíná 9. října 1969 v Atlantě 10, kdy je založena organizace Project Management Institute (PMI). Tato organizace začíná zkoumat problematiku a rozvíjet vlastní metodiku projektového řízení. Od roku 1984 pořádá certifikační zkoušky na certifkát Project Management Professional (PMP). První souhrn jejich metodiky s názvem A guide to the Project Management Body of Knowledge byl vytvořen v roce 1986, v roce 1991 se stává normou ANSI. Od té doby byla metodika několikrát inovována. Nejnovější (3. verze) byla publikována v roce Metodika PMBOK je dnes mezinárodně uznávanou normou IEEE Std Náplň PMBOK[2] Metodika PMBOK člení řízení projektu na pět skupin procesů projektového řízení a devět znalostních oblastí. Metodika obsahuje celkem 454 klíčových definic. Skupiny procesů jsou definovány tyto: Zahájení (Initiating) - rozpoznání potřeby projektu a jeho vznik. Plánování (Planning) - vytvoření a udržování realizačního plánu projektu. Vykonávání (Executing) - koordinace lidí a dalších zdrojů k provedení plánu. Dohled a kontrola (Monitoring and Controlling) - kontrola dosažení cílů a případné zásahy vedoucí k nápravě odchylek. Zakončení (Closing) - předání výsledků projektu a formální ukončení. Tyto skupiny obsahují procesy, které lze přiřadit k jednotlivým znalostním oblastem: Řízení integrace (Project Integration Management) - procesy zajišťující správnou koordinaci různých částí projektu. Řízení rozsahu (Project Scope Management) - procesy zajišťující kompletnost projektu a to, že projekt řeší pouze to, co řešit má. Řízení času (Project Time Management) - procesy související se včasným dosažením cíle projektu. 10 hlavní město státu Georgia v USA; roku 1996 hostilo olympijské hry 16

33 3.1. Tradiční metodiky Řízení nákladů (Project Cost Management) - procesy zajišťující nepřekročení přiděleného rozpočtu. Řízení kvality (Project Quality Management) - procesy, které zajistí, že výsledný produkt splní cíle projektu. Řízení lidských zdrojů (Project Human Resource Management) - procesy řídící efektivní využití lidí v projektu. Řízení komunikace (Project Communications Management) - procesy zajišťující efektivní koloběh informací v projektu. Řízení rizik (Project Risk Management) - procesy spojené s identifikací, analýzou a řešením rizik. Řízení zásobování (Project Procurement Management) - procesy spojené se zajištěním zboží a služeb zvenčí k potřebě projektu. Do těchto skupin a znalostních oblastí je rozřazeno celkem 44 procesů projektového řízení, které jsou definovány pomocí celekm 592 různých vstupů, výstupů, nástrojů a technik Shrnutí PMBOK Metodika PMBOK je orientována na projektové manažery, obsahuje konkrétní techniky (nejlepší praxe) řízení projektů i soft skills. Je znát americký přístup - nikoliv normativní, ale návodný. Metodika nezavádí žádnou řídící strukturu ani provázaný model řízení. Díky tomu lze jednotlivé části metodiky aplikovat nezávisle na sobě, což se děje např. i při utváření norem ISO týkajících se řízení různých procesů PRINCE2 Metodika PRINCE2 11 zavádí procesní strukturu projektového řízení. Metodika je normalizována a používána (nejen) jako oficiální metodika projektů spadajících pod vládu Velké Británie Historie PRINCE2[3] PRINCE2 vychází z dřívějších metodik PROMPTII a PRINCE. Původní metodiku PRINCE vytvořil v roce 1989 ústřední britský úřad pro počítače a telekomunikaci 12 jako vládní standard pro řízení projektů informačních systémů. 11 PRojects IN Controlled Environments 12 Central Computer and Telecommunications Agency (CCTA) 17

34 3. Metodiky řízení projektu Knowledge Area Process Groups Initiating Planning Executing Controlling Closing 4. Project Integration Management 4.1 Project Plan Development 4.2 Project Plan Execution 4.3 Integrated Change Control 5. Project Scope Management 5.1 Initiation 5.2 Scope Planning 5.3 Scope Definition 5.4 Scope Verification 5.5 Scope Change Control 6. Project Time Management 6.1 Activity Definition 6.2 Activity Sequencing 6.3 Activity Duration Estimating 6.4 Schedule Development 6.5 Schedule Control 7. Project Cost Management 7.1 Resource Planning 7.2 Cost Estimating 7.3 Cost Budgeting 7.4 Cost Control 8. Project Quality Management 8.1 Quality Planning 8.2 Quality Assurance 8.3 Quality Control 9. Project Human Resource Management 9.1 Organizational Planning 9.2 Staff Acquistion 9.3 Team Development 10. Project Communications Management 10.1 Communications Planning 10.2 Information Distribution 10.3 Performance Reporting 10.4 Administrative Closure 11. Project Project Management 11.1 Risk Management Planning 11.2 Risk Identification 11.3 Qualitative Risk Analysis 11.4 Quantitative Risk Analysis 11.5 Risk Response Planning 11.6 Risk Monitoring and Control 12. Project Procurement Management 12.1 Procurement Planning 12.2 Solicitation Planning 12.3 Solicitation 12.4 Source Selection 12.5 Contract Administration 12.6 Contract Closeout Tabulka 3.1: Procesy PMBOK zasazené do skupin a znalostních oblastí[1] 18

35 3.1. Tradiční metodiky Později se metodika PRINCE začala používat i v dalších odvětvích a v roce 1996 vzniká obecnější PRINCE2. Roku 2009 vyšla revidovaná verze PRINCE2:2009 Refresh. Metodiku zastřešuje britský úřad OGC 13, který je znám např. i manažerským standardem ITIL Obsah PRINCE2[4] Metodika zavádí tříúrovňovou organizační strukturu projektu: Projektová rada (Project Board), která dlí nad úspěchem projektu. Kontroluje jeho jednotlivé fáze, směřuje jej, stanovuje základní plán a požadavky, které vykomunikuje se zákazníkem. Nad projektovou radou dlí programový management společnosti, který není součástí projektového řízení, ale je organizačně nadřazen všem projektům ve firmě a může zakládat nové projekty. Projektový manažer (Project Manager) je zodpovědný za úspěch projektu, spravuje přidělené prostředky, udílí a kontroluje úkoly jednotlivých projektových týmů. Je denně v kontaktu s týmovými manažery a zodpovídá se projektové radě. Týmový manažer (Team Manager) řídí svůj tým vykonávající zadaný úkol a zodpovídá se projektovému manažerovi. U menších projektů se týmový manažer vynechává a projektovému manažerovi jsou přímo podřízeni jednotliví členové týmu. Každý projekt podle PRINCE2 se skládá z těchto fází: Předprojektová fáze (Pre-project phase). V této velmi krátké fázi je identifikována potřeba projektu. Vzniká projektová rada a je vypracována úvodní studie. Zahájení (Initiation). V této fázi je posouzena a rozpracována úvodní studie a vzniká plán projektu. Provádění (Stages - Execution). Tato fáze se může (podle plánu) libovolně opakovat a probíhá v ní gró projektu - jsou vykonávány úkoly související přímo s tvorbou produktu. Projektový manažer průběžně dohlíží a řídí realizační týmy. Na konci každé iterace této fáze se provádí zhodnocení postupu a upravuje se s projektovou radou směřování projektu. Zakončení (Close). Projektový manažer sepíše pro projektovou radu závěrečnou zprávu a shnre zkušenosti (Lessons report). Tyto dokumenty jsou radou schváleny a projekt je ukončen. 13 Office of Government Commerce 19

36 3. Metodiky řízení projektu Jednotlivé fáze jsou rozděleny do mnoha akcí a dokumentů, které jsou podrobně popsány. Jejich podrobná replikace je nad rámec rešeršní části této práce Shrnutí PRINCE2 Metodika PRINCE2 je zaměřena na všechny účastníky projektu. Pevně vymezuje role, řídící strukturu, návaznost procesů i obsahy všech projektových dokumentů. Oproti metodice PMBOK neobsahuje konkrétní techniky řízení, odvolává se na ně. PRINCE2 představuje evropský přístup k formalizaci řízení projektu - normativní. Jednotlivé části metodiky jsou spolu provázány, nelze je chápat ani implementovat samostatně. 3.2 Agilní metodiky Agilní metodiky vyšly z projektové praxe 14, kde se ukazuje, že příliš byrokratické řízení projektu může zdržovat 15, špatně učiněný odhad délky řešení některého úkolu může ohrozit včasné naplnění cíle a oddělená komunikace jednotlivých částí týmu nemusí včas zachytit případné problémy. Typickými rysy agilních metodik jsou častá a pravidelná komunikace, sdílení úkolů, informovanost všech členů týmu o všem, upozaděná formálnost dokumentů a iterativní vývojový cyklus. Agilní metodiky jsou vhodné pro menší projekty a pro projekty, které se často mění. Stabilní projekty nevyužijí specifik agilních metodik a u větších projektů je formálnost potřebnější (celý projekt není únosně uchopitelný napříč celým týmem) Scrum Metodika Scrum je agilní metodika, či spíše rámec, který umožňuje aplikovat různé procesy a techniky. Slovy jeho autorů je to styl řízení, ke kterému přirozeně tíhneme, když něco nevyjde a jsme přitlačeni ke zdi - tak proč to tak nedělat rovnou a cíleně?[5] Jádrem Scrumu jsou tzv. sprinty; projekt je členěn do poměrně krátkých časových úseků (maximálně týdny) a - protože se přání zákazníka rádo mění - neexistuje komplexní plánování. Krátké časové úseky dovolují rychle reagovat na změny a problémy, které nastanou. 14 zejména v oblasti vývoje softwaru 15 a zatěžovat členy týmu neproduktivní činností 20

37 3.2. Agilní metodiky Basic Concepts Key Elements of Prince 2 PRINCE2 The PRINCE2 Process Model Corporate or Programme Management Initiation Notification Project Notification End Stage Report Next Stage Plan or Exception Plan Closure Notification Direction Corp.. Starting up up a a Project (SU) Initiate a Project Project Brief + Plan Auth. To Initiate Project Init Docs Deliver Project? Authorize Project Approved PID Auth. Auth.next 2 Proceed stage Exception Report Highlight Reports Guidance & advise Premature Close Closure Recommend. End Project Report FAR, Lessons Rpt Draft Closure Notificat. project mandate Directing a Project (DP) Authorize initiation Authorize the project Authorize a Stage or Exception Plan (SB) Managing a Stage Boundary Give ad hoc direction Pre-Project Initiating a Project (IP) Controlling a Stage (CS) New WP -- Once during project -- Once per stage -- Many times during stage -- Once per Work Package Work Package Work Package Accept a WP Work Package Completed WP Notification Mgmt Prod -- Notification/Authorization -- Management Product Managing Product Delivery (MP) Based on OGC PRINCE2 material. Reproduced under license from OGC Auth. project closure Closing a project (CP) MP Outputs Checkpoint Reports Team Plans Quality Register Delivery Management Obrázek 3.1: Procesní schéma metodiky PRINCE2[4] 21

38 3. Metodiky řízení projektu Původ a historie metodiky Scrum Termín scrum pochází z rugby, kde se používá pro znovuzahájení hry po menším přerušení. 16 Průběh projektu podle metodiky Scrum vpravdě připomíná zápas rugby - tým postupuje kupředu jako jednolitý sehraný celek, yard za yardem, přičemž míč (symbolizující stav projektu) poskakuje střídavě dozadu a dopředu. Poprvé byl rugbystický přístup k projektovému řízení popsán v roce 1986, kdy Hirotaka Takeuči a Ikudžiro Nonaka představili novou metodiku zvýšující rychlost a flexibilitu. Základem byla praktická zkušenost různých podniků v automobilovém, polygrafickém a tiskařském průmyslu. Originální metodiku aplikoval Ken Schwaber ve své firmě v 90. letech 20. století. Ten během dalších let s dalšími lidmi metodiku pojmenoval, rozpracoval a utřídil. První paper s pojmenovanou metodikou byl publikován v roce 1995 a své jasnější obrysy získala v roce 2001, kdy byla vydána kniha Agile Software Development with Scrum Obsah metodiky Scrum[5] Rámec Scrumu sestává ze skupiny Scrum týmů (a s nimi spojených rolí), časových rámců, artefaktů a pravidel spojujícími jednotlivé části metodiky. Scrum týmy jsou sestaveny tak, aby pracovaly optimálně a flexibilně. Každý Scrum tým obsahuje tři hlavní role 17 : ScrumMaster, který je zodpovědný za pochopení a dodržování procesu týmem, Vlastník produktu, který je zodpovědný za dosažení kýženého výsledku (má na starosti produktový backlog), Tým skládající se z vývojářů s potřebnými dovednostmi, který realizuje práci. Srdcem Scrumu jsou tzv. sprinty, které zapouzdřují iterace vývoje. Sprint je periodicky se opakující časový rámec, jehož délka je v průběhu projektu vždy stejná a pohybuje se mezi jedním týdnem a jedním měsícem. V průběhu sprintu se mění pouze stav prací. Lidské zdroje, metriky a požadavky zůstávají neměnné. Sprint je ohraničen dvěma schůzkami: Plánovací schůzka, na níž si Scrum tým vytyčí cíle a průběh iterace. V první polovině schůzky se řeší, které funkcionality produktu se budou v nadcházející iteraci implementovat (seznam funkcionalit je obsažen 16 V některých textech je scrum považován za zkratku, což může být důsledkem psaní velkými písmeny v titulu raných prací Kena Schwabera. 17 Vykonavatelům těchto ústředních rolí říká Scrum prasata (pigs). 22

39 3.2. Agilní metodiky v produktovém backlogu). V druhé polovině schůzky se řeší, jak bude vytyčených cílů dosaženo. Pro měsíční sprint trvá tato schůzka 8 hodin (u kratších sprintů poměrně méně). Hodnotící schůzka, na níž Scrum tým rozebere se zájmovými osobami dosažené cíle (typicky předvedením), aktualizuje produktový backlog (včetně priorit a odhadů dokončení), zhodnotí zkušenosti z proběhlé iterace, aktualizuje výhled do budoucnosti a případně upraví některé parametry projektu. Pro měsíční sprint trvá tato schůzka 4 hodiny. V průběhu sprintu se tým 15 minut denně schází (daily scrum). Každý člen týmu popíše, co dokončil, co hodlá do dalšího daily scrumu dodělat a co mu v tom případně brání. Účelem je komunikace, zvýšení informovanosti, vzájemná pomoc a identifikace a odstranění překážek ve vývoji. Mezi každými dvěma sprinty probíhají ještě tzv. retrospektivní schůze (3 hodiny u měsíčních sprintů), na nichž Scrum master ladí s týmem pracovní postupy a povzbuzuje jej k vyšší efektivitě. Artefakty představují seznamy úkolů a funkčností (produktový backlog, sprint backlog) a odhady zbývající práce (release burndown, sprint burndown). Metodika Scrum obsahuje i další pomocné role 18, jejichž širší popis by byl již nad rámec této práce Shrnutí Scrumu Scrum je metodickým rámcem pro iterativní vývoj produktu. Nestanovuje konkrétní techniky a lze jej snadno rozšiřovat a doplňovat o prvky jiných metodik podle konkrétní potřeby Kanban Kanban 19 je just-in-time agilní metodika založená na tocích úkolů a slibující lepší využití času vývojářů Historie Kanbanu[6] Metodiku Kanban pro vývoj softwaru přizpůsobil v roce 2007 David J. Anderson. Základem je již dříve známý systém štíhlé výroby Kanban, který roku 1953 zavedla japonská automobilka Toyota do svého výrobního procesu. Toyota si u obchodů všimla, že drží a zpracovávají pouze tolik zboží, kolik předpokládají, že prodají. Obchody tak reflektují poptávku a jejich zaměstnanci vykonávají nezbytně nutné množství práce. Toyota se rozhodla aplikovat tento systém na provoz své továrny, kdy každá část provozu je obchod, který zpracovává 18 slepice (chickens) 19 (z jap.) vývěsní štít 23

40 3. Metodiky řízení projektu pouze nezbytně nutné množství zboží, jež je na výstupu poptáváno. Autorem systému Kanban je manažer Toyoty Taiichi Ohno Náplň metodiky Kanban[7] Metodika Kanban má pět klíčových vlastností: Vizualizace pracovního toku. Pracovní tok 20 bývá často schován v různých informačních systémech. Jeho zobrazení je základem pochopení (a posléze i správného řízení) prováděné práce. Pracovní tok je zobrazen na tabuli/nástěnce pomocí kartiček (představující určitou pracovní položku či funkcionalitu) rozřazených do sloupců (fáze, do níž práce pokročila). (Viz obr. 3.2) Minimalizace rozpracovaných věcí. Každá část pracovního procesu zpracovává omezené množství požadovaných funkcionalit. To umožňuje lépe soustředit vývoj a také zajistit roznoměrné rozložení práce (žádné pracoviště není přetěžováno). Další funkcionality lze na daném pracovišti zpracovávat jen tehdy, když navazující pracoviště naskladní některou zpracovanou. (Viz obr. 3.2) Řízení pracovního toku. Pracovní tok je potřeba sledovat a měřit a v případě potřeby provádět korekce a změny parametrů k zajištění plynulosti. Explicitní procesní politika. Každý proces by měl být explicitně popsán, aby mohl být rozumným způsobem diskutován a vylepšován. Vylepšovat společně - pomocí modelů a vědeckých metod. Díky explicitnímu popisu procesů, sledování pracovního toku a porozumění příslušných teorií o práci, tocích a rizicích může tým pochopit projekt do hloubky a navrhnout, matematicky zdůvodnit a diskutovat různá vylepšení Shrnutí metodiky Kanban Kanban připomíná řeku, po níž se plaví čluny (představující jednotlivé části cílového produktu) jeden za druhým. Jiné metodiky na této řece budují přehrady, v nichž se čluny hromadí, nebo posílají přepadové oddíly člunů, které obtížně proplouvají najednou zúženým korytem. Není to špatné, ale stavba přehrad nebo natěsnání velkého množství člunů do koryta řeky znamenají organizační námahu, jejíž výsledek nemusí být lepší. 20 Dovolil jsem si přeložit anglický termín workflow. Znamená to postup, pokrok v práci, průběh zpracování. 24

41 3.2. Agilní metodiky Obrázek 3.2: Příklad vizualizace procesního toku v Kanbanu.[8] Popis: Čísla u jednotlivých etap představují limity zpracovávaných požadavků. Ty jsou znázorněny většími bílými štítky. Menší štítky představují přidružené úkoly a lidé na obrázku je řeší. Jednotlivé požadavky mají uveden datum přidání a požadavek s hvězdičkou má vyšší prioritu. Jsou věci, které tato metodika neřeší - konkrétní postupy, techniky, organizační strukturu, komunikaci se zákazníkem Kanban v podstatě obsahuje pouze několik jednoduchých procesních pravidel, podle nichž se realizační tým postupně seřídí jako skalární pipeline počítačového procesoru. Metodika Kanban je v IT poměrně nová a bývá hodně srovnávána s metodikou Scrum:[7] Scrum předepisuje formální dokumenty, jako jsou burndown grafy nebo odhady dokončení. Kanban nic takového nenařizuje. Přesto se dle mého názoru hodí nějaké odhady dělat, aby šlo upravovat parametry toku potřebám zákazníka. Kanban předepisuje pouze vizualizaci pracovního toku. Kanban nezná iterační cykly (ale může je mít). Jednotlivé požadavky jsou zapracovávány průběžně jeden po druhém (resp. po velmi malých dávkách); Scrum musí zapracování požadavků naplánovat před zahájením sprintu a ani jeho průběh nemusí připomínat Kanban. (Mezi sprinty je řeka prázdná a čluny tvoří přepadové oddíly.) Ve Scrumu se musí požadavek vejít do jedné iterace, resp. musí se rozdělit, aby se vešel. V Kanbanu může být požadavek libovolně velký, jen popluje řekou pomaleji (a bude obeplouván menšími). Nový požadavek může Kanban zpracovávat kdykoliv (pokud má kapacity), Scrum jej může zařadit ke zpracování pouze při plánování sprintu. 25