O greseala in estimarile proiectelor software : optimismul nefondat

optim_nefondatGreselile care afecteaza acuratetea estimarilor pentru proiectele software pot fi de mai multe tipuri. Unele dintre ele pot fi prevazute. Altele, intuite (nu e acelasi lucru). Iar altele, deduse din anumiti factori de context.

Una dintre cele mai des intalnite greseli de acest fel este optimismul fara fundament. Adica increderea celui care estimeaza ca lucrurile vor merge bine, fara a putea argumenta ca intr-adevar se va intampla asta.

Doza de pesimism nu trebuie sa lipseasca din nici o estimare. Stiu, una dintre legile lui Murphy spune ca daca lucrurile pot sa mearga prost, atunci asa vor merge. Nu spun ca ar trebui facute estimarile in umbra legilor lui Murphy. Insa spun ca daca nu exista suficiente argumente care sa sustina ipoteza ca lucrurile vor merge bine, atunci trebuie neaparat luata in calcul varianta in care ele vor merge prost.

Nu va bazati pe faptul ca daca lucrurile au mers prost la un proiect anterior, ele vor merge mai bine in proiectul curent pentru ca oamenii implicati in primul proiect au acum o experienta mai vasta. Nimic nu garanteaza ca motivele pentru care noul proiect poate sa mearga prost vor fi aceleasi ca si la vechiul proiect. Sau ca e vorba de exact acelasi context. Sau ca lectiile care s-au putut invata din ratarea vechiului proiect au fost intr-adevar invatate. Dimpotriva – daca exista un precedent care poate fi folosit pe post de “worst case scenario”, analizati-l. Iar daca e cazul sa-l folositi, folositi-l.

Totodata, productivitatea e variabila si depinde de o multime de factori. E gresit sa presupuneti ca nivelul de productivitate va fi acelasi pe tot parcursul lucrului la un task anume. E chiar contraindicat, de fapt.

In alta ordine de idei, daca doi oameni estimeaza acelasi task, atunci e foarte probabil ca estimarile pe care le obtineti sa fie diferite (si corecte in acelasi timp – dar despre asta discutam altadata). Daca e vorba de un task ce face parte dintr-un proiect mai mare, care se va desfasura pe termen lung, probabilitatea ca taskul respectiv sa fie implementat chiar de catre developerul care a facut estimarea este tot mai mica. Asadar, marja de eroare care se impune in estimarea taskului respectiv trebuie sa acopere si cazul in care implementarea se va face de catre cineva cu experienta mai redusa si un nivel maxim de productivitate mai redus.

Cei mai multi developeri sunt optimisti prin definitie. Ceea ce e foarte bine, insa nu si atunci cand se fac estimari. Unul dintre sfaturile din cartea lui Steve McConnell – Software Estimation : Demystifying the Black Art (pe care-o recomand tuturor celor care au facut sau vor face vreodata estimari) suna asa : “Don’t reduce developer estimates – they’re probably too optimistic already”.

Ca sa inchei intr-o nota mai optimista, as spune asta : cand estimati, e limpede ca nu va puteti pregati pentru orice. Dar pregatiti-va pentru tot ceea ce – direct sau indirect – poate sa mearga prost. Sperati sa fie bine, dar pregatiti-va pentru cazul contrar. Atentie insa la marja de eroare de care spuneam mai sus. Ea trebuie sa se justifice. Nu inseamna ca o marja mare de eroare poate fi oricat de mare. In toate cazurile, ea va trebui argumentata – cu argumente reale, nu cu presupuneri. O marja de eroare mare si nejustificata nu va fi niciodata acceptata de nimeni.

E ok sa fim optimisti atunci cand estimam, dar numai atunci cand putem argumenta clar pe ce anume se bazeaza acest optimism. In caz contrar, optimismul nu-si are sensul. Lipsindu-i fundamentul, va duce la o estimare gresita si va pune in pericol proiectul.

Add a Comment

Your email address will not be published. Required fields are marked *