Administrace komentářů

Pokud to neznáte vy, tak je to vaše věc, ale při tvrzení, že nikdo a nikdy a neexistuje si myslím že jste trochu ujel.

Už jenom samotný fakt, že drtivá většina takové problémy nemá, svědčí o tom, že vámi popisované problémy nejsou způsobeny použitou technologií a organizací práce, ale něčím jiným. „Nikdo a nikdy“ je jenom takový hovorový výraz, který se často používá i v případě, že se najde pár výjimek. Vy byste se ale spíš měl zabývat rozporem, že tvrdíte, že něco způsobuje problémy, a většina uživatelů se s takovým problémem nesetkala.

Cena za chybu se nezlevňuje.

Cena za chybu při vývoji samozřejmě zlevňuje. Dříve jste musel přelepovat dirku nebo rovnou vyhodit celý štítek, přišel jste o drahocenný strojový čas – dneska zmáčknete delete nebo za minutu spustíte kompilaci znova. To je výrazné zlevnění.

Cena za chybu je funkce silně závislá na čase mezi jejím vyrobením a opravením. A s tím časem lze pracovat. V dobách štítků to bylo dlouho pro ty důvody které popisujete. A ještě dnes je např. rozdíl mezi tím, když si spustíte kompilaci z příkazové řádky a čekáte na zapomenuté středníky, a tím když to IDE automaticky podtrhne červeně. Programátor pracující s IDE opraví syntaktickou chybu rychleji než programátor pracující s editorem a překladačem. Aplikací stejného principu týmy pracující s CI opraví chyby v programu rychleji než týmy pracující s feature větvemi.

Nepřipadá vám to divné? Uvedete X příkladů, které programátorovi usnadňují práci a nenutí ho udělat to hned na první pokus správně, a nakonec k tomu přiřadíte pravý opak, který programátorovi práci přidělává a nutí ho vše dělat „na první dobrou“. To se k sobě moc nehodí…

Rozdělit čas na T1 vývoj a T2 testování znamená že do konce T2 nebudu vědět jestli práce v T1 za něco stojí. Co když na začátku T1 udělám chybný předpoklad a na tom postavím celou další práci? To je extrémní případ, ale ukazuje, jak je důležité odhalit co nejvíc problémů co nejdřív.

Proto se běžně vývoj a testování prolíná. Jenže k tomu je potřeba klid, nemůžete vyvíjet a testovat, když vám zároveň pořád přicházejí změny a chyby od někoho jiného.

Výhoda toho "mého" přístupu je, že eliminuje všechy složky, které vám běžně působí problém. A sice "ejhle", "honem", "trávíš čas" (ve smyslu čekáš/vyčerpáváš se) a "překopat". A to právě proto, že je to nastavené tak, aby se tyhle věci nestihly vyvinout a nabobtnat. … Ano čas je kratší, výsledek je funkční

Chápal bych to tak, že pro samou integraci s kódem, který se nikdy nepoužije, už vám nezbývá žádný čas na vývoj. Ale tak jste to asi nemyslel. Zajímalo by mne, jak tím, že někomu zkrátíte čas na vývoj, docílíte toho, aby nedělal chyby a navrhl vše rovnou správně. Proč se ta vaše metoda nepoužívá třeba ve výrobě? Vyrábíte jeden výrobek 3 dny a občas stejně vyrobíte zmetek? Od teď to musíte stihnout za 4 hodiny, a uvidíte, že zmetky už nebudou… Já bych na to tedy nevsadil ani korunu.

CHAPTER 1 Why Agile? Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.

Nás nezajímá, kdo používá úplně jiné metody vývoje, než vy. Nás by zajímal někdo, kdo používá tu vaši metodu „čím méně času, tím lepší výsledek“. Až budete mít někdy hodně klidnou náladu a jen tak něco vás nevyvede z míry, přečtěte si o tom, jak Microsoft vyvíjí Windows, a jak trvá týdny, než kód od programátora přes různé větve probublá do masteru.