Tolik teorie, v praxi ale z povzdálí pozoruji agilní vývoj mnohem většího projektu v řádu desetitisíců hodin, který už měl být dva roky hotový a vývoj se konci stále neblíží.
Klasické projektové řízení by je už dávno donutilo k nějaké akci a pořádné analýze.
Netvrdím, že to je vina agilního vývoje, ale problém je, že agilní vývoj firmy nemotivuje SW dokončit, právě naopak, protože zákazník platí a oni mají práci.
Problem asi bude v tom, cemu rikate komunismus. Zapadni demokracie, nejspise aby svym obcanum zjednodusili pohled na svet, za nej jednoduse oznacili vsechny systemy/zeme, kde byli u moci komuniste. Klasikove marxismu-leninismu ovsem komunismus popisovali zcela jinak - doporucuji navstevu dobreho antikvariatu a studovat, studovat, studovat ;-).
Přirovnání ke komunismu je dost trefné, ovšem z jiných důvodů, než myslíte. Není totiž pravda, že komunismus nikdo nedokázal uvést do praxe, v určitých oblastech časoprostoru se to podařilo.
Základní problém komunismu je, že potřebuje velmi specifický "typ" lidí, proto může fungovat lokálně, když se takoví seberou a založí si na dostatečně odlehlém místě komunu, ale jako model pro celou společnost by to znamenalo "přeprogramovat většinu", což se líbí "programátorům", ostatním už méně.
S agilním vývojem se to má podobně, když se sejde vhodný dodavatel s vhodným zákazníkem, může to fungovat. Jenže opravdu musejí být na obou stranách vhodní lidé, což není ani z jedné strany samozřejmé.
[S agilním vývojem se to má podobně, když se sejde vhodný dodavatel s vhodným zákazníkem, může to fungovat. Jenže opravdu musejí být na obou stranách vhodní lidé, což není ani z jedné strany samozřejmé.]
To potvrzuji. Agilní metodiky nemusí být pro každého. Naší podobnou agilních kontraktů (zjednodušeně: předem specifikace a nacenění, ovšem realizace ve sprintech) se agilní realizaci snažíme přivést širšímu okruhu klientů. Vyžaduje ovšem jednoznačně ochotu a dostatek časových kapacit u zákazníka.
Dle naší zkušenosti tuto formu realizace oceňují a preferují nejčastěji společnosti/lidé, kteří již mají zkušenost s vývojem středních a větších webů či aplikací standardním modelem a chtějí se maximálně vyhnout bodu "finálního ladění a předělávání", které bývá zpravidla těsně před spuštěním aplikace a je nejvíce stresující a náročná. Na agilním kontraktu oceňují, že se tato fáze vlastně rozděluje do několika malých bloků (sprintů) a tím se předchází stresům, zpožděním a změnám před spuštěním.
Petr Svoboda / ShopSys
Neznám podrobnosti vašeho kontraktu a platebních provázaností na předávané celky, takže to nedokáži zhodnotit.
Dle naší zkušenosti jsou klienti ochotni platit vždy až v případě, kdy je jim odprezentován sprint s dokončenou (a životaschopnou funkčností), které byla pro daný sprint předem určena. Na opravu případných chyb máme opět zase pouze čas po dobu příštího sprintu. Pokud se jedno nebo druhé neplní, klient platbu pozastaví.
V našich kontraktech neúčtujeme oproti zpětným výkazům hodin. Účtujeme funkce, předem naceněné a pro každý sprint se pouze vybírá dle priorit, co se má ve sprintu realizovat.
Petr Svoboda / ShopSys