Încă o dată, a apărut întrebarea cu privire la exactitatea estimărilor timpului necesar dezvoltării. Încă o dată am încercat să formulez un răspuns pentru mine.
În primul rând, estimările "exacte" nu există în principiu. Munca este întotdeauna o variabilă aleatorie, sub rezerva unei distribuții de probabilitate. În exterior arată așa.
În acest exemplu, probabilitatea de completare a sarcinii timp de 4 zile este de 0,5, timp de 6 zile - 0,75, timp de 8 zile - 0,9.
Eu, ca un adevărat de client rău și prost strictă aici încurcă de muncă și de timp pentru finalizarea sarcinii, dar este, în acest caz, nu contează. Pentru simplitate, vom presupune că sarcina este executată de o singură persoană și îi dă tot timpul până la finalizarea sarcinii. (Știți, cu astfel de estimări, "pentru simplitate", în nici un caz nu puteți fi de acord atunci când planificați proiecte reale, nu-i așa?)
Când suntem obligați să estimăm efortul, de obicei ne fixăm un prag aproximativ de probabilitate. De exemplu, dacă punem un prag de 0,9, atunci estimările noastre vor fi efectuate în medie de nouă ori din zece.
Aceasta este doar o formă aproximativă a curbei. Este puțin probabil ca cineva să poată formula cu precizie parametrii de distribuție pentru evaluarea următoarei sarcini. Poți, bineînțeles, să încerci să o construiești pe baza unor statistici colectate despre sarcinile deja îndeplinite. Dar statisticile, cel mai probabil, vor fi mincinoase, pentru că de fiecare dată condițiile care depind de parametrii de distribuție variază.
Și aici abordăm fără probleme prima problemă a exactității estimărilor. Una dintre întrebările preferate ale clienților (și care acționează în rolul lor superiori): „De ce este evaluarea ta întotdeauna greșit dacă decideți să aveți atât de mulți ani aceeași problemă?“
Și, în mod caracteristic, de multe ori suntem de acord cu el, și lăsând la birou după mustrării, el însuși chinuit, „și adevărul, iar când mă opresc pas cu pas pe aceeași greblă?“ Acest lucru este confirmat de numărul mare de pseudo-științifice și neștiințifice metode „științifice“ de apreciere a acestei a inventat industria de dezvoltare software pentru anii existenței sale. Încercăm să estimăm valoarea codului, numărul de yuzkei, nodurile funcționale sau papagalii. Înmulțim estimările cu numărul "pi" sau "e". Dar nu ne îndoim de principala cauză: o estimare precisă poate fi "calculată" dacă găsim o formulă magică.
Dar să ne gândim: îndeplinim cu adevărat aceleași sarcini?
Imaginează-ți. Am setat o sarcină pentru programator - spune, scrie o funcție pentru calculul rădăcinii pătrate. Programatorul a petrecut trei zile, de exemplu, o altă zi a continuat să testeze și să repare bug-uri.
Lunea următoare, l-am pus pe programator o nouă sarcină: scrieți funcția de calcul al rădăcinii pătrate. Și i-am dat patru zile. Pe baza experienței acumulate. Programatorul experimentat completează lucrarea în două zile și fără erori.
Îl lăudăm și îi dăm oa treia sarcină: scriem funcția extragerii rădăcinii pătrate.
După câteva luni de productivitate programator este stabilizat, iar el va fi capabil de a da trei funcții calcula rădăcina pătrată pe zi. Pe baza acestei performanțe, vom putea să dăm estimări foarte precise ... Estimările efortului de scriere a funcției de calcul al rădăcinii pătrată.
Absurditatea exemplului este evidentă, însă demonstrează problema de bază inerentă în majoritatea modurilor de estimare a muncii. Programatorii nu rezolvă niciodată aceleași sarcini. Toate sarcinile sunt unice.
Desigur, foarte des în programarea unei abordări generic pentru rezolvarea unor probleme specifice - tot felul de modele și cadre. În diferite domenii, programarea poate include mai mult sau mai puțin sarcini de rutină. Dar adevărul este că, de obicei, rutina automatizate (sau dat unui animalelor tinere fără experiență, care contribuie partea sa de imprevizibilitate), în timp ce cea mai mare parte de incertitudine constă tocmai în acea parte a problemei, ceea ce îl face unic.
Perturbarea clientului în toată sinceritatea: din punctul său de vedere, vom rezolva într-adevăr aceleași probleme de afaceri. Am petrecut aproape zece ani într-un domeniu foarte îngust - dezvoltând aplicații pentru terminale care acceptă carduri bancare. Și din punctul de vedere al clienților de afaceri. toți acești zece ani, am rezolvat de nenumărate ori absolut aceeași sarcină: să „învețe“ terminal pentru a efectua vânzarea cardului de client. Din punct de vedere tehnic, niciuna dintre aceste sarcini nu era similară celeilalte. Numărul de parametri pe care acestea diferă este enorm: hardware diferite, limbi diferite, compilatoare diferite, protocoale diferite, diferite interfețe de utilizator pentru afaceri ... Dar totul e lipsit de importanță - terminal sau execută tranzacția sau nu.
Poți să faci ceva despre asta? Cum să luați în considerare incertitudinea în planificarea proiectului?
Cea mai obișnuită modalitate: de a pune cât mai mult risc în planificare și de a da o estimare, pe care o puteți întâlni cu cea mai mare probabilitate posibilă. Această "oportunitate maximă" este determinată, în primul rând. gradul de impudență a managerului și dorința sa de a se negocia cu clientul, iar în al doilea rând - gradul de neglijare a paranoiei sale, manifestat în luarea în considerare a riscurilor.
Dar chiar dacă reușim să negociem estimări cu o probabilitate de 0,9, acest lucru nu va reduce tensiunile din proiect. În primul rând. fiecare al zecelea termen va fi în continuare perturbat (și aceasta va fi în mod necesar cea mai importantă și importantă sarcină). În al doilea rând. în patru cazuri din zece estimați supraestimate cel puțin de două ori (încă o dată se uite la graficul: de evaluare, cu o probabilitate de 0,9 este de două ori estimarea probabilității de 0,5). Apoi, pe tine stropiți de acuzații de reasigurare și de echipa dvs. - în timpul șederii de la locul de muncă.
Mult mai bine este modul de a face față incertitudinii propriei sale arme - teoria probabilității. Există multe metode de estimare probabilistice, dintre care cele mai cunoscute (din numărul de mențiuni din manuale) este metoda PERT. și cea mai fiabilă (în experiența mea personală) este Practice Planning Poker. Deși aderenții Agile, cel mai probabil, nu se gândesc la mecanismele probabilistice inerente acestei metode, ci pur și simplu iau și fac.
Planificarea pokerului oferă estimări surprinzătoare de precise. De fapt, cu ajutorul ei luăm în considerare în următoarea evaluare experiența colectivă de rezolvare a tuturor problemelor anterioare și a principalelor riscuri. Dar cu succes se poate aplica doar o echipă bine coordonată de dezvoltatori experimentați (citiți: Agile-Team).
O modalitate radicală de a rezolva problema este teoria constrângerilor. Metoda critică a lanțului presupune o respingere completă a estimărilor cu o probabilitate ridicată. În schimb, se propune estimarea sarcinilor individuale cu o probabilitate de aproximativ 0,5, stabilirea unei rezerve temporare generale pentru întregul proiect.
Dar acesta este un mod cu adevărat radical. Pentru a face acest lucru, trebuie să schimbați cultura de proiect a organizației.
Pauză. Citește din nou, încet, gândindu-te la sensul: vrei să schimbi cultura de proiect a organizației.
Încercați să estimați câte persoane din compania dvs. își construiesc munca în jurul modelului de "estimări corecte". Departamentul de Asigurare a Calității planifică testarea, pe baza timpilor de finalizare preconizați ai dezvoltărilor de dezvoltare. departamentul de vânzări încorporează aceste estimări în acord cu clientul, dar contractul nu mai este denumit „estimări“, și „timpul de livrare“. Departamentul de marketing anunță data lansării următoarei versiuni a "ucigașului concurenților" în comunicatul său de presă. Și sub toate acestea, cel mai mare sef abordează.
Și acum imaginați-vă că îi spuneți tuturor acelor oameni: "Din ziua de mâine vom da toate estimările cu o probabilitate de 0,5".
Nu, nu vor înțelege. Spui așa: "De mâine vom îndeplini numai jumătate din promisiunile noastre în termeni".
Ce veți auzi în schimb va fi chintesența culturii proiectului a organizației dvs.
Trimiteți-le prietenilor: