REST Fire

Let me introduce you to my latest pet project – REST Fire. It’s basically a thin wrapper around Apache HTTP client, providing simple DSL for REST service testing. You can test your REST APIs like this:

        fire().get()
                .to("https://www.google.com/search?q=rest-fire")
                .withHeader("Accept", "text/html")
        .expectResponse()
                .havingStatusEqualTo(200)
                .havingHeader("Content-Type", hasItem(startsWith("text/html")))
                .havingBody(containsString("rest-fire"));

And that’s basically all. If you know REST Assured library, you may be asking why I just do not use REST Assured and write something new instead. Apart from NIH syndrome, I have two reasons.

First of all, I do not like REST Assured syntax, where you define the request, then you validate the response and then again you send the request. REST Fire is more straightforward, just fire a requst and validate the response. The syntax is strongly inspired by Jadler, so if you want to mock backends and test your API at the same time, you do not have to switch between two different styles.

Secondly, REST fire is built on top of Apache HTTP client and lets you configure whatever you want. It’s even capable to use our exotic authentication mechanism.

Usage of Apache HTTP client has its downsides too. It is hard to simulate invalid requests. Apache HTTP client tries to make sure that the requests are valid and if you need to test reactions on invalid requests, you are out of luck.

So if you want to try REST fire, visit its GitHub page for more details and let me know what you think about it.

Svoboda v práci a agilní přístup

Pokud kolem lidí postavíte plot, začnou se chovat jako ovce.

Četl jsem knihu Freedom Inc. (česky Svoboda v práci) a při čtení mi došla spousta věcí. Knize samotné se budu věnovat jen okrajově, mám z ní smíšené pocity. První půlka byla super, druhou jsem jednoduše nezdolal.

Celá kniha se točí kolem toho, že jsou dva druhy firem. „Proč“ a „Jak“. Na jedné straně jsou tradiční společnosti, které lidem říkají jak mají pracovat. Dávají jim přesně vymezené úkoly, měří je metrikami, sešněrovávají nařízeními, motivují je odměnami a tresty, mají jasný řídící proces. Zkrátka klasika. Pak je druhý typ firem. V těch se lidem neříká co a jak mají dělat, ale ptají se jich proč dělají to co dělají. V prvním typu je důležitá hierarchie a procesy v druhém kultura a sdílená vize.

Podle autorů je druhý typ firem výrazně lepší v podstatě ve všech ohledech. Lidé jsou motivovanější, víc o věcech přemýšlejí, jsou iniciativní, neztrácí čas a energii zbytečnou byrokracií. Zkrátka a jednoduše se snaží naplňovat společný cíl. Společnosti prvního typu iniciativu a snahu jednotlivců spíš ubíjí procesy a pokusy o zaškatulkování.

Došlo mi, že to vysvětluje proč tolik firem selže při závádění agilního vývoje. Jsou to společnosti typu „Jak“. Když kouknete na agilní manifest, tak to z toho úplně číší. V klasické „Jak“ firmě nemůžete upřednostňovat jednotlivce před procesy, tyto firmy jsou na procesech stavěné. Nemůžete reagovat na změnu, plán je posvátná kráva. Nemůžete mít samoorganizující se týmy, co by pak dělali jejich manažeři a manažeři manažerů a jejich manažeři?

No jo, ale jak řídit firmu bez vyhlášek, procesů, hierarchie, pololetního hodnocení zaměstnanců a motivačních vstupenek do kina zdarma. To by přeci zavládla anarchie. Zaměstnanci by se celý den flákali, každé oddělení by si dělalo co chce, firma by se zmítala ve vlnách, nikam by se nerozvíjela a za chvíli by zkrachovala.

Máte pravdu, aby k tomu nedošlo, potřebujete dvě věci. Kulturu a vizi. Lidé ve firmě musí mít sdílenou kulturu a vizi, musí se shodnout na tom, kam má firma směřovat, jaké jsou její priority. Musí vědět jaký je jejich společný pohled na to co dělají, v čem chtějí být dobří, jak se k sobě chtějí chovat, jak chtějí řešit problémy, co je to něco, co je spojuje. Nejen že je těžké to uchopit a nadefinovat, ještě těžší je zařídit aby tomu lidé věřili, aby to přijali za své. Spousta z nich už zažila nepodařené a často neupřímné pokusy o něco podobného.

V jedné nejmenované korporaci jsem například zažil, jak kdosi vymyslel vizi celé firmy. Slavnostně nám to odprezentovali. Abychom to přijali za své, tak najali telefonistky, které nám telefonovaly a zkoušeli nás. Kdo správně odrecitovali firemní hodnoty, dostal dáreček. Hurá. Samozřejmě si z toho všichni dělali srandu a nic se nezměnilo. Bylo jen takové plácnutí do vody.

Vůdce nemůže donutit lidi přijmou firemní vizi, může se jen snažit navodit podmínky, při kterých se lidé přesvědčí sami.

Takže zpátky k agilitě. Známe přísloví říká „agile nemůžete dělat, agilní musíte být“. Agile nejde zavádět tak, že lidem přikážete, že mají mít ranní pětiminutovku, že musí mít nástěnku, že musí posouvat lístečky ve vámi určeném směru. Pokud k tomu budete přistupovat takto, tak pokus o zavedení agile skončí jako další z desítek nařízení, které ti lidé budou buď bezduše vykonávat nebo prostě ignorovat.

Bohužel se na to musí jít tou těžší cestou. Nejdříve je potřeba se shodnout na tom, proč to chceme dělat, co je naším cílem. Je nutné vědět, jaká je vize firmy, týmu, projektu nebo iterace. Pokud máme jasno ve vizi a lidé ji přijmou za svou, je nutné dát lidem svobodu tuto vizi naplňovat. Mluvím o skutečné svobodě, ne jen deklarované. Můžete tvrdit lidem, že mají svobodu, ale pokud zároveň musí plnit hromadu nařízení, u který není jasný důvod, tak to dobře nedopadne. Ano je mnohem snazší vydat nařízení, než se s lidmi bavit a hledat nejlepší řešení. Pak se ale nesmíte divit, že se budou chovat jako ovce.

Je jen na vás jestli chcete mít sebevědomé, iniciativní, snaživé a motivované pracovníky nebo poloautomaty, jejichž veškerou snahu a iniciativu sežere boj s korporací. Rozdíl je jen ve vizi a kultuře.

Lean from the Trenches

Dostala se mi do rukou skvělá knížka, Lean from the Trenches (Hubeňouři ze zákopů) od Henrika Kniberga (tady se dá stáhnout draft)

Hlavní důvod, proč mi přišla tak dobrá je, že tam řeší stejné problémy, jaké máme aktuálně my. Od plánování, přes implementaci, až po testování. Celá knížka je vlastně popis toho, jak dělali projekt pro švédskou policii trvající něco přes rok a čítající asi šedesát lidí. Používali mix Kanbanu, Scrumu, Leanu a kdovíčeho ještě. Což je nakonec jedno, protože jak píše,

.. občas týmy dělají Kanban, protože se jim nelíbil Scrum. Až později přijdou na to, že Scrum problémy nezpůsoboval, ale upozorňoval na ně.

Nástěnka

Velká část knihy se točí kolem jejich Kanban nástěnky. Abych zase ocitoval

Rychlost projektu je z velké části určena tím, jestli všichni vědí co se děje. Když všichni vědí, kde právě jsme a kam jdeme, je pro ně mnohem snazší jít stejným směrem.

Dokonce má celou kapitolu o tom, proč používají fyzickou nástěnku místo elektronické. Hlavní důvod je snadná měnitelnost. Je mnohem snazší ji rozvíjet a upravovat. Když něco chybí, tak se to dopíše. Něco je špatně, vezmu fixu a překreslím to. Není potřeba trávit hodiny klikáním v Jiře. Stačí vzít tužku a z pár minut je hotovo.

U všech svých klientů jsem si všiml jednoho vzoru – obdobné nástěnky mohou změnit organizační kulturu. … Viděl jsem, jak se změnily vzájemné vazby a jak se díky spolupráci u nástěnky zvýšila důvěra mezi týmy.

Metriky

Také mě zaujaly metriky, které používají. Jsou to

  1. Počet věcí (featur) dodaných za týden
  2. Čas, za který proleze featura celým procesem

Je dobré si všimnout, že neměří komplexitu. Takže jim je jedno jestli udělají deset velkých nebo malých věcí. Prý je to proto, že se to nakonec stejně vykrátí. Odhady složitosti jsou nepřesné a metriku zkreslují. Počet je podle něj stejně vypovídající, ale mnohem jednodušší. Navíc je to tlačí do malých kousků, což je taky jenom dobře.

Druhá metrika je také zajímavá. Mají ji hlavně proto, aby je nutila zkracovat fronty mezi jednotlivými fázemi. Příliš velký čas vás upozorní třeba na to, že věci zbytečně čekají na otestování. Když se snažíte celkový čas zkracovat, musíte tato úzká hrdla řešit a to celému procesu jen prospěje.

Náš proces nebyl navrhnut, ale objeven.

Diagramy příčiny a důsledku

Úplnou novinku pro mě byly diagramy příčin a důsledků. Řešíte třeba dlouhé release cykly. Doporučuje nakreslit si diagram. Začnete u toho, že máte dlouhé release cykly. Nad to píšete jaké to má dopady, a pod to jaké jsou důvody. Často tam vyběhnou začarované kruhy, jako třeba tady.

Cause-effect diagram

Doporučuje se samozřejmě zaměřit na kořeny toho problému. Když vyřešíte příčinu, je možné, že vyřešíte i problém. Začarovaný kruh se rozpadne. V tomto konkrétním případě je dobré vyhazovat požadavky, pokud se nějaké jiné do releasu přidají. Více se dočtete tady.

Ostatní

Pak tam má také spoustu zajímavých věcí o retrospektivách, neustálém zlepšování, pokrytí testy a dalších. Takže pokud válčíte s agilním procesem, tuto knížku vřele doporučuji. Je docela krátká, ale nacpaná praktickými radami. Ideální kombinace.