Je lepší mít jednu dokončenou knihu, nebo dvě rozepsané? Kdysi jsme v práci narazili na podobný problém. Doručovali jsme klientům málo nových dokončených funkcí, zatímco těch rozpracovaných jsme měli mraky. Mohli jsme mít desítky požadavků, které jsme řešili tak nějak souběžně a dokončovali jsme je jen pomalu. Jak z toho ven?
Přestaň začínat, začni dokončovat! To je motto, kterým jsme se začali řídit. Klíčovou metrikou se pro nás stala doba, za kterou jsme vyřešili klientův požadavek a této metrice jsme podřídilo skoro všechno. Řekli jsme si, že je lepší soustředit se na jeden úkol od začátku do konce bez přerušování a prostojů než se snažit řešit souběžně úkoly dva. To se snadno řekne, ale realita bývá složitější.
Pull requesty a reviews
Vezměte si třeba takové review, které jsme tehdy běžně dělali. Po tom, co jsme týden programovali nějakou novou funkci pro naše milé uživatele, jsme dali náš kód na posouzení jinému programátorovi. Ten samozřejmě neměl čas, protože řešil své věci a už vznikají první prostoje, kdy jen čekáme na ostatní. Nakonec se po dvou dnech hodnocení dočkáme, jenomže náš krásný kód se mu nelíbil a požaduje jisté úpravy. Některé zapracujeme, některé návrhy se nám nelíbí, takže proti nim protestujeme. Protože za sebou máme školení soft-skills, tak víme, že programátoři obyčejně používají o jeden stupeň horší komunikační prostředek než by bylo nejlepší, takže se rozhodujeme, že dotyčnému programátorovi zavoláme. Fajn nápad, ale kolega už odletěl na dvoutýdenní dovolenou na Mauricius, který nám nezapomněl doporučit. No dobře, tak zajdeme do kuchyňky, tam v rohu najdeme další oběť a protože nemá kam utéct, slíbí nám, že se na náš kód hned další den podívá. O tři dny později nám přistane v e-mailu komentář, že je to celé blbě, protože polovina kódu tam vůbec nemusí být, jelikož už stejný kód máme v jedné knihovně, která vznikla před půl rokem a o které jsme evidentně nevěděli. Moc nás to ale netrápí, protože e-mail si už čteme na letišti v Praze cestou na Mauricius.
Začínáme s mob programmingem
Člověk tak sice reálně tráví programováním něčeho pár dnů, ale pak stejně trvá i několik týdnů, než se kód dostane do produkce k uživatelům. Jak se zbavit podobných čekaček na hodnocení kódu a zároveň mít jistotu, že každý řádek kódu viděl a zkontroloval více než jeden programátor? Tak, že kód budou po celou dobu vývoje psát alespoň dva lidi, nejlépe ještě více. Začali jsme proto provozovat tzv. “mob programming”, česky asi “skupinové programování”. Tehdy se to ještě spojilo s covidem a nuceným home officem, takže jsme rovnou skočili do “remote mob programmingu”.
Ten probíhal tak, že několik lidí zformovalo typicky tříčlenný nebo čtyřčlenný tým, obsadil jeden zoom room a začal spolu dělat na jednom úkolu. Opravdu spolu a opravdu na jednom úkolu – všichni jsou celou dobu ve stejném zoom roomu, jeden člověk sdílí obrazovku a programuje a zbylí tři lidé neprogramují sami, ale radí se a komunikují mezi sebou jak nejlépe vyřešit daný úkol. Po čase se lidé v roli vymění a všichni se ve sdílení obrazovky prostřídají. A takhle furt dokola dokud se nedokončí úkol, který má tým na starosti.
Teče to
Jednou z hlavních výhod je, že tým, který “mobuje”, nemusí dávat svůj kód na posouzení dalším lidem, protože už ho vidělo lidí dost. Tím pádem odpadá ten věčný ping-pong, kdy se člověk v komentářích dohaduje o něčem i několik dní a furt to není dost dobré. Odpadá i další časté zpomalení, kdy někdo odjede na dovolenou a nechá za sebou rozdělanou práci. V čtyřčlenných skupinách obyčejně vždycky alespoň někdo zůstane a může pokračovat dále v rozdělané práci. Žádný úkol se tak prakticky nikdy nezastaví, vždy na něm někdo pracuje. Nečeká se na review, nečeká se na dovolené. Pokud už se na něco čeká, tak je to obyčejně na nějakou třetí stranu, třeba se čeká na vyjádření klienta, a s tím už se toho nedá moc dělat. Celý vývoj je tak mnohem plynulejší a tým jednotlivé úkoly doručí rychleji než jednotlivec, který musí stále na někoho čekat a kterého stále něco brzdí.
Příjemným vedlejším efektem pak je, že máme přirozeně rozpracováno méně úkolů. Když jsme měli 20 programátorů, kteří všichni pracovali na něčem sami, řešili jsme paralelně dvacet úkolů a měli jsme velký problém to uřídit a zkoordinovat. Když ale dvacet programátorů rozdělíme do pěti skupin po čtyřech lidech, řešíme najednou jen pět souběžných úkolů. Najednou je to řádově jednodušší na řízení.
Sharing is caring
Skupinové programování je výborné také pro sdílení znalostí všeho druhu. Od takových maličkostí jako že si všimnete, že kolega používá nějakou klávesovou zkratku v editoru, kterou jste neznal, až po sdílení doménových znalostí. Výborně funguje zaškolování nováčků, máme velmi dobrou zkušenost s tím, že než hodit nováčka do vody a nechat ho plavat v kódu samotného, je mnohem lepší když je součástí skupiny – rychleji pochytí firemní principy a styl programování. A mnohem dříve začne být užitečný, než kdy sám několik dnů zkoumá pro něj neznámý kód.
Pokud máte oblíbený styl programování, můžete snadno ve skupině nakazit svým nadšení třeba pro funkcionální programování ostatní členy týmy. Anebo si naopak můžete nechat ukázat, že dědění opravdu není nejlepší způsob sdílení kódu a že dědit se mají domy, ne třídy.
Při skupinovém programování tak dochází k obrušování hran, které celkově vede k hezčímu kódu. Neprojde vám žádný super-pokročilý a hyper-složitý one-liner, protože se vždycky najde někdo přímo v té skupině, kdo tomu zápisu nebude rozumět. Už během psaní musíte psát kód tak, ať mu rozumí zbývající členové týmu, jakákoliv nejasnost se musí vyjasnit hned, ne za dva týdny na review.
Pamatujete si, jak jste se nedávno při programování zasekli na nějaké kravině? Na nějaké blbosti, která vám nedošla, spálili jste na tom tři hodiny času a nakonec k vám přišel kolega a za půl minuty vám řekl, že vám tam chybí středník? Ve skupinovém programování máte k dispozici tři takové kolegy. Non-stop.
Rozhodování
Veškerá rozhodnutí, která padnou, jsou prodiskutována ve skupině čtyř lidí. Samozřejmě, ani skupina čtyř lidí se ne vždy rozhodne správně. Vyšší počet lidí automaticky neznamená správnost rozhodování. Ale ta šance na nalezení správného řešení se výrazně zvyšuje. Opravdu se stává jen výjimečně, že by skupina odevzdala nějaký úkol, který by byl vyřešený nějak úplně špatně. Možná v detailech jsou problémy, ale že by odevzdala řešení, který by bylo od základu špatně, to se neděje.
Pokud skupina odevzdává nějaké řešení, je si obyčejně více jistá a více si za ním stojí. Je to také daleko méně stresové, než když musí rozhodnutí učinit jednotlivec.
Čtyřikrát nižší výkonnost?
Když jsme to se skupinovým programováním zkoušeli, báli jsme se, že celková výkonnost firmy klesne. Přece když čtyři lidé dělají to, co jinde zvládne jeden člověk, tak to musí znamenat, že toho stihneme čtyřikrát méně, že?
Bohužel, nemáme žádná tvrdá data, která by potvrzovala nebo vyvracela tuto domněnku. Máme spíš jen naše pocity, které nám říkají, že ke ztrátě výkonnosti nedošlo. Pozorujeme zjevné benefity, že když je problém s nějakým systémem, tak jsou najednou k dispozici čtyři lidi, kteří přesně tuhle věc programovali a jsou schopni rychle zasáhnout, takže se nestávají chvíle jako “máme v produkci problém a člověk, který to programoval je na Mauriciu”. Celý vývoj je mnohem klidnější a méně stresový, protože víte, že na to nejste sám. Že si právě v klidu můžete vzít dovolenou a stejně bude v práci někdo, kdo za vás dodělá rozpracovaný úkol nebo vyřeší chybu na produkci. Přitom vidíme, že jinde zdaleka taková zastupitelnost není, což pak vede k reálným problémům typu “máme problém s tímhle skriptem, kterému rozumí jen náš ex-kolega, který před měsícem opustil firmu”.
V konečném zúčtování věříme tomu, že celková výkonnost firmy neklesla, spíš se zvýšila, díky benefitům jako je právě prakticky dokonalá zastupitelnost a vyšší kvalita kódu.
S čím jsou problémy
Nic není dokonalé. S čím jsme tedy měli problémy?
- Technické problémy. Když děláme remote-mob-programming, tak je samozřejmě problém se zvukem a celkově pak remote-mob-programming chvílemi připomíná vyvolávání duchů (“někdo se k nám chce připojit”, “Alžběto, jsi tam?”, “neslyšíme tě”, “slyšíš nás?”)
- Zatímco sdílení znalostí funguje dobře mezi členy jedné skupiny, tak sdílení napříč jednotlivými skupinami už nijak zajištěné není. Řešením je asi rotovat členy skupin řádově častěji, než to teď děláme.
- Někteří lidé si stěžují na to, že nemají takový ten pocit “flow”, kdy jste zažraní do úkolu, který zrovna děláte a prostě ze sebe jen sypete tisíce řádků kvalitního objektového kódu.
- Spoustě lidem vadí, že nemůžou poslouchat Cradle of Filth či jinou oblíbenou hudbu.
- Velký problém je to v kancelářích, protože to tam vypadá jako v call centru. Přijdete tam, všichni mají na hlavně sluchátka a trochu si připadáte, jako že v tom kanclu ani nejste.
- Samozřejmě, že každý člověk je jiný a ne každý snese být celý den na callu s dalšími třemi lidmi a celou dobu s nimi smysluplně komunikovat. Není to jako celý den kopat výkop, ale přesto může být člověk po celém dni “mobování” velmi unavený a psychicky vyčerpaný. V takovém případě je dobré si od mobování alespoň na chvíli odpočinout.
Shrnutí
Celkově naší zkušenost s (remote) mob programmingem hodnotíme velmi kladně a postupně na tuto techniku přešla většina programátorů ve firmě. Je to něco, o čem si myslíme, že nám to pomáhá ve vývoji a v čem hodláme pokračovat i nadále. Doporučuje 1000 z 1010 programátorů Stroeer Labs.
O mob programmingu existují i vědecké práce, můžete si přečíst například tuto: Mob Programming: From Avant-Garde Experimentation to Established Practice.