Cum estimezi un task pe care îl ai de făcut

Dacă ți-a plăcut acest articol, dă-ne un like pe Facebook.

Când ești programator începător tot ceea ce te va interesa este să rezolvi cât mai multe probleme, ca să poți să câștigi experiență și să primești proiecte mai dificile. Astfel, vei simți că progresezi și că devii un om de bază în echipa în care lucrezi.

Din păcate, ce am experimentat și eu ca newbie, este o grabă de a începe munca înainte de a înțelege problema pe care o ai în față și să ai un plan de atac.

Poate tu ești mai organizat decât mine, dar eu unul am întâmpinat probleme serioase fiindcă nu aveam puțină răbdare și nu îmi detaliam frumos pe foaie exact ce trebuie să fac ca să duc la capăt task-ul ce l-am primit.

În jobul meu de zi cu zi, trebuie să furnizez estimări în ore pentru fiecare task pe care urmează să îl rezolv. Sunt avantaje și dezavantaje în abordarea asta cu estimările, pe care le voi detalia în alt articol, dar faptul că ești pus în poziția de a furniza o estimare în ore, implică și o anumită înțelegere a task-ului pe care îl ai în față.

Cum poți estima că un task durează 2 ore sau 10 ore?

Dacă ai mai multe task-uri, le poți compara între ele și să stabilești un Task de Referință (TR) și să le raportezi pe celelalte la TR. Cel mai probabil vei alege ca TR un task similar cu ce ai mai făcut până acum sau despre care ai în mare habar cam cum se rezolvă. Spui că TR-ul tău va dura 2–3 ore să îl faci.

Te sfătuiesc să zici 3 ore și chiar te-aș sfătui sa mai adaugi o 1/2h la estimarea ta. În general, am observat că oamenii dau estimări optimiste și nu pesimiste. Poate din dorința de a arăta că pot celor din jur sau din dorința de a-și arăta lor că pot, începătorii vor da de obicei estimări optimiste. Apoi în funcție de TR-ul tău pesimist să dai estimări înmulțind TR-ul tău cu un factor de complexitate.

Ai 3 task-uri, T1, T2, T3, inclusiv T1 este TR-ul tău.

T1 = 3.5h.

T2 este un task destul de complicat, cam de 2–3 ori mai complex. Din nou, te sfătuiesc să fii pesimist și să consideri că T2 este de 3 ori mai complex.

T2 = T1 x 3 = 10.5h

T3 — complexitate mai mică, de 1–2 ori mai complex decât T1, așadar T2 este de 7h.

S-ar putea să ți se pară exagerate aceste estimări, nu-i nicio problemă, durata implementării tale va dovedi dacă au fost sau nu exagerate.

S-ar putea uneori să fie foarte precise, alteori total greșite aceste estimări, în plus sau în minus. În timp, estimările tale vor fi mai rafinate.

Cert este acum că ai un algoritm pe care îl vei rafina în timp pe măsură ce acumulezi experiență. În plus, când te va întreba cineva cum anume ai estimat durata de implementare a unui task, vei avea un algoritm pe care îl vei putea da ca exemplu, iar ceilalți vor veni cu sugestii, mai mult sau mai puțin utile, pentru rafinarea algoritmului tău.

Acum că ai un algoritm pentru a estima cât ți-ar lua un task, ai nevoie și de un set de pași ca să determini care este complexitatea unui task.

Pentru estimare avem o formulă de tipul

Estimare Task = Durată TR x Complexitate Task

Pentru determinarea complexității vom avea nevoie de niște întrebări care să ne ghideze pentru a descoperi cât de complicat este ceea ce vom face și dacă înțelegem în detaliu ce urmează să facem.

Cum determini complexitatea task-ului tău

1. Ce trebuie să faci?

Detaliază în câteva paragrafe care este funcționalitatea pe care trebuie să o creezi și apoi întreabă persoana care a cerut acea funcționalitate să îți confirme dacă detalierea ta reprezintă exact funcționalitatea pe care ei și-au imaginat-o.

Cei care de obicei cer funcționalități nu știu sigur ce au nevoie și atunci o astfel de detaliere s-ar putea să le clarifice și lor exact ce au nevoie.

Nu ai vrea să începi să implementezi ceva greșit.

Din această întrebare ar trebui să obții o imagine de ansamblu pe care o poți povesti și altor programatori dacă vei avea nevoie de ajutor.

2. Care sunt pașii pe care trebuie să îi faci ca să rezolvi task-ul?

Dacă întrebarea precedentă ne-a ajutat să înțelegem care este imaginea de ansamblu, acum trebuie să înțelegi în detaliu ce anume trebuie să faci pentru ca soluția ta să fie dusă la bun-sfârșit.

De obicei, un task complex este format din câteva task-uri mai mici. Fucking obvious, right?

Ei bine, e evident, dar mental vorbind, dacă nu ai multă exepriență în algoritmică, nu vei trata orice task ca fiind o adunătură de task-uri mai mici și asta îți va crea probleme pe viitor. Trust me, I’ve been there.

O observație deprinsă din ultimii 2 ani este că programatorii bun își schițează task-urile complexe, ca să se asigure că au înțeles bine ce au de făcut.

Împarte-ți task-rile complexe mereu în task-uri mai mici și compară lista ta cu lista unui programator care a făcut deja un task asemănător sau întreabă un programator cum ar rezolva el acea problemă, care ar fi pașii pe care el i-ar vedea.

La început, s-ar putea să vezi aceleași etape ca alți programatori sau nu vei detalia mai mult sau mai puțin ca alții, important e să detaliezi cât să fie clar că ai înțeles ce ai de făcut.

De obicei întrebarea de mai sus o să te ajute să afli câteva informații prețioase:

  • de ce fel de date am nevoie
  • de unde le iau
  • ce trebuie să fac cu datele mele
  • ce trebuie să afișez sau ce trebuie să se întâmple cu ele după ce le-am procesat
  • cum testez că funcționalitatea mea merge
  • care ar fi niște scenarii unde lucrurile ar putea să meargă prost
  • când se va considera că task-ul este încheiat

În etapa asta îți vei da seama dacă ai toate informațiile de care ai nevoie ca să îti faci treaba.

Dacă ai nevoie de o analogie, poți compara această etapă cu descrierea unei rețete pentru o prăjitură.

Ca să faci prăjitura ai nevoie să știi de ce ingrediente ai nevoie, cum să le combini, cum să faci aluatul, cât timp trebuie să lași prăjitura în cuptor, cum se face crema și cum se decorează acea prăjitură ca să fie și frumoasă pentru cei care o vor consuma.

Aceasta este cea mai importantă etapă, te rog nu sări niciodată peste ea.

3. Ce pattern-uri de coding voi folosi, ce structuri de date voi manipula?

Știu că deja intrăm în detalii de implementare, dar doar vom duce un pic mai departe ce am răspuns la întrebarea precedentă.

Cu ajutorul întrebării acesteia, vei începe să te gândești tehnic ce ai de făcut și vei începe să detaliezi planul tău de atac în felul următor:

  • va trebui să preiau niște obiecte din baza de date cu ajutorul unor query-uri SQL
  • va trebui să creez un obiect nou care mă va ajuta să centralizez doar informația de care am nevoie la afișare
  • va trebui să creez un array de obiecte noi pe care le voi pasa la funcția mea ce va face afișarea lor
  • va trebui să iterez prin lista mea de obiecte obținute din baza de date și să le adaug în lista mea de obiecte nou creată

Cred că ai prins ideea și anume că te vei gândi în detaliu la ce fel de structuri de date vei manipula și cum circulă informația prin algoritmul tău.

Întrebarea 4 adresează-ți-o după ce ai terminat implementarea și dacă mai ai timp sau ți se va acorda extra timp, aplică ceea ce o să răspunzi.

4. Cum pot îmbunătăți codul pe care l-am scris?

  • Ai bucăți de cod care se repetă? Poți abstractiza informația respectivă într-o funcție cu parametrii?
  • Poți reduce numărul de hit-uri la baza de date și să îți aduci informația “dintr-odată”.
  • Folosești toate variabilele pe care le-ai creat?
  • Ai nevoie de toate variabilele pe care le-ai creat?
  • Ai testat și documentat scenariile de test la care te-ai gândit?

S-ar putea ca după ce termini un task, să nu mai vrei să ai de-a face cu acel task. E ceva normal. Totuși, forțează-te un pic să mai treci o dată prin codul tău, la 2–3 zile după ce l-ai scris și vezi dacă e ceva ce ai fi putut face mai bine.

În felul acest, îți creezi un obicei care te va schimba în bine în câteva luni.

Vei dezvolta mentalitatea unui programator care își ia codul în serios și se comportă ca un autor.

Un autor bun vrea să scrie textul cel mai bun, un text care va fi citat de oameni pe Internet, care va inspira și va capta atenția tuturor celor care vor citi acel text.

Un autor bun vrea să fie mai bun la scris și să scrie din ce în ce mai bine.

***

Poate sugestiile mele de mai sus ți se vor părea un pic cam generale. Intenționat le-am formulat așa.

Nu vreau să îți sugerez lucruri care mi se potrivesc mie, considerând că ți se vor potrivi si ție, adevărul este că suntem foarte diferiți, iar proiectele pe care noi 2 lucrăm sunt și ele foarte diferite.

De asemenea, politica companiei/departamentului în care tu lucrezi, sigur va fi și ea diferită.

Înțelegând strategic care este rolul tău și cum te poți îmbunătăți în fiecare zi câte puțin sunt lucruri la care ar trebui să te gândești în mod constant.

În esență, dacă alegi să privești fiecare task pe care îl ai de făcut, ca pe o oportunitate să scrii un cod ceva mai bun, te vei folosi de munca ta de zi cu zi, pentru a deveni programatorul acela pe care toată lumea îl va stima și îl va respecta, iar tot ceea ce vei face tu de fapt va fi doar să scrii azi un cod mai bun decât cel de ieri și mai puțin bun decât cel de mâine și să oferi estimări cât mai aproape de realitate pentru tine și pentru colegii și clienții tăi.

Dacă ți-a plăcut acest articol, dă-ne un like pe Facebook.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.