Agilní vývoj nebo Vodopád

Před samotným vývojem aplikace je potřeba si říci, zda budeme aplikaci vyvíjet agilním způsobem či metodou Vodopád. Pro rozhodnutí si řekneme, co každá metodika obnáší a co to pro nás znamená.

Vývoj metodou vodopád
Vývoj metodou Vodopád probíhá tak, že máme kompletní zadání. To předáme vývojářům a očekáváme, že přesně toto zadání dostaneme zpracované ve formě aplikace za předem známou cenu a v domluvený termín. (tzv. fix time - fix price). Na první pohled zní tato metoda jako ideál. Zákazník přesně ví, co dostane a kolik zaplatí.

Na druhý pohled je třeba si uvědomit, že aby se mohl kdokoli zavázat k pevné ceně a tu dodržet, musí do této ceny započítat i předem neznámé faktory. Aplikace vyvíjená na zakázku totiž není to samé jako sériová výroba, u níž je každému jasné, že každý kus bude stát stejně. Každý zakázkový vývoj je unikátní.

Cenu aplikace na míru tak lze při nejlepší vůli pouze odhadovat na základě požadované funkcionality sepsané v projektu a zkušeností s minulými podobnými projekty. V ceně tak vždy bude obsažena i tzv. rezerva, aby měli vývojáři jistotu, že se do slíbeného času vejdou. Rezerva se většinou pohybuje mezi 5-20% celkové ceny. Čím je aplikace rozsáhlejší, tím hůře se náročnost a cena odhaduje a tím větší rezerva musí být.
Agilní vývoj
Druhou možností je agilní vývoj. Při agilním vývoji rovněž vznikne na začátku zadání, na základě kterého je možné dát prvotní odhad ceny a dle kterého se začne vyvíjet.

Agilní vývoj probíhá po tzv. sprintech - krátkých časových úsecích (typicky 2-3 týdny), kdy se společně se zákazníkem předem naplánuje, co přesně se bude dělat. Výsledkem je daná část zpracovaná tak, aby si ji zákazník mohl sám vyzkoušet a zhodnotit. Na základě toho, se poté může rozhodnout, zda je třeba ještě dále danou část rozvíjet nebo se může přejít na další funkcionalitu. Zákazník si tak do značné míry projekt řídí sám. Výhodou tohoto přístupu je možnost rychlejšího startu samotného vývoje a následné vytváření aplikace tak, aby byla vždy v souladu s aktuálními potřebami zákazníka. Výhoda řízení ze strany zákazníka může být současně i nevýhodou, neboť na zákazníka klade nutnost projektu se věnovat i během jeho implementace.

Další nevýhoda nastává v situaci, kdy si zákazník začne tzv. “vymýšlet”. Funkcionalita ještě nedokončené aplikace se neustále rozšiřuje a tím dochází i k navyšování ceny. Tuto nevýhodu je možné korigovat průběžným vytvářením přehledů, kde se aktuálně vývoj nachází oproti plánu. Díky tomu zákazník opět průběžně vidí odhady, kolik bude vytvoření celé aplikace stát.