| Omul-lună mitică | |
|---|---|
| Luna-omul mitic | |
| Autor | Frederic Brooks |
| Limba originală | Engleză |
| Original publicat | 1975 |
| Editor | Addison–Wesley |
| ISBN | ISBN 0201835959 |
| Următorul | Nu există nici un glonț de argint |
The Mythical Man-Month: Essays on Software Engineering este o carte despre managementul proiectelor software de Frederick Brooks .
De fapt, cartea lui Brooks este o colecție de eseuri care discută secvențial problemele cheie ale dezvoltării unor proiecte software mari: creșterea productivității programatorilor, organizarea muncii în echipă, planificarea și implementarea unui program de implementare. Una dintre temele principale ale cărții a fost ideea, numită ulterior „Legea lui Brooks”, că introducerea de noi forțe în proiect în etapele ulterioare de dezvoltare nu face decât să amâne termenul limită pentru proiect [1] .
Revista în limba engleză PC World a plasat cartea lui Brooks pe primul loc pe lista sa cu „ Top zece cărți IT care nu trebuie să admită că nu ai citit ” [2] . Potrivit unui sondaj efectuat de câteva mii de membri ai comunității Stack Overflow , cartea este una dintre cele mai influente zece cărți de programare din toate timpurile [3] . Cartea lui Brooks este descrisă pe site-ul Association for Computing Machinery Library astfel: „Foarte puține cărți despre managementul proiectelor software au devenit la fel de influente și atemporale” [4] . Potrivit editorialistului Java World Dustin Marks, The Mythical Man-Month este una dintre cele mai cunoscute cărți din întreaga literatură de dezvoltare software și, probabil, cea mai faimoasă carte în managementul proiectelor software [5] . Potrivit revistei Computerra despre cartea lui Brooks, „s-a crezut de mult în Statele Unite că, fără a o citi, niciun manager de dezvoltare software nu va putea acționa eficient” [6] .
Deci, poate că înainte de a te lansa într-un nou proiect de software, mai are sens să-l citești pe Frederick Brooks?
Săptămâna PC [1] .Observațiile lui Brooks se bazează pe experiența sa la IBM în timp ce gestiona proiectul sistemului de operare OS/360 . Pentru a accelera dezvoltarea, a făcut o încercare nereușită de a atrage mai mulți muncitori la proiect, termenele pentru care erau deja ratate. Observând capacitatea managerilor de a repeta astfel de greșeli, Brooks și-a numit în derizoriu cartea „biblia pentru inginerie software”: „toată lumea a citit-o, dar nimeni nu o urmează!”
Brooks a mai susținut că scrierea unui compilator în limbajul Algol ar dura șase luni, indiferent de numărul de persoane implicate în proiect.
Cartea a fost publicată pentru prima dată în 1975 , în 1979 a fost publicată în limba rusă. Ediția aniversară din 1995 (în rusă - 2000 ) conține capitole suplimentare: eseul „ Nu există glonț de argint ”, publicat în 1986 (capitolul 16), o revizuire a celor spuse în acest eseu 10 ani mai târziu (capitolul 17) și comentariile autorului asupra cărții sale la 20 de ani de la prima ediție (capitolele 18 și 19).
program și produs software. Un produs software este diferit de un program:
Un produs software necesită de 3 ori mai mult timp decât un program (Capitolul 1).
Omul-lună mitică. Timpul de livrare al proiectului nu este invers proporțional cu numărul de programatori din cel puțin 2 motive.
Dacă există N programatori, atunci numărul de perechi de programatori este egal cu N ( N - 1) / 2, adică odată cu creșterea numărului de programatori, timpul petrecut pentru interacțiune crește pătratic. Prin urmare, pornind de la niște N, o creștere a numărului de programatori încetinește proiectul.
Dacă termenele limită sunt ratate, angajarea de noi programatori încetinește proiectul din alt motiv: noii veniți au nevoie de timp pentru a învăța. Cartea articulează „Legea Brooks”: „Dacă un proiect nu este în termen, atunci adăugarea de forță de muncă îl va întârzia și mai mult”.
Cu un număr foarte mare de programatori, proiectul s-ar putea să nu se termine deloc: din cauza confuziei generale, încercările de a remedia erorile existente în software generează noi erori, astfel încât sistemul să nu se îmbunătățească (Capitolul 2).
echipele chirurgicale. Este logic ca echipa de dezvoltare să aibă un programator „bun” care implementează cele mai critice părți ale sistemului și alții care îl ajută sau implementează părțile mai puțin critice. Așa se fac operațiile. În plus, potrivit lui Brooks, cei mai buni programatori lucrează de 5-10 ori mai repede decât restul (Capitolul 3).
integritate conceptuală. Pentru a asigura integritatea conceptuală a sistemului, este necesară separarea arhitecturii de implementare. Un arhitect principal (sau un grup mic), acționând în interesul utilizatorului, decide ce ar trebui și ce nu ar trebui să intre în sistem. O idee „foarte cool” poate fi respinsă dacă caracteristica propusă nu se încadrează în designul general al sistemului. Simplitatea este foarte importantă; poate fi util să implementați doar un subset al capabilităților de care este capabil sistemul, deoarece dacă sistemul este prea complex, unele dintre capabilitățile sale vor rămâne neutilizate.
Arhitectul șef trebuie să își formuleze deciziile sub forma unui ghid de utilizare (Capitolul 4).
Efectul celui de-al doilea sistem. Un programator care își dezvoltă al doilea sistem tinde să adauge toate caracteristicile pe care nu le-a putut adăuga la primul său sistem (din lipsă de timp). Prin urmare, cel de-al doilea sistem se dovedește adesea a fi supraîncărcat cu capabilități (Capitolul 5).
documente formale. Fiecare manager de proiect ar trebui să creeze un mic set de documente formale care să descrie obiectivele proiectului, cum, de către cine și când vor fi implementate și cât vor costa. Aceste documente pot dezvălui neconcordanțe care altfel ar fi greu de observat.
Fiecare echipă de dezvoltare primește un set de cerințe pentru partea sa din sistem, inclusiv o descriere precisă a funcționalității sale și cerințele maxime pentru timpul procesorului, memorie, spațiu pe disc etc.
Interacţiune. Pentru a preveni dezastrul, echipele de dezvoltare trebuie să interacționeze între ele în toate modurile posibile. În loc să facă presupuneri cu privire la funcția pe care o implementează, dezvoltatorul ar trebui să pună arhitectului întrebări clarificatoare, deoarece ipotezele se pot dovedi a fi complet greșite. „Presumarea este mama eșecului”.
sistem pilot. Înainte de a putea fi dezvoltat un sistem final, trebuie dezvoltat un sistem pilot. Sistemul pilot va dezvălui erori de proiectare, după care trebuie refăcut complet (Capitolul 11). Brooks respinge această idee 20 de ani mai târziu în capitolul 19, deoarece abordarea creării de programe s-a schimbat în 20 de ani - modelul de dezvoltare iterativă adoptat în anii 60 și 70 a înlocuit modelul de dezvoltare în cascadă .
Versiunea și înghețarea sistemului. Pe măsură ce sistemul este construit, cerințele utilizatorului pentru acesta se pot schimba în funcție de experiența lor cu sistemul neterminat. Aceste dorințe ale utilizatorului ar trebui luate în considerare, dar numai până la un anumit punct, altfel munca la sistem nu va fi niciodată finalizată. După aceea, specificațiile sunt înghețate și toate cererile de modificare ulterioare sunt amânate până când începe lucrul la următoarea versiune (Capitolul 11).
Utilitati specializate. În loc ca fiecare programator să-și scrie propriile utilități, fiecare echipă de dezvoltare ar trebui să aibă un programator responsabil cu scrierea utilităților pentru echipa sa (de exemplu, un generator de cod care generează cod în conformitate cu anumite specificații). De asemenea, ar trebui să existe un grup care creează utilități pentru toți cei care lucrează la un anumit sistem (Capitolul 12).
Cost redus de dezvoltare. Brooks enumeră 2 moduri de a reduce costul dezvoltării software: