Category Archives: Agile

Agile je světonázor, co s tím?

Světonázor je více či méně koherentní chápání podstaty reality, které pomáhá jeho držitelům interpretovat nové informace ve světle jejich předsudků. Střety mezi světonázory nemohou být ukončeny jednoduchým odovláním se na fakta. I když se soupeřící strany shodnou na faktech, nemusí se shodnout na závěrech kvůli rozdílům v předpokladech. Michael Lind

Každý z nás má nějaký světonázor. Někdo věří, že existuje Bůh, někdo že ne. Někdo věří, že svět bude bezpečnější, když budeme mít všichni bouchačku, někdo že ne. Někdo věří, že funguje evoluce, někdo věří, že byl svět stvořen za šest dní. Podobných příkladů si určitě sami vymyslíte spoustu. Na světonázoru je zajímavé to, že je to něco uvnitř nás, na co mají fakta a realita velmi malý vliv. Naopak, světonázor ovlivňuje to, jak realitu vnímáme. Navíc je hrozně těžké si představit opačný pohled na věc. Říkáte si, jak se ten druhý může tak moc mýlit v tak evidentní věci.

Včera mi došlo, že agilní přístup je taky světonázor. Někteří lidé prostě věří tomu, že lidi jsou důležitější než procesy. Že je potřeba dělat chyby, abychom se mohli učit. Že je potřeba dát lidem autonomii, aby ze sebe mohli vydat to nejlepší. Jednoduše věří ve spoustu věcí. Když v ně věří, tak vidí spoustu příkladů, které jim ten pohled potvrzují. Nejen to co vidí kolem sebe, ale i každá knížka, každá přednáška jim říká, že mají pravdu.

Pak jsou ale lidé, kteří mají jiný světonázor. Věří, že je lidi potřeba řídit, říkat jim jak dělat svoji práci. Že je nejdůležitější, aby bylo všechno standardizované a zaškatlukované. Tito lidé zase vidí spoustu důkazů pro to, že mají pravdu oni.

Bohužel rozdíly ve světonázorech vedou ke sporům. Navíc k takovým, které se špatně řeší. Představme si, že někdo udělá chybu. Člověk s agilním přístupem by měl začít pátrat po příčinách. Měl by to brát jako příležitost k učení. Pro člověka s opačným pohledem na věc, jde o selhání, které je přirozené řešit procesem. Když se ho zeptáte, jestli si zkusil přesně pojmenovat ten problém a odhalit příčiny, tak se na vás kouká jako na blázna. Vždyť stačí napsat do dokumentu, že se lidi mají chovat tak a tak, a oni se tak chovat začnou. Když nepomůže dokument, tak kontrolní mechanismus zabere určitě. Proč to zbytečně komplikujete?

No jo, ale co s tím? Jelikož jsem známý průkopník slepých uliček, tak vám řeknu co nezabírá.

Logická argumentace
S tím jsem hrozně bojoval. Pořád jsem si myslel, že když to dokážu dost dobře vysvětlit, tak přeci musí pochopit, že mám pravdu. Vždyť je to tak evidentní. Bral jsem jako svoje selhání, že nedokážu předat to, proč musíme dát lidem co největší autonomii. Teď mi došlo, že jsem měl stejnou šanci na úspěch, jako kdybych chtěl Václavu Klausovi dokázat globální oteplování.

Ostrá letáková kampaň

Když to nedokážu vysvětlit já, tak to nechám na autoritách. Stačí kolegům jenom podstrčit knížku nebo jim pustit video a oni pochopí, že jak moc se mýlí. No jo, ale když jde o střet světonázorů, tak to nemůže zabrat. Naopak, často to pochopí „špatně“ a nejdou si tam důkazy pro to svoje. Dochází mi, že jsem působil jako Jehovista – úplně se vidím jak stojím u východu z metra a mám stojan s publikacemi o agile zdarma.

Takže vím co nefunguje, bohužel ale nevím co funguje. Lidi svůj světonázor můžou změnit, ale musí to vyjít z nich, zevnitř. Jediné co mě napadá je naučit se s tím žít a jít příkladem. Neznamená to, že radostně přijmu jakýkoliv proces, ale snad budu víc chápat, jak někdo tak chytrý, může přijít s věcí, která mi vůbec nedává smysl. Jednoduše má jiné vnímání reality.

Co je na Scrumu nejdůležitější?

Napadla mě taková pěkná otázka. Co je na Scrumu, nebo jiné vaší oblíbené agilní metodice, to nejdůležitější? Ano, je to nesmyslná otázka, ale mě se přesto líbí, protože krásně odhaluje, jak kdo o agile přemýšlí. Přestaňte číst a schválně se nad tím zkuste zamyslet. Co je pro vás na agile nejdůležitější? Bez čeho by to nedávalo smysl? Teď přestanete číst a přemýšlejte.

Já jsem si třeba kdysi myslel, že nejdůležitější jsou iterace. Tenkrát jsem dělal ve vodopádu a iterace mi přišly jako to nejdůležitější. Dnes to vidím jinak, a nemůžu pochopit jak jsem to mohl nevidět. Nejdůležitější je přeci tým. Ať se podíváte na jakoukoliv agilní praktiku, tak existuje kvůli týmu. Scrum Master pomáhá týmu dosáhnout jeho cílů, Product Owner musí být týmu k dispozici, retrospektiva je tu proto, aby se tým mohl zlepšovat, standup je od toho, aby tým věděl co kdo dělá. V Kanbanu se sleduje WIP aby tým viděl, jestli mu něco nedrhne. V XP je zákazník součástí týmu, tým má společné vlastnictví. Všechno se to točí kolem týmu. Slovo tým na nás kouká odevšud, nevidět ho je jako nevidět pro stromy les. Abych byl spravedlivý, přede mnou se ten les za stromy skrýval hodně dlouho.

Proč je tým tak důležitý? Použiji slova klasiků:

Stmelený tým je skupina lidí tak silně spojena, že celek je víc než součet jeho částí. Výkonnost takového týmu je větší než výkonnost těch samých lidí pracujících mimo stmelený tým. Neméně důležitá je radost z práce ve stmeleném týmu, která je často větší, než by odpovídalo povaze dané práce. … Jakmile se tým začne stmelovat, pravděpodobnost úspěchu roste dramaticky. … Tým nemusí být řízen v tradičním slova smyslu a rozhodně nemusí být motivován. Je rozjetý. … Důvod je jednoduchý, týmy jsou ze své podstaty formovány kolem cílů. … Před tím než se tým stmelí, jednotlivci můžou mít různé cíle. Nicméně jako součást stmelování, všichni přijali společný cíl.

Není toto pěkný popis toho, jak by měl fungovat agilní tým? Mimochodem, je to citát z mé oblíbené knihy Peopleware, z roku 1987. Nedávno se mi poštěstilo vidět počátky tmelení týmu v praxi a je to hodně zajímavé. Vidíte, jak se lidi najednou snaží řešit problémy, jak se začínají sami řídit, jak se víc a víc zajímají o to co a jak dělají. Vidíte jak ten vlak nabírá rychlost.

Tým je tedy srdcem každé agilní metodiky. Je bohužel i její achilovou šlachou. Iterace nebo retrospektivy zavedu snadno, ale jak zařídit, aby tým fungoval dohromady? Zalistujme v Peopleware o kus dál, do kapitoly týmovražda, kde se dočteme

Tým nemůžete stmelit. Můžete jenom doufat, že se to podaří, můžete se modlit, můžete zvyšovat šance na stmelení, ale nemůžete zařídit, aby se to stalo. Je to příliš křehký proces na to, aby se dal kontrolovat.

Autoři dál pokračují a píší jak se jim nedařilo najít způsoby, jak zařídit aby se tým stmelil, hrdě to přiznávají a říkají, že se jim naopak podařilo najít hromadu způsobů jak zařídit, aby se to nepovedlo. Jsou to hlavně:

  • Defenzivní management – kdy manažeři nevěří svým lidem
  • Byrokracie
  • Fyzické oddělení členů týmu
  • Fragmentace času lidí
  • Snižování kvality produktu
  • Nesmyslné termíny
  • Clique control

Takže pokud se u vás zavádění agile nedaří, podívejte se, jestli fungují týmy. Pokud ne, zkuste mu odstranit překážky a doufejte, že to začne fungovat.

Nasazujeme a testujeme (mikro)služby

Pokud dostanete chybu v testu vyšší úrovně, nemáte jenom chybu v testovaném kódu. Také vám někde chybí unit test.
Martin Fowler

Včera jsem se vrátil z GeeConu. Jelikož jsem neuvěřitelně vzdělaný, sečtělý a šikovný, tak mě tam zas tolik věcí nezaujalo. Dostala mě ale prezentace Sama Newmana o testování a nasazování mikroslužeb. Dozvěděl jsem se tam řešení problému, s kterým si nevíme rady.

Máme totiž platformu rozdělenou na služby, které jsou ve správě jednotlivých týmů. To má spoustu výhod. Každý si hraje na svém písečku, může si rozhodnout v jakém jazyce to bude psát, jak to bude testovat, jak často chce nasazovat a spoustu dalších věcí. Tím, že jsme platformu rozdělili na služby, se nám ohromně usnadnila práce. Každý máme svoji hromádku, o kterou se staráme a za kterou neseme zodpovědnost. Od té doby, co jsem se takto rozdělili, jsme se ohromně zlepšili ve vývoji, testování i nasazování jednotlivých služeb. Každá služba má totiž specifické požadavky a najednou nám odpadla většina pokusů najít dokonalé univerzální řešení. Víc experimentujeme a každý tým si najde co mu vyhovuje.

Problém ale je, že jednotlivé služby pořád tvoří jednu platformu a zákazníkovi je jedno, že moje část je skvěle otestovaná a funguje, když platforma nefunguje jako celek. Jednotlivé týmy se starají o svoje služby, ale docela nám drhne nasazování a testování, když se jednotlivé služby dají dohromady. Například je složité rozhodnout jaké kombinace služeb testovat, když má každá služba jiný cyklus nasazování. Dopředu moc nevíte jaké verze jednotlivých služeb se potkají na produkci. Co když neškodná změna jedné služby, rozbije něco ve druhé službě? Existuje několik evidentních řešení, které bohužel nezabírají.

Integrační testy

Ideálním řešením jsou integrační testy, které automaticky otestují celou platformu, všechny případy užití a všechny možné kombinace služeb. Před každou změnou se tyto testy spustí, a když projdou, tak je všechno v pořádku a můžeme nasazovat. Jak už jsem řekl, toto řešení je ideální, což bohužel znamená, že v reálném světě moc nefunguje. Abych mohl spustit integrační testy, tak musím všechno nasadit, pospojovat a pak spustit testy, které klikají skrz UI. To za prvé dost dlouho trvá a za druhé je tam tolik věcí, které se můžou rozbít, že testy někdy víc padají, než procházejí. Co dělat když testy neprojdou? Který tým se na to má podívat? Kdo určí co se rozbilo? Sam Newman sice říkal, že když integrační testy neprocházejí, tak je to dobře. Pravděpodobně to poukazuje na křehkost našeho testování. Ale zestabilnění integračního testování je příliš velké sousto, kterému se sice asi nevyhneme, ale bude to dost dlouho trvat. Do GeeConu jsem věřil, že to jde, že je to jediná správná cesta, že se jen málo snažíme. Ale asi jsem byl příliš velký idealista.

Navíc mi nedošla jedna zásadní věc. Protože jsou integrační testy pracné, pomalé a křehké, je dobré je používat jen na věci, které se jinak otestovat nedají. Třeba na otestování toho, že nám celý systém funguje. Spousta věcí se dá ale otestovat jinak, jednodušeji.

Nasazovat najednou

Druhá možnost je nasazovat najednou. Udělat release okna a dopředu vědět co kdo bude kdy nasazovat. Můžeme se tvářit, že nemáme služby ale jeden celek, který můžeme najednou otestovat a nasadit. V teorii to zní dobře, ale předpokládá to, že nikdo neudělá chybu. Že nikdo na poslední chvíli nezjistí, že mu něco nefunguje nebo že na něco zapomněl. Co pak? Odložit i release ostatních služeb? Následující release pak bude ještě větší, a tím se zvětší i pravděpodobnost, že se něco rozbije. Takže se release zas odloží a tak dál. To je cesta do pekel.

Kontrakt mezi službami

Když se nám nedaří testovat to celé najednou, co takhle dobře otestovat jednotlivé služby a pevně stanovit kontrakt mezi nimi? Něco podobného navrhoval kdysi kolega, že prý nemusíme tak intenzivně testovat celou platformu, stačí když dobře zdokumentujeme API. Tenkrát jsme mu to rozmluvili. Právem. Dokumentace je obvykle neúplná, nepřesná a zastaralá, ta by nám kvalitu nezajistila. Nedošlo nám ale, že jsme byli jen kousíček o řešení. Co takhle přísnější kontrakt? Co když tým spravující jednu službu uzavře kontrakt s týmem spravujícím druhou službu o tom jak ji budou používat. A místo toho, aby si na to plácli, tak na to napíší testy. Říká se tomu Consumer-Driven Contract.

Jednoduše se napíší testy, které říkají, my vás budeme volat takto a vy nám budete odpovídat takto. Když se přihodí toto, tak nám vrátíte tamto. Pokud někdo změní službu, spustí testy, které hlídají její kontrakt. Když projdou, je velká šance, že se nic nerozbilo. Díky testům kontraktu budeme mít otestovanou spolupráci mezi službami, díky ostatním testům služby samotné. Místo velkých megatestů, které to pokryjí najednou od hlavy až k patě, pokryjeme systém menšími, překrývajícími se testy. Navíc budeme mít i zdokumentovaný kontrakt mezi službami, což není nikdy na škodu.

Není to samozřejmě dokonalé, pořád tam budou věci, na které zapomeneme. Pořád budeme potřebovat integrační testy, ale nebude jich potřeba tolik. Stačí jich pár, které ale na oplátku můžeme pouštět třeba i na produkci.


Sam Neward toho radil víc, ale consumer-driven contracts mě zaujaly nejvíce. Abych vás neochudil o zbytek, tady je celá prezentace a toto jsou hlavní rady:

Buďte si vědomi vaší pyramidy testů. Vyvažujte ji.Pyramida testů říká v zásadě to, že byste měli mít hromadu unit testů, spoustu komponentových testů a míň integračních testů. Čím větší daný test je, tím míň jich chcete mít. Je to relativní číslo, neříká, že máte kašlat na integrační testy. Říká jen, že pokud máte víc integračních testů než unit testů, tak je něco špatně.

Rozumějte rovnováze mezi testováním a rychlou nápravou – Máte omezené množství zdrojů, je dobré najít rovnováhu mezi tím, jak umíte testovat a mezi tím jak rychle umíte odhalit a napravit chyby na produkci. Možná je výhodnější mít méně dokonalé testy, ale lepší monitoring a rychlejší releasy. Všimněte si, že je to o rovnováze, rozhodně neříká ať kašlete na testy.

Nasazujte jednu věc po druhé – V daném okamžiku nasazujte jenom jednu službu. Budete mít snazší rollback a diagnostiku chyb.

Zvažte consumer-driven contracts – o tom je celý tento zápisek.

Prozkoumejte nasazovaní založené na imagích, abyste zmenšili rozdíly mezi testovacími prostředími – místo toho, abychom měli jeden image s operačním systémem a všechno ostatní na něj instalovali, je údajně lepší vyrobit image s celou naší službou a ten image pak prohnat celým testovacím potrubím až po produkci. Vyžaduje to mít jednu službu per image, ale díky Dockeru to prý jde udělat lacině.