Což je správná metodika projektového řízení

Než se pustíme do přímé odpovědi na otázku položenou v nadpisu, je klíčové si objasnit, jakého konečného cíle chcete svým projektem dosáhnout.

Jak si představujete finální podobu produktu za měsíc, půl roku, nebo dokonce rok? Popište to. Tento pohled do budoucna vám pomůže nastavit realistická očekávání ohledně předvídatelnosti, flexibility, rychlosti uvedení na trh, schopnosti agilně reagovat na změny a také vám pomůže s fixací nákladů v čase.

Dnes se už zřizování projektů metodou vodopádu může zdát jako zastaralý koncept. Zejména, pokud máme nespočet důkazů o tom, že agilní přístup je nezbytný pro rychlou reakci na dynamické změny trhu. Pokud je však vaším cílem za rok dodat produkt s jasně definovanými a omezenými funkcemi a váš tým nemá žádné zkušenosti s agilními metodami, může být konzervativní vodopádový přístup stále vhodnou volbou.

Ne každá situace je takto jednoznačná. Pojďme se tedy podívat, jak můžete lépe posoudit, která metodika je pro váš projekt nejvhodnější.

Jak funguje vodopádový model?

Místo toho, abychom se zdržovali definicemi, které jsou notoricky známé již desítky let, podívejme se na typický průběh vodopádového projektu:

• Nejprve si důkladně naplánujete, jaký má být finální produkt a jaké jsou odhadované náklady.
• Následuje fáze sběru požadavků. V detailu se diskutuje o všech aspektech budoucího produktu, vznesou se námitky, ověří se detaily, dojde k odsouhlasení a nakonec se požadavky potvrdí.
• Následuje odhad nákladů a potvrzení rozpočtu.
• Poté se navrhne řešení. Probíhá několik setkání se zúčastněnými stranami, vytváří se různé dokumenty, které se nechají zkontrolovat. Následuje potvrzení a schválení finálního funkčního a technického návrhu.
• V další fázi se na základě návrhu implementuje řešení. Zde dochází k vývoji kompletního finálního produktu.
• Následuje testovací fáze, která zahrnuje různé druhy testů: unit testy, systémové testy, funkční testy, integrační testy, výkonnostní testy, regresní testy, uživatelské akceptační testy a mnoho dalších. Veškerá testovací dokumentace se předkládá zúčastněným stranám ke kontrole a schválení.
• Následuje nasazení řešení do produkčního prostředí. Cíloví uživatelé začínají používat finální produkt.
• Na závěr se plánuje fáze podpory, během které vývojový tým odstraňuje případné chyby.

Celý tento proces může trvat měsíce, ale i roky. Je zřejmé, že uživatelé uvidí výsledky až na konci tohoto procesu. Po dlouhém čekání přichází moment pravdy (nebo zklamání).

Pokud se během tohoto dlouhého procesu něco změní a finální produkt by měl vypadat jinak, je nutné podat žádost o změnu. Návrh se musí znovu projednat, přepracovat a znovu schválit. Každá změna tak prodlužuje celkový časový harmonogram projektu. Jakákoli změna vyžaduje restart celého procesu od začátku.

Na druhou stranu, tento přístup nabízí pevně stanovené fáze, fixní rozpočet pro každou fázi a pevný časový plán. I když na první výsledek musíte čekat dlouho, pokud jsou šance na změny minimální, může být tento přístup výhodnější.

Jak funguje agilní model?

Níže se podíváme na typický průběh projektu v agilním prostředí:

• Nejprve se definuje obchodní vize finálního produktu. Jde o obecný popis, ale s jasnými obchodními požadavky a očekáváními, co má produkt splňovat pro uživatele.
• Následuje vytvoření seznamu funkčních epických příběhů a technických úkolů, které pokrývají vizi.
• Na vysoké úrovni se odhadnou epické příběhy a úkoly, aby se získal hrubý odhad rozpočtu a časový rámec dodání. Dále se definuje minimální životaschopný produkt (MVP) a další vlastnosti, které tvoří finální produkt.
• Vytvoří se scrum tým a naplánují se sprinty. Epické příběhy se rozdělí do menších funkcí a uživatelských příběhů. Odhadnou se příběhy a naplánují se pro nadcházející sprinty na základě priority funkcí a příběhů.
• V každém sprintu se pracuje na jednotlivých příbězích. Do sprintů jsou zahrnuty všechny aktivity, včetně návrhu, vývoje, testování a nasazení. Na konci každého sprintu se uživatelům prezentuje výsledek a sbírá se zpětná vazba.
• Pokud se objeví nové okolnosti nebo požadavky, upraví se funkce nebo příběhy, aby odpovídaly aktualizovaným potřebám. Tyto změny se okamžitě promítnou do plánování následujících sprintů.
• Jakmile je rozsah MVP dokončen, je okamžitě uvolněn koncovým uživatelům, aby bylo možné získat rychlou zpětnou vazbu z produkčního prostředí.
• Vývoj zbývajících funkcí pokračuje a bere v úvahu zpětnou vazbu uživatelů z již vydané části systému.

Toto je stručné shrnutí, ale rozdíl oproti vodopádovému modelu je zřejmý. Rychlá zpětná vazba, adaptace na změny, pružná reakce na aktuální potřeby, a v neposlední řadě doručení prvního hodnotného produktu v nejkratším možném čase. To jsou výhody, které u vodopádového projektu nemáte šanci získat.

Agilní vs. vodopád

Úspěch každého projektu závisí na správné metodice řízení projektu. To zahrnuje definování procesů, metrik, hodnocení a obecných způsobů práce pro všechny týmy zapojené do projektu.

Týmy musí znát pravidla, podle kterých se řídit, co bude definovat milníky, kdy jich dosáhnout, a jak se měří úspěch. Současně musí zúčastněné strany chápat, co od projektu očekávat a kdy uvidí první výsledky práce.

Obecně lze říci, že projekty v cloudovém prostředí mají tendenci inklinovat k agilním metodikám (nebo by alespoň měly). Projekty pracující s on-premise infrastrukturami stále často preferují vodopádové procesy. Tento závěr se zdá být logický.

Cloudové prostředí je od základu navrženo tak, aby se adaptovalo na neustále se měnící okolnosti. Díky různým „elastickým“ službám se dokáže rychle přizpůsobit novým situacím. On-premise prostředí je často předdefinované od začátku. Je těžké ho s časem měnit, takže týmy pracují s danými proměnnými po celou dobu trvání projektu.

Shrnutí rozdílů mezi agilním a vodopádovým přístupem:

Tato volba definuje několik klíčových aspektů realizace projektu.

#1. Projektové požadavky a řízení změn

Jedním z nejdůležitějších faktorů ovlivňujících volbu metodiky je způsob nakládání s uživatelskými požadavky. Stejně tak i postup při změnách již schválených požadavků.

U vodopádového projektu jsou všechny požadavky definovány a podepsány na začátku. Jakákoli změna tohoto stavu se považuje za požadavek na změnu. Taková změna musí být znovu projednána, odsouhlasena a potvrzena.

Veškerá práce, která byla do té doby provedena, musí být znovu zkontrolována a může být nutné ji předělat. Náklady se musí znovu upravit (protože jde o práci navíc, která nebyla zahrnuta v původní smlouvě). V nejhorším případě se může prodloužit i celý časový plán projektu.

Agilní přístup naopak změny vítá. Změny se berou jako běžná součást každodenní práce. Se zúčastněnými stranami (obvykle jako výsledek poslední prezentace sprintu) se odsouhlasí, že změny jsou klíčové pro dosažení vize projektu. Tyto změny se pak okamžitě zapracují do plánování následujících sprintů.

Předchozí obsah se změní a týmy od toho dne pracují s novými požadavky. Nedochází tak ke ztrátě času ani nákladů. Jednoduše se okamžitě přizpůsobíte nové realitě a původní plán nahradíte novým. Správa požadavků na změnu tak není potřeba, protože je součástí plánování sprintu.

#2. Plánování a rozsah projektu

Jak je zřejmé, vodopádový projekt stanovuje veškerý rozsah na začátku. Kolem tohoto rozsahu se vytvoří projektový plán. Dále se rozdělí doba trvání projektu do konkrétních fází (typicky analýza, návrh, vývoj, testování, nasazení a podpora). Týmy a zdroje jsou přiděleny k jednotlivým fázím. Hlavním cílem je držet se původního plánu, co se týče nákladů a harmonogramu.

Agilní projekt má místo tvrdého plánu vizi finálního produktu. Cíl je jasný, ale cesta k jeho dosažení se může měnit. Časová osa projektu je také stanovena a odsouhlasena na základě odhadu poptávky a kapacity týmů pracujících na projektu. Plán ale nemá oddělené fáze. Každý sprint je malou fází, která obsahuje všechny aktivity potřebné pro úspěšné doručení produktu.

Stručně řečeno, vodopádový projekt považuje změny za komplikaci, kterou je nutné řešit. Agilní projekt naopak považuje změny za běžnou součást procesu, bez dalších následků.

#3. Sledování průběhu projektu

Vodopádový projekt sleduje průběh plánu v rámci jednotlivých fází projektu. Fáze návrhu nemůže začít dřív, než je dokončena fáze analýzy, testování nemůže začít dřív, než je dokončen vývoj, a tak dále.

Pokud se jedna z fází opozdí, ovlivní to průběh zbývajících fází projektu. Proto je nutné kontrolovat aktivity v každé fázi a zajistit, aby postupovaly lineárně. V opačném případě se zvyšuje riziko zpoždění nejen dané fáze, ale i celého projektu.

Agilní projekt sleduje pokrok prostřednictvím prezentací na konci každého sprintu. Funkční produkt je primárním měřítkem pokroku. Každý sprint by měl skončit s kompletním obsahem. Do dalších sprintů by se mělo přesouvat jen minimum nedokončených příběhů.

Celkový pokrok projektu je mnohem snazší posoudit, pokud si můžete vyzkoušet aktuální přírůstek produktu a dát týmu okamžitou zpětnou vazbu.

#4. Týmová spolupráce

Zde vidíme jasný rozdíl mezi oddělenými aktivitami u vodopádu a neustálou spoluprací agilního týmu.

Na vodopádovém projektu obvykle pracují různí lidé v různých fázích projektu. Může docházet k menšímu překrývání, ale stále se jedná o odlišné skupiny lidí. Dá se říct, že pracují v "silech".

Definice agilního týmu je postavena na komunikaci a hodnotě. Musí jít o tým, který dokáže provádět všechny aktivity v životním cyklu produktu. Nechceme, aby existovala týmová "sila". Neustálá komunikace mezi týmem a externími partnery je základem úspěšného agilního projektu.

#5. Řízení rizik

Je nutné mít zavedený proces pro sledování rizik, problémů a jakýchkoli překážek, které mohou nastat během trvání projektu.

U vodopádového projektu se to projevuje sledováním stavu aktuální fáze projektu. Standardní hlášení stavu formou semaforu zobrazuje zelenou (vše je v pořádku), žlutou (objevily se problémy, ale víme jak je vyřešit) nebo červenou (projekt má vážné problémy, které mohou ovlivnit harmonogram nebo rozpočet).

Agilní projekt zde postupuje jinak. Nesledujeme postup směrem k cíli, ale řešíme závislosti mezi různými týmy a typy aktivit. Cílem je zajistit, aby žádný tým nemusel čekat na jiný tým.

Přirozeně se mohou objevit rizika, ale v takovém případě se plán upraví tak, aby riziko eliminovalo, místo toho, abychom řešili riziko a přitom se snažili držet původního plánu.

Jinými slovy, agilní projekt se snaží všemi možnými způsoby upravit plán, aby se vyhnul předvídaným rizikům. Řízení rizik je tedy proaktivní. U vodopádového projektu se na rizika reaguje zpětně, a snaží se je vyřešit, co nejdříve při dodržení původního plánu.

#6. Implementační rámec

Implementační taktika pro vodopádové projekty je obecně méně problematická než pro agilní projekty. Vodopádový model je tradiční přístup, který lidé praktikují už mnoho let.

Agilní projekty naopak vyžadují transformační postupy, které změní návyky, myšlení a způsob práce. Je to náročný a často dlouhodobý proces. Společnosti investují velké množství času a zdrojů, aby naučily své zaměstnance adaptovat se na agilní procesy.

Výhody v podobě rychlé adaptace na měnící se potřeby zákazníka jsou značné. Změna myšlení a celkového pracovního prostředí je však obtížná.

Nicméně je to často jediný způsob, jak zůstat konkurenceschopný. Ti, kteří se této změny chopí, bývají odměněni úspěchem.

Závěrečná slova

Řekněme to na rovinu. Pokud nemáte velmi konzervativního zákazníka, který nemá motivaci rychle dodávat výsledky do produkce, je nejlepší začít s agilním modelem hned od začátku. To je v dnešním světě naprostý základ. A to platí i v případě tradičního nastavení systémů on-premise. Zejména pokud je tým nový nebo začíná od nuly, má smysl transformovat procesy tak, aby byly v souladu s agilními metodikami.

Přesto vidím projekty, kde lidé prostě odmítají dodržovat jakýkoliv agilní proces. Místo toho postupují tradičním způsobem smluvního díla s přesně stanoveným časem a rozpočtem. Pak očekávají, že se projekt bude držet tohoto nastavení bez odchylek od plánu a rozpočtu (s různými výsledky, obvykle ne dobrými).

Je to rozhodnutí, na které mají právo, ale tímto rozhodnutím zůstávají v minulosti. Možná jim to ještě nějakou dobu bude fungovat, ale je jen otázkou času, kdy to přestane fungovat.

Pro další informace se podívejte na podrobný článek o životním cyklu agilního testování.