Category Archives: Knihovnička SE

Mýtický člověko-měsíc

Nedávno se mi dostala pod ruku známá kniha The Mythical Man-Month, Frederick P. Brooks, Jr. Není bez zajímavosti, že letos slavíme 20 let od jejího prvního vydání. Musím se přiznat, že mě dost nadchla. Člověk se v ní dočte, jaké problémy museli vývojáři řešit v prehistorických dobách softwarového inženýrství.

Pro příklad uvedu volný výtah z kapitoly která dala jméno celé knize – Mýtický člověko-měsíc. Začněme nejdříve citátem, který se dnes označuje jako Brooksův zákon:

Přidáním lidí na zpožděný softwarový projekt ho ještě více zpozdíte.

Autor uvádí krásný příklad (text kurzivou jsou moje poznámky):

Mějme projekt který je odhadován na 12 člověko-měsíců. Na začátku nasadíme 3 programátory a budeme předpokládat, že projekt bude hotov za 4 měsíce. Stanovíme si milník na konec každého z nich. Dejme tomu, že jsme udělali chybu v odhadech a k prvnímu milníku dorazíme až po dvou měsících. Máme několik možností jak situaci řešit:

  1. Předpokládejme, že musíme dodržet termín a že byly špatně odhady jenom první části. Z původně odhadovaných 12 člověko-měsíců nám jich zbývá devět. S dvěma měsíci na dokončení nám to dává, že jsme 3 člověko-měsíce ve skluzu, a že pro dohnání skluzu potřebujeme 4,5 programátorů. Ke stávajícím třem tedy přidáme další dva.
  2. Předpokládejme, že musíme dodržet termín a že byly stejně špatné všechny odhady. Zbývá nám tedy 18 měsíců, což dává 9 programátorů. Najmeme dalších 6 programátorů
  3. Odložení termínu. Rada pana P.Fagga říká: „Nedělejte malé odklady“. Tzn. nechte si dost času, abyste termín dokončení nemuseli posouvat znovu.
  4. Zmenšení rozsahu. Pokud se nestíhá termín dojde k tomu tak jako tak. Jediná manažerova šance je snížit rozsah formálně, dřív než se ve spěchu začne odbývat design a testování.

Zamysleme se co se stane, když zvolíme první variantu. Předpokládejme, že dva nově najatí muži budou potřeba měsíc na zaučení se. Celou tu dobu se jim bude věnovat jeden ze stávajících programátorů (to se může zdát jako poněkud pesimistický předpoklad, nicméně můžeme do něj započítat vyšší nároky na vzájemnou komunikaci a koordinaci týmu, složitější rozdělení si práce atp.). Ve třetím měsíci vývoje tedy budou naplno pracovat jenom 2 programátoři. Před posledním měsícem projektu budeme mít 5 programátorů a 7 člověko-měsíců práce. Jsme tedy 2 čm ve skluzu. Jak to vyřešit? Že by dalším rozšířením týmu? (Tady přicházejí ke slovu manažerské dovednosti k tomu jak přesvědčit programátory aby to „nějak“ stihli, tzn. za cenu přesčasů a nízké kvality aplikace, často také zkrácením „nepotřebného“ testování)

Toliko ukázka z knihy (pro nezkreslenou informaci doporučuji originál). Vidíme jaké máme štěstí, že již žijeme v moderní době a nemusíme řešit stejné problémy jako v prehistorii softwarového inženýrství. Nicméně kdybychom si chtěli přeci jen odnést nějaké poučení, bylo by asi následující:

  1. Lidé a měsíce se nedají volně směňovat za člověko-měsíce
  2. Člověk by se měl dvakrát rozmyslet, než se rozhodne zachraňovat rozjetý projekt přidáváním lidí.