| Mýtický muž-měsíc | |
|---|---|
| Mýtický muž-měsíc | |
| Autor | Frederic Brooks |
| Původní jazyk | Angličtina |
| Originál publikován | 1975 |
| Vydavatel | Addison-Wesley |
| ISBN | ISBN 0201835959 |
| další | Neexistuje žádná stříbrná kulka |
The Mythical Man-Month: Essays on Software Engineering je kniha o řízení softwarových projektů od Fredericka Brookse .
Brooksova kniha je ve skutečnosti sbírkou esejů, které postupně pojednávají o klíčových problémech vývoje velkých softwarových projektů: zvyšování produktivity programátorů, organizování týmové práce, plánování a implementace plánu implementace. Jedním z hlavních témat knihy byla myšlenka, později nazvaná „Brooksův zákon“, že zavádění nových sil do projektu v pozdějších fázích vývoje pouze oddaluje termín projektu [1] .
Anglicky psaný časopis PC World umístil Brooksovu knihu na číslo jedna na svém seznamu „ Top Ten IT Books Never To Admit You Haven't Read “ [2] . Podle průzkumu několika tisíc členů komunity Stack Overflow je kniha jednou z deseti nejvlivnějších knih o programování všech dob [3] . Brooksova kniha je popsána na stránkách Asociace pro výpočetní techniku Library takto: „Velmi málo knih o řízení softwarových projektů se stalo tak vlivnými a nadčasovými“ [4] . Podle publicisty Java World Dustina Markse je The Mythical Man-Month jednou z nejslavnějších knih v celé literatuře o vývoji softwaru a pravděpodobně nejslavnější knihou v oblasti řízení softwarových projektů [5] . Podle časopisu Computerra o Brooksově knize se „ve Spojených státech dlouho věřilo, že bez přečtení nebude žádný manažer vývoje softwaru schopen efektivně jednat“ [6] .
Možná má tedy ještě smysl číst Fredericka Brookse, než se pustíte do nového softwarového projektu?
PC týden [1] .Brooksova pozorování vycházejí z jeho zkušeností v IBM při řízení projektu operačního systému OS/360 . Aby vývoj urychlil, neúspěšně se pokusil přilákat do projektu další pracovníky, jejichž termíny již byly prošlé. Brooks si všiml schopnosti manažerů opakovat takové chyby a posměšně nazval svou knihu „bible pro softwarové inženýrství“: „všichni ji četli, ale nikdo se jí neřídí!“
Brooks také tvrdil, že psaní kompilátoru jazyka Algol by trvalo šest měsíců, bez ohledu na počet lidí zapojených do projektu.
Kniha byla poprvé vydána v roce 1975 , v roce 1979 vyšla v ruštině. Výroční vydání z roku 1995 (v ruštině - 2000 ) obsahuje další kapitoly: esej „ Neexistuje žádná stříbrná kulka “, publikovaná v roce 1986 (kapitola 16), revizi toho, co bylo v této eseji řečeno o 10 let později (kapitola 17) a autorovy komentáře ke své knize 20 let po jejím prvním vydání (kapitoly 18 a 19).
program a softwarový produkt. Softwarový produkt se liší od programu:
Softwarový produkt vyžaduje 3krát více času než program (kapitola 1).
Mýtický muž-měsíc. Doba realizace projektu není nepřímo úměrná počtu programátorů minimálně ze 2 důvodů.
Pokud existuje N programátorů, pak se počet párů programátorů rovná N ( N - 1) / 2, to znamená, že s rostoucím počtem programátorů roste čas strávený interakcí kvadraticky. Proto, počínaje nějakým N, nárůst počtu programátorů projekt zpomaluje .
Pokud se termíny nedodržují, najímání nových programátorů zpomaluje projekt z jiného důvodu: nováčci potřebují čas na učení. Kniha formuluje "Brooksův zákon": "Pokud projekt nejde podle plánu, přidání práce jej ještě více zdrží."
Při velkém počtu programátorů nemusí být projekt nikdy dokončen: kvůli všeobecnému zmatku generují pokusy o opravu stávajících chyb v softwaru nové chyby, takže se systém nezlepšuje (kapitola 2).
chirurgické týmy. Pro vývojový tým má smysl mít jednoho „dobrého“ programátora, který implementuje nejkritičtější části systému, a několik dalších, kteří mu pomáhají nebo implementují méně kritické části. Takto se dělají operace. Podle Brookse navíc nejlepší programátoři pracují 5–10krát rychleji než ostatní (kapitola 3).
koncepční integrita. Pro zajištění koncepční integrity systému je nutné oddělit architekturu od implementace. Jeden vedoucí architekt (nebo malá skupina), jednající v nejlepším zájmu uživatele, rozhoduje o tom, co by mělo a nemělo jít do systému. „Velmi cool“ nápad může být zamítnut, pokud navrhovaná funkce nezapadá do celkového návrhu systému. Jednoduchost je velmi důležitá; může být užitečné implementovat pouze podmnožinu schopností, kterých je systém schopen, protože pokud je systém příliš složitý, některé jeho schopnosti zůstanou nevyužity.
Hlavní architekt by měl svá rozhodnutí formulovat ve formě uživatelské příručky (kapitola 4).
Účinek druhého systému. Programátor vyvíjející svůj druhý systém má tendenci přidávat všechny funkce, které do svého prvního systému přidat nemohl (kvůli nedostatku času). Proto se často ukazuje, že druhý systém je přetížený schopnostmi (kapitola 5).
formální dokumenty. Každý projektový manažer by měl vytvořit malý soubor formálních dokumentů, které popisují cíle projektu, jak, kým a kdy budou realizovány a kolik to bude stát. Tyto dokumenty mohou odhalit nesrovnalosti, které by jinak bylo obtížné postřehnout.
Každý vývojový tým obdrží sadu požadavků na svou část systému, včetně přesného popisu její funkčnosti a maximálních požadavků na procesorový čas, paměť, místo na disku atd.
Interakce. Aby se předešlo katastrofě, musí vývojové týmy vzájemně spolupracovat všemi možnými způsoby. Namísto předsudků o funkci, kterou realizují, by měl developer architektovi položit upřesňující otázky, protože předpoklady se mohou ukázat jako zcela mylné. "Předpoklad je matkou neúspěchu."
pilotní systém. Než může být vyvinut konečný systém, musí být vyvinut pilotní systém. Pilotní systém odhalí konstrukční chyby, po kterých musí být kompletně přepracován (kapitola 11). Brooks tuto myšlenku odmítá o 20 let později v kapitole 19, protože přístup k vytváření programů se za 20 let změnil – iterativní model vývoje přijatý v 60. a 70. letech nahradil model vodopádového vývoje .
Verze a zmrazení systému. Při budování systému se mohou požadavky uživatele na něj měnit na základě jeho zkušeností s nedokončeným systémem. Tato přání uživatele by měla být zohledněna, ale pouze do určitého bodu, jinak nebude práce na systému nikdy dokončena. Poté jsou specifikace zmrazeny a všechny následné požadavky na změnu jsou odloženy, dokud nezačne práce na další verzi (kapitola 11).
Specializované utility. Namísto toho, aby každý programátor psal své vlastní nástroje, měl by mít každý vývojový tým jednoho programátora odpovědného za psaní utilit pro svůj tým (například generátor kódu, který generuje kód podle nějaké specifikace). Měla by existovat také skupina, která vytváří utility pro každého, kdo pracuje na daném systému (kapitola 12).
Snížené náklady na vývoj. Brooks uvádí 2 způsoby, jak snížit náklady na vývoj softwaru: