Vlákno názorů k článku Budoucností vývoje velkých e-shopů jsou agilní kontrakty od PK - Kazdy takto veliky projekt ma rozpocet, za ktery...
-
PK (neregistrovaný)
Kazdy takto veliky projekt ma rozpocet, za ktery musi projektak predstavit investorovi finalni produkt, jestliže bude pred kazdym sprintem upresnovat pozadavky, ktere odhad dodavatele zvedne o X hodin, bude mu techto X hodin chybět na dalsi upravy a toto se muze postupně nabalovat az tak, ze dva mesice pred predanim bude budget (hodinovy nebo financni, to je fuk protoze to je to same) vycerpany a investor se bude zlobit. Klíčem je tedy mit dostatečný polstar na to, aby byl pri agilnim vyvoji prostor chovat se opravdu agilne a dostatecne skutecnosti dodavatele ci projektaka, ktery velikost polstare spravne odhadne.
Jinak s agilnim vyvojem souhlasim a nedokazu si predstavit rik dopredu nalajnovat neco, co dodavatel zavre na upravy pres kazdym dilcm vyvojem casti dila.
-
Tomáš2 (neregistrovaný)
s tímhle bych nesouhlasil.
Hlavní vlastnostní agilního vývoje je, že samotný produkt je velice rychle funkční a postupně se mu staví nové a nové vlastnosti, tj. ikdyž dojde k vyčerpání budgetu, pořád se může použít již zaplacená a dodělaná část.
Agilní vývoj minimalizuje cenu slepých větvý a daleko dříve na ně upozorňuje. U plánování je velice drahé najít a podchytit slepé větve dopředu, u složitých produktů to je skoro nemožné a cena je astronomická.
Všude kolem sebe máme krásné příklady, facebook, google, AMD, operační systémy a další jedou spíše agilní vývoj, rychlé obrátky produktů a postupná validace změn, náklady se počítají průběžně (třeba měsíčně). Naopak veškeré státní zakázky jsou striktně plánované, náklady se počítají na celý několikaletý vývoj, částky jsou astronomické. Stejná situace panuje třeba u vývoj vesmírných družic u NASA.
Je-li pro mě důležitý přesný výsledek za předem jasnou cenu v přesném termínu, agilnímu vývoji se vyhnu, ale připlatím si za to. Pokud jedna z těch věcí není pro mě stěžejní, na agilním vývoji ušetřím.
-
Dobrý den,
souhlasím. V naší branži jde typicky o migrace stávajících e-shopů na nové řešení.
I v tomto případě však zakázku realizujeme po sprintech, jakoby se měla aplikace po každém sprintu spustit do provozu. Postup je naprosto stejný s tím, že se na ostro spouští až např. po 8.sprintu (zákazník totiž nechce spustit e-shop s méně funkcemi, než měl předchozí a to je pochopitelné).
Petr Svoboda / ShopSys
-
Děkuji za postřeh. Nejsem však stejného názoru.
Naše zkušenost ukazuje, že čas ze strany zákazníka je v obou případech zhruba podobný. V případě agilních metodik vývoje je rozložen průběžně a v případě standardního modelu je největší množství věnováno až v konečné fázi (právě té stresující, kdy se předělává, opravuje, doprogramovájí se nové funkce, a kdy se odkládá termín spuštění).
Nemáme to však přesně kvantifikované - nikdy jsme nevyvíjeli velké e-shopy zároveň oběma způsoby, abychom to ve finále mohli porovnat.
Postupný vývoj, ladění a předávání vychází nákladově velmi podobně - ale verze ke spuštění dle očekávání klienta je dodána mnohem dříve a klient má průběžně nad projektem výrazně větší kontrolu.
V našem případě používáme pro agilní kontrakty naprosto stejnou kalkulaci cen prací.
V mnoha případech, kdy se některé části hotových funkcí po předložení klientovi zahazují, šetří postupný agilní vývoj také náklady (obou stran). Čas a peníze se tak mohou věnovat přínosnějším činnostem.
Petr Svoboda
-
fd (neregistrovaný)
Ale samozrejme ze souvisi, soucasti analyz je pochopitelne mimo jine i hodnoceni pouzitelnosti projektu. To sice neznamena, ze se nestane totez, ale pravdepodobnost se znacne redukuje.
Kdyz nic jineho, vznika nejaky navrh finalni podoby, o ktere v pripade, ze se rovnou pise, vlastne nikdo nema potuchy.
ČLÁNKY DO MAILU