Estimarea duratei unui proiect soft imi pare un lucru dificil. De obicei am tendinta sa subestimez timpul necesar, dar lucrurile nu merg intotdeauna cum ma astept si intru in criza de timp. Voi cum faceti sa estimati si sa va incadrati in timp ?
2 Likes
Daca ai constant probleme de estimare inseamna ca nu reusesti sa spargi conceptual proiectul pe bucati cat mai independente si usor de estimat individual. Recomand din tot sufletul User Stories Applied, de Mike Cohn. Gasesti cateva informatii pe scurt aici.
Indiferent daca practici Agile sau nu, partea legata de user stories o sa te ajute enorm. Eu am ajuns de-a lungul anilor la o forma hibrida de estimare, a carei cheie este identificarea rolurilor utilizatorilor, iar apoi a tuturor actiunilor pe care acestia le pot intreprinde. Apoi estimez fiecare user story / task in parte, insumez, si aia e.
Dupa ce citesti cateva materiale legate de user stories, arunca un ochi pe Acunote, un web app de task management care are si o componenta de estimare / time tracking (manual din pacate), si care iti spune cand ai estimat prost, cate story points (unitate de masura a estimarii) poti face intr-un interval de timp ca sa ai o imagine reala asupra a cat poti livra intr-un timp limitat, etc.
4 Likes
Estimarea este la același nivel de dificultate cu numirea variabilelor 
Aici poți citi o poveste amuzantă despre cum estimările dau pe lângă.
6 Likes
In software, “how long?” has two answers: 1) It’s done, and 2) I don’t know.
9 Likes
-
Un articol interesant pe tema asta:
http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/
Pentru o estimare cat mai buna trebuie sa reduci elementele de variabilitate. -
Daca problemele sunt pe partea de implementare recomandarea mea este folosirea de agile story points + planing poker care sa tina cont de capabilitatile fiecarui membru al echipei.
-
Istoricul este de asemenea folositor, la un moment dat dupa implementarea mai multor proiecte de aceeasi factura vei putea estima cu o eroare minimala.
1 Like
M-am mai linistit dupa ce am citit, se pare ca intarzierea proiectelor e o boala raspandita. 
1 Like
Voi depasiti deadline-uri? Nu stiu daca la noi s-a intamplat de 2 ori in 10 ani de zile… (vorbesc de cazurile in care nu s-au schimbat specificatiile pe drum & shit).
1 Like
Nici eu nu tin minte cand a fost ultima oara cand am depasit un deadline, fara sa fie din vina intarzierii clientului sau a schimbarilor de specs.
M-am mai linistit dupa ce am citit, se pare ca intarzierea proiectelor e o boala raspandita.
Asta nu inseamna ca e ok, mai ales daca ai termen contractual. Eu prefer sa adaug padding generos la estimare cand nu sunt sigur, si sa livrez mai devreme daca totul merge ok, decat sa pic in situatia inversa. De asemenea, de multe ori ii spun clientului ca proiectul o sa dureze in principiu X, dar sunt dispus sa ma angajez contractual doar la X + Y, pentru siguranta.
2 Likes
- usual rule: whatever you estimate * 2
- usual sub-rule: always try to deliver early
1 Like
@adrianbasilic Sa inteleg ca in 10 ani ai avut cel putin 2 proiecte in care nu s-au schinbat specs. Asta e bine.
De cele mai multe ori livrez mai mult decat cele discutate si atunci pot depasi estimarea initiala. Solutia este sa livrezi cat mai repede bucati din proiect si astfel clientul va adauga livrabile proiectui.
Ideea de agile trece pe locul doi deadline-ul, punand pe primul loc plus valoarea si calitatea. Datele fixe sunt pentru cei care nu inteleg proiectul si care au de bifat niste chestii. In situatia extrema in care data e fixa de constrageri externe(ex: cm 2014) pot scade numarul de feature-uri.
In rest, estimarea functioneaza pe acelasi principiu in orice metodologie: impartirea pe bucati cat mai mici, identificarea celor cu risc ( si adaugarea unui factor de multiplicare) , apoi suma
1 Like
Problema cu Agile e ca proiectele nu se sfarsesc. EVER. Or daca ai un client care nu e tocmai cel mai ok si vrei sa inchei colaborarea, e complicat. Also, nu prea poti jongla cu mai multe proiecte in paralel, ca la sfarsitul sprintului tu tre sa arati ceva. In toate proiectele.
1 Like
@victorstanciu Interesanta ideea cu padding-ul Y, dar cum faci cu clientii care mai adauga pe parcurs solicitari si apoi se mira ca estimarea este depasita ?
Eu explic foarte clar si raspicat clientilor, si repet de mai multe ori pe parcurs, ca estimarea de timp si cost este valabila numai si numai in limita feature-urilor convenite pana la momentul ala. Iar cand lucrez cu clienti noi pe care nu ii cunosc indeaproape inca, merg chiar un pas mai departe, si anexez toate cerintele lor la contract, cerinte pe care ii pun sa le semneze si stampileze. Nu am avut in felul asta niciodata in atatia ani probleme de genul asta.
Am avut in schimb multe experiente pozitive, de clienti care, atunci cand veneau cu o solicitare in plus, indiferent cat de mica, incepeau cu “Sa ne spui te rog cat ne costa sa…”. Dar asta se datoreaza si pentru ca am un spider-sense foarte ascutit, si nu lucrez decat cu clientii care “feel right”.
5 Likes
@victorstanciu Dar cum faci in cazul proiectelor de research, cand nu prea poti da o estimare clara ? De exemplu clientul vede ceva hot pe un site si vrea si el la fel, nu poti estima pentru ca n-ai mai facut ceva similar inainte.
Nu s-au schimbat specificatiile? Fara minciuni pe forum! :))
Din pacate, nu am avut proiect la care schimbarea specificatiilor sa nu afecteze estimarile, de la putin pana la ridicol.
Cu estimarile task-urilor izolate (pe proiecte deja live) nu tin minte sa fi avut probleme (cel putin nu mari), dar in cazul proiectelor de la zero sau a update-urilor de proportii, nu cred sa fi respectat vreodata deadline-ul, MEREU au aparut surprize din partea clientilor (sau 3rd party, mai ales cand era vorba de Facebook).
7 Likes
Daca tot vorbim de estimari depasite si minciuni, Adrian are pe site un disclaimer funny in acest sens:
Our website looks like this because we’re busy developing another version. If you came a month or two ago and found this same message, we’re not liars, we just left aside this project to work on other projects, for other people.
Foarte buna intrebare. Nu am un raspuns fix, judec de la caz la caz. De obicei, daca spre exemplu trebuie sa cercetez o tehnologie pe care nu am mai folosit-o, iar cercetarea in sine nu reprezinta o parte imensa din proiect, nu le iau bani clientilor pentru asta, ca o vad si ca pe un beneficiu personal, mai invat si eu ceva nou. Alteori, cand era mai mult de studiat, treceam pe modul de facturare la ora. Ii comunicam clientului un tarif orar, ii dadeam un estimat ballpark cat mai pesimist, si daca era ok, ii dadeam drumul la treaba. Nu am avut probleme.
3 Likes
În al doilea film - Estimation - se explică modul în care se stimează în Agile și cum se lucrează cu User Stories.
2 Likes
Salutare, mă întreb dacă sunt eu extrem de ineficient sau unii fac estimări fanteziste:
@Kingsley: Ruby on rails (framework) cu care creezi un site extrem de repede (faci un site like Reddit în 3 ore maxim). link
@isti37: > Un asa site nu e tocmai un site de facut pentru un incepator, chiar si mie mi-ar lua cel putin o saptamana buna, doua sa il fac si stiu exact ce e in spate, chiar o luna daca trebuie proiectata si baza de date link (este vorba despre un site identic cu https://www.hltv.org/)
Nota: am preluat un proiect legat de fotbal și mi se pare destul de complex (campionate pe diferite țări, transferuri, redenumiri echipe, live-uri, știri, newsletere, etc…)
@isti37 Nu e mare filozofie mai nici un program de CRM daca nu gasesti ceva ok. … E o munca de 2-3 ore pentru un programator cu experienta. link
Am mai întâlnit exemple dar nu mai știu pe unde sunt.
Eu cred că în spatele proiectelor enumerate în link-urile de mai sus stau echipe întregi de programatori, iar mie mi-ar lua luni de zile oricare dintre ele. Codez eu prea încet sau codează alții prea repede?
Mulțumesc!
2 Likes