Pentru a pregăti mâncăruri delicioase, este nevoie de timp. Dacă a trebuit să aștepte, este doar pentru că dorim să vă servească și oferi placere mai bine.
RESTAURANT MENIU "ANTOINE" În New Orleans
Proiecte de software de multe ori nu din cauza lipsei de timp calendaristică decât pentru toate celelalte motive combinate. De ce este aceasta o astfel de cauză comună de eșec?
În primul rând, slab dezvoltat metodele noastre de evaluare. De fapt, ele reflectă presupunerea tăcut și total fals că totul va merge bine.
În al doilea rând, metodele noastre de evaluare eronat confunda progresul cu eforturile depuse, implicit, presupunând că viteza proiectului proporțional cu numărul de persoane angajate în angajații săi.
În al treilea rând, deoarece managerii de proiect software nu sunt încrezători în evaluările lor, de multe ori lipsa de încăpățânarea politicos, ca un bucatar „restaurant Antoine“.
În al patrulea rând, punerea în aplicare a programului de lucru slab controlat. Modelul testat în alte discipline de inginerie, tehnici considerate inovații radicale în dezvoltarea de software.
În al cincilea rând, după detectarea lag-ului natural al graficului și reacția comună este de a crește numărul de dezvoltatori. E ca să stingă flăcările cu benzină. Ca urmare, lucrurile sunt mult mai rău. Cu cât mai puternică flacăra, cu atât mai mult nevoie de benzină, și ca rezultat în acest fel duce la dezastru.
Monitorizarea punerii în aplicare a programului va fi subiectul unei discuții separat. Să ne gândim mai detaliat celelalte aspecte ale problemei.
Toate programatori - optimiștii. Poate că acest tip de vrăjitorie modernă este deosebit de atractiv pentru cei care cred în finaluri fericite și nașe de basm. Poate că sute de ghinioane resping toate, dar cei care sunt folosite pentru a se concentreze pe obiectivul final. Și poate că este doar faptul că calculatoarele și programatori sunt tineri, iar tineretul este optimismul caracteristic. Orice ar fi fost, ca urmare a un singur lucru: „In acest moment, se va merge sigur!“ Or. „Tocmai am dezvăluit ultima greșeală!“
Deci, în centrul de planificare de dezvoltare software este o presupunere falsă că totul este bine, că este fiecare sarcină va lua la fel de mult timp ca „ar trebui“ să ia.
programatori optimism adânc merită atenție mai grave. Dorothy Sayers (Dorothy Cayers) în cartea sa excelenta „mintea Creatorului» ( "The Mind of Maker") evidențiază, în activități creative prin intermediul a trei etape: concepere, implementare, interacțiune. Prin urmare, un un program de calculator este mai întâi emerge ca o construcție perfectă de carte sau, nu există în timp și spațiu, dar numai în mintea creatorului ei. Implementarea același lucru în timp și spațiu se face printr-un stilou, cerneală, hârtie, sau - fire, siliciu și ferită. Crearea va fi finalizat, atunci când cineva citește o carte, să profite de calculator sau de a lansa programul, intrând astfel în contact cu mintea creatorului lor.
Această descriere este utilizat pentru Sayers de iluminat nu numai de creativitatea umană, ci și dogma creștină a Trinității, ne va ajuta în sarcina noastră curentă. Pentru o persoană care creează ceva, idei incomplete și contradictorii sunt revelate numai atunci când realizarea lor. Prin urmare, expunerea teoretică pe hârtie, experimentare, de fabricație este o parte integrantă a procesului creativ.
In multe tipuri de activitate creatoare a materialului nu este ușor de tratat. Lemnul este înțepat, vopsea murdar, circuit electric „inel“. Aceste constrângeri fizice restrânge gama de idei care pot fi exprimate, precum și crearea unor dificultăți neprevăzute în punerea în aplicare.
Punerea în aplicare necesită astfel timp și efort atât materialul fizic, și din cauza caracterului inadecvat al ideilor de bază. Cea mai mare parte dificultatea în punerea în aplicare, avem tendința de a explica lipsa de material fizic, din moment ce este „străin“ pentru noi - în contrast cu ideea că suntem mândri.
Când creați programul, avem de-a face cu un material extrem de flexibil. Programatorul efectuează construcția sa, pe baza gândirii pure - conceptele și reprezentările lor sunt foarte flexibile. Deoarece materialul este atât de maleabil, nu ne așteptăm ca orice dificultăți în punerea în aplicare, prin urmare, optimismul nostru profund. Din cauza failibilitatea ideilor noastre, există erori în cadrul programelor. Prin urmare, optimismul nostru nu este justificată.
Pentru sarcină individuală presupune că toate bude bine, trebuie să programeze un efect probabilistic. Lucrurile pot merge într-adevăr în conformitate cu planul, deoarece există o distribuție de probabilitate pentru posibile întârzieri, și există o probabilitate finită că întârzierile nu vor. Cu toate acestea, un proiect software mare constă dintr-un set de sarcini, dintre care unele pot fi inițiate numai după celălalt. Probabilitatea ca toate sarcinile sunt finalizate la timp, infinitezimal.
A doua eroare de raționament constă în însăși unitatea de măsură utilizată în estimarea și planificare: Man-Luna. Costul efectiv măsurat ca produsul dintre numărul de angajați la numărul de luni petrecute. Dar nu rezultatul obținut. Prin urmare, utilizarea de persoană luni ca unitatea de volumul de lucru este o iluzie periculoasă.
Fig. 2,1 ori, în funcție de numărul de angajați - sarcină completă separabile
Numărul și ocupate cu numărul de luni sunt valori interschimbabile numai atunci când sarcina poate fi distribuit între un număr de lucrători care nu au legătură între ele (fig. 2.1). Este adevărat atunci când culege grâu sau bumbac cules, ci prin sistemul de programare nu este așa.
Fig. De 2,2 ori în funcție de numărul de angajați - o sarcină indivizibilă
În cazul în care sarcina nu poate fi rupt în părți, deoarece există restricții cu privire la succesiunea de pași, o creștere a costurilor nu afectează graficul (fig. 2.2). Pentru a avea un copil este nevoie de nouă luni, indiferent de cât de multe femei sunt atrase de rezolvarea acestei probleme. Multe sarcini de programare sunt de acest tip, deoarece este în mod inerent depanare secvențială.
Fig. 2,3 ori, în funcție de numărul de angajați - sarcini separabile care necesită schimbul de date
Pentru sarcini care pot fi defalcate în părți, dar necesită schimbul de date între sarcini, costul de comunicare trebuie să fie adăugată la cantitatea totală de muncă necesară. Prin urmare, cel mai bun rezultat realizabil este puțin mai dificilă decât simpla conformitate cu numărul de angajat și numărul de luni (Fig. 2.3).
încărcare suplimentară este format din două părți - învățarea și schimbul de date. Fiecare angajat trebuie să fie instruiți tehnologie, obiectivele proiectului, strategia generală și planul de lucru. Această formare nu poate fi divizat în părți, astfel încât această parte a costului variază liniar cu numărul de angajați.
Fig. De 2,4 ori în funcție de numărul de angajați - o problemă cu interrelații complexe
Având în vedere că situația este mai rea decât schimbul de date. Dacă toate de locuri de muncă trebuie să fie coordonate separat între ele, creșterea costurilor ca n (n-2) / 2. Pentru cei trei muncitori nevoie de trei ori mai multe decât cele de comunicare Pairwise două până la patru - de șase ori. În cazul în care, în plus față de acest lucru este necesar în ședințele de trei, patru, etc. lucrătorilor să abordeze împreună problemele, situația devine chiar mai rău. Costurile suplimentare pentru schimbul de date se poate nega în întregime rezultatul zdrobire problemei inițiale și conduce la situația descrisă de Figura 2.4.
De la crearea software-ului este, în esență, un proiect sistemic - practica de relații complexe, costurile de date mari de schimb și să înceapă rapid să domine peste reducerea de termeni, realizate ca urmare a sarcinilor de divizare în subactivități mai mici. În acest caz, implicarea personalului suplimentar nu se taie și se extinde programul.
Dintre toate elementele de programul de lucru cele mai afectate de restricțiile privind succesiunea acțiunilor care fac obiectul depanare componentelor și testarea sistemului. În plus, timpul necesar depinde de numărul de erori constatate și modul în care acestea sunt „ascunse“. Teoretic, eroarea nu ar trebui să fie. Din cauza optimismul ei, noi de obicei tendința de a subestima numărul real de erori. Prin urmare, programarea pentru a adera la program, de obicei, cel mai greu de depanare.
Pentru un număr de ani în planificarea dezvoltării software-ului folosesc urmatoarea regula:
1/6 - programe de scris,
1/4 - testarea componentelor și testarea avansate de sistem,
testarea sistemului în prezența tuturor componentelor - 1/4.
Această regulă are câteva diferențe importante de la planificarea convențională:
1. Planificarea este dat mai mult timp decât de obicei. Totuși, de data aceasta abia suficient pentru dezvoltarea condițiilor tehnice detaliate și fiabile și insuficiente pentru cercetare sau de cercetare de noi tehnologii.
2. Jumătate din programul alocat pentru a finaliza depanare de cod, mult mai mare decât în mod normal.
3. Partea care este ușor de a evalua, și anume Codul de scriere durează doar o șesime din timpul total.
Studierea proiectelor, din care programul a fost făcut într-un mod convențional, am descoperit că câteva dintre ele recuperate dintr-un program de depanare jumătate de normă, dar, în practică, majoritatea timpului petrecut pe ea jumatate din timp real. Multe proiecte sunt în grafic în toate etapele, cu excepția sistemului de testare. [2]
consecințe dezastruoase în mod particular poate fi lipsa de timp pentru testarea sistemului. Având în vedere că întârzierea are loc în partea finală a graficului, nimeni nu a bănuit că programul este în pericol până în ziua de livrare a produsului. Vești proaste, au primit cu întârziere și fără avertisment, descurajând clienții și manageri.
Mai mult decât atât, în acest stadiu, o întârziere este consecințe fizice și psihologice deosebit de grave. Proiectul este implementat cu deplin
angajații de personal și costurile financiare maxime. Mai important, software-ul ar trebui să ofere sprijin celeilalte activități de afaceri (livrarea calculatoarelor, lansarea de noi capacități de producție, etc.), și asociate cu costuri secundare întârziate sunt foarte mari. În practică, aceste costuri secundare pot fi mai mari decât toate celelalte. Prin urmare, este foarte important în programul de lucru inițial să ia suficient timp pentru testarea sistemului.
Timiditatea în estimările
Pentru programator, ca să gătească, de presiunea de master poate defini data planificată pentru finalizarea problemei, dar nu se poate determina momentul finalizării sale actuale. Omletă, a promis două minute, poate fi cu succes prăjit, dar dacă în două minute nu este gata, atunci clientul are două opțiuni: să aștepte sau să-l mânca chiar crud. Aceeași gamă de standuri și în fața software-ul client.
Gatim există o altă posibilitate: adăugați căldură. Ca urmare, omletă este adesea fără speranță rasfatata: ars la un capăt și prime - cu o alta.
Nu cred că gestionarea de produse software mai puțin curaj sau de duritate decât cea a bucătari sau a altor manageri în domenii de inginerie. Dar grafica false, cu scopul de data dorită a proprietarului, este mult mai frecventă decât în orice alte domenii de inginerie. Foarte greu, la riscul de a pierde locul de muncă, cu energie și bunătate pentru a apăra viața, care este definită fără nici metode cantitative pentru lipsa de date, și susținută de, manager de cele mai multe ori intuiție.
În timp ce metodele de evaluare nu va primi o bază mai solidă, managerii pot lua doar inima și să-și apere previziunile lor, argumentând că cei săraci se bazează pe intuiția lor este mai bună decât una bazată pe dorințe.
Acțiuni la perturbarea calendarului
Ce să faci când mai important proiect software-ul începe să scadă în urma programului? În mod firesc, oamenii adăugat. După cum cifrele 2.1-2.4, aceasta nu ajută întotdeauna.
Să considerăm un exemplu. [3] Să presupunem că problema complexității este estimată la 12 om-luni, și trei oameni au rulat timp de 4 luni, iar la sfârșitul fiecărei luni, există patru puncte de control A, B, C și D, în care este posibil să se facă măsurători (Fig. 2.5).
Să presupunem acum că primul punct de referință a fost atins doar după două luni. Ce alternative sunt disponibile la managerul?
1. Să presupunem că este necesar să se respecte termenul limită a sarcinii, și numai prima parte a problemei a fost evaluată în mod eronat, că este, Figura 2.6 reflectă poziția reală. Acest lucru lasă 9 persoane-luni ale costurilor forței de muncă și două luni, astfel încât veți avea nevoie de 4Ѕ om, și la trei necesitatea existentă pentru a adăuga încă două.
2. Să presupunem că aveți nevoie pentru a respecta termenele sarcinii, și la fel de discret a fost tot scorul. și anume Poziția corespunde figura 2.7. Deci, există 18 om-luni de efort și două luni, astfel încât va trebui să 9 persoane. La trei necesitatea de a adăuga alte șase existente.
3. Modificați programul. Îmi place comentariul făcut de P. faggen (P. Fagg), un inginer cu experiență în informatică: „întârzieri mici nu se întâmplă.“ Acest lucru înseamnă că noul program ar trebui să fie suficient timp pentru a lucra a fost realizată bine și complet, și nu ar trebui să-și modifice din nou programul.
4. Pentru a reduce problema. În practică, acest lucru se termină întotdeauna atunci când echipa descoperă că nu se încadrează în programul. Când costurile secundare foarte mari este singurul lucru care poate fi făcut. Managerul o oportunitate de a reduce în mod oficial și ușor problema, schimba programul sau urmăriți modul în care sarcina trunchiate în tăcere atunci când schimbarea grăbită a proiectului și testarea incompletă.
În primele două cazuri, să insiste asupra faptului că sarcina a fost efectuată neschimbat timp de patru luni, este plină de dezastru. Să considerăm, de exemplu, efectul de reducere a primei alternative (fig. 2.8). Doi angajați noi, indiferent de modul în cunoștință de acestea sunt, și cât de repede nu le-ar putea găsi, trebuie să studieze problema folosind unul dintre dezvoltatorii cu experiență. În cazul în care este nevoie de o lună, 3 luni vor fi cheltuite pentru munca, care nu este inclusă în estimarea inițială. În plus, o sarcină rupt inițial în trei fluxuri, trebuie acum să fie redesenate în cinci părți. Prin urmare, o parte din lucrările deja efectuate vor fi pierdute, iar testarea sistemului va trebui să fie extinse. Ca urmare, la sfârșitul celei de a treia luni de funcționare rămân în mod substanțial mai mare de 7 luni, și de eliminare va fi de 5 persoane instruite și o lună. Conform Figura 2.8 produsului va fi întârziată în același mod ca și în cazul în care nici o persoană nu a fost adaugata (vezi. Fig. 2.6).
Dacă vă așteptați să se ocupe de patru luni, luându-se în considerare numai timpul de formare, dar nu și redistribuirea sarcinilor și testarea suplimentară a sistemului, la sfârșitul celei de a doua luni, trebuie să adăugați 4 în loc de 2 persoane. Pentru a compensa impactul redistribuirea sarcinilor și testare a sistemului va necesita mai multe persoane noi. Acum, cu toate acestea, echipa nu este formată 3, și cel puțin 7 persoane și aspecte precum organizarea echipei și repartizarea sarcinilor ia pe un nou nivel calitativ.
Extrem de simplificare a formula Act Brooks:
În cazul în care proiectul nu se încadrează în termenii, adăugarea forței de muncă va întârzia și mai mult.
Acest lucru demontează mitul omului-luna. Durata proiectului depinde de constrângerile impuse de secvența de lucru. Numărul maxim de dezvoltatori depind de numărul de subactivități independente. Aceste două valori fac posibilă pentru a obține un program, care va fi dezvoltatorii mai puțin aglomerate și mai multe luni. (Singurul pericol este posibila învechire a produsului.) Este imposibil, cu toate acestea, pentru a face programe de lucru, care angajează mai mulți oameni și durează mai puțin timp. Proiecte de software de multe ori nu din cauza lipsei de timp calendaristică decât pentru toate celelalte motive combinate.