facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přihlášení SystemNEWSPřehledy
 
Tematické seriály

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 
Nové!

RPA - automatizace procesů

Softwaroví roboti automatizují obchodní procesy.

články >>

 
Nové!

IoT – internet věcí

Internet věcí a jeho uplatnění napříč obory.

články >>

 
Nové!

VR – virtuální realita

Praktické využití virtuální reality ve službách i podnikových aplikacích.

články >>

 
Nové!

Bankovní identita (BankID)

K službám eGovernmentu přímo z internetového bankovnictví.

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
 
Partneři webu
IT SYSTEMS 7-8/2013 , Projektové řízení

Agilní project management

Příležitost, nebo hrozba?



MicrosoftAgilní project management představuje zcela nový trend v projektovém řízení, ke kterému se upíná nejedna organizace. Být agilní znamená být flexibilní vůči zadavateli, týmu a dalším podílníkům projektu a také vůči výstupu projektu. Mějte však na paměti, že agilita neznamená neomezenou volnost. I ten nejagilnější systém řízení musí mít jasná pravidla. Hranice mezi agilitou a nepořádkem je v praxi mnohdy velice tenká, a tak nezbývá, než i agilitu držet na uzdě.


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
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

O autorech

Ing. Drahoslav Dvořák, Ph.D., v současnosti řídí divizi Enterprise Project Management ve společnosti WBI Systems a.s. Své dlouholeté zkušenosti sdílí v řadě odborných publikací, například Řízení portfolia projektů – nejlepší praktiky Portfolio managementu. Dále přednáší řízení projektů a podnikovou informatiku na Vysoké škole Škody Auto v Mladé Boleslavi. Je jediným specialistou v České republice s certifikací Microsoft Most Valuable Professional pro oblast Project.

Ing. Martin Mareček, PMP, v současné době pracuje ve společnosti ČEZ, a.s., v útvaru řízení zahraničních majetkových účastí, kde odpovídá za oblasti asset managementu a minimalizace distribučních ztrát. V minulosti působil v ČSA na pozici manažera projektové kanceláře. Řídil i rozsáhlé projekty zaměřené na budování a rozvoj ICT infrastruktury. Je členem výboru české komory PMI, kde odpovídá za rozvojový program. Je držitelem mezinárodní certifikace Project Management Professional.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.