Jeff Atwood, autor stackoverflow.com, v jednom svém příspěvku na blogu napsal, že vše co nyní umíte, bude za pět let zastaralé. Na příběhu Alenky v říši divů ilust­ruje, že když se učíte nové techno­lo­gie, tak sice běžíte jak jen nejrych­leji dovedete, ovšem pouze proto abyste zůstali na místě. Pokud se někam chcete posunout, musíte číst i něco, co nezas­tará, něco o lidském faktoru a designu. Na jeho seznamu doporučené četby hned na druhém místě figuruje kniha esejů The Mythical Man-Month (Frederick P. Brooks). Takřka čtyřicet let staré dílo je stále aktuální. Můžeme si povzdech­nout, že i po tak dlouhé době se softwa­rové inženýr­ství (a nejen to) nepouč­ilo. Sám název se trefuje do člověkoměsíce, do nebez­pečné a zavádějící jednotky práce.

Člověkoměsíc

Člověkoměsíc jako jednotka práce je nebez­pečný a zavádějící především proto, že naznač­uje, že lidé a měsíce jsou jednotky navzájem zaměni­telné. Ostatně střílí si z toho i Dilbert. Ovšem zaměni­telné jsou pouze za předpok­ladu minimální komuni­kace při mecha­nic­kých pracích jako je sklizeň obilí nebo sběr bavlny, což se ani zdaleka nepodobá softwa­rovému inženýr­ství. Pracov­níci na softwa­rovém projektu spolu potře­bují komuni­ko­vat; tři kolegové třikrát více než dva, čtyři již vyžadují šestkrát tolik inter­akce než dva; podle vzorce n(n-1)/2. Nadto člověkoměsíce nijak neref­lek­tují čas potřebný na zaško­lení a zapra­cování nového programátora.

Tím se dostáváme k teorému zvanému Brooksův zákon, který říká, že přidáním lidské síly v pozdní fázi projektu paradoxně způsobíte to, že se projekt opozdí. Tak jako žena nosí dítě v lůně devět měsíců, tak nemůže devět žen donosit dítě za měsíc jediný.

Přesah, který v knize nenalez­nete, jsou body (story pointy) - bezroz­měrné jednotky, se kterými operují agilní metodiky jako je například Scrum.

Odhady

Programátoři jsou v podobné situaci jako kuchař, jemuž sice může majitel restau­race vnutit odhad, ale není již v jeho silách zvlád­nout samotné prove­dení. Omeleta, kterou vám slíbená do dvou minut zní skvěle, ale co když to nestih­nou? Zákazník má dvě možnosti, počkat nebo ji sníst syrovou. Naši zákaz­níci jsou na tom stejně. Kuchař má ještě další možnost, zvýšit výkon sporáku - jednu stranu pak připálí a druhá zůstane syrová.

Opět vsuvka z agilních technik - odhady týmu je potřeba respek­to­vat, product owner je neovlivňuje.

K odhadům snad ještě to, že okomet­ricky zabere samotné kódování ⅙ času, design ⅓ a testy ½ (z toho ¼ jednot­livé kompo­nenty a ¼ integ­rační testování). Navíc celkové náklady na údržbu činí typicky 40 procent nákladů na vývoj, někdy i více. A čím více uživa­telů, tím více chyb najdou.

Krátce k termínům. Propás­ne­te-li nějaký, vynas­nažte se, ať ten příští splníte. Jinak to půjde s morálkou z kopce.

Management

Kvalita lidí a jejich organi­zace jsou pro úspěch projektu daleko důležitější než nástroje a technické postupy.

Přeřa­zení z technické pozice na odpovídající manažer­skou pozici by nemělo doprovázet zvýšení platu a rozhodně by nemělo být prezen­továno jako povýšení. Manažery je potřeba posílat na technické kurzy a senior technické pracov­níky na kurzy manažer­ské. Ti, pokud talent dovolí, musí být připra­vování na to, aby technicky i emočně zvládli vést skupinu nebo měli potěšení z toho, že přiloží ruku k dílu programování.

Zajímavý postřeh se týká speci­fi­kace, před začátkem samotné imple­men­tace musí být přezkoumána její úplnost a srozu­mi­tel­nost. Programátoři toho nejsou schopní. Pokud speci­fi­kaci neroz­umí, vesele si najdou cestu skrze její mezery a nejasnosti.

Nebojte se neúspěchu

Je mnohem lepší být expli­citní a mýlit se, než být vágní. První verze bývají sotva použi­telné: příliš pomalé, příliš velké, obtížně použi­telné, nebo všechno dohromady.