Myslím, že tento stav vede k obrovskému plýtvání programátorskými kapacitami a rozpočty klientů a je neudržitelný. A zatímco dnes agilní kontrakty málokdo poptává či nabízí, v blízké budoucnosti budou i v e-commerce standardem.
Jen za poslední dva roky jsme v ShopSys tvořili dvanáct opravdu velkých nových e-shopů, dvě třetiny z nich byly klasické e-shopy a třetina B2B portály. Pracnost každého přesáhla 400 developerských člověkohodin. V takto velkých projektech se bavíme o velkém rozpočtu, proto jsme se u každého snažili co nejvíce vyjasnit očekávání funkčnosti a nastavit co nejpřesnější kalkulaci. To znamená dalších 80–120 člověkohodin a desítek hodin přímo se zákazníkem a dalšími aktéry (většinou zástupcem dodavatele podnikového informačního systému, tzv. ERP).
A teď si tipněte, v kolika případech se výsledná aplikace spustila ve funkčnosti, kterou si zákazník nadefinoval při analýze projektu? Nějaké tipy? Polovinu? Čtyři z dvanácti?
Ne, je to nula. Žádný. Ani jeden jediný projekt.
Fail v cílové rovince
Při standardním vodopádovém modelu vývoje softwaru je na začátku zakontraktovaná požadovaná funkčnost. Podle rozsáhlé specifikace se poté stovky hodin aplikace vyvíjí. Zadavatel je sice vtažen do procesu vývoje, přináší mu to však jen povinnosti – součinnost při rozhodování, dodávání podkladů apod. Průběžné výsledky práce mu toho moc neřeknou, pokud je vůbec dostává. Z důvodu částečného rozpracování nemůže až do samotného konce nic opravdu otestovat.
Pomiňme chyby, které se při vývoji softwaru vždy vyskytnou a musejí odladit. Zadavatel poprvé zjišťuje, že chce výsledek trochu jinak než si původně myslel a dost jinak, než původně zadal, až v den dodání. A za poslední měsíce se toho tolik změnilo! Funkce X už není potřebná, funkci Y je potřeba komplet předělat, protože zákazníci ji používají jinak, a pro funkci Z nemá ERP data potřebně strukturovaná a je tak k ničemu.
Tím je třetina odprogramovaného a draze zaplaceného času v čudu. Je potřeba spoustu věcí pozměnit, nové doprogramovat. Datum spuštění je v nedohlednu a budget v neznámu. Proč stovky provozovatelů e-shopů zažívají tyto problémy? Co za tím stojí?
Nedůvěra, v tom to vězí
Zadavatel nevěří společnosti, která má e-shop tvořit. Nevěří ajťákům. S ajťáky má už přece špatné zkušenosti – a když ne on, tak pět jeho kamarádů. Zadavatel chce mít KONTROLU, přesně vědět, co shopdeveloper dodá, kdy a za kolik. Jenže iluzi kontroly staví nad zadáním, které nezná, a v podstatě znát ani nemůže. Představa, že IT funguje jako nákup auta. Vybrat sedačky, barvu karosérie a výbavu. Jenže e-shop není auto. Je to abstraktní dílo, které se vyvíjí postupně.
Iterace jsou spása
Co se stane, když dodávku půlroční práce rozdělíme na 12 kousků? 12× větší šanci cokoliv změnit. 12 příležitostí pro zadavatele odchytit, že původní představa neodpovídá realitě, 12 příležitostí ověřit důvěru v shopdevelopera a případně odstoupit od smlouvy. 12× zmenšujete riziko, že to dopadne katastrofou. Získáváte 12 příležitostí zjistit, jak v praxi fungují agilní metody vývoje softwaru.
Jak probíhá agilní vývoj?
Na začátku jsou stejné požadavky. Dokonce nacenění je stejné. Víte co, kdy a za kolik. Samotná práce však probíhá totálně jinak.
Vydefinuje se a vyvine Minimální životaschopný produkt, tedy jakási minimální funkční varianta nového e-shopu, ta se v některých málo případech rovnou i spustí. Poté následují dvoutýdenní (případně třítýdenní) sprinty. Pro každý sprint vybírá zadavatel a shopdeveloper, jaká funkčnost má největší prioritu.
Na konci sprintu se prezentuje živá ukázka funkčního produktu (a někdy se také nasazuje na ostrý web). Na konci každého sprintu je funkční a o něco lepší e-shop. Nenastává situace, že je hotový filtr, ale nejsou pro něj data nebo že je hotovo nastavení šablon v administraci, ale ještě nejsou nakódovány na frontendu. Do sprintů se plánuje jen vývoj ucelených částí.
V budoucích sprintech je vždy o něco méně funkcí z naceněných a specifikovaných požadavků z kontraktu, naopak přibývá úprav specifikací či funkce nové. Ty jsou zapracovány hned v následujících dnech příštího sprintu, ne po konci celé zakázky.
Stejná cena, stejný termín, jiná funkčnost
Výsledná zakázka neodpovídá původnímu zadaní. To ale nevadí – zadavatel v průběhu tvorby sám chtěl, aby tomu tak nebylo. Pokud by trval na předchozí funkčnosti, tak dnes nespouští e-shop na ostrý web, ale řeší jak eshop předělávat.
Při agilním kontraktu cena zakázky sice nenarostla, ale úspěch nebyl zadarmo. Zadavatel musí být součástí vývojového týmu a každý týden tak strávit 2–3 hodiny při telefonátech či videohovorech a další jednotky hodin vlastní přípravou. Díky tomu má však celou realizaci opravdu pod kontrolou.
Agilní kontrakty ano či ne?
Z naší zkušenosti jsou agilní kontrakty vhodné, když:
- je tvořen e-shop na míru či B2B portál
- pracnost individuálních úprav a kódování frontendu přesahuje 400 člověkohodin
- na projektu souběžně pracuje 4 a více pracovníků (programátoři, front-end developeři, testeři, projektový manažer)
- zástupce tvořeného e-shopu chce a věnuje min. 2 hodiny týdně komunikaci s shopdeveloperem
Agilní kontrakty se naopak nehodí, když:
- je spouštěn šablonový e-shop, nejčastěji na pronájem (ty v ShopSys neděláme)
- pracuje-li na zakázce v jednom okamžiku pouze jeden pracovník (pak jsou náklady na projektový management a komunikaci v nepoměru k odvedené developerské práci)
- je tvořen e-shop bez výrazných individuálních úprav či napojení na ERP
Z výše řečeného vyplývá jediné – agilní kontrakty se stanou i v Česku standardem při dodávce větších e-shopů.
ČLÁNKY DO MAILU