Ve válce jsme - zpět na článek

Ono to může fungovat, ale jen za předpokladu že všichni v procesu ví která bije. Což se v realitě neděje, protože ve většině firem je projektový manažer reálně markeťák který zjistil že projektový management je v kurzu, takže teď je jako projektový manažer, přičemž jeho projektové řízení je obvykle ve stylu „mě tyhle technikálie nezajímaj, jede ti to nebo ne?“ a věty z kterých se každému ajťákovi otvírá kudla v kapse – např. „ale tohle v 99 % nenastane, tak to nemusíme zas tak moc řešit“. Vysvětlit mu, že buď to nenastane ve 100 % případů čili se to řešit nemusí, nebo to nastat může a musí se to nějak vyřešit ať už to nastane v 0.01 % případů nebo v 99 % případů je v zásadě nemožné.

Agilní programování je pro tyhle lidi modla, protože ve vývoji platí Paretovo pravidlo: oni vidí že za týden máte 80 % výsledku, takže pak mají ten postoj „teď už to jen doťuknem a kasírujem“. Takže další týden ve středu předpokládají dokončení. A když to ještě ten další týden nemáte, už začínají řešit „co kurva děláte, dyť to bylo před tejdnem hotový“. Nejlepší jsou od takových lidí projektové dokumentace… to nemá cenu ani papíru na kterém to je.

No, z mé zkušenosti – jediný dobrý projektový manažer byl ten, který v minulosti sám programoval. Všichni ostatní stáli za pendrek nezávisle na snaze pochopit která bije.

Paya: tohle je právě gró idiotskosti – jinak se to říct nedá – Agilu.

Pokud vzniká cokoli většího než primitivní mobilní/webová „appka“, NENÍ MOŽNÉ VALIDOVAT MALÉ CELKY, protože nemají žádný grafický výstup/vstup kterému by zákazník rozuměl, protože jsou to interní datové a algoritmické struktury.

Nebo názorněji: pokud stavím parní lokomotivu, co budu přesně se zákazníkem validovat v jednotlivých iteracích? První iteraci rám, druhou tu šíleně složitou spleť trubek v kotli a termodynamický návrh kotliště:
https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.ytimg.com%2Fvi%2FQImXVYEtiGc%2Fmaxresdefault.jpg&f=1&nofb=1
třetí iteraci interní mechanismus šoupátek a pístů, čtvrtou vnitřnosti automatického přikládání uhlí a konstrukci táhel, pátou vyvážení kol, šestou tlakování a sedmou odpružení podvozku?

Co přesně na tom bude „validovat“ zákazník, jehož požadavek je „postavte mi parní lokomotivu, který utáhne n tun nákladu rychlostí v při spotřebě uhlí m tun a životnosti t let“?

Architektura musí být DANÁ předtím, než začne kódování samotné. To je jaksi esenciální vlastnost architektury – že se staví podle ní, aby vše fungovalo. Refaktoring totiž nutně zanáší do integrovaného systému velké množství mrtvého kódu a jiných chyb a tudíž je extrémně nežádoucí.

K poslední větě – ano, dá se to dělat relativně dobře – pokud buď prodloužíte iterace tak, že trvají alespoň 3 měsíce což byl průměrný vývojový čas jedné funkce/featury v Enterprise software předtím, než přišli Agile koučové… Nebo pokud vyvíjíte tak směšně malé appky, že ji opravdu dovedete celou včetně UI dokončit za 1 sprint.

fatdwi: pokud děláte aplikaci, kde dovedete každou její featuru vyvinout za jednu iteraci krátkou 2 týdny až do uživatelem pochopitelných výstupů… Tak prostě nemáte moc velkou aplikaci nebo moc složité featury ;-) To je celé.

Pokud je výstupem 80% featur/modulů v systému nějaká složitá binární struktura, kterou pak využije jiný modul, aby umožnil ještě jiným modulům z toho nakonec dostat celou řadu užitečných dat, která jsou teprve viditelná… Taková binární struktura coby výstup modulu/featury a výsledek sprintu je přesně tak srozumitelná koncovému zákazníku, jako termodynamika kotle parní lokomotivy, tzn. vůbec. Za tím si stojím.

Zažil jsem mnoho hodin brutálních hádek s dogmatickými Agile Coachi a Scrum Mastery kteří tvrdili přesně to, co předřečníci včetně vás – že „každá funkcionalita se dá rozdělit na featury které se dají vyvinout zas 1 sprint“, že „pokud se to nedá stihnout za 1 sprint, musí to jít rozdělit“ atd. A Waterfall se netoleruje ani tam, kde dává smysl, protože Waterfall je špatný a Agile je dobrý, áááno.

Všechny firmy dnes dogmaticky a fanaticky jedou linii „Agile je jediný správný druh vývoje“ a kdo tomu nechce rozumět, toho si podá Agilní Kouč s vyšším managedementem a buď dostane padáka, nebo se do takové firmy ani nikdy nedostane. Agile je dnes náboženství.

Paya: já chápu tu teorii. Slyšel jsem ji tisíckrát. Je tak úúúžasná a dokonalá. Akorát že jaksi nemá průnik s praxí.

A to mj. a minimálně proto, že ten, kdo software nakupuje (vyšší management) je světelné roky vzdálen od toho, kdo jej používá (úředníci či technický personál) a proto má úplně jiné požadavky, hodnoty a přístup, než koncoví uživatelé.

Opět samozřejmě pokud se bavíme o něčem specifičtějším, než appkách na smartphone nebo kancelářských balících, které používá každý vč. toho vyššího managementu.

Já si nic nepřidávám, já odhaluji v plné nahotě pokrytectví Agilu přesně tak, jak jej popisujete vy, fatdwi a 11 z 10 Agile coachů.

„Smyslem Agilu je dodávat v krátkých ITERACÍCH hotovou funkcionalitu malých celků, kterou je možné PŘEDVÉST zákazníkovi aby mohla být VALIDOVÁNA a případně včasně předělána.“

Pokud výstupem jedné iterace není featura kterou lze předvést zákazníkovi a validovat, Agile nedává smysl – stane se arbitrárním procesem sekání práce pro sekání samotné.

Pokud jste schopen odhadnout náročnost vývoje na den přesně, jste lepší než všichni vývojáři se kterými jsem kdy dělal – od absolventů až po 70leté matadory – a lepší než jakýkoli vývojář, o kterém jsem kdy v životě slyšel. Jste kouzelník, génius, superman a já se kořím před vašimi výkony.

Jan Mrcasik:
“ tvrdili přesně to, co předřečníci včetně vás, že „každá funkcionalita se dá rozdělit na featury které se dají vyvinout zas 1 sprint“, že „pokud se to nedá stihnout za 1 sprint, musí to jít rozdělit“ atd“

Můžete ocitovat, z čeho jste tu naprostou kravinu v mém příspěvku vyčetl? Zkuste se víc soustředit na to, co jiní píší a méně na své projekce.

„Všechny firmy dnes dogmaticky a fanaticky jedou linii…“

Pokud jste z mého příspěvku mohl něco skutečně vyčíst, tak právě to, že toto Vaše tvrzení je omyl, daný tím, že jste pravděpodobně omezený na zkušenosti ve firmách, které takto fungují. Přečtěte si ale můj druhý odstavec a tam to máte černé na bílém. Své tvrzení můžete tedy v klidu opravit na „Všechny firmy ve kterých dnes pracuji dogmaticiky a fanaticky…“ a následně se zamyslete nad tím, proč tam teda jste, když je to taková hrůza?

Jan Mrcasik: nikdo netvrdi ze je spravne to tak delat vsude, jenom namitam ze to fungovat muze.
Muzu vas ubezpecit ze tak vesele vznika patrne vetsina sebevetsiho softwaru v soucasnosti, nekdy s lepsima, nekdy pravda s horsima vysledkama.

Napr. to UI se da navrhovat a validovat soucasne s backendem i kdyby se mela budouci funkcionalita nasimulovat – to my v sw develpmentu umime, nevim jak v lokomotivach.

Architektura se v softwaru meni neustale – to neni nic zvlastniho. Spis jde o to ji navrhovat/menit s rozmyslem a tak aby se v budoucnu musela menit co nejmin nebo to bylo jednoduchy.

Featura na 3 mesice se stejne musi rozsekat aby se dala lip planovat a trackovat. Ale vase predstava o delce trvani implementace je uplne mimo (patrne uvazujete jako featuru mnohem vetsi celek nez na kterych se realne pracuje). 3 mesice je major vec ktera se klidne mesic planuje vc. architektury. Vetsina featur je hotova vcetne testu v ramci dni.

Jan Mrcasik: Moc by pomohlo, kdybyste si nechal svoje projekce a soudy o me od cesty, vite o me s prominutim hovno (a ste vedle jak ta jedle ve vsem co o me min v tomhle postu dedikujete a pak nad tim slavnostne vitezite).

Vase osobni zkusenost se miji s mou. Nemam potrebu vas jakkoliv presvedcovat, jen sdilim jinej pohled a to ten ze to muze fungovat.