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

Před přímou odpovědí na otázku v názvu je vždy dobré si ujasnit, jakého konečného cíle projektu chcete dosáhnout

Jak bude produkt vypadat za měsíc, za půl roku a za rok. Ale teď to popiš. To vám dá určitou perspektivu a stanoví základní očekávání ohledně úrovně vaší předvídatelnosti, flexibility, agility, rychlosti uvádění na trh a fixace nákladů v čase.

Ano, dnes se zřizování projektů vodopádů zdá být směšným nápadem. Zvláště pokud se již nesčetněkrát prokázalo, že pokud chcete rychle reagovat na posuny na trzích, nemáte jinou možnost, než jít agilně. Ale pokud je vaším cílem za rok dodat produkt s funkcemi, které jsou již od začátku docela jasné a omezené, a máte týmy lidí bez předchozích zkušeností s agilní metodikou, pak určitě zůstaňte konzervativní a jděte do vodopádu.

Ne každý případ je tak jednoduché uzavřít. Pojďme se podívat, jak lépe vyhodnotit, která metodika je pro váš projekt lepší.

Jak vypadá vodopád?

Namísto toho, abychom se pouštěli do nějakých definic, které si všichni uvědomují již několik desetiletí, praktický výsledek vodopádového projektu obvykle vypadá takto:

Nejprve si naplánujte, co chcete udělat jako konečný výsledek/produkt a kolik to může zhruba stát.

Spusťte proces shromažďování požadavků. Důkladně jste prodiskutovali všechny detaily konečného produktu, vznesli námitky, zpochybnili, odsouhlasili, znovu prodiskutovali a nakonec potvrdili.

Odhadněte celou věc a potvrďte rozpočtové očekávání.

Navrhněte řešení. Uspořádejte několik setkání se zúčastněnými stranami. Vytvářejte různé dokumenty a nechte je zkontrolovat zúčastněnými stranami. Potvrdit a schválit finální funkční a technický návrh.

Implementujte řešení na základě návrhu. Zde vyvíjíte kompletní konečný produkt.

Vstupte do testovací fáze a provádějte 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 potenciálně mnoho dalších (v závislosti na kultuře společnosti). Vše zdokumentujte a nechte zúčastněné strany, aby to přezkoumali a schválili.

Nasaďte řešení do produkčního prostředí. Zde začínají cíloví uživatelé používat konečný a kompletní produkt.

Naplánujte si nějakou fázi podpory, během níž vývojový tým opraví případné chyby řešení.

Celý tento proces může trvat několik měsíců až několik let. Jak můžete předvídat, uživatelé uvidí výsledky až na konci tohoto procesu. Po dlouhém čekání tedy přichází okamžik pravdy (nebo neúspěchu).

Pokud se během té dlouhé doby něco změní a konečný produkt by měl vypadat trochu jinak, jedná se o situaci, kterou nazýváte žádostí o změnu. Návrh musí být znovu otevřen, přepracován a znovu schválen. Prodlužuje celý časový harmonogram o další část. Každá změna vyžaduje restart celého procesu předtím.

Na druhé straně máte skálopevnou definici fáze, pevný rozpočet pro každou fázi a pevný čas. I když musíte na první výsledek čekat dlouho, pokud jsou šance na změny během cesty minimální, může to být stále výhodnější volba.

Jak vypadá agilní?

Takto může projekt fungovat v agilním nastavení:

Definujte obchodní vizi konečného produktu. Zhruba, ale s jasnými obchodními požadavky a očekáváními, co má produkt splňovat pro uživatele.

Vytvořte seznam funkčních eposů a technických prostředků, které pokrývají vizi.

Proveďte odhad eposů a aktiv na vysoké úrovni, abyste vytvořili určitá očekávání štíhlého rozpočtu a časový rámec dodání. Definujte, co je minimální životaschopný produkt (MVP) a jaké jsou ostatní vlastnosti tvořící konečný produkt.

Vytvořte scrum tým a naplánujte si sprinty v časovém rámci. Rozdělte eposy do funkcí a příběhů s týmem. Odhadněte příběhy a naplánujte je pro nadcházející sprinty na základě priority funkcí a příběhů.

Pracujte na příbězích v každém sprintu. Zahrňte všechny aktivity do sprintů, tedy návrh, vývoj, testování a nasazení. Na konci každého sprintu předložte uživatelům výsledek přírůstku a požádejte o zpětnou vazbu.

Pokud se něco vymkne z cesty nebo má požadovaný výsledek, změňte funkce nebo příběhy, aby se přizpůsobily aktualizované realitě. Odrážet to okamžitě od příštích sprintů.

Ihned po dokončení rozsahu MVP jej uvolněte koncovým uživatelům, aby získali rychlou zpětnou vazbu k produkci.

Pokračujte ve vývoji zbývajících funkcí odrážením výsledků zpětné vazby uživatelů z již vydané části systému.

To je jen rychlé shrnutí, ale rozdíl oproti vodopádu je již jasný. Rychlá zpětná vazba, adaptace, reflexe aktuálních potřeb měnících se v čase, první hodnotný produkt dodán v co nejkratším čase. To vše jsou vlastnosti, které nemáte šanci získat v projektu vodopádu.

Agilní vs. vodopád

Projekt nemůže být úspěšný bez vhodné metodiky projektového řízení. To znamená definovat procesy, metriky, hodnocení a obecné způsoby práce pro týmy tvořící projekt.

Týmy musí vědět, jaká pravidla mají dodržovat, co bude určovat milníky, kdy jich dosáhnout a jak měřit a vyhodnocovat úspěch. Zúčastněné strany musí zároveň pochopit, co od projektu očekávat a kdy budou moci vidět první výsledky práce.

S trochou zobecnění lze říci, že projekty fungující v cloudových prostředích výrazně častěji inklinují k agilním metodikám (nebo by alespoň měly). Projekty pracující s on-premise infrastrukturami stále velmi často preferují vodopádové procesy. To přichází jako přirozený závěr.

Cloudové prostředí je od základu vytvořeno tak, aby vyhovovalo neustále se měnícímu prostředí. Adaptuje se co nejrychleji (pomocí různých „elastických“ služeb) nové realitě. On-premise prostředí je často předdefinováno na začátku. Je těžké to časem změnit, takže týmy pracují s deterministickými proměnnými po celou dobu trvání projektu.

Shrnutí přístupu Agile vs. Waterfall.

Funkce Vodopádový přístupAgilní přístup Zpracování uživatelských požadavků Změna je považována za formální proces (žádost o změnu). Možná bude potřeba předělat práci, což bude mít dopad na náklady a časové osy. Přijímá změny jako součást standardního procesu, bez významného dopadu na náklady nebo časové osy. Plánování a rozsah projektu Na začátku definuje rozsah a drží se ho. Fáze jsou tuhé a drží se původního plánu. Má jasnou vizi konečného produktu, ale umožňuje změny. Práce je organizována do sprintů s flexibilitou v tom, jak jsou úkoly dokončeny. Sledování pokroku projektu Sleduje pokrok v každé fázi. Zpoždění v jedné fázi může ovlivnit celou časovou osu projektu. Sleduje pokrok prostřednictvím ukázkových relací na konci každého sprintu. Zaměřuje se na funkční produkt. Týmová spolupráce Různí lidé v různých fázích projektu, omezená interakce. Mezifunkční tým s neustálou komunikací mezi členy týmu a zainteresovanými stranami. Řízení rizik Sledování stavu na základě postupu ve fázi. Reaguje na rizika zpětně a přitom dodržuje plán. Zaměřuje se na proaktivní řešení závislostí mezi týmy a aktivitami. Přizpůsobuje plán tak, aby eliminoval předpokládaná rizika. Implementační rámecTradiční metodologie. Vyžaduje transformační postupy pro přizpůsobení agilnímu přístupu. Zahrnuje změnu návyků a myšlení.

Tato volba však bude definovat několik aspektů vlastností provádění projektu.

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

Jedním z nejdůležitějších aspektů určujících výběr je způsob, jakým bude nakládáno s požadavky uživatele. A také, jaký je postup, pokud je později potřeba změna již dohodnutých požadavků?

U vodopádového projektu jsou všechny požadavky definovány a podepsány zúčastněnými stranami na začátku; pokud dojde k jakékoli změně tohoto stavu, projekt to považuje za požadavek na změnu. Musí být znovu potvrzeno, odsouhlaseno a potvrzeno.

Jakákoli práce, která již byla do té doby provedena, musí být znovu zkontrolována a zahájena znovu. Náklady je třeba znovu upravit (jelikož se jedná o vícepráce, na které se původní smlouva nevztahuje). V nejhorším případě je třeba prodloužit i celý časový plán projektu.

Díky agilnímu nastavení jsou změny vítány. Ke změnám přistupujete jako ke standardní každodenní práci. Souhlasíte se zúčastněnými stranami (pravděpodobně jako výsledek poslední ukázky sprintu), že změny jsou zásadní pro udržení vize projektu. Poté tyto změny okamžitě naplánujete na další sprinty.

Předchozí obsah se tím změní a týmy od toho dne nadále pracují s novými požadavky. Nedochází k žádné 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. Není vůbec potřeba speciální správa změnových požadavků. To vše je součástí iniciativ plánování sprintu.

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

Jak můžete očekávat, projekt vodopádu nastavuje a opravuje veškerý rozsah na začátku. Vytvoříte plán projektu kolem tohoto rozsahu. Poté rozdělíte dobu trvání projektu do konkrétních fází (typicky analýza, návrh, vývoj, test, nasazení, podpora a údržba) a opravíte týmy a zdroje kolem těchto fází. Po většinu časové osy projektu je vaším hlavním cílem co nejvíce se držet tohoto původního plánu, pokud jde o náklady a načasování.

Agilní projekt má místo tvrdého plánu vizi konečného produktu. Konečný stav je jasný, ale cesta k dosažení tohoto stavu se může volně měnit. Časová osa projektu je také stále definována a odsouhlasena na základě předběžného odhadu poptávky a kapacitního zatížení týmů pracujících na projektu. Plán nemá oddělené fáze. Místo toho je každý sprint malou fází, která obsahuje všechny aktivity, které tým potřebuje k úspěšnému vydání přírůstkového produktu.

Stručně řečeno, projekt vodopádu zachází se změnami jako s komplikací, kterou je třeba vyřešit (a příležitostí pro prodejce získat další peníze). Naproti tomu agilní projekt zachází se změnou jako s běžným obchodem bez dalších důsledků (kromě vhodnějšího konečného produktu).

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

Projekt vodopádu sleduje průběh plánu v rámci jednotlivých fází projektu. Fáze návrhu nemůže začít před dokončením fáze analýzy, testování nemůže začít před dokončením celého sestavení a tak dále.

Pokud se některá z fází opozdí, ovlivní to průběh zbývajících fází projektu. Proto je důležité kontrolovat aktivity v každé fázi a zajistit, aby v průběhu času postupovaly lineárně. V opačném případě zvyšujete riziko zpoždění této konkrétní fáze a následně i celého projektu.

Agilní projekt sleduje pokrok, hlavně pomocí ukázkových relací na konci každého sprintu. Funkční produkt je primárním měřítkem pokroku. Přirozeně chcete zajistit, aby každý sprint skončil s kompletním obsahem sprintu. Žádné nebo jen minimum příběhů se přenáší do dalších sprintů.

V konečném důsledku je mnohem snazší vidět celkový pokrok projektu, pokud si můžete přímo vyzkoušet aktuální přírůstek produktu a okamžitě se vrátit k týmu s velmi konkrétní zpětnou vazbou.

#4. Týmová spolupráce

Jde o přísně oddělené aktivity vodopádu versus kontinuální spolupráci se všemi stranami agilního týmu.

Na vodopádovém projektu obvykle pracují různí lidé v různých fázích projektu. Mohou se do určité míry přelévat, ale stále jsou to různé skupiny lidí. Skoro sila, dalo by se říct.

Definice agilního týmu spočívá v komunikaci a hodnotě. Musí to být také vícefunkční tým schopný provádět všechny činnosti životního cyklu produktu. Sila týmů je něco, co nechcete existovat. Neustálá komunikace mezi týmem a externími partnery je základní definicí úspěšného agilního projektu.

#5. Řízení rizik

Je zřejmé, že chcete mít proces pro sledování všech rizik, problémů nebo jakýchkoli překážek, které projekt může během své časové osy přinést.

V případě vodopádového projektu se to promítá do sledování stavu aktuální fáze projektu. Standardní hlášení stavu podobné semaforu bude zobrazovat zelenou (vše je v pořádku a v souladu s plánem), žlutou (některé důležité problémy jsou na místě, ale stále je jasné, jak je vyřešit) nebo červenou (což znamená projekt má vážné problémy, které mohou ovlivnit původní harmonogramy nebo rozpočet).

Agilní projekt je zde také jiný. Ve skutečnosti nesledujete pokrok směrem k cíli. Spíše řešíte závislosti mezi různými týmy a typy činností. Cílem je zajistit, aby žádný tým nečekal na jiný tým s postupovými aktivitami.

Přirozeně se mohou objevit rizika, ale pak musí řešení změnit plán do budoucna, aby riziko zmizelo, spíše než vymýšlet řešení rizika a přitom zachovat původní plán.

Jinými slovy, agilní nastavení projektu využívá všechny možné způsoby, jak změnit plán tak, aby nečelil předpokládaným rizikům, což znamená, že řízení rizik je proaktivní. V případě vodopádového projektu reagujete na rizika zpětně a snažíte se je vyřešit v co nejkratším čase při dodržení původního plánu.

#6. Implementační rámec

Implementační taktika pro vodopádové projekty je samozřejmě méně problematická než pro agilní projekty. Metodika vodopádů je obvykle stav, který lidé praktikují již mnoho let.

Na druhou stranu projekty vyžadují agilní transformační postupy, které změní jejich návyky, myšlení a způsoby práce. Je to náročný a často také dost dlouhodobý proces. Společnosti investují značné množství času a zdrojů, aby naučily lidi adaptovat se na agilní procesy.

Přínosy v podobě rychlého přizpůsobení se měnícím se potřebám zákazníka jsou značné, ale změna myšlení lidí a celkového pracovního prostředí je to nejtěžší.

Většinou je to také jediný způsob, jak zůstat na trhu kompetentní, takže kompromisy jsou pro ty, kteří uspějí, odměněny velkým úspěchem.

Závěrečná slova

Řekněme to jasně. Pokud nemáte velmi konzervativního zákazníka bez velké motivace rychle dodávat výsledky do výroby (ať už k tomu mohou mít jakékoli důvody), nejlépe uděláte, když začnete modelovat agilní týmy hned od začátku. To je v dnešním světě doslova oříšek. 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 s původními lidmi, stále má smysl transformovat procesy tak, aby byly v souladu s agilními metodikami.

Přesto stále vidím projekty, kde lidé prostě odmítají dodržovat tento druh agilního procesu nebo jakékoli jiné nastavení, ale striktně fázově specifickou organizaci práce. Postupují obvyklou cestou nasmlouvání díla na konkrétní čas a rozpočet. Poté očekávají, že projekt bude následovat toto nastavení bez odchylek od plánu a peněz (s různými výsledky, obvykle ne dobrými).

Je to rozhodnutí, na které mají právo, ale nakonec se s takovým rozhodnutím rozhodnou také zůstat v minulosti. Možná jim to ještě nějakou dobu bude fungovat, ale je jen otázkou času, kdy to přestane fungovat.

Dále se podívejte na podrobný článek o životním cyklu agilního testování.