“The Fudge Factor” in estimarea proiectelor software

fudge

Se spune ca daca estimarile ar fi exacte, ele s-ar numi “exactimari”. Exista asadar un motiv intemeiat pentru care ele se numesc in continuare “estimari” .
Vorbind la modul general, o estimare este de fapt o predictie cu privire la durata si costurile unui anumit task.

Vom sti cu certitudine daca estimarea data pentru un task anume a fost corecta abia la finalul taskului respectiv. Raportul dintre rezultatul final si rezultatul estimat reprezinta asa-zisul “fudge factor”. De exemplu, daca un task anume a fost estimat la 3 ore si a durat de fapt 4.5 ore, atunci fudge factorul in acest caz este 4.5 / 3 = 1.5 .

Estimarile pentru un anumit task difera in functie de pregatirea/nivelul developerilor care estimeaza. Un fudge factor se poate calcula corect pentru un anumit tip de task doar daca taskul respectiv a fost estimat si dezvoltat de aceeasi persoana. Odata calculat, evolutia mediei factorului respectiv poate fi urmarita in timp – iar persoana care estimeaza isi poate imbunatati estimarile in functie de acest factor.

Fudge factorul calculat pentru o persoana care estimeaza un anumit task difera in functie de :

  • tehnologia folosita
  • framework-ul pe care se va dezvolta
  • tipul taskului care se estimeaza

PM-ul poate tine statistici legate de acest factor, pentru fiecare dintre developeri. Aceste statistici vor ajuta – printre altele – la ajustarea estimarilor primite de la fiecare developer in parte.

De exemplu, putem lua urmatorul caz fictiv – presupunand ca este vorba de un proiect pe arhitectura LAMP (Linux / Apache / MySQL / PHP), framework-ul ExpressionEngine – iar taskurile implica modificari de front-end :

  • taskul I
    • estimare : 4 ore
    • realizare : 7 ore
    • raport : 7 / 4 = 1.75
    • concluzie : depasire cu 75% a timpului de lucru estimat
  • taskul II
    • estimare : 5 ore
    • realizare : 8 ore
    • raport : 8 / 5 = 1.6
    • concluzie : depasire cu 60% a timpului de lucru estimat
  • taskul III
    • estimare : 6 ore
    • realizare : 8 ore
    • raport : 8 / 6 = 1.33
    • concluzie : depasire cu 33% a timpului de lucru estimat

In aceasta situatie, developerul si-a imbunatatit fudge factorul in timp. Adica a invatat sa estimeze mai corect.
Totodata, PM-ul va avea suficiente informatii incat sa faca o medie. Media va fi ( 1.75 + 1.6 + 1.33 ) / 3 = 1.56 . Practic, asta inseamna ca deocamdata developerul respectiv isi depaseste estimarile in medie cu 56% – pentru taskurile care implica modificari de front-end pe ExpressionEngine.
Presupunand ca proiectul continua iar developerul va da estimari pentru alte doua taskuri – PM-ul va sti ce multiplicator sa foloseasca pentru estimarile primite de la developer, pentru a ajunge la un rezultat posibil apropiat de realitate. Spun “posibil” si “apropiat” pentru ca vorbim totusi de estimari, nu de “exactimari”.

Asadar, vom avea :

  • taskul IV
    • estimarea developerului : 3 ore
    • estimarea finala : 3 * 1.56 = 4.68 ore
  • taskul V
    • estimarea developerului : 5 ore
    • estimarea finala : 5 * 1.56 = 7.8 ore

Dupa implementarea ultimelor doua taskuri se vor lua in calcul timpii lor de realizare iar media care reprezinta fudge factorul va fi recalculata.

Statisticile pot fi uneori derutante (iar alteori, enervante), insa sunt necesare. Nu putem imbunatati ceva ce nu putem masura. Calibrarea unei metode de estimare e necesara – si nu trebuie facuta “dupa ureche”, ci in baza unor informatii concrete. Iar o astfel de informatie o reprezinta media factorului mentionat anterior, a carui integrare in procesul de estimare poate fi privita ca si un exemplu de “fine tuning” al estimarii respective.

No Responses

Add a Comment

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