miticul om-lună

Brooks discută mai multe cauze ale eșecurilor de programare. Cea mai durabilă este discuția sa despre Legea lui Brooks:adăugarea forței de muncă la un proiect software târziu o face mai târziu. Luna-om este o unitate ipotetică de lucru care reprezintă munca făcută de o persoană într-o lună; Legea lui Brooks spune că posibilitatea de a măsura munca utilă în lunile-om este un mit și, prin urmare, este elementul central al cărții.

proiectele complexe de programare nu pot fi perfect împărțite în sarcini discrete care pot fi lucrate fără comunicarea între lucrători și fără stabilirea unui set de relații complexe între sarcini și lucrătorii care le îndeplinesc.

prin urmare, atribuirea mai multor programatori unui proiect care rulează în urmă va face chiar mai târziu. Acest lucru se datorează faptului că timpul necesar pentru ca noii programatori să învețe despre proiect și cheltuielile de comunicare sporite vor consuma o cantitate din ce în ce mai mare din timpul calendaristic disponibil. Când n oamenii trebuie să comunice între ei, pe măsură ce n crește, producția lor scade și când devine negativă, proiectul este întârziat și mai mult cu fiecare persoană adăugată.

• formula de intercomunicare grup: n (n-1 − / 2
• exemplu: 50 dezvoltatorii da 50 · (50 – 1) / 2 = 1225 canale de comunicare.

no silver bulletEdit

Brooks a adăugat ” no Silver Bullet-Esență și accidente de Inginerie Software „—și reflecții suplimentare asupra acestuia,” „no Silver Bullet „Refired” -la ediția aniversară a miticului om-lună.

Brooks insistă asupra faptului că nu există un glonț de argint – „nu există o singură dezvoltare, nici în tehnologie, nici în tehnica de management, care, prin ea însăși, promite chiar și un ordin de mărime îmbunătățire într-un deceniu a productivității, a fiabilității, a simplității.”

argumentul se bazează pe distincția dintre complexitatea accidentală și complexitatea esențială, similar cu modul în care legea lui Amdahl se bazează pe distincția dintre” strict serial „și”paralelizabil”.

efectul celui de-al doilea sistem

efectul celui de-al doilea sistem PROPUNE că, atunci când un arhitect proiectează un al doilea sistem, acesta este cel mai periculos sistem pe care îl va proiecta vreodată, deoarece va tinde să încorporeze toate adăugările pe care inițial nu le-au adăugat la primul sistem din cauza constrângerilor de timp inerente. Astfel, atunci când se îmbarcă pe un al doilea sistem, un inginer ar trebui să fie conștient de faptul că acestea sunt susceptibile de a supra-inginerie it.

tendința către numărul ireductibil de eroaredit

autorul face observația că într-un sistem adecvat complex există un anumit număr ireductibil de erori. Orice încercare de a remedia erorile observate tinde să ducă la introducerea altor erori.

progresul trackingEdit

Brooks a scris „întrebare: cum un proiect software mare ajunge să fie un an întârziere? Răspuns: o zi la un moment dat!”Alunecările incrementale pe mai multe fronturi se acumulează în cele din urmă pentru a produce o întârziere generală mare. La fiecare nivel de management este necesară o atenție continuă la îndeplinirea obiectivelor individuale mici.

Conceptual integrityEdit

pentru a face un sistem ușor de utilizat, sistemul trebuie să aibă integritate conceptuală, care poate fi realizată numai prin separarea arhitecturii de implementare. Un singur arhitect șef (sau un număr mic de arhitecți), care acționează în numele utilizatorului, decide ce se întâmplă în sistem și ce rămâne afară. Arhitectul sau echipa de arhitecți ar trebui să dezvolte o idee despre ceea ce ar trebui să facă sistemul și să se asigure că această viziune este înțeleasă de restul echipei. Este posibil ca o idee nouă a cuiva să nu fie inclusă dacă nu se potrivește perfect cu designul general al sistemului. De fapt, pentru a asigura un sistem ușor de utilizat, un sistem poate oferi în mod deliberat mai puține caracteristici decât este capabil. Ideea este că, dacă un sistem este prea complicat de utilizat, Multe funcții vor rămâne neutilizate, deoarece nimeni nu are timp să le învețe.

manualul

arhitectul șef produce un manual de specificații ale sistemului. Ar trebui să descrie în detaliu specificațiile externe ale sistemului, adică tot ceea ce vede utilizatorul. Manualul ar trebui modificat pe măsură ce feedback-ul vine de la echipele de implementare și de la utilizatori.

sistemul PilotEdit

la proiectarea unui nou tip de sistem, o echipă va proiecta un sistem de aruncare (indiferent dacă intenționează sau nu). Acest sistem acționează ca un” plan pilot ” care dezvăluie tehnici care vor determina ulterior o reproiectare completă a sistemului. Acest al doilea sistem mai inteligent ar trebui să fie cel livrat clientului, deoarece livrarea sistemului pilot nu ar provoca altceva decât agonie clientului și, eventual, ar distruge reputația sistemului și poate chiar compania.

documente Formaleedit

fiecare manager de proiect ar trebui să creeze un mic set de documente formale care să definească obiectivele proiectului, modul în care acestea trebuie realizate, cine le va atinge, când vor fi realizate și cât vor costa. Aceste documente pot dezvălui, de asemenea, neconcordanțe care altfel sunt greu de văzut.

estimarea Proiectuluiedit

când se estimează timpii proiectului, trebuie amintit că produsele de programare (care pot fi vândute clienților plătitori) și sistemele de programare sunt de trei ori mai greu de scris decât programele simple independente interne. Ar trebui să se țină cont de cât din săptămâna de lucru va fi cheltuită efectiv pentru probleme tehnice, spre deosebire de sarcinile administrative sau alte sarcini non-tehnice, cum ar fi reuniunile și, în special, întâlnirile „stand-up” sau „all-hands”.

CommunicationEdit

pentru a evita dezastrul, toate echipele care lucrează la un proiect ar trebui să rămână în contact între ele în cât mai multe moduri posibil—e-mail, telefon, întâlniri, memo-uri etc. În loc să presupună ceva, implementatorii ar trebui să ceară arhitectului(arhitecților) să-și clarifice intenția cu privire la o caracteristică pe care o implementează, înainte de a continua cu o presupunere care ar putea fi foarte bine complet incorectă. Arhitectul(arhitecții) sunt responsabili pentru formularea unei imagini de grup a proiectului și comunicarea acestuia către alții.

echipa chirurgicalăedit

la fel cum o echipă chirurgicală în timpul intervenției chirurgicale este condusă de un chirurg care efectuează cea mai critică lucrare, în timp ce direcționează echipa să asiste cu părți mai puțin critice, pare rezonabil ca un programator „bun” să dezvolte componente critice ale sistemului, în timp ce restul unei echipe oferă ceea ce este necesar la momentul potrivit. În plus, Brooks consideră că programatorii „buni” sunt, în general, de cinci până la zece ori mai productivi decât cei mediocri.

înghețarea codului și versiunea sistemului

Software-ul este invizibil. Prin urmare, multe lucruri devin evidente numai după ce o anumită cantitate de muncă a fost făcută pe un nou sistem, permițând unui utilizator să o experimenteze. Această experiență va genera perspective, care vor schimba nevoile unui utilizator sau percepția nevoilor utilizatorului. Prin urmare, sistemul ar trebui modificat pentru a îndeplini cerințele modificate ale utilizatorului. Acest lucru poate apărea numai până la un anumit punct, altfel sistemul nu poate fi niciodată finalizat. La o anumită dată, nu ar trebui să mai fie permise modificări ale sistemului și Codul ar trebui să fie înghețat. Toate cererile de modificări ar trebui amânate până la următoarea versiune a sistemului.

instrumente Specializatedit

în loc ca fiecare programator să aibă propriul set special de instrumente, fiecare echipă ar trebui să aibă un producător de instrumente desemnat care poate crea instrumente foarte personalizate pentru munca pe care o face echipa, de exemplu, un instrument generator de cod care creează cod pe baza unei specificații. În plus, instrumentele la nivel de sistem ar trebui construite de o echipă comună de instrumente, supravegheată de managerul de proiect.

reducerea costurilor de dezvoltare software

există două tehnici de reducere a costurilor de dezvoltare software despre care Brooks scrie:

• implementatorii pot fi angajați numai după finalizarea arhitecturii Sistemului (un pas care poate dura câteva luni, timp în care implementatorii angajați prematur nu pot avea nimic de făcut).
• o altă tehnică pe care Brooks o menționează nu este de a dezvolta software deloc, ci pur și simplu de a-l cumpăra „de pe raft” atunci când este posibil.