Názory k článku Budoucností vývoje velkých e-shopů jsou agilní kontrakty

Omyl, komunismus byl do praxe uveden hned na první pokus. To, co vzniklo před 98 lety, byl přesný důsledek základních myšlenek komunismu.

Ne, agil jako celek určitě není špatně - ale jako pokaždé, není všespasitelný. Zákazníci rádi požadují agilní metodiky a zapomínají, že se tímto upisují k výrazně vyššímu zapojení do projektu - na což u nich není síla/znalost/zdro­je... Výsledek je pak zajímavý.

presne tak, a hlavne pri agilnim vyvoji musi byt zastupci businessu schopni a ochotni plnit svou roli.

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.

Ovsem na ktere strane, zda u zakaznika nebo dodavatele :-)))

Budoucnost velkych (a nejen tech) eshopu zavisi na jedine veci, kupni sile zakazniku. A ta se v teto zemi neustale pozvolna snizuje, i za prispeni CNB.

To ovšem nijak nesouvisí s metodikou vývoje

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.

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.

pri agilnim vyvoji platit vzdy za hodiny. a pokud je omezeny rozpocet, tak se pri agilnim vyvoji nemusi dostat na vsechny pozadavky (a proto by mely byt na zacatku zprioritizovane). kolegyne mela hezky obrazek, kde ukazovala rozdil mezi waterfallem s jeho dimenzemi/"tro­jimperativem" (cena-kvalita-cas) a agilnim pristupem (pri stanovenem rozpoctu se pracuje, dokud se nevycerpa, teda pokud se nahodou nestihne vsechno udelat)
nicmene dovedu si predstavit, ze kontrakt s dodavatelem kapacit na IT vyvoj bude znit "za 3 miliony kapacity analytika a za 3 miliony kapacity vyvojare" a kdyz bude chtit pak pokracovat, tak si priobjedna. ale to je zase platba "za hodiny".

Uvedu to hned ze začátku - dělám v ShopSys.

Souhlasím, že pro dodavatele je lepší dodat SW. Problém je, že u velkých projektů od zadání k předání uplyne několik měsíců a my sice dodáme SW podle zadání a analýzy, ale zákazník už to takto nechce a nepotřebuje, protože se změnila situace na trhu, je nový trend nebo se změnil obchodní ředitel a mají novou strategii (vše jsou reálné případy). Pro nás by bylo nejlepší jim to předat s tím, že vše je podle domluvy hotovo. Ale klient bude naštvaný. A to není situace, kterou chceme.

Proto se teď orientujeme na agilní kontrakty, protože zde může klient v půlce, kdy dostane část funkcí, říci, že toto už takto nechce a pak se řeší, jaké věci se odsunou. Také průběžně vidí, co je uděláno a průběžně si funkce přebírá... Je to pak více o komunikaci a domluvě a je mnohem větší pravděpodobnost, že na konci budeme jak my, tak klient spokojeni.

Pokud mne skleroza nemyli, tak by melo byt "Ucit se, ucit se, ucit se" :-)

A paranoia neumí psát, omlouvám se za překlepy

Ahoj. Nemám co dodat a plně s napsaným souhlasím.

ad 3. Ideální je mít pro role samostatné lidi. Někdy s ohledem na velikost týmu, velikost projektu a rozpočet je z naší zkušenosti ovšem sloučení rolí nutné a vhodné.

ad 4. I to je důvod, proč nejsou agilní kontrakty nasaditelné na všechny projekty ale pouze na ty, kde pracuje více lidí (a mohou se zastoupit) a při delší absenci může být do týmu přidán další zdroj/člověk.

ad 5. Spolupráce klienta se nám u agilních kontraktů ukázala jako naprosto zásadní proměnná. Nechceme po klientovi volné rozpočty (i při agilních kontraktech garantujeme předem pracnost/cenu jednotlivých činností/úprav. Chceme však častý kontakt, prioritizaci, sledování dem a připomínky. I proto píšeme tento článek a pokoušíme se dělat osvětu.

K tomu přemýšlení a meditaci vám připojím link, pokud se sem náhodou ještě vrátíte...
https://www.youtube.com/watch?v=a-BOSpxYJ9M

Dobrý den,
Takovému modelu nemám co vytknout, zdá se mi pro obě strany férový.
Držím vám palce.

Nerozumím, 90 hodin režijních prací, co se neuctuji. Kdo je platí?

Pri agile by se mely automaticky psat testovaci rutiny.
Podminovaci zpusob nebyl pouzit nahodne ci omylem ...

A jak je to při agile s testováním?

Při "klasickém" přístupu máte na konci ucelený SW produkt, který jste schopen komplexně otestovat na všechny závislosti a vlastnosti, než jej předáte. (Odhlédnu nyní od toho, že to již nemusí být ten produkt, který zákazník potřebuje.)

Při agile, jestli tomu dobře rozumím, tak na konci každého sprintu nejen abyste testoval to, co si při sprintu udělalo (a může to být funkce/vlastnost, se kterou se při původní analýze vůbec nepočítalo), ale abyste taky otestoval celý produkt, jelikož došlo k jeho změně. A nevíte, jestli nějaká nově nasazená záležitost neovlivnila již hotovou část.

Z textu a komentářů jsem pochopil, že náklady na režii bývají typicky větší než u klasicky řízených projektů (větší požadavky na součinnost zákazníka, management komunikace, atd.). Jsou zvýšené i náklady na testování?

Tak tedy ad 3- které role nejčastěji slučujete a proč? Pokdu to tedy není supertajná interní informace

takže to je vlastně taková alfa co se dodělává za provozu

Nebudu psát za ShopSys, ale za sebe (firma, ve které působím má i odvětví e-commerce řešení, na jednom z produktů je aplikována scrum metodika).
Náklady na testování jsou vyšší zejména zpočátku. Testeři všeobecně jsou bráni jako "režie", protože jejich práci nelze úplně dobře měřit. U nás testeři připravují x test scénářů, každý z nich má y test cases. Za jeden sprint cénářů vznikne třeba 30, podle nich se testuje průběžně (in-time testování). Na konci sprintu se všech 30 scénářů vezme a otestuje se znovu, spolu s již zpracovaným základním flow produktu. Případné konflikty se řeší s Product ownerem, pokud je třeba přepracovat, přichází na pomoc Scrum master.

Je samozřejmostí, že každý programátor zároveň píše unit testy, pokud to čas dovolí, jednou za delší období testeři připraví testovací den i programátorům, ať si vyzkouší sedět na druhé straně.

Mnoho firem bere testing jako okrajovou věc, což rozhoně není dobře, ve finále se to podepíše pod kvalitou výsledného produktu

Zavadil jsem o článek a diskusi po delší době. Moje zkušenost je ale aktuální.
U Shopsysu jsou agilní kontrakty spíše prostým záměrem, jak ze zadavatele vytáhnou více peněz na dotažení chyb. Bude-li projekt realizován dle smlouvy a v termínu, lze úpravy dělat brzy po předání. Protahuje-li se projekt k devíti měsícům po termínu jako ten náš, těžko uvažovat o úpravách, když není hotovo nasmlouvané. Jak mi potvrdil pan Svoboda, hodiny jsou vyčerpány, ale eshop ke spuštění nemíří. V průběhu devíti měsíců od pokusu o předání eshopu jsem musel vypisovat chyby implementace a funkčnosti a bylo jich opravdu hodně. Kodér to hrubě neuměl a neprováděl elementární kontrolu FE po nakódování. Realizované práce působily, jako by kodér specifikaci vůbec nečetl.
Při urgování dalšího zpoždění mi pan Svoboda vysvětlil, že měli problém s cash flow, takže preferovali eshopy, které mají blíže k dodělání a tímpádem i k úhradě a můj eshop vyhodnotily, že tam bude více práce, proto není prioritní.
Shopsysu by agilní kontrakty jistě pomohly, protože za dílčí práce by mohli inkasovat průběžně a za implementaci designu by zbýval menší doplatek, který by Shopsys tolik nepálil. Vše by se ale vleklo donekonečna a zadavatel by zaplakal. Zadavatelé, kteří mají stejnou zkušenost, do agilních kontraktů nepůjdou. Možná by Shopsysu místo agilních kontraktů pomohlo zavedení osobní odpovědnosti za odvedenou práci a menší střídání konzultantů u projektů, pak bude cash flow ok.
Agilní kontrakty jsou aplikovány především ve veřejném sektoru - téměř všechny se hrubě prodražily a zdržely (OpenCard, Tunel Blanka atd.).

To, že někdo agil neumí, neznamená, že celý agil je špatně. Bohužel pouze mizivé procento z firem co agile dělají jej umí.

Jen se zeptám, je to fix price, nebo cost-plus? Má zkušenost je že se všichni co mají něco společného (byť jen slovně) s agile snaží minimalizovat vývojové rozpočty a fixed priced kontrakty a produkt se dodělá, opraví se všechny chyby a doimplementují či přepracují všechny potřebné funkce až během SLA. Stane se pak ale přibližně toto.
Zadavatel nemá zvláštní potřebu moc přemýšlet o zadání. Objednává stylem: chci nové erp, nebo třeba eshop. Má vyčleneněn rozpočet a čas a ví, že produkt doopravdy dostane až po nějaké době běhu servisní smlouvy kdy bude podávat "reklamace". Dodavatel nemá zvláštní potřebu dojednat přesné zadání a ani vlastně jednat o ceně, protože předání je vlastně jen formální, cenu lze snadno uhlídat alokováním těch nejlevnějších lidí a že to bude mít chyby nikoho netrápí.
Během SLA pak nastává, že má zákazník motivaci čerpat co nejvíce hodin (opravy, konzultační hodiny, apod.), zatímco dodavatel ty hodiny již prodal a je motivován jich dodat co nejméně.

Na druhou stranu je to status quo akceptovaný již od začátku, takže to takto funguje. Je to ale výhodné, lepší?
Zadavatel zaplatí totéž a dostane tutéž funkčnost jako kdyby produkt objednal za fix a proběhla řádná analýza. Drobné plus je, že rozhodování můžu odložit, je to ale taky prvek nejistoty. Kupuju, ale nevím co. Mínus je, že produkt dostanu v nedeterministickém čase (zřejmě později).
Dodavatel má plus, že nemusí nic plánovat, nemusí nic rozhodovat, nemusí mít kvalitní zaměstnance, nemusí řešit termíny, kvalitu. Vlastně jediné co musí řešit je dohodnout ten kšeft a pak už je to bez rizika. Mínus je, že bez rizika není zisk.

____
Mluvím stále teoreticky, o vaší firmě nic nevím.

Dobře agilní metodiky, rozumím. Vrátím se na začátek, pokud proběhne analýza, která má být úplná a jednoznačně definovat podklady pro programátorskou práci, jak postupovat v vpřípadě, že úplná a jednoznačná není, tj při programování se pak musí značně improvizovat a upřesňovat. Vrací se peníze za analýzu, nebo jak v takovém případě postupujete?

Asi je nejlepší hned na začátku si rozmyslet za co chcete aby se platilo. Z pozice zákazníka i dodavatele. Jestli za dílo, nebo za hodiny.
Z pozice zákazníka pokud je obvykle vaší motivací obdržet hotový software, ale může být výhodné "uvázat" si pracovní sílu dodavatele pro adhoc úpravy když vlasně pořádně nevím co chci.
Z pozice dodavatele je obvykle výhodné dodat software a svou marži ovlivňovat interně řízením odpracovaných hodin (kvalitou pracovní síly), ale pokud nejsem schopen řídit firmu a motivovat lidi, může být výhodné "uvázat" svou pracovní sílu odběrateli a zajistit si pevný příjem.

Nechci soudit, ShopSys ani nejí zákazníky neznám, ale nemůže mít popisovaný neúspěch příčinu v souběhu těchto zmr.ehm jevů, tedy jakési neochoty podnikat v podnikání?

To je jako rikat, ze komunismus take neni spatny. Bohuzel zatim jej nikdo nedokazal uvest do praxe...

znám řadu firem, kde agilní vývoj funguje ku prospěchu a produktivita je po přechodu lepší.

Znám ale mnohem více firem, kde agilní vývoj nefunguje, bohužel.

Ano uvadite pekne priklady, predevsim proto, ze se pak dlouhe mesice vyvoje hodi pres palubu, protoze se v realu ukaze, ze to nikdo nechce pouzivat.

Kolik jen svych uzasnych projektu zrusil treba google?

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.

Agile je ideální pro projekty řešené vlastními lidmi uvnitř firmy. V takovém případě je dle mého ale velmi reálné nebezpečí, že z původně efektivního a pružného agilního přístupu se stane nástroj pro krytí IT urvaného ze řetězu. Na takové IT nikdo nemůže, protože termíny plní, náklady jsou fixní (přece ty interní lidi stejně živíme) a s funkcionalitou si vždycky pohne, aby to zvládlo.
Agilní projekty s externím dodavatelem se pak vymykají chápání přímo na realizaci nezainteresovaných osob, takže se pak kvůli nim nedá udělat nic jiného, než oba přístupy kombinovat a udělat takového kočkopsa - jen tak ale může být pozice dodavatele a odběratele vyrovnaná.

A jak pak vychází pracnost oproti klasickému modelu? Tady je mnohem více režie, i když i více kontroly ze strany zákazníka.
Nutně pak musejí vycházet agilní kontrakty jako dražší (a to i bez započítání práce na straně zákazníka)

1) nevim proč to není označeno za komerční článek
2) 400 mh mít v kategorii velký projekt...

Ahoj Petře, pěkný článek, je vidět, že nad agile uvažuješ a medituješ čím dál více:)

Zažila jsem pokusy o agile, agile stylem "nastudujeme si *vyber agilní metodiku*, skočíme na jedno školení a už všecko umíme" a pak jsem měla tu čest působit v týmu, kde se jelo na scrumu. Ale opravdu jelo, včetně aktivní účasti klienta během vývoje. Každodenní scrumy, plánování sprintů, sprint reviews, přesně dané role, okamžité řešení problémů... paráda:)

Jedna věc je mít agile nastudovaný horem spodem, ale jsou faktory, které agile minimálně hodně zadrhnou, ne-li absolutně zastaví. Ze zkušenosti je to hlavně:
1- neochota týmu dělat nové věci- ono je celkem jedno, jakou roli člověk v týmu zastává, pokud má s agilním vývojem nějaký problém, většinou to přenese i na ostatní a motivace i výsledky jdou dolů.
2- z nějakého důvodu nevhodně zvolení scrum masteři a product owneři- neboli role rozdělovače práce na člověkohodiny a člověk odpovědný za směřování vývoje a konečnou podobu produktu. To, že je někdo výborný projekťák ještě neznamená, že má na to být i výborným SM, stejně tak bezvadný analytik není vždycky nejlepším PO
3- jeden člověk ve více rolích- tohle úzce souvisí s dalším bodem. Zažila jsem pokusy sloučit roli scrum mastera a product ownera do jedné osoby, dopadlo to blbě (většinou pro toho člověka, protože toho měl prostě moc a žádný jiný pohled na věc). Stejně tak není dobré mít databázového specialistu, který se ale zároveň stará o kódování designu a ve volné chvíli testuje kolegům hotové úkoly. Taky tester/analytik/dě­večka pro všechno není dobrý nápad. Proč? Člověk tak ztrácí své pevné místo v týmu, svou roli, kupí se mu práce a nastává u něj pracovní schíza, kdy má pět pohledů na jednu věc, kteoru nakonec stejně nestihne, protože se nedovede rozhodnout.
4- nedostatečná kapacita týmu
Viz výše, pokud už jdu do projektu agilně, musím mít dopředu přehled o volných kapacitách a zároveň musím počítat s nejhorším možným scénářem- jeden programátor dlouhodobě nemocný, druhý odejde, scrum master otěhotní a product owner zemře (ad absurdum, já vím:) ). A i když se nedá plánovat vše na 100%, musím se situaci přizpůsobit a nesnažit se přizpůsobovat tým projektu. Protože pak už se každé plánování sprintu stává vlastně přesouváním nedokončených úkolů do dalšího sprintu a člověk je tam, kde byl před agile vývojem
5- nespolupráce klienta
Každý druhý klient si o agile něco načte a pak to strašně vyžaduje, pak už mu ale nedojde, že ho bude během vývoje pořád někdo prudit a chtít po něm konzultace, akceptace, schůzky... zejména z tohoto důvodu u nás v týmu agile není aktuálně dost dobře možný. Klient, jakožto logistická firma, má zaměstnance permanentně vytížené na 110% a na takovou spolupráci jednoduše nemá lidi.
6- absence sprint reviews
Většina lidí to bere jako otravu a zbytečnou schůzku, když přece všichni ví, co šlo v posledním releasu ven, ale chce to komplexní pohled jak na to, co se povedlo, tak taky na to, co se nepovedlo, kde jsou slabiny, na čem je třeba zapracovat. A to všechno pokud možno bez hádek a vzájemného obviňování.

Na svou etapu se scrumem vzpomínám moc ráda, je pravda, že tým sám o sobě byl složen z výjimečných lidí a myslím, že havně díky tomu a pořádnému vedení jsme byli schopni výborně komunikovat a hlavně dodat produkt v očekávané kvalitě bez zpoždění.

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 ;-).

V tom pripade je velice zajimave, ze ty komunity (odtud komunismus) stale, byt v malem, funguji, napriklad v Izraeli. A funguji prave s onou zakladni myslenkou, ze vse patri vsem, a kazdy dela to co umi.

Vy ani nevite, co to komunismus vlastne je.

Ono jsou i projekty, kde nelze zprovoznit pouze kus produktu. Třeba přepis staré aplikace do nového prostředí s převodem dat ...