Joel on Software

Joel on Software   Joel despre Software

 

Alte articole din "Joel on Software" in Romaneste

Alte articole din "Joel on Software" in engleza

Scrie-i autorului (numai in engleza)

 

Planificarea simpla a proiectelor software


De Joel Spolsky
Tradus de catre Adrian Spinei
Verificat de catre Petru Paler
Martie 29, 2000

In octombrie trecut, nord-vestul Statelor Unite a fost impanzit cu reclame la un produs numit Acela, un nou tren expres pe ruta Boston - Washington. Cu reclame la TV si afise cam peste tot, ai crede ca s-a creat macar un pic de cerere pentru noul serviciu Amtrak.

E posibil. Amtrak nu a reusit sa afle. Acela a fost amanat, apoi din nou amant, asadar campania de marketing a fost vizibila in vreme ce serviciul Acela nu era inca disponibil. Ceea ce-mi aminteste de cugetarea unui responsabil de marketing cand unul din produsele sale a primit o cronica extrem de favorabila cu o luna inainte de a fi pus in vanzare : "Publicitatea este excelenta ! Ce pacat ca nu poti cumpara blestematia!"

Companii de jocuri cu ego-urile umflate au o mare placere din a se lauda pe site-urile lor ca urmatorul joc va fi comercializat "atunci cand e gata". Calendar? N-avem nevoie de prostia de calendar! Noi suntem programatori de jocuri beton! Majoritatea companiilor nu au parte de acest lux. Intrebati-i pe cei de la Lotus. Atunci cand au comercializat versiunea 3.0 de la produsul lor 123, acesta necesita un procesor 80286, care inca nu era prea raspandit. Ei au amanat produsul inca 16 luni in vreme ce l-au limitat din greu ca sa poata lucra in 640k de memorie, care era limita la un 8086. Atunci cand au terminat, Microsoft avea deja 16 luni de avans in dezvoltarea Excel-ului, si, ca o uriasa gluma a destinului, procesorul 8086 era deja invechit!

In vreme ce scriu aceste randuri, Netscape's 5.0 este intarziat cu aproape doi ani. Partial, aceasta se datoreaza faptului ca au facut greseala sinucigasa de a arunca tot codul si de a reporni de la zero: aceeasi greseala care a trimis Ashton-Tate, Lotus, si Apple's MacOS in pubelele istoriei software. Netscape si-au putut vedea partea de piata la browsere variind de la aproape 80% la cam 20% in tot acest timp, neputand face nimic ca compenseze competitia, din cauza ca produsul lor software cel mai important era desfacut in 1000 bucati pe podea si nu putea fi folosit la nimic. Aceasta decizie, mai mult decat orice altceva, a fost bomba nucleara pe care Netscape si-a detonat-o in interiorul firmei. (renumita scrisoare deschisa a lui Jamie Zawinski contine toate detaliile).

Asadar, aveti nevoie de un calendar. Aceasta este o sarcina de care aproape nici un programator nu vrea sa auda. In experienta mea, vasta majoritate a programatorilor incearca sa scape fara sa faca nici un fel de calendar. Dintre putinii care il fac, majoritatea au fost obligati de superiori sa il faca, il fac fara interes si nimeni nu crede in calendarul fixat cu exceptia managementului, care simultan crede si ca "nici un proiect software nu se poate termina la timp" si in existenta OZN-urilor.

Si-atunci de ce nimeni nu face un calendar ? Din doua motive esentiale. Unu, treaba este extrem de complicata. Doi, nimeni nu crede ca ar fi util la ceva. De ce sa mai scrii un calendar atunci cand stii precis ca nu va fi corect ? Exista o perceptie cum ca aceste calendare sunt gresite in mod sistematic si doar se inrautatesc pe masura ce trece timpul, si-atunci de ce sa mai suferi ?

Citit mai jos o modalitate simpla de a face calendare corecte.

1) Folositi Microsoft Excel. Nu va complicati cu softuri pretentioase gen Microsoft Project. Problema cu Microsoft Project este ca porneste de la ipoteza ca doriti sa petreceti o groaza de timp gandindu-va la dependente. O dependenta apare atunci cand aveti doua taskuri, din care unul TREBUIE sa fie completat inainte ca al doilea sa poata incepe. De fapt, experienta spune ca in software dependentele sunt atat de evidente incat nu merita efortul de a le formaliza explicit.

O alta problema cu Project este ca se presupune ca vei fi capabil sa apesi pe un mic buton si gata, ai "rebalansat" proiectul. Inevitabil, aceasta inseamna ca se vor rearanja si realoca diverse sarcini la persoanele din echipa. Intr-un proiect software, treaba aceasta este cam lipsita de sens. Programatorii nu se pot schimba asa de usor intre ei. Ii va lua de sapte ori mai mult timp lui John sa corecteze bug-urile Ritei decat Ritei sa corecteze bug-urile Ritei ! Iar daca incerci sa aloci programatorul de interfete utilizator pe o problema de WinSock, el o sa inghete productivitatea pentru o saptamana, invatand sa programeze WinSock. Concluzia : Project este perfect pentru planificarea constructiei de cladiri, nu pentru software.

2) Pastrati un format simplu. Formatul standard pe care il utilizez pentru calendare este atat de simplu incat il puteti memora chiar acum, pe loc. Porniti doar cu sapte coloane:

Daca aveti mai multi dezvoltatori in echipa, fie pastrati o fila separata pentru fiecare dintre ei, sau puteti face o coloana cu numele dezvoltatorului alocat pe fiecare task.

3) Fiecare functionalitate este compusa din mai multe task-uri. Un bun exemplu de functionalitate este adaugarea unui corector gramatical la programul dumneavoastra. Adaugarea unui corector gramatical consista in cateva task-uri mici, separate pe care programatorul trebuie sa le execute. Practic, cea mai importanta parte a creatiei unui calendar este alcatuirea acestei liste de taskuri. De unde si regula de baza:

4) Numai programatorul care scrie codul poate sa estimeze durata. Orice alt sistem in care managementul a scris un calendar si l-a inmanat programatorilor este sortit esecului. Numai programatorul care va face munca efectiva isi poate da seama care sunt pasii necesari pentru a implementa functionalitatea. Si numai acesta poate estima cat dureaza fiecare din acesti pasi.

5) Utilizati task-uri marunte. Aceasta este o regula de baza pentru a face calendarul ca sa functioneze efectiv. Taskurile trebuie sa fie masurate in ore, nu zile. (Cand vad un calendar care se masoare in zile, sau chiar saptamani, stiu imediat ca e fantezist). Poate credeti ca un calendar cu task-uri marunte e doar ceva mai precis. Gresit! Foarte gresit! Cand porniti cu un calendar cu task-uri largi si apoi le spargeti in task-uri mai marunte veti ca peste un rezultat diferit, nu doar unul mai precis. Este un numar complet diferit. De ce se intampla acest lucru ?

Atunci cand alegeti task-uri marunte, va fortati sa intelegeti realmente care sunt pasii necesari. Scrierea procedurii foo. Crearea unui dialog. Citirea fisierului wav. Acesti pasi sunt usori de estimat, pentru ca ati mai scris proceduri, creat dialoguri si citit fisiere wav si inainte.

Daca sunteti neglijenti si alegeti task-uri "grase" (de tip "implementarea corecturii gramaticale") atunci nu prea v-ati gandit la ceea ce vreti sa faceti. Iar daca nu v-ati gandit la ceea ce vreti sa faceti, atunci nu aveti cum sa stiti cat timp va va lua.

Ca o regula de baza, fiecare task trebuie sa ia intre 2 si 16 ore. Daca aveti un task de 40 de ore (o saptamana) pe calendar, inseamna ca nu l-ati "despicat" suficient.

Iata si alt motiv pentru a alege task-uri marunte, va forteaza sa analizati functionalitatea cu pricina. Daca aveti o functionalitare zglobiu numita "Integrare cu Internet" si pentru care estimati cu larghete 3 saptamani, aveti o mare problema. Dar daca trebuie sa precizati ce metode aveti de gand sa scrieti, atunci veti fi fortat sa despicati functionalitatea. Fiind fortat sa planificati in avans la acest nivel, se va elimina o mare parte din instabilitatea proiectului software.

6) Tineti evidenta estimarii originale si curente. Atunci cand adaugati o noua functionalitate la calendar, estimati cat de mult va lua completarea ei si umpleti valorile coloanelor Orig[inal] Est[imat] si Est[imare] Cu[renta]. Pe masura ce proiectul avanseaza, daca va ia mai mult (sau mai putin) decat ati preconizat, puteti modifica valoarea din coloana estimarii curente. Acesta este cel mai bun mod de a invata din greseli si de a invata pe viitor cum sa faceti o estimare cat mai buna a taskurilor. Majoritatea programatorilor nu au nici cea mai mica idee despre cate de mult va lua un task. Este in regula. Atata vreme cat calendarul permite invatarea continua si modificarea continua, calendarul va fi util. (Va fi poate nevoie sa anulati anumite functionalitati sau sa amanati proiectul, dar calendarul va fi mereu corect in sensul in care va va arata o situatie realista a proiectului). Am observat ca majoritatea programatorilor invata sa estimezee taskuri foarte bine dupa aproximativ un an de experienta.

Dupa ce taskul este terminat, coloanele Estimare Curenta si Trecut vor fi identice, iar campul Ramase va ajunge la 0.

7) Actualizati coloanele in fiecare zi. Pentru a face aceasta, nu e nevoie sa va folositi cronometrul in timp ce munciti. Chiar inainte de a pleca acasa, sau inainte de a adormi sub birou daca sunteti unul dintre acei maniaci, pretindeti ca ati lucrat vreme de 8 ore (ha!), ganditi-va la ce taskuri ati lucrat, si impartiti 8 ore in cele cateva coloane in concordanta cu bilantul pe care l-ati facut. Campurile ramase sunt calculate automat de catre Excel.

In acelasti timp, modificati coloana de Estimare Curenta pentru diverse taskuri pentru a reflecta realitatea. Actualizarea zilnica a calendarului nu ar trebui sa va ia mai mult de doua minute. De aceea am numit metoda "Planificare simpla" -- pentru ca este rapid si usor.

8) Planificati concedii, vacante, etc. Daca planificarea proiectului se intinde pe cam un an, fiecare programator va avea macar 10-15 zile de concediu. Va trebui sa aveti un task in calendar pentru concedii, unul pentru sarbatori, si pentru orice alta activitate susceptibila sa consume timpul echipei. Ideea este ca data de livrare poate fi calculata facand suma coloanelor cu timpul ramas si divizand cu 40 -- rezultatul reprezinta numarul de saptamani de lucru ramase, cu totul inclus.

9) Puneti timpul de debug in calendar! Debugging-ul este cel mai dificil de estimat. Ganditi-va ;a ultimul proiect la care ati lucrat. Sansele sunt ca debugging-ul a luat cam 100% - 200% din timpul care a fost necesar pentru scrierea aceluiasi volum de cod. De aceea trebuie sa prevedeti aceasta activitate in calendar, si probabil va fi una dintre cele mai mari.

Iata cum merge treaba. Sa presupunem ca un dezvoltator lucreaza la task-ul wava. Estimarea originala a fost de numai 16 ore, dar deja 20 de ore au trecut si se pare ca va fi nevoie de inca 10 ore de lucru. Asa ca dezvoltatorul scrie 30 in dreptul Estimarii Curente si 20 la Trecute.

La sfarsitul etapei, toate aceste "alunecari" au inceput probabil sa se cam adune. Teoretic, pentru a aduce la zi planificarea trebuie anulate cateva functionalitati. Din fericire prima functionalitate pe care o putem taia contine acel mare task numit Buffer care are deja o sumedenie de ore alocate.

In principiu, dezvoltatorii corecteaza codul pe masura ce il scriu. Un programator nu trebuie niciodata sa lucreze la cod nou daca ar putea in acest timp sa corecteze erori. Numarul de buguri trebuie sa ramana cat mai mic in proiect la un moment dat, pentru doua motive:

1) Este mai usor sa corectezi buguri in aceeasi zi in care ai scris codul. Poate fi foarte dificil si consumator de timp sa fixezi buguri o luna mai tarziu cand ai cam uitat cum functioneaza codul.

2) Corectarea bugurilor seamana un pic cu cercetarea stiintifica. Este imposibil de estimat cand veti rezolva un bug. Daca la un moment dat exista o lista cu doar unul sau doua buguri important, este usot de estimat cand va fi livrat produsul, pentru ca factorul greu de estimat are o pondere mica in volumul total de munca ramasa de efectuat. Pe de alta parte, daca sunt sute sau mii de bug-uri importante ramase, este imposibil de prezis cand vor fi rezolvate.

Daca dezvoltatorii corecteaza bug-urile pe masura ce avanseaza, care ar mai fi rostul unui task de debugging ? Evident, chiar daca incerci din greu sa rezolvi toate bug-urile pe masura ce inaintezi, la sfarsitul fiecarei etape apare inevitabil o suma de probleme care se ivesc doar dupa ce bug-testerii (in intern sau beta) gasesc bug-urile intr-adevar dificile.

10) Puneti timpul de integrare in calendar. Daca in echipa este mai mult de un programator, vor exista puncte in care se dezvolta lucruri inconsistente care trebuie aduse la un numitor comun. Mai multi programatori pot implementa cutii de dialog multiple pentru aceleasi functionalitati. Cineva care va lua "la periat" toate meniurile, acceleratoarele de tastatura, etc. va gasi in mod sigur lucruri de curatat si de organizat, puncte de redundanta si de incoerenta. De indata ce doua persoane lucreaza in comun pe aceeasi bucata de cod, vor apare erori de compilare si de logica -- ele vor trebui corectate, iar timpul necesar va fi un task pe calendar.

11) Calculeaza un buffer ("tampon") in orar. Lucrurile au tendinta sa debordeze fata de previziunile initiale. Sunt doua tipuri importante de buffer la care veti vrea sa va ganditi. Primul: trebuie acoperite taskurile ce dureaza mai mult decat estimarea. Al doilea: luati in calcul existenta unor task-uri la care nu v-ati gandit ca vor apare, cum ar fi de exemplu ca managementul a decis ca implementarea functionalitatii wawa este SUPER IMPORTANTA si trebuie obligatoriu sa faca parte din urmatorul release.

Vei fi surprins sa afli ca toate concediile, sarbatorile, debugging, integrare, buffer-ul s-ar putea sa se adune la un volum de timp mai mare decat task-urile efective. Daca esti atat de surprins inseamna ca nu programezi de foarte mult timp, nu-i asa ? Ignora aceste lucruri pe riscul tau.

12) Niciodata nu lasa managerii sa dicteze programatorilor sa reduca o estimare. Multi manageri novici cred ca pot "motiva" programatorii sa lucreze mai repede dandu-le calendare dragute, "stranse" (nerealist de scurte). Cred ca acest gen de motivatie este absolut stupida. Atunci cand sunt in intarziere, ma simt deprimat si total nemotivat. Atunci cand sunt in avans fata de orar, sunt agreabil si productiv. Calendarul nu este locul in care sa se efectueze jocuri psihologice.

Daca managerul forteaza reducerea estimarilor, iata ce trebuie sa faci. Creeaza-ti o coloana noua in calendar care se numeste Estimarea lui Radu (presupunand evident ca numele tau este Radu). Scrie estimarea ta acolo. Lasa managerul sa faca orice-o vrea cu coloana Estimare curenta. Ignora estimarile managerlui si atunci cand proiectul se termina, compara cine e mai aproape de realitate. Am observat ca numai amenintand sa fac asa ceva face minuni, in special cand managerul isi da seama ca tocmai s-a angrenat intr-un concurs cu miza de a arata cat de incet poti lucra!

De ce managerii incompetenti incearca sa convinga dezvoltatorii sa reduca estimarile?

La inceputul proiectului, managerii tehnici se intalnesc cu cei care conduc afacerea si apar cu o lista de functionalitari care ei cred ca va dura 3 luni, dar in realitate va lua cam 9. Cand te gandesti la scrierea de cod fara a lua in considerare toti pasii care trebuie efectuati, totdeauna pare ca va lua n timp, cand in realitate va lua aproximativ 3n timp. Cand faci un calendar real si aduni toate task-urile, vei realiza faptul ca proiectul o sa ia mult mai mult timp decat s-a prevazut initial. Este evident.

Managerii incompetenti incearca sa rezolve acest lucru gandindu-se cum sa convinga oamenii sa lucreze mai repede. Acest lucru nu este foarte realist. Poti fi capabil sa angajezi mai multi oameni, dar ei vor trebui sa ajunga la regimul de croaziera si probabil vor lucra la sub 50% din eficienta vreme de cateva luni (afectand si productivitatea celor ce vor trebui sa-i asiste). Mai mult, la piata de munca actuala incercarea de a adauga cativa programatori buni va lua cel putin 6 luni.

Poti fi eventual capabil sa obtii 10% mai mult cod de la dezvoltatori dar la costul de a-i "arde" 100% intr-un an. Castigul este mic, iar strategia seamana cu a-ti manca propriile seminte in loc de ale semana.

Poti sa fii capabil sa scoti 20% mai mult cod tragand de oameni sa lucreze din greu, fara sa tii seama de cat de obositi sunt. Boom, timpul de debugging se dubleaza. O miscare absolut gresita care se rezbuna intr-un mod aproape karmic.

Dar niciodaca nu poti sa obtii 3n volum de munca in n timp, iar daca tu crezi ca poti, te rog spune-mi la ce companie lucrezi ca sa fiu sigur ca n-o sa iau vreodata actiuni acolo.

13) Un calendar e ca o colectie de cuburi de lemn. Daca ai o gramada de cuburi de lemn care nu intra intr-o cutie, ai doua alternative : iei o cutie mai mare sau lasi afara cateva cuburi. Daca livrarea este in 6 luni si pe calendar sunt 12 luni, ori livrarea trebuie intarziata ori niste functionalitati trebuie eliminate. Pur si simplu blocurile nu se pot micsora, iar daca sustii ca se poate, te lipsesti de cea mai elementara oportunitate de a putea prevedea viitorul mintindu-te pe tine insisi despre acest viitor.

Un alt efect interesant al calendarelor este ca te forteaza sa tai functionalitati. De ce acest lucru este pozitiv ? Hai sa presupunem ca avem doua functionalitati : una care este efectiv utila care va face produsul absolut exceptional (exemplu: tabelele in Netscape 2.0) si o alta care este relativ usoara si pe care programatorii ar adora s-o implementeze (de exemplu : tagul BLINK), dar care nu serveste unui scop util sau de marketing.

Daca nu faceti un calendar, programatorii vor incepe cu functionalitatea usoara/amuzanta. Ei vor intarzia, si singura alegere va fi ori sa intarzie livrarea ori sa anuleze functionalitatea utila/importanta.

Daca faci un calendat, chiar inainte de a incepe treaba vei realiza daca trebuie sa tai ceva, asa ca vei taia functionalitatea usoara/amuzanta si va ramane de dezvoltat doar cea utila/importanta. Fortandu-te sa tai functionalitati, vei sfarsi prin a face un produs mai puternic, mai bun, cu un amestec mai judicios de functionalitati si care are sanse sa fie livrat la timp.

Imi amintesc cand am lucrat la Excel 5. Lista initiala de functionalitati era enorma si ar fi depasit cu mult calendarul. Groaznic, ne-am gandit. Toate aceste functionalitati sunt super-importante. Cum vom putea trai fara un wizard de editare de macro-uri ?

Dupa cum s-a dovedit ulterior, nu am avut de ales, asa ca am taiat pana ce am ajuns la "piele si os" ca sa facem fata livrarii. Toti au fost nemultumiti de taieturi. Ca sa ne calmam resentimentele, ne-am spus ca nu taiem functionalitati ci doar le amanam pentru Excel 6, din moment ce ele sunt mai putin importante.

 Pe masura ce Excel 5 se apropia de completare, am inceput sa lucrez la Excel 6 cu un coleg. Eric Michelman. Am parcurs impreuna lista functionalitatilor de "Excel 6" care fusesera taiate. Am fost absolut socati sa vedem ca eram in fata celei mai incoerente liste de functionalitati imaginabila. Nici una dintre ele nu merita implementata. Nu cred ca nici una a fost implementata in urmatoarele 3 versiuni. Procesul de subtiere a functionalitatilor pentru a acomoda livrare a fost cel mai bun lucru posibil. Daca nu am fi facut asta, Excel 5 ar fi luat cam de 2 ori mai lung si ar fi inclus 50% functionalitati inutile. (Nu am nici un dubiu ca exact acest lucru s-a intamplat cu Netscape5/Mozilla: nu a existat calendar, nu a existat o lista definitiva de functionalitati, nimeni nu a vrut sa taie nimic, si nu s-a putut livra. Cand se va livra, vor avea o sumedenie de briz-brizuri cum ar fi clienti de IRC cu care nici n-ar fi trebuit sa piarda vremea.)

Appendix: Lucruri pe care e bine sa le stii despre Excel

Unul dintre motivele pentru care Excel este un produs excelent pentru calendare este ca programatorii care lucreaza la el il folosesc pentru mentinerea propriilor calendare ! (Nu multi dintre ei ruleaza scenarii de afaceri alambicate ... sunt totusi programatori !)

Shared Lists Folosind comanda File/Shared Lists permite tuturor sa deschida fisierul in acelasi timp si sa modifice simultan. Din moment ce intreaga echipa va actualiza constant calendarul, este extrem de util.

Auto Filter Aceasta este o modalitate excelenta de a filtra calendarul in asa fel incat, de exemplu, poti vedea numai functionalitatile care iti sunt alocate. Combinat cu Auto Sort, poti vedea toate taskurile in ordinea prioritaitii, ceea ce constituie efectiv un "TODO list" actualizat automat. Cooooool!

Pivot Tables Aceasta este o modalitate excelenta de a vedea sumare si tabele incrucisate, De exemplu, se poate face un grafic care arata orele ramase pentru fiecare dezvoltator, pentru fiecare prioritate. Tabelele pivot sunt ca painea feliata si milkshake-urile cu ciocolata. Trebuie sa inveti sa le folosesti pentru ca vor transforma Excel-ul intr-o unealta de un milion de ori mai puternica.

Functia WORKDAY din Excel Analysis Toolpak este o excelenta metoda de a obtine date precise dintr-un calendar.



Acest articol a aparut initial in engleza cu numele Painless Software Schedules  

Joel Spolsky este fondatorul Fog Creek Software, o mica firma de software din New York City. El a absolvit Universitatea Yale si a lucrat ca programator si manager la Microsoft, Viacom si Juno.


Continutul acestor pagini reprezinta opinia unei singure persoane.
Tot continutul Copyright ©1999-2005 de Joel Spolsky. Toate Drepturile Rezervate.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky