Agile Story Points vs Hours: come stimare meglio lo sviluppo del software

Avvolgere la mente intorno ai processi di sviluppo del software può essere difficile. Quando ti viene in mente un'idea e ti avvicini agli sviluppatori, le prime due cose che chiedi sono quanto costerà l'implementazione e quanto tempo ci vorrà per creare . La stima è uno dei primi passi nello sviluppo di app.

In questo articolo, confrontiamo i due modelli di stima più popolari nello sviluppo di software moderno: punti della storia agili vs ore .

Continua a leggere per imparare a stimare il tempo in Agile, ottenere il succo di entrambi i modelli di stima, comprendere le loro differenze e vedere perché gli sviluppatori potrebbero scegliere l'uno rispetto all'altro.

Le ore sono abbastanza facili da capire e sono state il modello di stima principale nello sviluppo del software per molto tempo. Le ore, note anche come ore uomo o ore di lavoro, sono il numero di ore che uno sviluppatore trascorre sul progetto.

Quindi cosa sono i punti della storia e perché sono emersi se abbiamo già un modello di stima semplice e diretto?

Contenuti:

1. Cosa sono esattamente i punti della storia?
2. Ecco come vengono calcolati i punti storia in Agile
3. Vantaggi della stima nei punti della storia
4. Svantaggi della stima nei punti della storia
5. Vantaggi della stima in ore
6. Svantaggi della stima in ore
7. Riesci a convertire i punti della storia in ore?
8. Punti della storia vs ore: cosa scegliere per lo sviluppo del software?

Cosa sono esattamente i punti della storia?

Gli story point sono un modello di stima relativo nativo di Agile e Scrum. Stimano lo sforzo per costruire un prodotto affrontando tre aspetti dello sviluppo:

• la quantità di lavoro che il prodotto richiede

• la complessità delle caratteristiche del prodotto

• rischi e incertezze che potrebbero influenzare lo sviluppo

All'inizio della valutazione del progetto, gli sviluppatori scelgono la storia utente più piccola e semplice di un prodotto, ad esempio una storia utente di registrazione, e la impostano come storia utente a 1 punto. Questa è la storia di base : una storia utente che verrà utilizzata per i confronti della complessità. A tutte le altre storie utente verrà assegnato un numero di punti storia in base a quanto siano complesse da sviluppare rispetto alla storia di base.

Sembra abbastanza semplice in superficie, ma chi decide il numero di story point in ogni storia?

Ecco come vengono calcolati i punti storia in Agile

Come per le ore, le persone che lavoreranno sul prodotto di solito stimano i punti della storia per lo sviluppo. Tuttavia, il processo di stima è leggermente diverso con i punti della storia.

Per assegnare i punti della storia a una storia utente, sono coinvolti diversi sviluppatori . Dovrebbero essercene almeno due, ma l'azienda può chiedere a tutti i suoi sviluppatori di contribuire giocando a quello che l'industria chiama Planning Poker . Ecco le regole del gioco:

1. Ogni sviluppatore riceve un set di carte Planning Poker.

2. Gli sviluppatori scelgono una storia utente e discutono della sua complessità e dello sforzo di sviluppo necessario.

3. Ogni sviluppatore propone una carta corrispondente al numero di punti che assegnerebbe alla storia.

4. Se le stime dei punti della storia sono le stesse, il numero stimato di punti viene assegnato alla storia.

5. Se i punti della storia suggeriti differiscono, gli sviluppatori discutono la storia dell'utente fino a quando non ottengono un numero di punti approvato dalla maggioranza.

6. Gli sviluppatori scelgono la prossima storia utente.

7. Ripetere i passaggi da 3 a 5.

Quando tutte le nostre attività sono diventate remote, questo processo è stato modificato. Invece di carte e incontri, i punti della storia vengono decisi nelle discussioni online, durante le riunioni Zoom o nei messenger.

Sembra un po' così:

Questo non significa che tutti gli sviluppatori coinvolti nella stima dei punti della trama lavoreranno sul progetto, ovviamente. Ma un vantaggio chiave del sistema dei punti storia è che crea un quadro più o meno universale che può essere utilizzato non solo sul progetto in questione ma anche su progetti futuri con caratteristiche simili.

Ci sono due opzioni usate frequentemente per stimare i punti della storia. Puoi assegnare i punti:

• utilizzando qualsiasi numero intero (1, 2, 3… 13,14,15, ecc.)

• usando i numeri nella sequenza di Fibonacci (1, 2, 3, 5, 8, 13… 55, 89, 144, ecc.)

La sequenza di Fibonacci è un'opzione più conveniente per stimare lo sviluppo in quanto lascia un certo margine per l'approssimazione. Il modello di ordine numerico è un po' troppo preciso per effettuare confronti convenienti.

Durante lo sviluppo e tra i progetti, se la user story risulta essere più o meno complessa di quanto originariamente stimato, i punti story assegnati potrebbero essere modificati.

Vantaggi della stima nei punti della storia

Se il processo di assegnazione dei punti della storia sembra un po' complesso, non lasciarti ingannare. Ci sono vantaggi nella pianificazione della capacità con gli story point.

1. I punti della storia sono indipendenti dallo sviluppatore

I punti storia per ogni storia vengono assegnati da diversi sviluppatori in negoziazione e il motivo è che il numero viene assegnato non solo per un particolare prodotto e uno sviluppatore particolare, ma "in media". Perché questa è una cosa buona?

Le cose accadono. A volte, lo sviluppatore del tuo progetto potrebbe lasciare il tuo progetto ed essere sostituito. Forse si ammaleranno, decideranno di prendere un congedo parentale o un anno sabbatico, o semplicemente lasceranno l'azienda. Forse si riveleranno sottoqualificati o sovraqualificati per il progetto.

Quando vengono sostituiti, un nuovo sviluppatore potrebbe avere una velocità di lavoro diversa , che porterà a una nuova stima delle ore di lavoro necessarie per creare il prodotto.

I punti della storia riducono al minimo questo problema . Assegnati da diversi sviluppatori, forniscono uno sguardo generale su quanto sia complessa una particolare user story. I punti storia funzionano per tutti gli sviluppatori di una determinata azienda. (Tuttavia, tieni presente che le stime degli story point non saranno corrette per aziende diverse.)

2. I punti della storia semplificano il ricalcolo del tempo di sviluppo

Nella stima del tempo Agile con punti storia, i team usano il termine velocità per riferirsi al numero di punti storia rilasciati in un singolo sprint.

Le squadre monitorano costantemente la loro velocità, ed è piuttosto variabile all'inizio. Una squadra può rilasciare funzionalità che valgono cinque story point una settimana e venti story point la successiva. Ma questo è solo all'inizio. Man mano che il progetto avanza, il grafico della velocità si uniformerà .

Con le ore, se un membro del team cambia, ogni attività in cui è coinvolto dovrà essere rivalutata per adeguare le scadenze. Con gli story point, questo non è necessario: il team può modificare la scadenza del progetto dopo lo sprint successivo conoscendo il cambiamento nella velocità complessiva.

I punti della storia valutano le prestazioni del team nel loro insieme , eliminando la necessità di una nuova stima per attività.

3. Gli story point sono utili per monitorare le prestazioni del team

Quando hai team che lavorano su progetti e/o attività simili in momenti diversi, la velocità può facilmente mostrarti i progressi fatti da ogni team. Sono migliorati e di quanto? Quale team o sviluppatore ha difficoltà e potrebbe aver bisogno di ulteriore formazione? Qual è la curva di apprendimento? Forse una squadra diversa si comporta meglio?

Velocity è un ottimo strumento per valutare le prestazioni dei tuoi team non solo sul posto ma continuamente.

4. La stima del tempo di lancio con i punti della storia è più precisa

Tracciando la velocità, il team sa con alta precisione quanti story point possono rilasciare in uno sprint. Anche se il team di sviluppo dell'app impiega del tempo per calcolare la sua velocità, una volta calcolata, la data di lancio stimata è facile da prevedere .

Inoltre, i cambiamenti nei membri del team, nei requisiti o nel numero/complessità delle funzionalità non causano molti problemi con la nuova stima.

5. Puoi riutilizzare i punti della storia per progetti futuri per accelerare la stima

Non è raro che un'azienda sia esperta in una nicchia specifica (o più) e costruisca più di un prodotto con un insieme simile di funzionalità. Dopo aver completato anche un solo progetto stimato in punti storia, gli sviluppatori possono fare riferimento a questa stima per nuovi progetti . Ciò ridurrà il tempo per la stima.

Tuttavia, è importante tenere traccia della velocità per ogni progetto poiché le circostanze possono cambiare.

6. I punti storia migliorano il lavoro di squadra

Tradizionalmente, le società di sviluppo hanno diversi team di sviluppatori, ognuno dei quali lavora su progetti separati. Quando si effettua una stima in ore, è lo sviluppatore che lavora al progetto che effettua una stima. Questa è una buona cosa, in generale, poiché chi sa meglio quanto tempo impiegherà qualcosa rispetto alla persona che lo fa?

Tuttavia, stimare la complessità nei punti della trama offre un'opportunità per gli sviluppatori nello stesso campo di cooperare , cosa che altrimenti accade raramente. Questo tipo di lavoro di squadra offre un'ottima occasione per condividere esperienze e motivarsi a vicenda.

Svantaggi della stima nei punti della storia

C'è sempre il rovescio della medaglia, ovvero come nascono i grandi sistemi. Anche la stima basata sulla complessità ha i suoi svantaggi e ogni team deve decidere autonomamente se superare i vantaggi.

1. I punti storia dovrebbero essere assegnati da più di uno sviluppatore

Il punto di forza del modello dei punti storia è la sua obiettività e valore per le stime future. Ma perché ciò sia vero, la stima deve essere eseguita da più di uno sviluppatore . Per le piccole aziende con un unico team o le aziende in cui c'è un solo specialista in un campo (cioè un solo designer o sviluppatore iOS), gli story point non portano tanti vantaggi. Tali piccole aziende scelgono tradizionalmente le ore lavorative come modello di stima.

2. La stima dei punti della storia richiede un notevole arretrato

Per realizzare il pieno potenziale dei punti della storia, la tua squadra dovrà dedicare una notevole quantità di tempo . Se stai lavorando a un progetto con funzionalità su cui il team non ha mai lavorato in precedenza (o non ha lavorato a tempo pieno), i primi due o tre sprint saranno difficili da prevedere in termini di prestazioni. Certo, più elementi arretrati hanno i tuoi team, più precise possono essere le loro stime a causa dell'abbondanza di dati statistici. Ma i punti della storia non sono un sistema pronto per essere utilizzato immediatamente.

3. I punti della storia sono più complessi per il budget

Gli story point sono ottimi per impostare scadenze precise e date di lancio, che possono essere importanti per gli sviluppatori e per il marketing del cliente. Tuttavia, quando si tratta di stimare i costi di sviluppo dell'app, sono meno convenienti .

Il fatto è che gli sviluppatori trascorrono del tempo su un progetto non solo scrivendo codice (o realizzando progetti o testando). Un po' di tempo viene speso per la ricerca, la discussione - all'interno del team e con il cliente - per apportare modifiche, ecc. Il tempo speso per stimare i punti della storia è anche tempo speso per il progetto, ma non è incluso nei punti per storia.

Il budget durante la stima in punti storia è possibile, ma di solito è più veloce e più facile equiparare il denaro al tempo speso per il progetto.

4. La velocità è calcolata per squadra

Ciò significa che se i team si mescolano tra i progetti, dovrai calcolare separatamente la velocità per ciascuna combinazione di sviluppatori. Pertanto, la stima per un team non sarà necessariamente vera per un altro team e anche la modifica di un singolo membro del team può potenzialmente invalidare le stime precedenti.

D'altra parte, puoi utilizzare la stima della complessità per trovare le combinazioni più performanti. Ci vorrà tempo, però.

Vantaggi della stima in ore

Sebbene alcuni team Agile utilizzino gli story point, molti devono ancora passare dall'orario di lavoro. Ci sono ragioni importanti per questo. Copriamo anche loro.

1. Le ore sono un modello familiare

L'innovazione è grande, ma ci vuole tempo. Sia gli sviluppatori che i loro clienti sono esperti nella stima delle ore lavorative. Per molti, l'idea è "se non è rotto, non aggiustarlo". Finché il sistema offre stime praticabili, perché passare a qualcos'altro?

La differenza nella precisione delle stime potrebbe non essere abbastanza grande da consentire ad alcuni sviluppatori di modificare il modo in cui fanno le cose.

2. I clienti di solito pagano per ore

Questo richiede poca elaborazione. Per i clienti, la stima basata sulla complessità potrebbe creare confusione . Inoltre, se per il cliente il budget è più importante della data di lancio (che spesso è), gli story point non saranno rilevanti per lui.

3. La stima basata sulle ore può essere eseguita da uno sviluppatore

Per piccoli team o liberi professionisti, gli story point sono in gran parte inutili, poiché richiedono più punti di vista. Senza alcun riferimento, la stima in punti della trama è una seccatura inutile.

Le ore, invece, offrono allo sviluppatore che lavora al progetto un modo per fare autonomamente delle stime abbastanza precise .

Lo stesso vale per la velocità di squadra. Quando i team cambiano ogni volta, come accade con i liberi professionisti o l'outsourcing parziale, il monitoraggio della velocità ha ben poco senso. La stima basata sulle ore è la scelta migliore qui.

Svantaggi della stima in ore

Ecco i motivi per cui i team potrebbero decidere di smettere di usare le ore come modello di stima.

1. Essere l'unico responsabile della stima è un sacco di pressione

Da un lato, stimare il tuo fabbisogno di tempo può essere più semplice, poiché fai affidamento solo su te stesso.

D'altra parte, se non riesci a fornire le tue stime, è un duro colpo. A maggior ragione se il team in attesa di iniziare i propri compiti dipende dal fatto che tu completi i tuoi.

Inoltre, lo stress causato dalla pressione per mantenere ciò che tu stesso hai promesso può interrompere un'attività che altrimenti procede bene.

2. La stima di uno sviluppatore è sempre meno precisa di quella di un team

Le stime individuali sono soggettive e legate alle circostanze emotive e psicologiche dello stimatore.

Alcuni sviluppatori tendono a sopravvalutarsi e a fissare tempi che in seguito faticano a rispettare. Ciò non solo interrompe lo sviluppo (e comporta costi aggiuntivi per il team in caso di multe), ma provoca anche stress e esaurimento negli sviluppatori .

Altri sottovalutano le proprie capacità , prolungando lo sviluppo più di quanto oggettivamente necessario. L'insicurezza e l'abitudine di pensare troppo, controllare e ricontrollare il lavoro spesso portano a scadenze di sviluppo fissate a date successive e le attività raramente vengono completate prima delle scadenze . L'input del team consente una stima più obiettiva.

3. Più grande è il compito, più difficile è stimare in ore

Ciò è correlato anche a situazioni di non sviluppo. È facile dire quanto tempo ci vorrà per leggere un libretto universitario di tre pagine, ma più difficile stimare quanto tempo ci vorrà per finire Guerra e pace .

Lo stesso vale per lo sviluppo. Le piccole attività sono facili da stimare per gli sviluppatori con una certa esperienza. Tuttavia, più grande è il compito, più cose - che accadono sia all'interno che all'esterno del progetto - possono influenzare lo sviluppo. Le stime basate sulle ore non offrono i margini che hanno i punti della storia, rendendo le stime più approssimative.

4. Poca flessibilità

La stima basata sulle ore è basata sugli sviluppatori. Se un membro del team che lavora sul prodotto cambia a metà del progetto, il team dovrà ricalcolare ogni user story interessata ancora in fase di sviluppo o pianificata per gli sprint futuri. Può essere molto lavoro, a seconda della fase in cui si trova il progetto e della differenza di competenze tra lo sviluppatore originale e quello nuovo. La stima del tempo basata sulle ore è piuttosto rigida.

Riesci a convertire i punti della storia in ore?

I clienti possono chiedere a un team che effettua stime in story point di convertire la mappatura degli story point Agile in ore . La maggior parte delle persone che non hanno familiarità con le ultime tendenze di sviluppo del software non sapranno cosa pensare dei punti della storia.

Tuttavia, quando un cliente chiede quante ore equivalgono a un punto della storia, è impossibile rispondere in modo definitivo. Uno dei componenti chiave della stima basata sulla complessità è lo sforzo speso per completare la storia. Ma lo sforzo non si traduce direttamente in tempo speso . Le ore affrontano l'incertezza in un modo più vago rispetto ai punti della storia.

Più il compito è complesso, maggiore è l'incertezza e i rischi. Convertire i punti della storia in ore in modo semplice e fare affidamento solo sulla velocità non tiene conto di molti di questi rischi, poiché la stima basata sulle ore è più approssimativa rispetto ai punti della storia quando si tratta di rischi e incertezze.

In una certa misura, l'uso della sequenza di Fibonacci nell'assegnazione dei punti della trama terrà conto dell'incertezza nei tempi di sviluppo, ma non consente esattamente una conversione diretta.

Ecco un esempio.

Una storia a punti di 1 piano (storia di base) richiede, diciamo, due ore per essere completata.

Una storia di 13 piani potrebbe richiedere 26 ore nel migliore dei casi, se nulla va storto o si mette di mezzo. Ad esempio, se l'API utilizzata si adatta perfettamente, da endpoint a endpoint. Ma se non lo fa, la storia potrebbe richiedere tra, diciamo, 30 e 50 ore, a seconda di quante discrepanze ci sono. Nessuno può dire in anticipo come andrà se lo sviluppatore non ha ancora lavorato con l'API in questione.

Quindi, nel tradurre i punti della storia in ore, deve esserci un moltiplicatore per la crescita esponenziale per affrontare l'incertezza. E quel moltiplicatore sarà diverso da una squadra all'altra.

Punti della storia vs ore: cosa scegliere per lo sviluppo del software?

Come puoi vedere, sia i punti della storia che le ore sono scelte valide per uno sviluppatore per stimare i progetti.

Tutto sommato, diremmo che più aziende di prodotto scelgono i punti della storia mentre i fornitori di servizi esterni tendono a preferire le ore.

Le aziende che lavorano con un modello a prezzo fisso di solito scelgono una stima basata sulle ore. I team che preferiscono Scrum spesso scelgono i punti della storia, poiché sono letteralmente nati da Scrum e sono nativi di questa metodologia.
Nei nostri anni di esperienza, siamo arrivati ​​a vederla in questo modo:

• Se stimare accuratamente la data di lancio è più importante che adeguare il budget, cerca i punti della storia.

• Se il budget è più importante di una data di lancio precisa, considera le ore.

O, soprattutto, combinare i due.

I punti della storia sono molto convenienti per i team di sviluppo che lavorano su progetti lunghi in cui la velocità di monitoraggio farà la differenza.

Le ore sono importanti per i clienti che si preoccupano di spremere il loro budget. Inoltre, le ore hanno più senso per i progetti a breve termine.

Il sistema basato sulla complessità è ancora abbastanza giovane, così come lo stesso Scrum, ed è ancora in via di sviluppo. La combinazione di entrambi i modelli di stima e l'elaborazione di un sistema per modificare rapidamente ogni punto della storia in ore fornisce i vantaggi di entrambi i modelli riducendo al minimo gli svantaggi.