Category Archives: Agile

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ší.

Důležité je i to, co neuděláte

Když se jednoho slavného sochaře zeptali, jak pracuje, řekl jim že to je jednoduché. Stačí z bloku kamene odseknout všechny ty části, co nejsou socha. Zbavíte se zbytečných částí a uprostřed vám zbude to důležité.

Došlo mi, že to samé platí i u software. Je nesmírně důležité si vybrat co nedělat. Máme nepřeberné množství věcí, které naše aplikace může dělat, nespočet nápadů které můžeme implementovat. Zároveň ale máme omezené množství času a kapacity, musíme si proto moc pečlivě vybírat co dělat a co ne.

Přistihl jsem se, že moje přirozená reakce je přesvědčovat lidi, aby se nepouštěli do nových věcí a radši použili to co máme. Nebo přinejmenším, aby to co chtějí udělat, výrazně zjednodušili. A dokonce mi to i dělá radost. Jsem mnohem radši, když někoho přesvědčím, aby něco neudělal, než když mu pomůžu vymyslet jak to udělat. Většinou mi na to stačí pár dobře mířených otázek typu „Co nám to přinese?“, „Opravdu to potřebujeme?“ nebo „Jak se to bude používat?“

Přijde mi, že v naší branži máme sklon dělat věci moc složitě. Slyšíme náznak problému a už nám to v hlavě jede. Začneme si stavět vzdušné zámky, začneme vymýšlet jak to udělat co nejelegantněji, tak aby to bylo super efektivní a ideálně tak abychom využili tu poslední cool technologii. Často přeskočíme fázi kdy bychom se měli zamyslet, co za problém vlastně chceme řešit a jestli to nejde jinak.

Myslel bych si, že jsem líný, ale podobný přístup pozoruji i u svých výrazně pracovitějších kolegů. Nedávno se kolegovi podařilo snížit odhady jednoho řešení na třetinu tím, že vymyslel fintu jak většinu z té práce neudělat a přesto vyřešit problém. To je něco, co nepodchytíte žádným review, nepopíšete metrikou, nenapíšete si to do životopisu, zákazníci se o tom nedozví a přesto je to strašně důležité. Je to ta část kamene kterou odseknete, ta část práce kterou neuděláte.

Jaký problém tím vyřešíme?

Minulý týden jsem kolegům přednesl revoluční návrh. Zaměstnanci začnou nosit výložky stejně jako vojáci. Programátoři by začínali u desátníka, architekti u rotmistra a manažeři u majora. Jak se dalo čekat, návrh vzbudil bouřlivou diskuzi. Nejdřív si vzal slovo kolega František. Jsme americká firma, výložky by měly být podle americké armády. Jindřich se přidal se zajímavým rozborem různých hodností ve světových armádách. Netušil jsem, že se v tom tak vyzná. Vladan navrhl vylepšení, výložky by měly být barevně odlišeny podle týmu, ve kterém daný člověk pracuje. To byla voda na Jindřichův mlýn, útvary se prý odjakživa odlišují pomocí insignií.

Pak se ozval Bedřich, známý potížista. Prý k čemu to bude dobré? To je snad jasné. Budeme vědět, kdo je na jaké pozici a když přidáme barvy nebo insignie, tak budeme i vědět, z kterého týmu daný člověk je. Petra se následně zeptala, jak to bude připevněné, že prý se bojí, že se budou kolegové převlékat ještě méně než dosud. Za pár minut jsme se shodli, že kombinace suchého zipu a spínacích špendlíků by to mohla vyřešit. I když František dál trval na lepidle a Jindřich na firemních košilích. Pak se zas ozval Bedřich. Prý jaký problém tím vyřešíme. Poprosil jsem ho, ať je konstruktivní a řekne mi, co konkrétně mám na svém návrhu vylepšit. Vypršel čas, poděkoval jsem všem za zpětnou vazbu, svůj návrh podle ní upravím.

No dobře, celý tento příběh jsem si vymyslel, nicméně jsem zažil pár podobných diskuzí. Obsah byl výrazně méně absurdní, ale průběh se moc nelišil. Někdo přijde s dobře míněným návrhem, rozpoutá se diskuze o detailech, ale nezazní to nedůležitější – jaký problém nám to vyřeší.

Proč je to tak důležité? Protože každá změna něco stojí a my máme omezené množství času, duševní energie, pozornosti a dalších zdrojů. Musíme si proto vybírat. Samozřejmě, pokud je to malá změna, třeba na úrovni týmu nebo jednotlivce, tak ji můžeme udělat bez většího přemýšlení. Když se rozhodnu, že mi větší úspěchy u žen zajistí nošení růžových ponožek, tak mě to moc nestojí. Ale i tak je dobré vědět, proč změnu dělám, abych mohl vyhodnotit jestli to pomohlo.

Horší je to s celofiremními aktivitami. Ty nemůžeme dělat jen tak. Ty jsou vždy nákladné už jen v komunikaci, vysvětlování, překonávání odporu, učení se novým věcem. U takovýchto změn nestačí vědět co zlepší, musíme vědět jaký problém vyřeší. Pokud chystáte velkou změnu jen kvůli drobnému zlepšení, tak je velká šance, že napácháte víc škody než užitku.

Takže u každé větší změny prosím ptejte „Jaký problém tím vyřešíme?“ před tím, než se vrhnete do řešení detailů. Pokud se vám nedaří na tuto otázku jednoznačně odpovědět tak se vám pravděpodobně změna nevyplatí. Ale pozor, jak už jsem tu kdysi psal, je jednoduché najít problém pro řešení, které mám zrovna v hlavě. Chci zavést výložky, tak najdu problém – nevím kdo má jakou roli a v jakém týmu dělá. Nemusím to dělat záměrně nebo se zlým úmyslem, tak prostě můj mozek pracuje. Proto je dobré se zamyslet, jestli se jedná o problém, který nás opravdu pálí natolik, že ho stojí za to řešit na celofiremní úrovni.