Fare stime accurate del progetto software

stima del progetto software

Pixabay

introduzione

La stima è semplicemente difficile. Purtroppo è anche molto necessario. Le aziende utilizzano le stime per proiettare i programmi di rilascio, assumere impegni con i propri clienti, decidere se vale la pena implementare una funzionalità proposta, monitorare la velocità dei team e assegnare priorità al lavoro in modo efficace. I dirigenti spesso vogliono sapere quando una funzionalità o un deliverable sarà pronto per la produzione. Dopo tutto, lo sviluppo del software non è un investimento banale. Senza stime, come farebbe una valutazione il project manager? Se gli esseri umani potessero prevedere il futuro con precisione, le persone non vincerebbero alle corse di cavalli il 2% delle volte. La stima è il grande enigma. È essenziale e necessario che le aziende chiedano ai propri dipendenti di fare l'impossibile: prevedere il futuro.

Per prima cosa, esaminiamo alcuni metodi di stima popolari (nel caso in cui ti sei perso parte dell'eccitazione). Quindi possiamo vedere cosa significa questo per noi e per i nostri progetti.

Il modello di Fortune Teller

Questo modello non richiede quasi alcuno sforzo per produrre una stima. Gli stimatori pensano per un po 'a ciò che è necessario fare per implementare e testare una funzionalità, quindi tirano fuori un numero. Suona molto come "… (lunga pausa)… Ummmmm… 6 settimane". Poi tutti annuiscono e andiamo avanti. Potrebbero passare un bel po 'di tempo sul front-end a parlare di ciò che sanno dei requisiti (che probabilmente non è il quadro completo). Questa attenta analisi rende la loro stima più affidabile. Alla fine del progetto, c'è sempre una logica accettata per il motivo per cui la stima era così lontana dalla realtà. Ci sono sempre circostanze impreviste che possono servire da capro espiatorio. Spesso non viene in mente a nessuno che il modello sia gravemente difettoso.

Quindi come possiamo migliorare questo processo? Lo so! Possiamo usare la Decomposition Technique (cioè dividi e conquista). Questo approccio presuppone che tu conosca l'ambito completo della funzionalità o del progetto sul front-end. Ogni caratteristica è suddivisa in piccoli pezzi. Ogni pezzo viene stimato (stile indovino), quindi li sommiamo per ottenere una stima complessiva della funzione / del progetto. Questo è sicuramente un approccio più complicato, ma sembra migliore per due motivi:

• Pezzi di lavoro più piccoli tendono ad essere più facili da stimare in modo affidabile.
• Sebbene ci sia ancora la possibilità di errore (+/- una certa quantità), si presume che gli errori si annulleranno a vicenda quando si sommerà tutto e si otterrà una stima complessiva più affidabile.

Il difetto fondamentale di questo approccio è che i singoli contributori (le persone che effettivamente fanno il lavoro) universalmente sottovalutano. Sono ancora significativamente migliori di quelli sopra e intorno a loro, ma non è un livello alto. Non sembra il caso perché abbiamo visto tutti casi in cui gli sviluppatori si sono sorpresi realizzando qualcosa prima del previsto. Ma questo è un singolo punto dati, non una tendenza. Le persone in realtà vincono occasionalmente al casinò; spendi soldi in un casinò ogni giorno per un anno e avrai meno soldi di quelli con cui hai iniziato. Se monitori le stime rispetto ai valori effettivi per un anno o due, scoprirai che le stime non sono all'altezza della realtà. Mentre molti uomini d'affari sono assolutamente sicuri che gli sviluppatori stanno pigramente riempiendo le loro stime e utilizzando il tempo extra per "placcare oro" o controllare le loro scorte,i dati mostrano il contrario. La strategia di "cancellazione" non funziona.

E ora? Abbandoniamo il modello dell'indovino e passiamo a un approccio basato sulle dimensioni. Si scopre che, mentre gli umani sono piuttosto orribili nello stimare il tempo di completamento, in realtà siamo abbastanza bravi a dire quanto sia grande qualcosa. Siamo particolarmente bravi nel dimensionamento comparativo ("è più grande di quello, ma più piccolo di quello laggiù"). Se pensiamo in termini di dimensioni o complessità piuttosto che di tempo, il nostro cervello lo elabora in modo più affidabile. Quindi possiamo prendere i valori delle dimensioni e calcolare il numero effettivo di ore per il progetto in base a un'elegante formula magica! Ed è allora che entra in scena il popolare modello dei punti funzione (a sinistra del palco).

Analisi dei punti funzione (FPA)

Per l'analisi dei punti funzione, dobbiamo identificare cinque tipi di cose nella nostra applicazione: input esterni, output esterni, query esterne, file di interfaccia esterna e file logici interni (non preoccuparti troppo delle definizioni; puoi ricercarle in seguito). Ogni esempio di quelli (una funzione) ha una complessità ad esso associata (bassa, media o alta). Usiamo la tabella seguente per capire quanti punti vengono assegnati a ciascuna funzione.

Ora, se sommiamo i punti per tutte le nostre funzioni, potremmo ottenere un numero come 457 punti funzione per il nostro progetto. Quindi abbiamo solo bisogno di una formula per calcolare il numero di ore… Sulla base del nostro ultimo progetto, il nostro "tasso di consegna" era di 15 punti funzione per persona al mese. Sono circa 30 mesi persona di lavoro, che dovrebbero richiedere poco più di due mesi e mezzo per la mia squadra di 12. Ta-da!

Questo è certamente più complesso del nostro modello precedente. In effetti, ci sono quattro aree chiave di complessità da riconoscere.

1. I cinque tipi di componenti non sono necessariamente intuitivi ed è facile dimenticare di inserire qualcosa nell'elenco o assegnarlo al bucket sbagliato.
2. La tabella utilizzata per generare effettivamente i punti funzione contiene numeri magici che richiederebbero molto impegno per la convalida. Questi numeri sono calibrati correttamente per generare stime affidabili per i miei team?
3. Il tasso di consegna (un pezzo fondamentale del puzzle) viene calcolato in base alla produttività del tuo team. Quante volte dobbiamo calcolare un nuovo numero? In realtà ci sono pochissime indicazioni su questo.
4. Cosa costituisce una complessità bassa, media o alta? Come lo definiamo in modo che tutti lo capiscano? Ottenere quel diritto non è fondamentale per l'accuratezza dei nostri calcoli?

Ci sono diverse parti mobili in questo esempio molto semplice, e non abbiamo nemmeno discusso di modelli di complessità più complicati e degli altri dati che possono entrare in gioco (es. Tasso di costo, tasso di supporto, densità di difetti, ecc.). Più parti in movimento significano più possibilità che si verifichino errori. Stiamo rendendo la stima troppo complicata adesso? Non stiamo pagando gli sviluppatori per dedicare molto tempo alla stima. Non posso vendere un preventivo ai miei clienti. Ho bisogno di un software funzionante. C'è qualcos'altro là fuori?

Going Agile

Ora diamo un'occhiata brevemente all'agile scrum (quanto basta per fare un confronto). Come affermato in precedenza, gli esseri umani sono pessimi nello stimare il tempo e sono piuttosto bravi nel dimensionamento comparativo. Ecco un paio di termini da capire:

• Uno sprint - un periodo di tempo definito in un riquadro (di solito due settimane).

• User story: un lavoro discreto, preferibilmente abbastanza piccolo da essere svolto da una persona in uno sprint. Questa è la cosa che stiamo stimando.

La strategia più popolare utilizza una sequenza di Fibonacci (0, 1, 2, 3, 5, 8, 13) per le stime. Non è lineare: man mano che si sale la scala, la dimensione degli spazi aumenta. La chiave è che le lacune dovrebbero essere sufficientemente ampie da non avere motivo di discutere su differenze insignificanti. Una volta superato il 3, la differenza tra 4 e 5 o 7 e 8 è così trascurabile che è inutile perdere tempo a capire quale sia. Funzionerebbe anche una sequenza in base 2 (0, 1, 2, 4, 8, 16, ecc.).

“Ma aspetta, questo è solo un numero. Cosa significa? Quante ore è un punto? " I punti non hanno lo scopo di correlare direttamente alle ore, perché se lo facessero, i team sarebbero tentati di tornare alla stima in ore e poi convertirla in punti in qualche modo. Come discusso in precedenza, l'accuratezza delle nostre stime deriva dal dimensionamento comparativo e non dalla stima del numero di ore che qualcosa richiederà. Se dai al team la capacità di pensare in termini di ore, stai compromettendo la tua capacità di stimare accuratamente.

Supponiamo che tu abbia iniziato con un esercizio di calibrazione. Porta il tuo team in una stanza e guidalo attraverso un elenco di 10-12 storie di utenti. Scegline uno piccolo ma non il più piccolo e fallo prima. Rivedilo e annuncia che questa storia è un "3". Non lo stai chiedendo. Stai dicendo. Quindi passa alla storia successiva. "Se fosse un 3, cos'è questo?" Ora il team sta valutando le storie rispetto ad altre storie. Alla fine, avranno un'idea abbastanza chiara di ciò che costituisce un "1", un "2", ecc. Non stanno stimando. Il tempo non ha importanza. Stanno ridimensionando le storie, rispetto ad altre storie che hanno già un numero. È quindi possibile inserire storie di esempio per ogni numero nella sequenza in un documento chiamato righello. Possono usarlo come riferimento se non sono sicuri di cosa sia un "5".

Ora ecco la chiave. La salsa magica che fa funzionare questo lavoro è la "velocità" (il numero di punti che una squadra può completare in uno sprint calcolato in media su 3-4 sprint). Diciamo che il tuo sprint è di due settimane e la tua squadra di 8 persone ha una velocità media di 35 punti. Ottieni 35 punti in 640 ore di lavoro (8 x 80 ore). Se scopriamo che una funzione richiederà circa 100 punti di lavoro dall'inizio alla fine, allora so che sono circa 6 settimane di lavoro e ~ 1900 ore. Il team diventa molto bravo nel dimensionare costantemente le storie e tu lo sfrutti per pianificare il tuo progetto. Questo calcolo funziona perché la durata è coerente da sprint a sprint.

Per fare una pianificazione di alto livello a lungo termine, puoi chiedere ai tuoi lead di suddividere le funzionalità di alto livello in storie interim di battuta e di inserire valori in punti. Ci sarà una perdita di precisione, ma stai sfruttando il modello che già comprendono. Un percorso più accurato sarebbe il dimensionamento relativo a livello di funzionalità. "Questa funzione è più grande di quella da 40 punti, più piccola di quella da 120 punti laggiù e leggermente più grande della funzione da 65 punti che abbiamo appena creato." Le storie sono raggruppate in "epiche". Se ogni caratteristica è epica, alla fine saprai quanti punti ci sono voluti per completare quella funzione. Conserva una cronologia e puoi usarla per la pianificazione del rilascio.

Conclusione

Ci sono molte metodologie in uso oggi. Ognuno ha pro e contro. In qualche modo dobbiamo capire come massimizzare l'accuratezza delle nostre stime in modo da poter prendere buone decisioni. Ciò non significa che le nostre stime debbano essere accurate. Devono solo essere abbastanza precisi da essere utili. Se non capisci la stima, potresti presumere che le stime non fossero accurate perché il team non ha svolto un buon lavoro. Non hanno stimato correttamente o non hanno eseguito correttamente il progetto. Le percosse continueranno fino a quando le stime non miglioreranno. Ma le stime non dovrebbero mai essere utilizzate come impegno. È la migliore ipotesi sulla base delle informazioni limitate che abbiamo oggi. Quando vengono visualizzate nuove informazioni, dobbiamo consentire la revisione delle stime. Qualsiasi altra cosa è aspettarsi l'impossibile, che è un problema con la leadership (non con la squadra).

L'approccio di Scrum è molto più semplice di quello che vediamo nell'analisi dei punti funzione. E direi che è molto più affidabile delle tabelle magiche con numeri magici. Ottiene il massimo rapporto qualità-prezzo (sforzo minimo con un grado di precisione ragionevolmente alto). Dal punto di vista dell'impegno, non crea un processo pesante da comprendere e utilizzare per i team. Il pezzo di stima di agile può effettivamente accadere molto rapidamente una volta che tutti hanno compreso i dettagli del lavoro da stimare. È sicuramente meglio che tirare fuori i numeri dal nulla. Sfruttare la velocità fa qualcosa di molto importante: porta i dati storici nel calcolo. Ad ogni sprint, ricalcoli la tua velocità. Questo è fondamentale, perché nel tempo il throughput cambia. I team che utilizzano FPA potrebbero derivare il loro tasso di consegna dal loro progetto precedente,che in alcuni casi è stato diversi mesi fa. Probabilmente molte cose sono cambiate da allora. Il mio suggerimento è di esplorare Agile e di impegnarsi davvero nella comprensione dei punti della storia e della velocità. Non ricadere sulla stima in ore solo perché è quello che capisci. Credo che ti ringrazierai più tardi.

Sondaggio rapido