Buď agilní

Sára Vernerová

7/19/2021

Na začátku každého projektu se tým setkává s jednou zásadní otázkou. Budeme projekt řídit agilně nebo využijeme waterfall? Aby projekt dopadl dobře, potřebuje využít jasně definovaných procesů té či oné metodologie, čímž zajistíme vysokou kvalitu konečného produktu. Starším a dnes méně využívaným přístupem, na jehož základech ale i tak projektový management stále stojí, je vodopádový přístup. Je charakteristický dlouhou analytickou částí, ve které se definuje celý rozsah (scope) projektu. V okamžiku, kdy je celý projekt popsán, přichází vývoj, testování a deployment. Změny ve scopu projektu jsou nevítané, drahé a přináší zpoždění. Vývojářské společnosti po zkušenostech s tímto přístupem již příliš nechtějí nabízet smlouvy typu Fixed Time/Fixed Cost (typické pro vodopádový přístup), protože u dynamických projektů je téměř nemožné je přesně nacenit. V průběhu času se očekávání mohou měnit, což na konci dne přináší frustraci na obě strany. I když je samozřejmě zásadní vědět, co má daný produkt dělat a jak by měl vypadat, vývoj samotný je často vhodnější řídit agilním způsobem. Agilně znamená, že budete dodávat výstupy častěji a inkrementálně, a budete reagovat na případné změny rychle. Nicméně je vhodné konstatovat, že výzkumy neprokázaly, že by byla úspěšnost projektu ovlivněna zvoleným přístupem. Jedná se tedy spíše o osobní preferenci a zkušenosti. Teď se podíváme blíže na jednotlivé přístupy.

Vodopádový přístup rozděluje vývojový cyklus na jasně ohraničené fáze, jakými jsou sběr požadavků, analýza, design, vývoj, unit testing, systém a user acceptance testing, deployment a následné oficiální uzavření projektu. Před přechodem do každé další fáze musí být ta předchozí řádně uzavřena a dokumentována. Klíčoví stakeholdeři by měli podepsat závěrečný dokument, ve kterém potvrdí dosažení jednotlivých milníků dané fáze. Jakékoli změny v průběhu projektu jsou nevýhodné pro všechny, většinou totiž znamenají zásah do základních projektových dokumentů a vybírají si tak svou daň v podobě delšího času a většího objemu peněz. Změní se rozpočet, projektový harmonogram, často jsou potřeba i nové zdroje nefinančního charakteru.

• snadnější nacenění projektu
• pevně definovaný scope
• jasně měřitelný pokrok
• definované týmové role
• vyhrazené zdroje
• časové ohraničení projektu

• rigidní struktura, která neumí dobře pracovat s potenciálními změnami
• nepřipouští si žádnou míru nejistoty
• nedostatečné zapojení zákazníka v pozdějších fázích projektu
• přístup je obecně nevhodný pro větší projekty, jejichž výsledek leží v příliš vzdálené budoucnosti

Agile klade důraz na rychlý deployment, díky kterému je zpětná vazba téměř okamžitá a zákazníkova spokojenost tak bývá vyšší. Definujeme časově kratší sprinty, které trvají z pravidla dva týdny. Na začátku každého sprintu tým vybírá, na jakých výstupech se bude pracovat, a využívá k tomu prioritizaci založenou na vstupech od zákazníka. Na konci každého sprintu zákazník spolu s týmem revidují dokončenou práci.

• rychlejší vývojový cyklus
• více zaměřený na zákazníka a jeho spokojenost
• flexibilní, co se potenciálních změn týče
• podporuje živou komunikaci v týmu
• ideální pro velké projekty

• vyžaduje zapojení zákazníka, který s tím ale vždy souhlasit nemusí
• nevíme, kolik bude projekt na konci dne stát
• doporučuje se, aby tým byl fyzicky pospolu, což není vždy možné
• díky možným změnám přesně nevíme, v jakém čase bude projekt doručen

Klasický vodopádový přístup je vhodný například k implementaci krabicových řešení na straně klientů, kdy nezasahujeme do produktu jako takového, maximálně řešíme menší konfigurace. Rovněž můžete zvolit vodopád, pokud se jedná o jednoduchý projekt, jako například statické webové stránky nebo e-shop s předdefinovanou šablonou. Pokud ale víte, že budete vyvíjet komplexní produkt na míru, a buď vy nebo zákazník nevíte naprosto jistě, jakou má mít výslednou podobu, využijete jednu z agilních metod. Nejznámějšími jsou Scrum, Kanban, Lean Development nebo XP (Extreme Programming). Každá z metod nabízí něco, společné však mají to, že detailně naplánují vývoj na relativně krátké období, a tento proces opakují až do zdárného konce. Na trhu opět najdete několik nástrojů, které celý proces ulehčí, případně vám ho rovnou nastaví. Mezi nejznámější nástroje patří Jira, ale dnes se dá i velmi dobře využívat i GitHub nebo z českých nástrojů Easy Project. Nepodceňte dokumentaci projektu jako takového. Vždy počítejte s tím, že budete kdykoli potřebovat nového člena týmu, který by měl být schopný rychlého zorientování bez vaší plné asistence. Mějte tak dostupnou technickou i funkční specifikaci, definujte alespoň klíčové procesy. Vhodné je mít i sepsané testovací scénáře s evidencí jejich provedení. Mnoha vývojářům a projektovým manažerům tohle všechno často přijde jako zbytečná byrokracie. Skutečnost je ale taková, že vám to celé může začít velmi rychle přerůstat přes hlavu, pak jen velmi těžko budete zaplňovat mezery. Posledním doporučením je, abyste se nebáli metody kombinovat. Osobně vidím jako nejlepší využít waterfall na analýzy a sbírání požadavků, vývoj následně řídit agilně, a ukončit projekt opět waterfallem.