Kde se vzal agilní project management?

Agilní metody pro řízení projektů se etablovaly zejména v souvislosti se stoupající komplexitou výstupů projektů. Tím také rapidně vzrostla pravděpodobnost a velikost možného odchýlení konečného výsledku od původního očekávání. Tato praxe vedla vedoucí projektů k myšlence minimalizovat čas mezi vznikem konkrétního očekávání zákazníka a produktem, který je mu dodán.

Druhý faktor stojící za agilním boomem, který se v současnosti silně projevuje, představuje nejistota. Ta nutí zadavatele k čím dál častějším kontrolám parciálních výstupů, čímž se posiluje důvěra, že projekt jde správným směrem. A to i za cenu zvýšených nákladů na projekt. Současnost zkrátka chyby neodpouští.

Konečně poslední z faktorů, které výrazně zpopularizovaly agilní metody zejména v oblasti vývoje softwaru, představuje efekt srovnatelný s úsporami z rozsahu známými z ekonomie. Sdružování podobné práce představuje velmi elegantní způsob, jak zefektivnit svou činnost. Snížení množství „přepínání“ mezi různými typy aktivit a zvýšení bloků stejné nebo obdobné práce vede ke zvýšení kvality a množství výkonu.

Na čem agilní management stojí?

Pokud ve své organizaci pozorujete některou z výše uvedených příčin, pak logicky vyvstává otázka, zda tradiční vodopád nenahradit agilním přístupem. V kontextu tohoto dilematu je dobré vědět, že také zavedení agilního přístupu má své požadavky. Zavést musíte minimálně následující trojici pilířů agilního project managementu:

• Backlog idejí/požadavků – backlog představuje konsolidovaný seznam veškerých požadavků týkajících se činnosti firmy či oddělení. Je vhodné požadavky zachytávat pomocí standardizovaného formuláře. Navazující prioritizaci, která oddělí požadavky na realizaci od idejí, je třeba provádět v pravidelných termínech. Z pohledu podpůrných nástrojů můžete použít jak specializované systémy určené výhradně pro řízení požadavků, tak například i firemní intranet.
• Sprint – z celkového seznamu oprioritizovaných požadavků dochází k definici sprintů. Sprint je typicky vymezen pevně v délce jednoho až čtyř týdnů, ve kterém dochází k realizaci zahrnutých požadavků. Jeho výstupem je prototyp, který je diskutován se zadavatelem projektu a na základě jeho ověření dochází k redefinici či reprioritizaci požadavků, které se řadí do dalšího sprintu. Při volbě optimálního podpůrného nástroje musíte zohlednit skutečnost, nakolik jsou vaše projekty čistě agilní, a nakolik „hybridní“. Jinými slovy, jak velkou část projektu realizujete agilně a jak velkou vodopádově. U hybridů je opět namístě zvážit standardizované nástroje pro podporu řízení projektů, jako například MS Project.
• Scrum meeting – realizace jednotlivých sprintů je řízena prostřednictvím scrum meetingů. Tyto schůzky se vyskytují v průběhu každého sprintu v několika variantách. Na začátku probíhá plánovací mítink, kde dochází k vymezení požadavků z backlogu do daného sprintu. Následně běží krátké denní mítinky, kde se schází celý tým a prezentují se výstupy z předchozího dne, zjištěné problémy a plán na další den. Výstupní scrum meeting pak obsahuje prezentaci prototypu, jehož bylo dosaženo. Klíčovým nástrojem pro podporu scrum meetingů je tzv. burn-down report, který srovnává plánovanou a skutečnou práci zbývající do konce sprintu.
   

Obr. 1: Sprint a jeho Burn-down report v MS Project 2013

Kde jsou rizika?

Představa, že pokud se s využitím projektového řízení nedaří dosáhnout požadovaných cílů, tak spása přijde s přechodem na agilní řízení, není správná. Z hlediska vlastního řízení jde o jiný přístup k dosažení požadovaného cíle. Avšak z pohledu preciznosti dodržování určitých pravidel, fungující vzájemné komunikace a celkové kázně při organizaci a realizaci pracovních úkolů je agilní management stejně náročnou disciplínou jako projektové řízení.

Abyste tedy mohli v maximální možné míře těžit z pozitiv agilního světa a zároveň se vyhnuli souvisejícím rizikům, je třeba jasně vymezit hranice, za které již agilní přístup nepustíte:

• Pozor na konflikt agilního přístupu se smluvní dokumentací. Pokud smluvní dokumentace projektu obsahuje jasně vymezené subvýstupy a termíny jejich předání a akceptace, pak tato informace nutně musí propadnout i do agilního světa. Je tedy třeba hlídat nejen realizaci jednotlivých požadavků, ale i skupiny, které tvoří subdodávky vymezené smlouvou.
• Prototypy, které zadavatelům předvádíte, se nemusí vždy setkat s jejich pochopením. To v konečném důsledku znamená, že zadavatel nebude schopen potvrdit cestu, po které jste se vydali. Následné rozbití již uzavřených sprintů pak vytváří nemalý chaos.
• Pokud se na projektech řízených agilně podílí velké týmy, pak hrozí, že denní scrum meetingy zaberou ve finále více času, než představuje úsilí uspořené při zhromadňování práce. Tímto dochází k devalvaci efektu plynoucího z nárůstu rozsahu podobné práce.
• Evidence odvedené práce bývá v praxi mnohdy zjednodušena na úroveň typu práce (vývoj, analýza, support) a není vztažena k jednotlivým požadavkům. Pokud to tak není, pak neexistuje vazba mezi odvedenou prací, požadavkem a produktem, což v konečném důsledku znemožňuje hodnocení efektivity výstupu projektu jako celku.

Jak rizikům předcházet?

První a zásadní rada zní: varujte se těch, kteří přichází s návrhem na přechod na agilní řízení bez propracovaného návrhu celkového procesu, rolí a odpovědností. Agilně rozhodně neznamená chaoticky s očekáváním náhodného výsledku. Agilně znamená cíleně, po malých krocích, rychle a flexibilně za dodržování přísné pracovní kázně:

• Z pohledu dodávky jako celku musíte dále vymezit jasné parametry dodávek, a to zejména z pohledu termínů a nákladů na realizaci. Náklady v sobě musí obsahovat také vymezení práce, jejíž objem pochopitelně není nekonečný. Kvalitativní rovina, tedy celkový objem vlastností, může zůstat definovaný volněji, pakliže to zadavatel projektu formálně akceptuje.
• Jednotlivé požadavky v backlogu musí mít jasnou identifikaci dodávky, se kterou souvisí, a na centrální úrovni je třeba hlídat plnění dodávek. Tento hlavní plán drží typicky manažer oddělení či úseku, který zodpovídá ostatním úsekům za včasnost dodávek. Tento plán představuje významný prvek prioritizace požadavků, a v konečném důsledku ovlivňuje jejich nasazování do sprintů.
• Pokud vzniká tlak na velký tým přesahující dvacet členů, je vhodné redefinovat rozsah jednotlivých sprintů – tedy zkrátit sprint tak, aby členů bylo méně. Tím se snižuje tlak na administrativu.
• Vykazování práce musí být vztaženo ke konkrétnímu požadavku tak, aby bylo možné hodnotit efektivitu jednotlivých požadavků a následně na úrovni hlavního plánu i efektivitu celých dodávek.

Drahoslav Dvořák, Martin Mareček