Chtěl bych se vrátit ke knize Slack, o které jsem tu už psal. Tenkrát jsem si vybral kapitolu, která se mě tehdy docela dotýkala. Bohužel z ní nebylo vidět, o čem ta kniha je. A to je škoda, protože Slack je jedna z nejlepších knih, kterou jsem o managementu četl (ono jich zas tolik nebylo).

Název Slack by se dal podle slovníku přeložit jako časová rezerva, nevyužitý nebo dokonce flákat se. O tom všem to je – o potřebě určité volnosti. Jako příklad uvedu citaci

Vezměte si například sekretářku (Pamatujete si ještě sekretářky? Kdysi obvyklý prvek firemního života.) Práce sekretářky […] usnadňuje hladký průběh pracovního života manažera. Říkejme ji Silva.

Problém je samozřejmě v tom, že teď plně využitá sekretářka jednoduše nereaguje tak rychle jako Silva. Tato nově výkonná osoba prostě nereaguje tak rychle na věci, které je potřeba udělat, protože má moc práce.

Platí něco podobného o programátorech? Když přijdete na to, že potřebujete 73% programátora, můžete hodit ten zbytek do „poolu“ k dispozici jiným manažerům? Když potřebujete 100% senior programátora, můžete počítat s tím, že ho budete mít na 100%? Co když bude potřebovat poradit nováčkovi, co když bude potřeba řešit něco na projektu na kterém už dávno oficiálně není? Co když bude potřeba pomoci s nabídkou pro nového zákazníka?

Představte si firmu, kde může manažer říci, „Já potřebuju Tondu jen na 50%, zbytek dávám k dispozici, ať si ho veme kdo chce“. Může to fungovat?

Podle mě ne. Za prvé, ten manažer ho nechce jen na 50%, on ho chce jen na 50% platit. Nevěřím, že pro něj bude práce přesně na 4 hodiny denně. Spíš bych tipoval, že víc.

Navíc mám pro vás jednu novinku, programátoři se nedají krájet. Když si z programátora ukrojím půlku, dostanu dvě půlky mrtvoly. Když to udělám jen obrazně, dopadne to jen o trochu lépe. Takže opakuji: 1 programátor – 0,5 programátora << 0,5 programátora. Platí rovnice, kterou se opět můžeme dočíst v knize (od které jsem se na moment trochu odchýlil, za což se všem postiženým omlouvám) Trest za přepínání úloh = čas potřebný pro přesun na novou úlohu + oprava chyb způsobených nevhodným přerušením v práci + čas pro opětovné se ponoření do úkolu + frustrace + ztráta vazby na tým

Takže jak to dopadne v naší hypotetické firmě, která umožňuje prodat dvě půlky programátora? Napadají mě dvě možnosti. Buď budeme potkávat na chodbách usínající programátory, kteří pracují na 150% procent. Nebo se prostě a jednoduše budou falšovat výkazy, tak aby to vypadalo, že máme dvě nezávislé půlky programátora.

Žádný plán nepřežije střet s nepřítelem. [polní maršál Helmut Graf von Moltke]

Včera jsem dočetl knihu Agile Estimating and Planning od Mika Cohna. Je to kniha docela zajímavá, zvlášť pro mě, který o daném tématu neví skoro nic.

Dozvěděl jsem se v ní proč je dobré plánovat, proč je to tak těžké a hlavně jak to dělat správně agilně. Konečně jsem také pochopil co je to story point (bod příběhu ??).

V agilních procesech by mělo odhadování mělo probíhat ve dvou fázích. V první fázi určíme takzvané uživatelské příběhy (story). Tzn. sepíšeme si, co vlastně budou jednotliví uživatelé se systémem dělat. Je to podobné jako klasické případy užití (use case), jenom mnohem stručnější. Příběh může vypadat například takto: „Jako uživatel mohu uložit dokument“. Poté celý tým odhaduje relativní velikost jednotlivých příběhu. Přiřazuje jim body, které nemají žádný reálný základ. Odrážejí jenom relativní velikost jednotlivých příběhů mezi sebou. Takže uložení dokumentu může mít velikost 5 bodů, načtení třeba 3. Sečtením bodů všech příběhů získáme odhad velikosti celého projektu (releasu).

Poté nastává druhá fáze, kdy se snažíme převést bezrozměrné body na čas. Zde nám začíná hrát roli rychlost (velocity). Pokud už agilně vyvíjíme, víme kolik bodů zvládne daný tým udělat za iteraci. Tomuto číslu budeme říkat rychlost. Poté už můžeme přibližně odhadnout, kolik iterací zabere současný projekt. Jednoduše vynásobíme rychlost počtem bodů. Pokud rychlost neznáme, můžeme ji odhadnout tak, že si zkusíme odhadnout trvání pár příběhů v hodinách a z tohoto odhadu odhadnout rychlost. Nicméně pravá rychlost týmu se projeví až (už) po prvních pár iteracích.

V čem je tento přístup výhodný? Je snadný. Je snadné říci, jestli je implementace jednoho uživatelského příběhu dvakrát těžší než implementace druhého. Je snadné říci, že jiné dva příběhy jsou přibližně stejně obtížné. Při odhadování velikosti opravdu jenom porovnávám jednotlivé příběhy mezi sebou.

Čas se počítá až v druhé fázi a to více méně automaticky. Rychlost je dána, tu známe z předchozích iterací. Takže jenom vynásobíme velikost projektu rychlostí a máme odhad trvání projektu. Je hodně těžké švindlovat a lhát si do kapsy. Těžko se hájí to, že začneme tvrdit, že se rychlost z čista jasna zvýší na dvojnásobek. Naopak, když se nám kvůli nějakým problémům rychlost sníží, projekt se automaticky přeplánuje. Okamžitě uvidíme, jak dlouho bude projekt trvat pokud budeme mít tuto rychlost i v dalších iteracích.

Kniha se samozřejmě věnuje i jiným tématům než odhadování a plánování celého projektu. Věnuje se i plánování jednotlivých iterací, monitorování, komunikaci a jiným tématům. Hodně pěkná je i kapitola o určování toho, které příběhy implementovat a které ne, ale o tom snad napíši někdy jindy.

Poznámka: Snažil jsem se termíny překládat do češtiny. Uvědomuji si, že některé termíny znějí trochu kostrbatě. Pokud máte lepší překlad, napište mi ho prosím.