Racionální, nekonspirační důvody, proč odmítnout vakcínu na nCOV-19 - zpět na článek

Nezlobte, se, ale nerozumíme si:
nejprve možná toto, aby bylo jasno, kam mířím: http://lukas.plachy.eu/kb/SDLC.png
I) „nejde o cizelování a vylepšování toho stejného,“ vs. „ale inkrementální přidávání funkcionality“ …. nechápu, jak je lze na dané úrovni level-of-detail napsat tyto dvě věty a postavit je proti sobě, když je to přece přesně totéž. Inkrementální přidávání funkcionality přeci není nic jiného, než vylepšování a cizelování téhož předmětu (zakázky, projektu…) a vice versa.
Marně tápu, co vás mohlo svést na scestí a jediné, co mne napadá je, že pokud byste si – snad, hypoteticky – pod „cizelováním a vylepšováním“ představoval věci jako například refaktoring kódu, (výhradně) ladění (už existujících funkcionalit) atp. tak to už jste ale opustil projektové řízení a jsme někde úplně jinde, to jsou totiž činnosti, které nemají (na projektové úrovni) svůj vlastní životní cyklus, ale jsou pouze jeho součástí či nástrojem. Ale to tedy pouze pokud jste měla takovou představu „cizelování a vylepšování“.

„analogie s agile je mimo“ – já jsem spirálu původně do této debaty nezavlekl, to vy jste ji tam nacpal kvůli těm vodopádům. Když tedy nyní píšete, že analogie s agile je mimo, tak popíráte sám sebe. Spirála – jak ostatně popisuji na příkladu těch vodopádů v předchozím příspěvku – s agile analogická určitě není, myslím, že jsem to dokonce psal („Spirála je něco zcela jiného a určitě to není sada malých vodopádků…“)

II) ad agile – 1. … to je zásadní nepochopení běžných řídící postupů a čiší mi v tom v pozadí velmi teoretický přístup odpojený od praxe. Neexistuje čistě agile jednotka, tedy i když uděláte agile tým, dycky mu bude někdo šéfovat, a dycky bude někdo ovlivňovat jeho členy, pravidla hry, metodiky. Prostě, vždycky to bude někdo řídit a i kdyby to bylo jen metodicky, je to pořád součást managementu. A to je přesně ten moment, kdy se do hry vložili manažeři a pochopili agile dost ukrutně … no .. asi bych řekl blbě (tak jak popisuji výše s X a Y).
II) 2. ad zbylé tři odrážky: ale Vy mi argumentujete hypoteticky teoretickým pravidlem agilních metodik a já argumentuji jejich reálnými implementacemi, o které na začátku říkam, jak je z****á (jak se toho chytili manažeři atd.), tak to se na mě nezlobte, ale takový argument nelze reflektovat. Podle dopravních předpisů by taky měl být na silnicích ráj…

Vy se mi snažíte zkrátka vysvětlit, že to, co tvrdím, je pravda a tudíž pravdu nemám – takovou sofistiku považuji za poněkud neomalenou. Neboli: argumentujete tím, že když říkam, že (volně parafrázováno) „agile není v pořádku, protože je obvykle (organizačně) implementován dost blbě“ tak (pokud správně parafrázuji Vaše vývody) „agile je v pořádku, protože když není, tak je obvykle (organizačně) blbě implementován“, což – pokud jsem tedy trefil smysl Vašich tvrzení – je přesně ve shodě s tím, čím začínal můj původní příspěvek.

Tedy, na rozdíl od Vašich vývodů, které mi přijdou založené spíše na teoretické stránce „jak by to mělo být“, jsem už o implementace agilních postupů zakopnul a – vztaženo k původnímu agilnímu manifestu – jsem se už dost zhrozil, a abych řekl pravdu i znechutil. Argumentovat mi tedy tím, že (opět zkouším, doufám, že korektně, sumarizovat) „kdyby byly agile implementován správně, byl by (sám o sobě, nikoliv pro vývoj léku) ok, tedy agile je ok a to co píšete je v té teorii špatně + když argumentujete agilem, tak s ním souhlasíte pro použití ve farmakologii“ na moje tvrzení „agile je teoreticky hrozně hezkej, jenže obvykle (prakticky, reálně) tak zprasenej, že argumentovat jím (v původním článku pro vývoj léku) není ok“ je, pokud jsem oba výroky správně zapsal, fakt velmi velmi ošklivé, protože jsem hluboce alergický na případy, kdy jsou výroky „myslím, že je to X“ argumentovány hospodskou argumentací typu: „nikoliv, nemáte pravdu, je to totiž X“.

Jinak technická: o akcích které musejí proběhnout za sebou a kritické cestě tuším píšu ve svém původním příspěvku taky. Jenže zatímco kritická cesta zkrátit opravdu nejde jaxi z definice, tak ovšem existují postupy, které umožní rozpojit závislosti jednotlivých (projektových) akcí na sobě a tím rozpojit i kritickou cestu (a tedy tím ji ‚zkrátit‘ – to je samozřejmě vulgárně, nepřesně, slangově řečeno, ale v praxi se často používají takovéto „hlouposti“ s tím, že všichni zúčastnění vědí, oč jde). A to bylo meritum mého původního příspěvku, které hovořilo o tom, že opravdu paralelizace je možná, a je to otázka jemnějších vstupně/výstupních závislostí projektových akcí, jejichž závislosti zde nicméně neznáme a pokud jejich závislosti lze rozpojit (v případě softwarového vývoje se používají mockupy/prototypy rozhraní, zpráv, datových souborů atp., v konstrukčních oborech pak jsem slyšel o vhodně použitých maketách, přípravcích atp., které doopravdy umožnily například vybavit tramvaj několika kilometry kabeláže dříve, než byla zmíněná tramvaj vyrobena), pak je paralelizace možná. Argumentovat (v případě diskutovaného problému) příklady, kde to nejde je hezké, ale ne vyčerpávající a tedy to neprokazuje tuto nemožnost paralelizace.
Zde například vůbec nejde o sledování terapeutických účinků, ale díval bych se třeba na všechny tři fáze klinické studie a hledal bych tam otázku, jak to, že když dříve běhaly striktně za sebou, tak najednou běží paralelně … a třeba (říkám třeba!) … bychom zjistili, že jejich sériovost byla podmíněna jen byrokratickou mašinérií a vůbec nemá opodstatnění, tedy II. fáze nepotřebuje žádné vstupy z fáze I. atp. Není to můj obor, neumím to tedy potvrdit, ale vím, že bez detailní znalosti I/O projektových akcí to neumím ani vyloučit a to je také to, co v původním příspěvku píšu autorovi článku.