11. 09. 2018
Chcete-li dojít ke zdárnému dokončení projektu, stanovte hned v úvodu vhodnou metodiku jeho řízení. Kdy se vám vyplatí „vodopád“ a kdy naopak přistoupit k agilní metodě?
S vodopádovým modelem (anglicky „waterfall“) pracujeme v BlueGhostu nejčastěji. Metodika vychází z přesně specifikovaného zadání, kterému v začátcích práce na projektu předchází důsledná analýza. Důležité je, aby měl i zadavatel jasno, co vlastně potřebuje. V rámci specifikace se přesně rozvrhnou všechny kroky potřebné ke splnění jasně definovaného cíle. Následně se postupuje podle předem stanoveného harmonogramu. Od začátku je stanovený termín předání finálního produktu, cena a kvalita. Velmi oblíbenou vodopádovou metodikou je PRINCE 2.
Agilní metodiky jsou více flexibilní – konečné výsledky vždy stojí nad průběžným procesem, cílem je maximálně uspokojit zákazníka. Svým přístupem k agilnímu vývoji aplikace proslul třeba švédský Spotify.
Jedním z nejvyužívanějších frameworků spadajících pod agilní způsob projektového řízení je Scrum, během kterého se projekt rozdělí do několika dílčích částí, takzvaných sprintů. Každý sprint trvá ideálně 14 dní, během kterých se průběžně upřesňují funkcionality. Ty se pak testují a dolaďují k dokonalosti. Někdy padne rozhodnutí určité funkce vůbec nerealizovat, jindy se naopak přidají navíc podle aktuálních potřeb zadavatele, jeho zákazníků nebo třeba zaměstnanců.
A která metoda se při vývoji webu, e-shopu nebo jiné on-line aplikace víc vyplatí vám? Zkuste si položit následující otázky.
Projekty řízené metodikou vodopád nejvíce těží z důsledného rozplánování postupů. Cena, termín a kvalita jsou od začátku dané smlouvou a technickou specifikací. Pokud například při tvorbě webu vznikne problém na straně vývojáře, vícenáklady jdou za ním. Jestliže naopak práce odsýpají bez zádrhelu, může na tom dodavatel vydělat víc, než původně očekával.
U agilního přístupu naopak není konkrétní výstup dopředu nikdy znám, na začátku se stanoví spíš obecný rozsah projektu. Na druhou stranu by se s ohledem na průběžnou interakci se zadavatelem nemělo stát, že výsledný produkt neodpovídá jeho aktuálním potřebám. Rozpočet a termín dodání se stanovují spíš v ideálním případě, vyúčtování je naprosto transparentní vždy – klient průběžně platí pouze to, co se zrovna odpracovalo.
V průběhu tvorby projektu vodopádem je velmi důležitý projektový manažer, který hlídá dodržování technické specifikace, termíny a náročnost prací. Obstarává dokumentaci, sleduje vývojáře a řídí i testování aplikace. To samozřejmě není zadarmo; na projektové řízení často padne až ⅓ z celkového rozpočtu.
U agilního řízení klasický projektový manažer neexistuje. Například hierarchie Scrumu vytváří role Scrum Mastera a Product Ownera, kdy druhou jmenovanou zastává klient nebo člověk klientem pověřený. Finanční náklady na projekťáka tím odpadají. Asi 15 % z rozpočtu spotřebuje práce Scrum Mastera, který odstraňuje problémy a motivuje tým k lepším výsledkům. Větší zapojení do testování a celého projektu ale žádá několik hodin klientova volného času v každém sprintu. Coby Product Owner musí pokaždé schválit postupy prací, převzít hotovou práci a zkontrolovat ji.
K novému e-shopu sprintem vpřed? Rozjeďte to frameworkem Scrum s Modrým duchem!
Rozplánování práce na začátku může u metody waterfall předem odhalit některé chyby. Podle odhadů Steva McCoennella, autora knih o softwarovém inženýrství, to může přinést až dvousetnásobné finanční úspory na projektu. Vzhledem k předem dané technické specifikaci se ale u vodopádu velmi těžce řeší případné změnové požadavky. Největší problém nastává, když si zadavatel s dodavatelem odsouhlasí specifikaci, aby ve výsledku zjistil, že mu takové řešení nevyhovuje. U větších projektů je v podstatě pravidlem, že se některé potřeby nebo problémy objevují až v průběhu prací. Jiné původní požadavky se naopak stávají nepodstatnými. Jízda podle dokumentace pak obvykle znamená dodatečné vícepráce a naopak utrácení času dodavatele za některé věci, které nejsou pro zákazníka zas tak podstatné.
V agilu specifikace vůbec neexistuje, a pracovníky tak svazuje pouze obecné zadání každého čtrnáctidenního sprintu. Ty mohou pružně reagovat na průběžný vývoj projektu i klientovy aktuální potřeby. Při větším množství připomínek a zdlouhavějším ladění se ale může stát, že se nepodaří kompletní plány na aplikaci zcela dodržet. Proto je důležité neustále monitorovat, co všechno se dokončilo a kolik se toho v daném rozpočtu ještě stihne udělat.
S přesnými specifikacemi u metody waterfall souvisí mnohem více papírování, což ale opět zvyšuje cenu. U agilního řízení důsledné dokumentování odpadá. Úkoly pro jednotlivé sprinty se průběžně nastavují v procesních aplikacích, jakou je třeba software JIRA. Takový přístup práce výrazně urychlí, některým klientům ale více vyhovuje pravidlo „co je psáno, to je dáno“.
Vodopád se obecně vyplatí u menších projektů, kde je často 100% jasné, co se má udělat a jak to bude fungovat. Je tedy více pravděpodobné, že by předem definovaný plán ohrozil jakékoliv změny. Zadavatel získává aplikaci na klíč, aniž by s ní zbytečně ztrácel čas. Jednoduše zadá projekt, který s časovým odstupem za domluvenou cenu dostane.
Agilní metody jsou stavěné hlavně na rozsáhlejší, dlouhodobější a technicky náročnější projekty. S ohledem na plánování pracovních kapacit a logické odbavování úkolů je výstup předem znám jen rámcově, pracovníci jsou svázaní pouze obecným zadáním každého jednotlivého sprintu. To umožňuje organizovat práci i pracovní týmy s orientací na splnění aktuálního cíle. Agilním vývojem by se mělo dospět k tomu, že se dá aplikace spustit alespoň v režimu Minimum Viable Product a je možné ji dál rozvíjet.
Praktický
Inspirující
Zábavný
Nic moc
