Guest post: Kvalitář? Review? Řízení rizik? – k ničemu, softwarové projekty jen zdražují a zdržují. A nebo ne?

Dobrý den Johne, přátelé

rád bych využil možnosti zareagoval na články, kterými u tebe Zsolt Szabo nedávno otevřel téma vývoje softwaru.

Po pravdě, s články nejsem moc spokojený.

Začnu od konce, respektive od Zsoltova prvního článku. Ještě předtím bych ale rád varoval všechny programátory a vývojáře – dál nečtěte. Riskujete zvýšený krevní tlak a možná i pocit ukřivděnosti. 🙂

Zsolt rozebral možnosti vývoje web aplikace a vytvořil krásný rozhodovací strom. Jeho zásadní nevýhodou je však to, že i přes Zsoltovu snahu nebere v potaz realitu většiny podnikatelů, tedy lidí bez jakýchkoli znalostí o vývoji softwaru.

Většina programátorů apriori předpokládá, že všichni podnikatelé tuší, co software je, co všechno (a proč) obsahuje i jak vzniká.

Lidé, na které Zsoltův článek míří, však podle mě nemají žádnou potřebu tomu rozumět. Nepotřebují a nechtějí vědět, co je frontend a backend. Vůbec je nezajímá, jak se objeví(?) funkčnost, kterou vyžadují.

Pro podnikatele jsou důležité jiné věci – aby bylo hotovo co nejdříve a nejlevněji, aby software dělal to, co má, kdy a kde má a aby vypadal podle jejich představ. A to je kámen úrazu.

Další článek zametl s celou problematikou proč je něco vyvinuté pozdě jen tvrzením, že podnikatelé jsou příliš optimističtí a že nebyl správně definovaný rozsah. Škoda, že nezmínil, že existují spousty přístupů a metodik, jak se přesně tomuhle vyhnout.

Abych si přihřál polívčičku, tohle přesně je práce projekťáka u dodavatele a quality managera na straně objednatele. A není to vážně tak triviální. (Tedy, pokud se nesmíříte s pseudo-agile přístupem, kdy prostě platíte programátora, dokud to nevypadá, jak chcete. A on přepisuje tam a zpátky podle toho, jak pískáte. To ale v realitě skončí spokojeností málokdy.)

Vývoj softwaru totiž není hladká cestička a obsahuje spoustu odboček, na které zadavatel nemyslí a jejichž opomenutí se připomene mnohem později a za mnohem více peněz, než kdyby se tyto problémy řešily včas.

V zásadě jste zcela vydáni na milost a nemilost dodavateli, spoléháte na jeho profesionalitu a doufáte, že se nenechá přemluvit k šetření na nesprávných místech. A to je kámen úrazu, protože z principu dodavatel chce jen vydělat a všechny tyhle metodiky a přístupy ukusují z rozpočtu a z jeho zisku. A kdo si na sebe chce dobrovolně ušít bič profesionálního dohledu, že?

Horší je, když má podnikatel pocit, že vývoji softwaru rozumí, protože už jeden projekt v praxi viděl, ve firmě spustili webové stránky vytvořené v ekosystému WordPress, či se dokonce kdysi na škole učil programovat. Takový podnikatel má představu, že už vše viděl a když bude projekt řídit jako svoji firmu, tak vše ohlídá, bude to včas a skoro zadarmo. Z jeho pohledu dodavatelé všechno jen zbytečně komplikují.

Takový projekt obvykle končí totální katastrofou. Obzvlášť když je dodavatelem kodér (úmyslně neříkám programátor nebo developer) bez znalosti projektového řízení (a co hůř, s představou, že to v žádném případě nepotřebuje), nemůže to dopadnout jinak než nespokojeností obou zúčastněných stran.

A tím bych ukončil obecné povídání. John mě požádal, abych se podělil o skutečné příběhy katastrof, jichž jsem byl svědkem za 18 let, co tohle dělám.

Jednotlivé příběhy jsem musel kvůli NDA anonymizovat, ale pokud se v tom poznáte, tak je to čistě shoda náhod. 🙂

Moje práce bohužel není vidět. Když ji dělám pořádně, od začátku projektu, tak vlastně projekt běží hladce a rizika, o kterých mluvím, nikdy nenastanou, takže jsem “zbytečný”.
Problémy, kterým zabráním, z definice nenastanou.

Takže zábavné jsou samozřejmě ty ostatní historky.

Příběh první: Pohřbená multikára aneb “To není potřeba testovat, vždyť to běhá u desítek zákazníků roky”

Kdybych dostal stovku pokaždé, když slyším “to je ověřený kód, to nám běhá v x zařízeních roky”, byl bych na tom jako John. Bohužel, tenhle argument je naprosto neplatný. Jediné, co to znamená je, že se chyba ještě neprojevila.

Chci to ukázat na následujícím případu – software, velmi jednoduchý, v zásadě jen řídil dávkovač písku v lomu.

Dovedete si představit stav, ve kterém dorazil nebohý majitel firmy ráno do práce, když mu ve 3 hodiny ráno zavolali z kamenolomu, že jeho software namísto 1 kubíku nasypal 9 a jen díky tomu, že šel řidič na cigáro a množství zadával z vnějšku kabiny, nemusí řešit smrťák?

Ano, software fungoval skvěle, jen prostě proměnná “kolik” nebyla (tentokrát?) binárně “0001” ale “1010” (tedy 9). Díky intenzivnímu zkoumání jsme nakonec našli problém.

Programátor šetřil pamětí a využil zbytek registru na počítadlo doby od restartu. No a po uplynutí “1111 1111 1111 ” hodin (tedy 4095 hodin decimálně, neboli 170 dní) bez restartu přeteklo počítadlo o paměťovou buňku vedle.

Tato řídicí jednotka běžela minimálně 6 let v provozu, než chyba nastala, a stejných cca 80 jednotek je roztroušeno po Evropě.

Argument “roky nám to funguje” prostě není a nikdy nebude platný. Pravděpodobně si říkáte, že tato chyba měla být nalezena při testování. Bohužel, takový test, který by odhalil všechny možné chyby tohoto druhu, lze napsat snad jen pro družici (psal jsem to), ale pro 80 jednotek do lomu je to totální overkill.

Šlo tomu tedy předejít testováním? Ne.

Šlo tomu předejít jinak? Samozřejmě že ano. Stačilo nastavit správně coding standard (standard pro kódování = jak co psát, jaké konstrukty používat a jaké ne) a udělat jednoduchou revizi kódu druhým programátorem.

Jenže to stojí trochu času a navíc je to “zbytečná práce”.

A moje zbytečná práce je nutit ostatní dělat tyhle zbytečné práce. Nakonec pak většinou ale nepohřbíme náklaďák pod hromadou písku.

Příběh druhý: “Kolik stojí jeden vadný bit”
Když jsme mluvili o testování, vždycky je otázka, kolik do testování chceme investovat a proč. To řeší docela složitý proces řízení rizik. (Opět PM/QM práce.)

Ale není to vlastně zbytečné? Navíc testování je “drahé a neproduktivní”, Ne?

A proč vlastně tohle píšu? Neb příběh, kolik stojí jeden bit.

Představte si sériovou produkci kde výsledkem je ECU včetně softwaru. Na každém kusu, který linka vyrobí, firma vydělá 5 Euro. Měsíčně jich linka vyrobí 200 000.

Bavíme se o jedné z asi 50 řídicích jednotek, které má moderní auto napojené na sběrnice. Tedy vážný vývoj, ne jako v předchozím příběhu, který byl v zásadě o prototypové výrobě.

Software v jednotce měl jít aktualizovat při servisu. Bohužel, programátor, který software psal ho do jednotky nahrával jen přes testovací stanici. Žádný z testů probíhajících v emulovaném prostředí nebyl schopen odhalit, že vlastně přes sběrnici nahrát nejde, a to kvůli jednomu přeplému bitu.

Nechci se bavit o tom jak a zda mohla být tahle chyba odhalena, jen vám chci ukázat jaké důsledky mohou nastat z byznysové stránky a o čem jako kvalitář taky uvažuju.

Jednotka stojí 10 EUR, zisk je na ní 5 EUR. Jediné řešení je ji při servisu prostě nahradit. Za to si servis účtuje cca 100 EUR navíc za práci (a 5 EUR za novou jednotku je náš náklad).

Jednotek s touto vadou bylo vyrobeno 350 000 (linka jela skoro dva měsíce).
Takže jeden vadný bit stál zhruba 36 milionů EUR.

Možná by byl lepší nápad zaplatit víc testerů a kvalitářů, a smířit se s tím že vývoj bude o půlku delší, že?

Příběh třetí: “Ty papíry nepotřebuju, hlavně ať to rychle jezdí”

Znáte ten pocit, když zákazník nemá vždy pravdu? Když chce nesmysl? To se ještě dá překousnout. Problém je, když Vám tvrdí něco jiného, než co má ve smlouvě.

Ve smlouvě na rekonstrukci tramvaje byla schovaná noticka, “a vývoj proběhne dle BOSTRAB”.

Nikdo z obchodu si s ní nedělal starosti, vývojáři se snažili aby tramvaj fungovala jak má, zákazník nás popoháněl.

“Dokumentace? Analýzy? Zkoušky? To já nepotřebuju.” i to je Vám schopen zákazník oficiálně oznámit.

Bohužel, když byl prototyp hotov, tak zákazník prohlásil: “Za 14 dní máte termín, kdy budete řešení obhajovat na drážním úřadě jako změnu na schváleném typu”. Což je právě to, co BOSTRAB řeší.

A tehdy začalo půlroční peklo dopisování dokumentace, zpětné vytváření analýz a, upřímně, i falšování záznamů o věcech, co s funkčním prototypem už nejdou dělat.

Ano, zákazník nic nepotřeboval, ale drážní úřad ano. A firma to celou dobu měla ve smlouvě.

Požadavky na vývoj podle něčeho, případně doložit zkouškou, má obrovské dopady na to, co musíte a jak to musíte udělat.

SW kvalita je tady právě kvůli adekvátní analýze problému a ušetření obdobných krizí.

Příběh ćtvrtý: “Analýzu rizik udělejte až zpětně, je to jen plýtvání časem”
Jednotlivé kroky výrobního procesu mají svůj čas a místo. Když je chcete dodělávat zpětně, stává se z nich jen formalismus, který nic nepřináší. Přinejhorším pak musíte všechno zpětně předělat. A to je drahé.

Typickým případem je analýza rizik na designu (FMEDA).

V metru jsou dveře, které se otevírají na povel z nadřazeného systému. Otevírá je motor, který zná polohu dveří, ale tu si ve skutečnosti jen dopočítává jeho řídicí jednotka na základě povelů do motoru.
Ve dveřích je senzor (kontakt), který detekuje, jestli jsou dveře zavřené a nebo ne.

Pokud děláte analýzu rizik zpětně, můžete se dostat do následující situace.

Nad dveřmi jsou dvě řídicí jednotky připojené na dvě nezávislé sběrnice, které řeší spoustu věcí v segmentu vozu, kromě ovládání dveří. Je potřeba z nich vyvést kabely pro čtení senzoru a pro ovládání motoru.

Projektant (navrhuje kabeláž, úchyty, prostě mechaniku) vám klidně zavede obojí do jedné jednotky. Elektrický návrhář s tím nemá problém. Programátor do ní v pohodě napíše logiku ovládání i logiku detekce zavření.

Nikdo neudělal nic špatně, všichni udělali svou práci jak měli. Vše funguje.

Ale je tu obrovský bezpečnostní problém. Ano, a to je právě obor FMEDA – detekovat problémy a řešit je změnou v návrhu.

Pokud tato jednotka selže, naprosto nevíte, jestli jsou dveře zavřené nebo otevřené. (A pokud selže pořádně, ani nevíte že selhala a myslíte si, že víte v jakém jsou stavu.)

A pak se metro rozjede s otevřenýma dveřma…

Řešení je strašně jednoduché, stačí mít ovládání v jedné a detekci v druhé jednotce (která tam tak jako tak je).

Malá změna v kabelovém svazku a přesun kódu z jedné jednotky do druhé.

Ve fázi vývoje je to práce možna na 2 hodiny s nulovými náklady.

Když ale máte ve výrobě zadané všechny přípravky a všechny kabelové svazky, tak se jedná o změnu za stovky tisíc v nákladech.

A to vážně nechcete.

Jo, není nad to dodělávat ty “papíry” zpětně, hlavně ať nám jede výroba.

Příběh pátý: “Vždyť je to jen beta verze a nikdo ji nenajde”

Bezpečnost informací
– řešíte to vůbec? Co vás možná zajímá jsou zkratky jako GDPR, ISO27000….
Ale vážně chápete příčiny?

Byla jedna firma v hyperkonkurenčním prostředí. Ta si nechávala vyvíjet svůj nový e-shop a jako obvykle, nechala vše na dodavatelích.
Dokonce, protože je to jednodušší, jim poskytla pro vývoj svou ostrou databázi zákazníků a data o smlouvách.
Proč ne, přeci se to bude importovat tak jako tak.
Proč dělat anonymizovaný testovací dataset, to je plýtvání časem a penězi.

Bohužel, jak říkám, prostředí je hyperkonkurenční a jeden konkurent si googlil a hledal. Hledal něco úplně jiného, ale našel beta verzi eshopu. Začal tedy klikat a zkoušet.

Doteď dobrý, mohl si prohlédnout design, možná se inspirovat, ale to by mohl za měsíc při spuštěné ostré verze tak jako tak.

Naneštěstí pro firmu a naštěstí pro něj, si něco chtěl přes ctrl+a zkopírovat. A najednou si při označení všeho všiml bílého linku na bílém pozadí – Admin. (Jo jo, super nápad, takhle schovat nezabezpečený vývojářský přístup, toho si nikdo nevšimne…)

A díky tomu si vytáhl celou databázi zákazníků, uzavřených smluv a cenových nabídek.

Moc dobře pro něj, zisk pár miliónů a desítek přetažených zákazníků.

Jo, byla to jen betaverze na doméně z gabonu…

Příběh poslední : “Dokumentaci i kód máme, tady v té skříni”
Možná jste už slyšeli o Cargo kultu. Napodobování vnějších znaků nějaké činnosti totálně bez pochopení toho, k čemu slouží.

Krásným příkladem je firma, která slyšela, že s vyvinutým SW by měla dostat i zdrojový kód. Mít zdrojový kód je dobrá věc, jde pak změnit dodavatel. Ale když přišlo na věc, bylo vše jinak.
Ono totiž předat někomu 500 vytištěných stran s tím, že tady je zdrojový kód, je dost na nic. Mám dojem, že netaktní vývojář se u zákazníka smál snad deset minut.

A firma zaplakala a vyvíjet se muselo z čisté louky.

Není to osamocený případ a problémem není jen kód. Netušíte kolik věcí exportovaných do PDF jsem viděl. Designy, schémata, pokladačky, ale třeba i grafiku.
K čemu to je, když to zpětně do nástroje nenahrajete?
Povím vám to, je to k ničemu…

Vývojová dokumentace má sloužit k tomu, aby jste byli schopni ze zálohy (archivu) obnovit projekt tak, aby šlo jednoduše a levně opravit malou chyby nebo přidat novou funkci. Ne proto abyste měli “papíry”, protože to chce standard.

A tak je to bohužel se vším. Doufám, že jsem vám na pár případech ukázal proč a jak je lepší se občas zastavit a přemýšlet, že standardy nejsou jen papíry a pro úřady, a že hurá přístup není ani nejlevnější ani nejrychlejší.

Kdybyste si chtěli popovídat, nebo se na něco zeptat, moje stránky jsou www.softsyng.com a můj linkedin je https://www.linkedin.com/profile/view?id=46111140&trk=nav_responsive_tab_prof a mail je petr.svimbersky@softsyng.com

Bohužel vím, že stejně si musíte prožít alespoň jeden podobný příběh, než vás napadne, že je možná dobrý nápad nedělat vše sami a nevynalézat znovu kolo.

Povězte mi v komentářích, jak se strašně mýlím a dramatizuju,
Petr

Spread the love

28 thoughts on “Guest post: Kvalitář? Review? Řízení rizik? – k ničemu, softwarové projekty jen zdražují a zdržují. A nebo ne?

  1. Skvělý článek, jen “osobně” nevím proč je tam toto varování:

    > Ještě předtím bych ale rád varoval všechny programátory a vývojáře – dál nečtěte. Riskujete zvýšený krevní tlak a možná i pocit ukřivděnosti.

    Již několik let se živím programováním a mám podobné zkušenosti i názory.

    1. Zcela souhlasím. Akorát to u mě to není několik let, ale 20 let. Vždycky si říkám, že bych si měl ty historky zapamatovat, abych jednou měl co vyprávět vnoučatům, ale většinu jsem už (raději) zapomněl… :-).

  2. chapu co jsi tim chtel rict, ale nestastne zvolena forma odradi spoustu lidi od precteni, trosku ubrat textu a budes mit vice pozornosti.

    ** poslednich par mesicu mam moznost pracovat na Risk management & compliance software pro ruzne banky a nestacim se divit jak s rizikem v techto institucich nakladaji (cti nenakladaji).

    1. Díky za feedback, jj je to na víc článků (po pravdě dělám školení a konzultace od minimálně 8hodin do dlouhodobé spolupráce, tohle je fakt široké téma), ale John chtěl spíš příhody ze života. Tak jsem vybral ty co něco říkají (a mají zábavný efekt)

      JJ člověk se nestačí divit, co je možný 🙂
      P.

  3. Ahoj, to co pises je validni. Jen takove sluzby rizeni dodavatelu a krizovy management SW jsou urceny pro firmy s vetsimi budgety a robustnimi jiz rozjetymi procesy viz. tvuj velmi bohaty background. Start-upy na druhou stranu funguji jako pirati, potrebuji rychle otestovat svuj SW v praxi, nevedi, jestli to cele k necemu je a hlavne do toho musi dat co nejmene penez. Jenom prece jde o penize z jejich kapsy a nebo kapes mensich investoru.

    1. Ahoj,
      no máš pravdu, ale co je to větší budget?

      Za mne se vyplatí věci dobře řídit, pokud počítáš s vývojem nad 100-manday tedy s rozpočtem nad 500 000. (2 vývojáři na 2 delší měsíce..)
      Podto se prostě smiř s tím, že odhadovaný čas a rozpočet vynásobíš dvěma a jsi ok.

      Když si SW ve startupu píšeš sám…stejně za svoje chyby nakonec zaplatíš….
      ale to je prostě zkušenost.

      Jinak dělám poradenství i na agile/rapid prototyping – na to abys uměl věci dělat rychle a bez dokumentace je nejdřív musíš umět dělat správně, abys pak mohl rozhodnout, co zrovna v téhle fázi nepotřebuješ (a za cenu chvilky práce navíc si připravil, aby to pak šlo dodělat)…..

    2. Asi tak no. Záleží na co je SW určen.
      Jestli je to nějak startup nebo ten SW bude mít vliv na tok milionů dolarů či dokonce lidské životy.

      1. Ahoj,
        přesně jak říkáš. Na tohle je spousta nástrojů na vyhodnocování, co je nejjednodušší, ale do článku jsem to už necpal, je asi následující úvaha:

        Řekněme, že naším etalonem bude IT vousáč v garáži co jen sype kód. Kolik tedy zainvestovat?

        Nejjednodušší strom analýzy co můžeme použít je:

        Zasahuješ do vnějšího světa za obrazovkou (HW v počítači s jednou ledkou, Arduino ve vysavači……až po auto, vlak či letadlo) a nebo ne? (Web, appka, server…)
        -ANO (bude na to oborový standard co musíš řešit, ale v kostce dál:)
        Může to zabít / zranit lidi?
        – ANO
        Safety relevant – Stoji to 2x oproti garáži
        -NE
        Může to způsobit škodu?
        -ANO
        QM relevant – Tak 1,7 garáže (rule of thumb)
        -NE
        Řeš jen zákony / normy +/- kolik tě stojí zákonná záruka když to budeš opravovat
        -NE – Vyhodnoť jaké jsou na to zákony
        + Můžeš udělat někomu škodu?
        -ANO
        Zhodnoť náklady na zaplacení škody * pravděpodobnost a ošetři to
        -NE
        Spočti kolik tě stojí nefunkčnost na ušlém zisku a riskni to nebo to ošetri

  4. Sepsat to asi chvili trvalo, ale jako reklama na vlastni sluzby se to asi vyplatilo – proc ne.
    Delal jsem 15 let vsechno – radoveho programatora, sef vyvojare, architekta, analytika, business konzultanta, projektoveho vedouciho. Predevsim v bankovnim prostredi, ale i v telemetrii apod.
    Myslim, ze je zatim brzo, aby si lidi uvedomovali paralely mezi svetem IT a svetem “starsim”.
    Pomalu uz lidi rozumi, ze automechanik je stejna role jako ten, kdo mi instaluje operacni system a ucetni program. Roky to ale trvalo, nez lidi pochopili, ze souseduv synek mi sice nainstaluje (kradenej :-)) MS Office, ale mel by dostat zaplaceno jako ten, kdo mi prezuje kola na aute.
    Stejna situace, ale zdaleka ne v tak pokrocilem stavu je i to, co popisujes.
    Kazdy chape, ze pri stavbe potrebuje stavebni dozor – nekoho, kdo neni znamy stavebni firmy a nema citovy vztah k zednikum, ze predelat tu krivou podlahu da fakt kupa prace a ten pravy uhel vlastne nemusi byt uplne pravy.
    Kdyz jsem cca pred 5 lety skoncil s vyvojem softwarem, snazil jsem se tem samym firmam vysvetlit, ze potrebuji neco jako stavebni dozor pro vyvoj software a ze jim usetrim miliony, kdyz dostanu statisice, a nebudou vydani na pospas dodavatelum software. “Nastesti” pro me to nechapali, tak jsem zacal delat neco jineho, protoze jsem nemel nervy na to, delat, co se snazis ted ty – delat tuhle osvetu.

    Az po sem ti v podstate davam a pravdu.

    Je ale treba videt i druhou stranku veci a to je neodmyslitelna ekonomicka kalkulace, kterou bychom za normalnich okolnosti meli vsichni delat. Realita je takova, ze je to hodne zavisle na oboru, typu software, zralosti firmy, na tom, jaka hrozi rizika a co muzou investori stratit. Nekde se totiz legitimne vyplati jit do toho “po hlave” a spolehat na stesti a nahodu nez delat veci poradne a bezpecne. Ke kvalitni praci jsou potreba kvalitni lide a ty nase skolstvi (nemyslim ted jen v CR) z principu neprodukuje a produkovat ani nemuze. Proto vetsinu kodu vytvari v podstate jednoucelovy lidsti roboti, kteri z celeho kontextu nechapu temer nic, ale “staci to”.
    Hlavni pricinou, proc se vyplati nekvalita, je bezesporu neexistence volneho trhu, mraky regulaci a protekcionistickych opatreni. Kdyby bylo “spolecensky” akceptovatelne selhani a pozadovala se zodpovednost, hned byly duvody posunout release o nejaky ten mesic a vyclenit par korun na rizeni kvality. Kdo ale kdy videl zkrachovat banku nebo aspon verejne viditelnou kauzu? Sam bych mel takovych pribehu do televize kupu a klienti by si mohli udelat predstavu, kde drzi svoje penize.

    1. Díky,
      njn chápu. Tak mne z 90ti procent platí korporáty co to řešit musí (safety) a chápou (jak píšu kolik stojí jeden bit, to je přesně ono 🙂 ).
      Jen mi pak přijde škoda, když vidm mal firmy si znovu a znovu zbytečně nabíhat….

  5. Ahoj Petr,

    Ja som si myslel, ze tie moje clanky nikto necita 🙂 Preto aj ten posledny bol taky onicom.

    Dakujem ze si sa na SW vyvoj pozrel aj z ineho pohladu. Ja som to popisoval ako zakladanie startupu kde som to cele programoval sam.

    Tvoja sluzba soft synargy podla mna dava zmysel. Poznam vela firiem ktore zaplatili velke peniaze za custom SW vyvoj a skoncilo to zle.

    1. Ahoj Zsolte,
      jj to víš, pár let to dělám 🙂 Když člověk programuje svoje věci sám, tak pak ví, kde a proč se to zadrhlo 🙂 O tom ten článek nebyl 🙂

      A díky, žes mne nakopl o tom taky někdy něco napsat pro veřejnost a ne jen furt školit korporáty 🙂

      Přeju spoustu úspěchů a kdybys potřeboval, tak se ozvi
      P.

  6. Ahoj,
    to jsem rád, že se líbilo. Já považuju programování v zásadě za řemeslo, kdo se mu nějakou dobu věnuje (ideálně více firem a více oborů) tak se mnou obvykle souhlasí 🙂 Takovým lidem říkám vývojář.

    No bohužel jsou tu spousty chlapců po škole (dospějí, ale trvá to) a startupáků….. (taky vyrostou).

    No a ti píšou taky spoustu blogísků…. nebudu jim tu dělat reklamu, ale zkus třeba hledat “Proč se na software záruka nedává….”

    A to jsou ty potrefené husy 🙂 Tedy ne evidentně Ty 🙂

  7. Chápu pointu, ale nejsem fajnda tý formy. Navíc je vidět, že Petr je klasický projekťák, který jede tvrdý metodiky. A to už přestává být běžný v SW vývoji, který zabere víc jak 1 000h

    1. Díky 🙂
      No já už právě projekťák přes 8-10let nejsem, ale jsem kvalitář 🙂
      Jinak ono i agilní metodiky umím (a někde dělám), jen….. ono to není o tom, nic nedokumentovat a neřídit.

      Naopak, aby agilní metodika byla úspěšná, tak to chce mnohem větší sebekontrolu teamu, než tzv. tvrdé metodiky 🙂

      Tak 1000h je 125mandays, tedy plus minus 6 člověkoměsíců 🙂 To už se právě vyplácí ídit a kontrolovat, když tě takový vývoj stojí cca 700kKč.

      A díky za koment

  8. No, otázka je kolik podnikatelů, zvlášť v ČR tohle bude (bude chtít) řešit. Pro většinu z nich je podstatné aby to bylo rychle a levně, na nějaké testování nebo risk management s..e pes. Stálo by to čas a peníze. To radši garážovka, hlavně ať to do listopadu jede.

    Ono se není moc čemu divit, dnes je všechno tak “agilní”, že 90 % uživatelů jsou v podstatě beta testeři. “Autopilot” od Tesly je jen jeden z mnoha příkladů. Ono vůbec v automotive je to velmi zajímavé, protože nějaké testování zabezpečení jen zdržuje. A tak se občas zjistí, že udělat si z moderního vozu prosyceného infotainmentem autíčko na mobilové ovládání lze nejen zevnitř skrz nějaké to USB, ale i třeba z telefonu a zcela dálkově.

    1. Ahoj,
      tak Tesla no comment – to není automotive ale startup.

      Jinak v automotive právě na to prachy a prostor jsou.
      Nemíchej quality, security a safety.
      Security, kde se zapojí jakákoli konektivita vně (nebo otevře jakýkoli port) je teď velké téma, a fakt je, že v autech co jsou uváděné na trh teď (tedy navrhované cca 5let dozadu) už to bývá ok, u starších je to tristní. Ale o tom vůbec nemluvím 🙂

      Agilní jde prostě jen jen něco někde 🙂 A od toho potřebuješ kvalitáře, aby to vyhodnotil 🙂

      Jinak řešit to bude podle mě každý podnikatel, co už se jednou spálil. Jinak jsou všichni strašně chytří, ale ono to totiž bez toho řzení v listopadu od garážovky nepojede 🙂

      To si ale musí zjistit každý sám

  9. Moc pěkný článek, díky za něj.

    Jen drobná poznámka: mám za to, že 1010 binárně není 9 dekadicky … ale těch skutečných 9 (1001) spíš vypadá na “přitečenou” jednotku.

    1. Aaaa, děkuju jsi první kdo si všim:)
      sakra někde v editacích to uniklo… Fakt to bylo najednou 9 místo 1.

      Ale na pointě to nemění, v 16bit registru bylo 4bit a 12bit číslo, a díky endianitě to uteklo fakt nepěkně.

      A neinkrementovalo se to přes masku, ale přímo s operací na registru 🙁 Holt nulovej codingstandard a nepoužívání standardních konstruktů.

      Díky moc

Leave a Reply to Jirka Cancel reply

Your email address will not be published. Required fields are marked *