Fer estimacions precises de projectes de programari

estimació de projectes de programari

Pixabay

Introducció

L’estimació és senzilla. Malauradament, també és molt necessari. Les empreses utilitzen estimacions per projectar programacions de llançament, prendre compromisos amb els seus clients, decidir si val la pena implementar una característica proposada, fer un seguiment de la velocitat dels equips i prioritzar el treball de manera efectiva. Els executius solen voler saber quan una funció o un lliurament estarà llest per a la producció. Al cap i a la fi, el desenvolupament de programari no és una inversió trivial. Sense estimacions, com faria una valoració el cap de projecte? Si els humans poguessin predir el futur amb precisió, la gent no guanyaria en carreres de cavalls el 2% del temps. L’estimació és el gran enigma. És essencial i necessari que les empreses demanin a la seva gent que faci l'impossible: predir el futur.

En primer lloc, revisem alguns mètodes d’estimació populars (per si us heu perdut part de l’emoció). A continuació, podem veure què significa això per a nosaltres i els nostres projectes.

El model de l’endeví

Aquest model no requereix gairebé cap esforç per produir una estimació. Els estimadors pensen una mica en què s’ha de fer per implementar i provar una característica i, a continuació, llancen un número. Sona molt a "… (llarga pausa)… Ummmmm… 6 setmanes". Aleshores tothom assenteix amb el cap i seguim endavant. Podrien passar una bona estona parlant sobre el que saben dels requisits (que probablement no sigui la imatge completa). Aquesta anàlisi acurada fa que la seva estimació se senti més fiable. Al final del projecte, sempre hi ha una justificació acceptada de per què l’estimació estava tan allunyada de la realitat. Sempre hi ha circumstàncies imprevistes que poden servir de boc expiatori. Sovint a ningú se li ocorre que el model té greus defectes.

Llavors, com podem millorar aquest procés? Ho sé! Podem utilitzar la tècnica de descomposició (és a dir, dividir i conquerir). Aquest enfocament suposa que coneixeu l'abast complet de la característica o projecte a la part frontal. Totes les funcions es divideixen en trossos de mida mossegada. S’estima cada tros (estil d’endeví) i, a continuació, els sumem per obtenir una estimació global de la característica / projecte. Aquest és sens dubte un enfocament més complicat, però sembla millor per dos motius:

• Els trossos de treball més petits solen ser més fàcils d’estimar de manera fiable.
• Tot i que encara hi ha l'oportunitat d'error (+/- una certa quantitat), es suposa que els errors es cancel·laran mútuament quan ho sumeu tot i obtindreu una estimació global més fiable.

El defecte fonamental d’aquest enfocament és que els col·laboradors individuals (les persones que realment fan la feina) subestimen universalment. Encara són significativament millors que els que hi ha a sobre i al seu voltant, però no és un llistó elevat. No sembla que sigui així, perquè tots hem vist casos en què els desenvolupadors es van sorprendre aconseguint alguna cosa abans del previst. Però es tracta d’un punt de dades únic, no d’una tendència. De fet, la gent guanya ocasionalment al casino; gasta diners en un casino cada dia durant un any i tindràs menys diners dels que començaves. Si feu un seguiment de les estimacions i de les dades reals durant un o dos anys, descobrireu que les estimacions són inferiors a la realitat. Tot i que molts empresaris estan absolutament segurs que els desenvolupadors omplen mandrosament les seves estimacions i fan servir el temps addicional per "xapar" o comprovar les seves existències,les dades mostren el contrari. L'estratègia de "cancel·lació" no funciona.

Llavors, ara què? Abandonem el model d’endeví i passem a un enfocament basat en la mida. Resulta que, tot i que els humans som bastant horribles a l’hora d’estimar el temps de realització, en realitat som bastant bons a dir el gran que és alguna cosa. Som especialment bons en la mida comparativa ("és més gran que això, però més petit que allà"). Si pensem en termes de mida o complexitat en lloc de temps, els nostres cervells el processen de manera més fiable. A continuació, podem agafar els valors de mida i calcular el nombre real d’hores del projecte a partir d’una fórmula màgica intel·ligent. I és llavors quan entra en escena el popular model de punts de funció (escenari esquerre).

Anàlisi de punts de funció (FPA)

Per a l’anàlisi de punts de funció, hem d’identificar cinc tipus de coses a la nostra aplicació: entrades externes, sortides externes, consultes externes, fitxers d’interfície externa i fitxers lògics interns (no us preocupeu massa per les definicions; podeu investigar-les més endavant). Cada exemple (una funció) té una complexitat associada (baixa, mitjana o alta). Utilitzem la taula següent per esbrinar quants punts s’assignen a cada funció.

Ara, si sumem els punts per a totes les nostres funcions, podríem obtenir un nombre com ara 457 punts de funció per al nostre projecte. Llavors només necessitem una fórmula per esbrinar el nombre d’hores… Segons el nostre darrer projecte, la nostra “taxa d’entrega” era de 15 punts de funció per persona i mes. Això suposa una feina aproximada de 30 mesos, que hauria de trigar una mica més de dos mesos i mig per al meu equip de 12. Ta-da!

Sens dubte, això és més complex que el nostre model anterior. De fet, hi ha quatre àrees clau de complexitat que cal reconèixer.

1. Els cinc tipus de components no són necessàriament intuïtius i és fàcil oblidar-se de posar alguna cosa a la llista o assignar-la al dipòsit equivocat.
2. La taula que s’utilitza per generar realment els punts de funció conté nombres màgics que requeririen molt d’esforç per validar. Estan calibrats correctament aquests números per generar estimacions fiables per als meus equips?
3. El percentatge de lliurament (una peça crítica del trencaclosques) es calcula en funció de la productivitat del vostre equip. Amb quina freqüència hem de calcular un número nou? En realitat, hi ha molt poca orientació sobre això.
4. Què constitueix una complexitat baixa, mitjana o alta? Com ho definim perquè tothom ho entengui? No és fonamental fer-ho bé per a la precisió dels nostres càlculs?

Hi ha diverses parts mòbils en aquest exemple molt senzill i ni tan sols hem debatut sobre models de complexitat més complicats i les altres dades que poden entrar en joc (per exemple, taxa de cost, taxa de suport, densitat de defectes, etc.). Més parts mòbils significa més possibilitats que es produeixin errors. Estem fent que l'estimació sigui massa complicada ara? No paguem als desenvolupadors per dedicar molt de temps a l'estimació. No puc vendre un pressupost als meus clients. Necessito un programari de treball. Hi ha alguna cosa més per aquí?

Anar àgil

Ara mirem breument el scrum àgil (el suficient per fer una comparació). Com es va dir anteriorment, els humans són terribles a l'hora d'estimar el temps i són bastant bons en la mida comparativa. Aquí teniu un parell de termes per entendre:

• Un sprint: un període de temps en caixa (normalment dues setmanes).

• Història de l'usuari: una obra discreta, preferiblement prou petita per fer-la una persona en un sprint. Això és el que estimem.

L’estratègia més popular és utilitzar una seqüència de fibonacci (0, 1, 2, 3, 5, 8, 13) per fer estimacions. No és lineal: a mesura que puja l’escala augmenta la mida dels buits. La clau és que els buits han de ser prou amplis com perquè no hi hagi motius per discutir sobre diferències insignificants. Un cop superat el 3, la diferència entre el 4 i el 5 o el 7 i el 8 és tan insignificant que no té sentit dedicar temps a resoldre quin és. També funcionaria una seqüència base-2 (0, 1, 2, 4, 8, 16, etc.).

“Però espereu, aquest és només un número. Què vol dir? Quantes hores és un punt? " No es pretén que els punts es correlacionin directament amb les hores, perquè si ho fessin els equips estarien temptats de tornar a estimar en hores i després convertir-los en punts d'alguna manera. Com s'ha comentat anteriorment, la precisió de les nostres estimacions prové de la mida comparativa i no l'estimació del nombre d'hores que trigarà alguna cosa. Si doneu a l’equip la capacitat de pensar en termes d’hores, comprometreu la vostra capacitat d’estimar amb precisió.

Suposem que heu començat amb un exercici de calibratge. Traieu el vostre equip a una habitació i passeu-los per una llista de 10-12 històries d'usuaris. Trieu-ne un de petit però no el més petit i feu-ho primer. Reviseu-lo i anuncieu que aquesta història és un "3". No ho estàs preguntant. Ho estàs dient. A continuació, passa a la història següent. "Si això fos un 3, què és aquest?" Ara l’equip està redimensionant històries en relació amb altres històries. Finalment, tindran una bona idea del que constitueix un “1”, un “2”, etc. No estimen. El temps no importa. Estan dimensionant històries, en relació amb altres històries que ja tenen un nombre. A continuació, podeu posar històries d’exemple per a cada número de la seqüència en un document anomenat regla. Poden utilitzar-ho com a referència si no saben ben bé què és un "5".

Ara aquí teniu la clau. La salsa màgica que fa que funcioni és la "velocitat" (el nombre de punts que un equip pot completar en un esprint de mitjana entre 3-4 esprint). Suposem que el vostre esprint és de dues setmanes i que el vostre equip de vuit persones té una velocitat mitjana de 35 punts. Obteniu 35 punts en 640 hores de treball (8 x 80 hores). Si ens adonem que una característica trigarà uns 100 punts a treballar, ja sé que són aproximadament 6 setmanes de treball i aproximadament 1900 hores. L’equip es dedica molt bé a dimensionar les històries de manera constant i ho aprofiteu per fer la planificació del vostre projecte. Aquest càlcul funciona perquè la durada és constant de sprint a sprint.

Per fer una planificació d'alt nivell a llarg termini, podeu demanar als vostres clients potencials que desglossin les funcions d'alt nivell en històries provisionals d'una sola línia i que hi posin valors puntuals. Hi haurà un grau de precisió perdut, però esteu aprofitant el model que ja entenen. Un camí més precís seria el dimensionament relatiu a nivell de funció. "Aquesta característica és més gran que aquesta característica de 40 punts, més petita que la de 120 punts que hi ha allà i una mica més gran que la característica de 65 punts que acabem de fer". Les històries s'agrupen en "epopeies". Si cada funció és una èpica, al final sabreu quants punts va trigar a completar-la. Conserveu un historial d'això i el podeu utilitzar per a la planificació de la vostra versió.

Conclusió

Actualment hi ha moltes metodologies en ús. Cadascun té pros i contres. D’alguna manera, hem d’esbrinar com maximitzar la precisió de les nostres estimacions per poder prendre bones decisions. Això no vol dir que les nostres estimacions hagin de ser exactes. Només han de ser prou precisos per ser útils. Si no enteneu l'estimació, podeu suposar que les estimacions no eren exactes perquè l'equip no va fer una bona feina. No van fer estimacions correctes o no van executar correctament el projecte. Les batudes continuaran fins que les estimacions millorin. Però les estimacions no s’han d’utilitzar mai com a compromís. És una millor conjectura basada en la informació limitada que tenim actualment. Quan aparegui nova informació, hem de permetre revisar les estimacions. Qualsevol altra cosa espera l’impossible, que és un problema amb el lideratge (no amb l’equip).

L’enfocament de Scrum és molt més senzill que el que veiem a l’anàlisi dels punts de funció. I diria que és molt més fiable que les taules màgiques amb números màgics. S’aconsegueix el màxim rendiment (mínim esforç amb un grau d’exactitud raonablement alt). Des de la perspectiva de l’esforç, no crea un procés de pes pesat perquè els equips l’entenguin i l’utilitzin. L’estimació de l’àgil es pot produir molt ràpidament quan tothom entén els detalls de l’obra que s’estima. Sens dubte, és millor que treure nombres de l’aire. Aprofitar la velocitat fa quelcom molt important: aporta dades històriques al càlcul. Cada esprint, recalculeu la vostra velocitat. Això és fonamental, ja que amb el pas del temps canvia el rendiment. Els equips que utilitzen FPA poden obtenir el seu percentatge de lliurament del seu projecte anterior,que en alguns casos va ser fa uns quants mesos. Probablement ha canviat molt des de llavors. El meu suggeriment és que exploreu Àgil i que realitzeu esforços per comprendre els punts i la velocitat de la història. No us deixeu d’estimar en hores només perquè enteneu això. Crec que us agraireu més endavant.

Enquesta ràpida