Komparativní vyhodnocení
Získali jsme šest parametrů s poměrně solidní vypovídací schopností. Účelem této komparace není vytvářet imaginární metriku měření fenoménů, které ani přesně změřit nelze, ale vyhodnotit na základě takto izolovaných hledisek a toho, co zde bylo řečeno, přednosti a slabiny obou modelů. Rozhodl jsem se proto do níže uvedené tabulky zapisovat hodnocení jen formou kladného (+) nebo záporného (-) znaménka a toto své hodnocení krátce okomentovat.Záporné hodnotící znaménko v žádném případě neznamená, že si daný přístup nedokáže v příslušném parametru s problémem poradit, nýbrž pouze nevýhodu, kterou musí řešit obtížněji.
Parametr komparace Tradiční Agilní Komentář P1-Zohledněná očekávání podílníků + - Jsou situace, kdy do rolí agilního týmu jen těžko obsadíme všechny klíčové podílníky projektu, čímž se ‚agilní‘ efekt výrazně ztrácí. Tyto požadavky a očekávání nelze přitom přehlížet. Tradiční přístup s takovou situací od začátku počítá a má pro ni nástroje. P2-Předvídatelnost vývoje projektu + - Průběžně aktualizovaný časový rozvrh prací umožňuje zorientovat se kdykoliv v situaci na projektu a získat odhad jeho stavu i pro určitý termín v budoucnu. Tento nástroj rovněž přehledně znázorňuje souvislosti a posloupnosti projektových aktivit, což umožňuje vedení projektu činit poměrně snadno komplikovaná rozhodnutí a vyhodnotit okamžitě jejich dopady v rámci integrovaného řízení projektu. Agilní tým je do značné míry závislý na informacích, které drží jeho jednotliví členové ve svých hlavách. Rozličné aspekty komplexních rozhodnutí mohou být v daný okamžik obtížně odhadnutelné, pokud neproběhne nejdříve týmová diskuse. P3-Postavení a odpovědnost projektového manažera + - Postavení, odpovědnost a nároky na manažera v agilním týmu jsou výrazně slabší, než je tomu u tradičních metodik. Tradiční vedoucí projektu musí v zájmu zajištění kontroly nad komplexními projekty velmi dobře zvládat aplikaci obsáhlého portfolia nástrojů a technik, disponovat reálnou schopností vést tým a sám přímo odpovídá za jeho výkonnost. P4-Flexibilita plánování - + Lehkost a hbitost mechanismů plánování v agilním projektovém řízení je autentickou odpovědí na stále se zrychlující tempo doby a zvyšující se nároky (a to nikoliv pouze v oblasti SW vývoje). Řízení změn je v tradičních metodikách ve srovnání s těmi agilními skutečně poněkud rigidní, i když i zde lze tyto mechanismy zrychlit a zjednodušit vhodným nastavením už na úrovni plánu řízení projektu. U rozsáhlých či bezpečnostně kritických projektů je však formálnost integrovaného změnového řízení nezbytností. P5-Míra zapojení zákazníka - + Skutečnost, že se zákazník stává aktivním hybatelem realizačního týmu, je zřejmě nejdůležitějším přínosem agilního pojetí řízení projektů. Zákazník je soustavně obeznámen s výstupy a směřování projektu, což vede k jeho ztotožnění se s produktem již během jeho vzniku a předchází se nepříjemnému překvapení či zklamání. Právě zklamání při velkém třesku představení finálního produktu v tradičních projektových modelech bývá nezřídka Achillovou patou tradičně řízených projektů. Podmínkou úspěchu agilního týmu je však nominace kompetentních zástupců zákazníka, kteří disponují poměrně vysokou mírou delegovaných pravomocí od vlastního managementu. P6-Míra kontroly zákazníka - + Pravomoc a flexibilita, kterou zákazník získává svou účastí v agilním týmu a volnou působností nad rozsahem projektu, jsou nejen komfortní a motivující, ale rovněž velmi zavazující. Pokud zákazník pochopí pravidlo zafixovaného rozpočtu i času a přistoupí na ně, vzniká skutečně výjimečný automatismus kontroly projektu, který mohou tradiční koncepty jen závidět. Aby však fungoval, musí být zajištěna skutečně stabilní a spolehlivá výkonnost agilního týmu v průběhu celého projektu. Z vlastní zkušenosti mohu říci, že čím vyšší a vyrovnanější jsou odborné kvality a profesionální úroveň jeho členů, tím více se dostaví onen ‚agilní efekt‘ funkčního produktu a spokojeného zákazníka. Těchto předpokladů se zpravidla u nově zformovaného týmu obtížně dosahuje. Je tedy značnou výhodou, pokud byl již dříve zformován alespoň vývojový tým, a to buď v předchozím projektu, nebo etapě.
Poprvé jsem agilní PM nasadil při vývoji dílčí, nicméně klíčové, komponenty strategicky důležitého informačního systému jedné nadnárodní společnosti. Zákazník získal po předchozích ne zcela dobrých zkušenostech a nemilých překvapeních přesvědčení, že bude lepší, když se bude sám ve vývoji ‚své‘ aplikace angažovat, v čemž jsem ho rozhodně podpořil. Po poradě s interním vývojovým týmem jsme se rozhodli zvolit postupy agilní metodiky Test Driven Development (TDD), která zároveň plnila funkci tradičních procesů zajištění kvality a verifikace rozsahu, což bylo velmi praktické. Bez některých tradičních metodických nástrojů jsme se však stejně neobešli. Bylo totiž mnohem snazší držet se tradiční metodiky, než hledat striktně ‚agilní řešení‘. Časový rozvrh prací jsme potřebovali pro práci jak my sami na straně dodavatele, tak i zákazník. Stal se pro nás nezbytností například i při plánování uvolňování výstupů.
Z naší tradiční podnikové metodiky jsme si tedy vzali pouze nezbytné nástroje a postupy, které jsme následně obohatili o přednosti agilního řízení a agilního týmu. Výsledkem byla kvalitní aplikace, se kterou byl zákazník spokojen v témže okamžiku, kdy byla dokončena. Produkt byl dodán dokonce ještě dříve, než bylo původně plánováno a za nižších nákladů.
Jak z hodnotící tabulky, tak i z uvedené příkladu tedy můžeme učinit následující závěr:
Vycházíme-li z předpokladu univerzálnosti nasazení v praxi, nelze tvrdit, že tradiční přístup je lepší, než agilní a naopak. Oba modely si nejsou alternativou, ale spíše komplementem, eliminujícím slabiny jednoho či druhého konceptu v různých typech projektů. Věřím, že toto se podařilo v této krátké komparaci dostatečně prokázat.