| Mitikus emberhónap | |
|---|---|
| A mitikus emberhónap | |
| Szerző | Frederic Brooks |
| Eredeti nyelv | angol |
| Az eredeti megjelent | 1975 |
| Kiadó | Addison–Wesley |
| ISBN | ISBN 0201835959 |
| Következő | Nincs ezüstgolyó |
A The Mythical Man-Month: Essays on Software Engineering című könyve Frederick Brooks szoftverprojektmenedzsmentjéről szól .
Valójában Brooks könyve olyan esszék gyűjteménye, amelyek egymás után tárgyalják a nagy szoftverprojektek fejlesztésének kulcsfontosságú problémáit: a programozók termelékenységének növelését, a csapatmunka megszervezését, a megvalósítási ütemterv megtervezését és végrehajtását. A könyv egyik fő témája a később "Brooks-törvénynek" nevezett gondolat volt, miszerint a fejlesztés későbbi szakaszaiban új erők bevonása a projektbe csak a projekt határidejét tolja el [1] .
A PC World angol nyelvű magazin Brooks könyvét az első helyre helyezte a " Top Ten IT Books Never To Admit You Haven't Read " listáján [2] . A Stack Overflow közösség több ezer tagjával végzett felmérés szerint a könyv minden idők tíz legbefolyásosabb programozókönyve közé tartozik [3] . Brooks könyvét az Association for Computing Machinery Library honlapján a következőképpen írják le: "Nagyon kevés a szoftverprojekt-menedzsmentről szóló könyv vált ennyire befolyásossá és időtlenné" [4] . A Java World rovatvezetője , Dustin Marks szerint a The Mythical Man-Month az egyik leghíresebb könyv a teljes szoftverfejlesztési irodalomban, és valószínűleg a szoftverprojektmenedzsment leghíresebb könyve [5] . A Computerra magazin szerint Brooks könyvével kapcsolatban "az Egyesült Államokban régóta úgy gondolják, hogy elolvasása nélkül egyetlen szoftverfejlesztési menedzser sem tud hatékonyan fellépni" [6] .
Szóval, mielőtt egy új szoftverprojektbe kezdenénk, még mindig van értelme Frederic Brookst olvasni?
PC-hét [1] .Brooks megfigyelései az OS/360 operációs rendszer projekt menedzselése során szerzett IBM -nél szerzett tapasztalatokon alapulnak . A fejlesztés felgyorsítása érdekében sikertelenül próbálkozott újabb munkások bevonásával a projektbe, aminek a határidői már elmaradtak. Észrevette, hogy a vezetők képesek megismételni az ilyen hibákat, Brooks gúnyosan "a szoftverfejlesztés bibliájának" nevezte könyvét: "mindenki olvasta, de senki nem követi!"
Brooks azt is állította, hogy egy Algol nyelvi fordítóprogram megírása hat hónapot vesz igénybe, függetlenül a projektben részt vevők számától.
A könyv először 1975 -ben jelent meg, 1979- ben oroszul. Az 1995 -ös évfordulós kiadás (orosz nyelven - 2000 ) további fejezeteket tartalmaz: az 1986-ban megjelent " Nincs ezüstgolyó" című esszét (16. fejezet), az ebben az esszében elhangzottak átdolgozását 10 évvel később (17. fejezet) és a szerző megjegyzései könyvéhez 20 évvel az első kiadás után (18. és 19. fejezet).
program és szoftver termék. A szoftvertermék különbözik a programtól:
Egy szoftvertermék háromszor több időt igényel, mint egy program (1. fejezet).
Mitikus emberhónap. A projekt átfutási ideje legalább 2 okból nem fordítottan arányos a programozók számával.
Ha N programozó van, akkor a programozópárok száma egyenlő N ( N - 1) / 2-vel, vagyis a programozók számának növekedésével az interakcióra fordított idő négyzetesen növekszik. Ezért néhány N-ből kiindulva a programozók számának növekedése lelassítja a projektet.
Ha a határidők elmaradnak, az új programozók felvétele más okból is lassítja a projektet: az újonnan érkezőknek időre van szükségük a tanuláshoz. A könyv így fogalmaz: "Brooks törvénye": "Ha egy projekt nem az ütemterv szerint halad, akkor a munkaerő hozzáadása még tovább késlelteti."
Nagyon sok programozó esetén előfordulhat, hogy a projekt egyáltalán nem fejeződik be: az általános zűrzavar miatt a szoftver meglévő hibáinak javítására tett kísérletek új hibákat generálnak, így a rendszer nem javul (2. fejezet).
sebészeti csapatok. Érdemes a fejlesztőcsapatnak egy "jó" programozóval rendelkeznie, aki megvalósítja a rendszer legkritikusabb részeit, és többen, akik segítik vagy a kevésbé kritikus részeket implementálják. Így történnek a műtétek. Ráadásul Brooks szerint a legjobb programozók 5-10-szer gyorsabban dolgoznak, mint a többiek (3. fejezet).
fogalmi integritás. A rendszer elvi integritásának biztosításához el kell különíteni az architektúrát a megvalósítástól. Egy vezető építész (vagy egy kis csoport) a felhasználó érdekeit szem előtt tartva dönti el, hogy mi kerüljön be a rendszerbe és mit nem. Egy "nagyon klassz" ötlet elutasítható, ha a javasolt funkció nem illeszkedik a rendszer általános kialakításába. Az egyszerűség nagyon fontos; hasznos lehet a képességeknek csak egy részhalmazát megvalósítani, amire a rendszer képes, mert ha a rendszer túl bonyolult, akkor egyes képességei kihasználatlanul maradnak.
A főépítésznek használati útmutató formájában kell megfogalmaznia döntéseit (4. fejezet).
A második rendszer hatása. A második rendszerét fejlesztő programozó hajlamos minden olyan szolgáltatást hozzáadni az első rendszeréhez, amelyet (időhiány miatt) nem tudott hozzáadni. Ezért a második rendszer gyakran túlterhelt képességekkel rendelkezik (5. fejezet).
hivatalos dokumentumokat. Minden projektmenedzsernek létre kell hoznia egy kis formális dokumentumcsomagot, amely leírja a projekt céljait, hogyan, ki és mikor valósítja meg azokat, és mennyibe kerül. Ezek a dokumentumok olyan következetlenségeket tárhatnak fel, amelyeket egyébként nehéz lenne észrevenni.
Minden fejlesztőcsapat megkapja a saját rendszerrészére vonatkozó követelményeket, beleértve a funkcionalitás pontos leírását, valamint a processzoridőre, a memóriára, a lemezterületre stb. vonatkozó maximális követelményeket.
Kölcsönhatás. A katasztrófa elkerülése érdekében a fejlesztőcsapatoknak minden lehetséges módon kölcsönhatásba kell lépniük egymással. Ahelyett, hogy feltételezéseket tenne a megvalósított funkcióról, a fejlesztőnek tisztázó kérdéseket kell feltennie az építésznek, mert előfordulhat, hogy a feltételezések teljesen tévesek. "A feltételezés a kudarc anyja."
pilot rendszer. A végleges rendszer kidolgozása előtt egy kísérleti rendszert kell kidolgozni. A pilot rendszer feltárja a tervezési hibákat, ami után teljesen újra kell építeni (11. fejezet). Brooks 20 évvel később, a 19. fejezetben elutasítja ezt az ötletet, mivel a programok létrehozásának megközelítése 20 év alatt megváltozott – a 60-as és 70 - es években elfogadott iteratív fejlesztési modell váltotta fel a vízesés-fejlesztési modellt .
A rendszer verziószámítása és lefagyasztása. A rendszer felépítése során a felhasználó igényei a befejezetlen rendszerrel kapcsolatos tapasztalatai alapján változhatnak. A felhasználó ezen kívánságait figyelembe kell venni, de csak egy bizonyos pontig, különben a rendszeren végzett munka soha nem fejeződik be. Ezt követően a specifikációk befagyasztásra kerülnek, és az összes későbbi módosítási kérelmet elhalasztják a következő verzión (11. fejezet) végzett munka megkezdéséig.
Speciális közművek. Ahelyett, hogy minden programozó saját segédprogramokat írna, minden fejlesztőcsapatnak legyen egy programozója, aki a csapatának segédprogramokat írjon (például egy kódgenerátor, amely valamilyen specifikáció szerint kódot állít elő). Létre kell hozni egy olyan csoportot is, amely az adott rendszeren dolgozó mindenki számára készít segédprogramokat (12. fejezet).
Csökkentett fejlesztési költség. Brooks két módszert sorol fel a szoftverfejlesztés költségeinek csökkentésére: