![\"\"](\"https:\/\/staticalmo.com\/wp-content\/uploads\/2024\/11\/StoryPointEstCheatsheet1.png\")
Cos\u00ec come nella matematica esistono le parentesi per spezzettare i problemi, nella metodologia agile si possono spezzare le storie per abbassare i punti. Un punto dibattuto della metodologia agile sta nel come convertire punti in ore-uomo e quanto farle costare al cliente.<\/p>\n
<\/p>\n
PERT, detta anche stima a tre valori<\/h2>\n
Ti presenter\u00f2 una diversa modalit\u00e0, pi\u00f9 statistica e \u201cvecchia\u201d, che, come puoi anticipare, ha i suoi svantaggi. Si potrebbe esagerare dicendo che si tratta di una modalit\u00e0 a prova di bomba<\/i>, perch\u00e9 la modalit\u00e0 PERT veniva usata dal settore militare americano. Oggi usano tecniche pi\u00f9 avanzate come il metodo Montecarlo, ma hanno progetti decisamente pi\u00f9 complessi delle non grandi aziende, che leggeranno questo articolo. Questo articolo si rivolge a PMI, grosso modo come gli altri.<\/p>\n
<\/p>\n
Questa tecnica parte in maniera piuttosto facile: si inizia stabilendo<\/p>\n
a: il numero di giorni, ore, etc. reputato minore per il completamento di un progetto, attivit\u00e0<\/p>\n
b: reputato il pi\u00f9 possibile, verosimile<\/p>\n
c: il massimo<\/p>\n
<\/p>\n
Da cui si costruisce una specie di media M = a+4b+c\/6<\/p>\n
<\/p>\n
Sulle costanti della formula, 4 e 6, ci torniamo dopo perch\u00e9 ci si pu\u00f2 giocare.<\/p>\n
<\/p>\n
E ora viene la parte pi\u00f9 difficile di questo metodo. Con quei numeri si pu\u00f2 costruire una distribuzione in probabilit\u00e0, che risulta un caso particolare di distribuzione beta, a sua volta un caso molto particolare di distribuzione normale.<\/p>\n
Questo ci permette di poter calcolare, ad esempio al 95% di confidenza, entro quanto tempo completeremo il progetto o le attivit\u00e0, in funzione dei numeri decisi all’inizio. <\/b>Aiuta dal punto di vista contrattuale e a non creare dissapori fra dirigente e squadra operativa, che spesso ha da ridire sulle tempistiche stimate<\/i>.<\/p>\n
<\/p>\n
Le costanti<\/h2>\n
Si pu\u00f2 lavorare sulle costanti per fare stime pi\u00f9 difensive, che pesano di pi\u00f9 casi estremi e quindi stime con un intervallo pi\u00f9 ampio. Questo ha particolarmente senso quando poche persone decidono quei 3 numeri di sopra, e quindi possono tenere a bada il loro pregiudizio<\/a> inserendo questo fattore correttivo. Ma se hai una media e grande azienda ed ad un progetto quei numeri vengono decisi da pi\u00f9 di 15 persone, fra dirigenti e dipendenti, il teorema centrale del limite ti viene in soccorso, perch\u00e9 ti semplifica il tipo di distribuzione risultante da questa interazione, producendo una stima meno distorta da possibili casi estremi.<\/p>\n <\/p>\n Per esperienza posso dire che il metodo agile risulta pi\u00f9 pesante dal punto di vista della descrizione della storia, mentre quello PERT dal punto di vista numerico.<\/p>\n <\/p>\n Esistono casi per\u00f2 dove entrambi i metodi falliscono non per la stima ma per come si parte. E non esistono metodi che tengono: serve esperienza. Alla data di scrittura dell’articolo ho registrato 2 casi su oltre 26 dove ho bucato la stima della tempistica.<\/p>\n Un caso aveva a che fare con una variazione in corso d’opera per i dati: avevo fatto l’analisi su X, li ho comunicati al cliente e si \u00e8 accorto che voleva quei risultati su altro. Mi ha detto di ripetere la cosa sui dati Y, non prevista<\/b> inizialmente.<\/p>\n In altro caso una libreria richiedeva una conoscenza molto approfondita della sua documentazione e gli errori di output non puntavano direttamente a quel suggerimento.<\/p>\nConclusioni<\/h2>\n