Category Archives: Agile

Mob programming

Posledních několik měsíců pracujeme s kolegy pomocí metody mob programming. V jednoduchosti jde o to, že celý tým pracuje u jednoho počítače, jeden píše, ostatní navigují. Funguje nám to úplně skvěle, měli byste to určitě také zkusit. Abych vám to trochu usnadnil, tak tu zkusím sepsat naše zkušenosti.

Výhody

Začnu výhodami. Ta nejzajímavější je pro mě ta, že odpadne většina ceremonií a koordinace. Celý tým pracuje pohromadě na jedné věci, nemusí se tedy koordinovat, dělat schůzky a navzájem se vyrušovat.

Představte si, že rozjíždíte nový projekt. Pokud pracujete klasicky, každý vývojář na vlastním písečku, tak je to celkem složité. Nejdřív musíte vymyslet a rozdělit úkoly pro jednotlivé vývojáře. Jarda bude zakládat strukturu projektu, Pepa bude studovat dokumentaci k externím systémům, Karolína bude chystat testovací prostředí. I když máte náhodou dost úkolů pro celý tým, tak se ti lidé musí neustále koordinovat. Věříte Jardovi, že strukturu projektu založí tak, že bude vyhovovat celému týmu? Co když to bude mít hotové a Karolína vymyslí lepší postup? Je zakládání testovací prostředí opravdu tak důležité, že se musí dělat hned, nebo to děláte jen proto, aby měli všichni co dělat? Jak Pepa předá znalosti dokumentace ostatním?

V mobu je to všechno mnohem snazší. Je nejdůležitější založit strukturu projektu? Všichni to dělají pohromadě. Dokončili jsme to? Všichni se vrhnout na něco jiného. Koordinace tam samozřejmě stejně probíhá, ale přirozeně, v průběhu práce. Vezměme například plánování. Právě jsme něco dokončili a nevíme co dál? Společně vybereme další nejdůležitější věc a vrhneme se na ní. Nemusíme řešit kdo umí co líp, kdo je na co specializovaný. Potřebujete retrospektivu? Není problém, uděláme ji hned. Není potřeba svolávat zvláštní meeting, všichni máme čas najednou. Zpočátku jsme tak třeba retrospektivu občas i několikrát denně a bylo to naprosto přirozené, jenom se tým přepl z módu programování do módu retrospektiva. Code review? Nemusíte na nikoho čekat nebo ho vyrušovat uprostřed rozdělané práce, všechno probíhá hned u každého napsaného řádku. Většina rozhodnutí probíhá okamžitě, čeká se jen na věci, které se z nějakého důvodu řeší mimo tým.

Další zjevná výhoda je kvalita kódu. V našem týmu jsme tři hodně zkušení vývojáři, každý z nás dokáže napsat slušný kód i samostatně. Ale ve třech je ten výsledek o hodně lepší. Když není jasné, jakou cestou se vydat, tak se to okamžitě probere, vybere se nejlepší řešení a jede se dál.

Vyšší kvalita výstupu z mobu u nás vynikne v porovnání s kódem, který vznikne při technických pátcích. V pátek si jednotlivě hrajeme s věcmi, na které není v průběhu týdne priorita. Kód který takto vzniká je prostě na první pohled horší než ten, který napíšeme společně. Dokonce i ten můj.

Je pravda, že kvalitu kódu by určitě zvedlo i párové programování. Ale už se nám několikrát stalo, že si někdo někam odběhl a zbytek pokračoval jen v páru. Po návratu nám ten třetí vymyslel fintu, která řešení výrazně vylepšila.

Třetí velká výhoda je učení se. Každý z nás je v něčem lepší. Když ostatní vidíte přímo při práci, tak se učíte mnohem rychleji. Od jednoho okoukáte finty při editaci, od druhého finty při psaní funkcionálního kódu, od třetího návyky při testování. O kódu diskutujete v podstatě pořád, takže se pořád učíte. A nejen kódování, poznáte jiné pohledy ne design, na to jak si kdo organizuje práci a podobně. Je to neuvěřitelně obohacující.

Na co si dát pozor

Samozřejmě to není všechno procházka růžovou zahradou. Hlavně ze začátku je to celkem náročné. Nebyli jsme zvyklí takto pracovat, takže nám to občas docela skřípalo.

Doporučil bych ze začátku přísně dodržovat pravidla. Řidič by měl poslušně dělat to co mu říká navigátor, neměl by se snažit dělat věci podle sebe. Měl by se chovat jako o trochu chytřejší klávesnice. Pro mě osobně bylo tohle hodně těžké. Jsem přeci zkušený programátor, proč by mě měl někdo navigovat. Je ale nesmírně důležité toto pravidlo dodržovat právě proto, abychom se naučili poslouchat co se nám ten druhý snaží říci. To je věc, kterou (nejen) v mobu potřebujete neustále.

Navigátor by se měl svědomitě snažit určit míru potřeby navigace. Je to podobné jako v autě. Zkušenému řidiči stačí oznámit, že má jet do Brna a pak se jen vézt. Pokud řidič neví kde je, musíte mu radit každé odbočení. A pokud je to řidič začátečník, je potřeba mu radit i to, jaký stupeň má zařadit. S navigováním v mobu je to podobné. Chvíli trvá naučit se poznat, co kdo v daný okamžik potřebuje. I řidič se musí naučit dát vědět, jestli je ztracený nebo jestli je mu všechno jasné, jestli potřebuje vodit za ručičku nebo jestli mu jen stačí naznačit směr.

A pokud zrovna neřídíte ani nenavigujete, musíte se naučit odlišit situace kdy je potřeba mlčet a kdy do toho začít navigátorovi kecat.

Nám se osvědčil časovač, který nás nutil se pravidelně po čtyřech minutách střídat a časté retrospektivy, kdy jsme si vyříkali, co fungovalo a nefungovalo. Časem jsme pravidla postupně opouštěli a nic se nestalo. Věřím ale, že jen dodržování pravidel nám umožnilo naučit se vnímat potřeby ostatní.

Jeden důvod, proč nám to občas skřípalo byla nejasnost zadání. Když si řidič myslí, že jedeme co nejrychleji do Brna a navigátor, že je nutné co nejdřív někde nabrat benzín bez ohledu na zajížďku, tak pak oba nechápou, co ten druhý blbne. Nám pomáhá rozpadnou si story na malé kroky a ukázat si, že teď děláme tohle. Časem jsme se naučili se i zastavit a zeptat se co se děje a nepovažovat toho druhého rovnou za pomateného.

Umět se zeptat toho druhého, proč dělá něco nepochopitelného je důležitá schopnost, bez které se v mobu neobejdete. A opět nejen v mobu.

To mě vede k další nevýhodě mobu. Je to celkem psychicky náročné. Hlavně proto, že kromě kódu musíte vnímat i lidi kolem sebe. Najednou to není jenom o tom, že jsem ponořený v problému, musím si všímat i těch divných bytostí co na mě pořád mluví. Celkem nezvyk. Je proto důležité si pravidelně dělat přestávky, aby měl člověk čas dobít baterky.

Další věc, která mě při mobování překvapila je to, jak jsem závislý na počítači. Jak moc si nepamatuju jména základních tříd, jak moc často potřebuju googlovat. Když navigujete, tak si připadáte jako bez rukou. Chcete řidiči říci, že má použít třídu XYZ, ale nepamatujete si její název. Po čase mě to přešlo, ale ze začátku je to docela síla. Časem se naučíte přiznat si, že nevíte a říci řidiči, že si to má vygooglovat sám.

Co nám nejde dodnes je dubugování. Při hledání chyb potřebujete rychle zkoušet hypotézy a vyvracet nedopečené nápady. To jsme se zatím v konfiguraci řidič/navigátor nenaučili. Dáváme buď víc prostoru řidičovi nebo se každý rozejde na vlastní počítač. Na druhou stranu opravdu záludnou debugovací situaci jsme měli zatím jen dvakrát, v mobu je výrazně větší šance, že si chyby někdo rychle všimne.

Nečekaně dobře nám mob funguje v době koronaviru. Jedeme vzdáleně, sdílíme obrazovku, při střídání pushujeme do Gitu, což zabere pár sekund. Naopak, pokud se někdo potřebuje postarat o děti nebo podlít maso, tak jen odběhne a tým jede dál. Nevím ovšem, jak by nám to vzdáleně fungovalo, kdybychom si na sebe ještě vzájemně zvykali.

Dnes jsme ve fázi, kdy pravidla už moc nedodržujeme, střídáme se když se to hodí, navigují všichni co zrovna neřídí a tak nějak tušíme, jak by danou situaci řešil, který člen týmu. Já vím, že se kluci vyhýbají ifu jak čert kříži, kluci vědí, že nerad používám data classy tam kde nemají být. Občas nám to skřípe, občas si nerozumíme, ale většinu doby máme pocit, že dohromady odvedeme víc kvalitnější práce než by to dokázal každý zvlášť. Takže se nebojte to zkusit. Je to zábava a naučíte se hrozně moc.

Jaké potřebuji zadání

V poslední době často řeším, jaké bych chtěl dostávat zadání. Došel jsem k tomu, že správné zadání má mít právě tyto dvě části:

  1. Popis problému, který potřebujeme vyřešit.
  2. Business metrika, kterou změříme, že se to povedlo.

Zní to jednoduše, ale nám se to ne a ne podařit. Pojďme se na to podívat postupně. Místo popisu problému stále dostáváme řešení. Místo „zákazník netuší, co má udělat na registračním formuláři“ dostáváme „tlačítko ‘Odeslat’ zvýrazněte červenou barvou“. Místo „potřebujeme ušetřit výdaje na ministerstvech“ dostáváme „postavte vládní čtvrť v Letňanech“.

I když se mi zdá rozdíl mezi popisem problému a řešením zjevný, lidi z nějakého důvodu prostě nejsou schopni se u popisu problému udržet a stále sklouzávají k řešení. Než se podíváme na důvody, proč to tak bývá, řekněme si, proč nechci přicházet k hotovému řešení.

Když dostanu připravené řešení, tak s ním často nesouhlasím. Často totiž nedává technicky nebo dokonce logicky smysl. Napadl mě následují příklad, představte si, že navrhujete auta a přijde vám požadavek – do okna spolujezdce vyrobte uzavíratelný otvor o průměru 18,7 cm.

Pokud se vám něco podobného stane, máte v podstatě jenom dvě špatné možnosti. Můžete to řešení napadnout a říci, že je potřeba vymyslet jiné. Nebo můžete sklapnout podpatky, udělat to podle zadaného řešení i když nechápete proč to děláte a technicky vám to nedává smysl.

Změna zadaného řešení je často hrozně politicky složitá, spoustu lidí na něm strávilo spoustu času, dohodlo se na tom několik vrstev managementu, už se to slíbilo zákazníkovi a teď nějaký hloupý programátor přijde s tím, že by to dělal jinak? Proč se sakra ptáš, na to jaký problém tím chceme vyřešit? Prostě udělej v okně spolujezdce otvor o průměru 18,7 cm a přestaň klást hloupé otázky. Víš kolik času jsme strávili rozhodováním, jaký má být poloměr té díry? Že to nejde? Tvoje práce je tyto drobné technické detaily řešit.

Pokud najdeme odhodlání navrhované řešení zpochybnit, potřebujeme nejdřív zjistit popis problému. Proč by chtěli mít díru v okénku? Naštěstí se můžeme někoho zeptat. „Proč chtějí díru v okně spolujezdce?“ „No, náš důležitý zákazník chce vozit dlouhé tyče, do auta se jim nevejdou, tak je chtějí držet rukou podél auto venku z okénka. Ale když mají otevřené okénko, tak jim dovnitř fouká.“ (XY problem) V těchto okamžicích si vzpomenu na strýčka Boba, který říká, že profesionál se pozná podle toho, že umí říci zákazníkovi „ne“. Takže profesionálně řeknu „ne“ a jsem označen za negativního. Nicméně je to pro mě lepší než druhá alternativa, udělat něco, co nedává smysl.

Abych to shrnul, pokud mě stavíte k hotovému řešení, nutíte mě buď vám to řešení rozbít nebo udělat něco, co firmě dříve nebo později uškodí. U díry v okénku se ty škody dají celkem slušně vysvětlit, dopad kupení hacků na hacky v složitém programu se vysvětluje podstatně hůř.

Tady arogantně předpokládám, že řešení, které přijde od neprogramátora musí být špatně. Často špatně je a to ze dvou jednoduchých důvodů. Programátoři často bývají jediní, koho napadne se ptát, co se bude dít v okrajových případech. Co se stane, když vypadne připojení v internetu v tomto okamžiku. Jak napravíme data, když operátor do toto políčka napíše špatné číslo. Co budeme dělat, když se k tomuto odkazu dostane zlý hacker. Co se stane, když držíte rukou tyč venku z okna a nabouráte? Programátoři se na takovéto otázky ptají, protože musí, potřebují to pro svoji práci. Pamatuji jen pár neprogramátorů, kteří měli podobné uspořádání mysli.

Druhý důvod souvisí. Software je celkem složitá věc, chování nejen v okrajových případech bývá komplikované a nikdo nemá šanci si zapamatovat, jak se vlastně ta vaše aplikace chová za všech okolností. To je ale informace, kterou nutně potřebujete vědět, když vymýšlíte změny. Programátor se může podívat do kódu, kde to v lepším případě zjistí. Lidi, kteří neumí číst kód nemají šanci se těmto důležitým informacím dostat.

Nicméně předpokládejme na chvíli, že máte super analytika, který všechno tajemná zákoutí vaší aplikace udrží v hlavě nebo v dokumentaci a donese vám perfektní řešení. I tak je to špatně. Když neznám problém, který řeším, tak pracuji naslepo, nevím proč dělám to dělám, měním se v robota (nebo lumíka) Když hádám, který problém řeším, můžu to uhodnout špatně a tím pádem to naimplementovat špatně. Když nechápu proč chtějí díru v okénku, tak ji pravděpodobně udělám na špatném místě, takže skrz ní ruka ani prostrčit nepůjde.

Nevýhod hotových řešení je víc, nezbývá mi tu na ně ale místo, takže si je doplňte za domácí úkol. Pojďme se teď radši zamyslet, proč je tak těžké se udržet u popisu problému.

Tichá pošta

U nás se to děje především kvůli tiché poště. Obchodník řeší se zákazníkem jeho problém. Zákazník už má samozřejmě v hlavě nějaké řešení. Obchodník si pak sedne s produktového manažerem, kde si buď řešení potvrdí nebo vymyslí lepší. Proberou to se zákazníkem, ten jim to schválí, vytesá se to do kamene a teď už jen zbývá to naimplementovat.

Tento scénář má mnoho variací, místo zákazníka může být management, místo produktového manažera analytik, místo tesání do kamene je obvyklejší grafický návrh, ale všechny ty scénáře mají jedno společné. K lidem, kteří to budou dělat a kteří celému systému obvykle rozumí nejvíc, se to dostane až když je to celé vymyšlené.

Řešení hledá problém

Abych se netrefoval jen do cizích řad, tohle se děje často vývojářům. Máme v hlavě řešení, ale nemáme k němu problém. Nemusí to být zrovna vládní čtvrť, může to být nejnovější knihovna nebo jiný hype. Pokud jste někdy ve vaší firmě slyšeli „musíme najít něco, na co bychom použili strojové učení“ tak víte o čem mluvím. U nás to většinou skončí tím, že zkusíme napsat popis problému, který bychom strojovým učením mohli vyřešit. Poté většinou zjistíme, že se daný problém dá řešit lépe nebo že ten problém vlastně nemáme.

Vymýšlení řešení je přirozené

No a to nejtěžší na konec. Lidská mysl je stoj na řešení problémů. Je tak tak dokonalá, že když žádný problém nemá, tak problémy vymýšlí, aby měla co řešit. Je hrozně těžké se udržet u popisu problému. Je těžké říci „můj problém je takový a takový“, je pro nás přirozenější říci „chci to a to“. Je těžké říci „nerozumím tomuto formuláři“, říkáme „měli byste prohodit tato dvě políčka“. Každý chce přispět svým nápadem, takže se udržet u popisu problému je opravdu náročné i když lidi přesvědčíme, že je to nezbytné.

Zkuste si následující hru, podívejte se do vašeho backlogu a spočítejte kolik je tam lístečků s popisem problému a kolik čistě s popisem řešení. U těch popisů řešení zkuste zformulovat popis problému. U kolika z nich to dokážete u kolika z nich si nejste jisti? U těch, u kterých to dokážete, zkuste narychlo vymyslet alternativní řešení. Kolik z nich bude lepších, jednodušších, levnějších?

Příště se podíváme na druhý bod, business metriku, kterou to všechno změříme.

Jak zrychlit vývoj

Představte si, že jste antropolog, který byl vyslán ke kmeni programátorů, aby vyzkoumal, jak zrychlit jejich práci.

Nejjednodušší je, začít daný kmen pozorovat. Máme štěstí, o programování žvaní téměř bez přestání. Vypadá to, že nejdůležitější je, jestli se používají mezery nebo něco, čemu říkají tabelátory. Tak ne, nejdůležitější je psát funkcionálně, stav by měl být prohlášen za tabu. Aha to asi taky ne. Že by řešením bylo zbavit se typů? Nebo je naopak zavést? Co domorodec, to názor.

Také jim můžeme položit následující dvě otázky

  1. Kdybyste si mohli volně vybrat technologie pro příští projekt, o kolik byste byli rychlejší?
  2. Pokud byste psali váš současný projekt se současnou technologií znovu od začátku, o kolik byste ho udělali rychleji?

Nevím jak váš, kmen, ale u toho mého by výběr správné technologie moc velké zrychlení nepřinesl. To se samozřejmě může lišit, pokud děláte v korporaci, která vás nutí používat nepoužitelné nástroje, tak přechod na něco příčeňejšího může přinést docela dost. Něco jako když vás nutí hrát basketbal ve svěrací kazajce a pak vám uvolní jednu ruku. Ale u nás ostatních, technologie a programovací finty už tak zásadní přínos obvykle nemají. Něco jako, když jsme doteď hráli bosí a dostaneme super boty. Pomůže to, ale pokud nedokážeme trefit koš, tak zas ne o tolik.

Co odpověď na druhou otázku? To je jiná. Kdybychom současný projekt dělali znovu, tak bychom se vykašlali na tuhle funkcionalitu, protože jsme ji nakonec stejně vymazali, zeptali bychom se finančního ředitele na jeho názor mnohem dřív, takže bychom nemuseli půlku aplikace úplně předělávat. Možná bychom se do toho projektu vůbec nepustili, protože bychom věděli, jak neuvěřitelně nákladné to nakonec bude.

Proč bychom ten samý projekt psali po druhé mnohem rychleji? V čem je ten rozdíl? V tom, že se při implementaci projektu hlavně učíme. Ano, navenek to vypadá, že hlavně píšeme kód, ale největší fuška je v učení se. Učíme se co zákazník chce. Učíme se jak to sakra zaintegrovat do té hromady čehosi, co už ve firmě máme. Učíme se, jak komunikovat se svými kolegy. Učíme se jak ten systém provozovat. Učíme se jak to efektivně nasazovat. Pořád se prostě jen něco učíme.

Ano, psaní kódu je důležité, je to náš hlavní užitečný výstup, ale není to to, co nás brzdí. Sebelepší programovací prostředí, které mi bude číst myšlenky a generovat podle nich kód mi nepomůže, pokud nevím co mám dělat. Možná vás to překvapí, ale nepomůžou mi dokonce ani mikroservices.

Proč to píšu? Přijde mi, že si to lidé neuvědomují. Jeden můj výše postavený kolega se nám snaží pomoci tím, že chce některou naší méně důležitou programovací práci hodit na někoho mimo tým. Prostě někoho najmeme a o nám to naprogramuje. Jednoduché jako facka. Není. Psaní kódu je bohužel ta nejméně problematická část. Nejtěžší je vymyslet co to má dělat, jak se to má napojit, jak to provozovat a udržovat. To se outsourcovat nedá. Psaní kódu je navíc to co nás na tom baví, takže by nám zůstaly ty věci kolem. Programování by si slízl někdo jiný. Odporná představa.

Důležitost učení si ale neuvědomují ani programátoři. Ti stále vedou své žabomyší války o tom, jestli je lepší Emacs nebo Vi, jestli mají ukládat data do SQL nebo NoSQL, jestli mají používat Docker nebo nevím co. Něco z toho jsou užitečné debaty, ale dokud se ve stejné míře nevěnují i tomu, jak se lépe učit i ty nezáživné neprogramovací věci, tak jsou to debaty bezpředmětné. Lepší technologie mi může pomoci vyndat ze svěrací kazajky i tu druhou ruku, ale když nebudu mít zájem učit se pravidla hry a nepochopím, že tu skákavou kulatou věc mám dostat do té obroučky co visí nesmyslně vysoko nad hřištěm, tak jen budu pokračovat ve zmateném pobíhání po hřišti. Nejspíš mě to bude víc bavit, ale výsledek nebude o moc lepší.