Vlákno názorů k článku Budoucností vývoje velkých e-shopů jsou agilní kontrakty od Petr Svoboda - Jsou činnosti, které se naceňují (a účtují) a...

Jsou činnosti, které se naceňují (a účtují) a které nikoliv. Režijní činnosti pokrývá rozdíl mezi kalkulovanou hodinovou sazbou a reálnými hodinovými náklady společnosti.

Čím větší rozdíl je, tím větší generuje vývojářská společnost hrubý zisk (ale také tím dříve práce dokončí a může dělat další). Je tedy motivovaná režijních činností provádět co nejméně (tedy např. generovat co nejméně chyb; vyjasnit si očekávání zákazníka každé funkce a programovat přesně to, co klient očekává namísto následného přepisování apod.)

Petr Svoboda

Chápu jak to myslíte.

Jsme si vědomi této obavy klientů a proto všechny úpravy a funkčnosti i při agilních kontraktech naceňujeme předem a sami neseme riziko, když úprava zabere více času (jako u standardního modelu specifikace->cena->programování).

Realizaci ovšem dělíme na několik části (po sprintech) a v nich hotovou práci prezentujeme klientovi, jako část hotového díla a vyžadujeme společné odladění, jako by se takto mělo spouštět (vždy životaschoný produkt). Pokud nenarazíme na potřebné nové změny, pokračujeme dál již domluvenou prací dle analýzy. Pokud jsou ale potřeba úpravy, vydefinujeme jaké a opět předem naceňujeme. S klientem se dohodneme, jakou má změn prioritu a podle toho jde do dalších sprintů.

Pokud se po sprintech objeví chyby, jsou opravovány režijně a neodečítají hodiny alokované dalšímu sprintu.
Příklad: v každém sprintu se odpracuje např. 150 člověkohodin na úpravách (placených úprav s cenou definovanou v kontraktu), ale dalších např. 90 člověkohodin je věnováno režijním činnostem (včetně oprav).

Agilní kontrakty jak je používáme my, jsou jakousi kombinací standardních kontraktů (specifikací a cen tvořených předem při analýze) a agilních metodik vývoje softwaru. Klientům zachovává kontrolu nad rozpočtem, ovšem umožňuje jim rychlé změny zadání a rychlé odhalení nepřesností/ne­pochopení. Nám spolupráce zajišťuje hodnotný a detailní feedback po každém sprintu a nikoliv až před spuštěním finálního projektu, protože klient je do realizace vtažen po celou dobu téměř úměrně. (a je pravda, že to ne každému klientovi to může vyhovovat)

Petr Svoboda / ShopSys