Bentornati a tutti. Oggi vorrei parlarvi di una delle più misteriose parti del mondo degli Agile Framework: gli story point. Sono Giuseppe, sono uno Scrum Master e mi sto specializzando nella gestione di progetti software tramite metodologia Agile. Questo è il mio blog, dove voglio condividere con voi quello che sto imparando dalle mie esperienze, magari possono diventare utili anche a qualcun altro là fuori.
Gli story point sono forse uno degli strumenti più complicati da comprendere e da padroneggiare, forse perché sono proprio un elemento astratto del framework Scrum. In particolare, gli story point non sono un'unità di misura reale e quando si comincia ad utilizzarli tutto il team deve essere coinvolto in questo tipo di attività. Ebbene, gli story point non sono certo essenziali per l'utilizzo di un framework Agile, ma per quanto mi riguarda sono sicuramente uno degli elementi più interessanti.
Perché ne hai bisogno?
Gli story point sono molto utili per stimare la complessità di un lavoro. Con gli story point, il team, lo Scrum Master e il Product Owner possono stimare, e ripeto, stimare, la complessità di un'attività.
Cosa sono?
Non esiste una regola che li definisca. Generalmente sono numeri espressi in una scala numerica che partono da uno e arrivano a 21 secondo la sequenza di Fibonacci: 1, 2, 3, 5, 8, 13, 21. Ad ogni modo, nella mia esperienza, posso dirvi di aver visto e sentito di team che utilizzano la dimensione delle maglie, ad esempio: XS, S, M, L, e così via. Oppure le dimensioni dei calici di birra. In passato ho anche conosciuto un team che utilizzava la scala dei punti a poker per stimare le proprie attività. Onestamente, la fantasia la fa da padrone. Online si trova di tutto, e di solito viene utilizzato lo standard dimensionale con cui il team si trova più a suo agio, che più lo diverte.
Come assegnare gli story point?
A puro titolo di esempio, immaginiamo che la scala scelta sia quella di Fibonacci. Generalmente, prima di assegnare i punti, tutto il team prende visione di quelli che saranno i lavori da fare. Si leggono tutti insieme le storie, cioè le specifiche che il cliente desidera, e se necessario si chiedono spiegazioni al Product Owner. Quando tutto è chiaro, tutto il team inizia ad assegnare dei punti alle attività. Solitamente, per assegnare questi punti, ogni membro del team ha un set di carte in mano con sopra disegnati i numeri da 1 a 21, secondo la sequenza di Fibonacci appunto. A questo punto, ogni membro del team, per ogni attività, sceglie una carta e vota quell'attività pensando a quanto può essere complicata. Attenzione: è importante votare a carte coperte. Quando tutto il team ha finito, le carte vengono scoperte. Sarete sorpresi di scoprire che, anche in questa occasione, senza che i membri del team potessero confrontarsi a vicenda, molti di loro avranno la stessa opinione, avranno votato con la stessa carta.
Cosa succede se uno o più carte sono totalmente differenti dalle altre?
Per esempio, immaginiamo che durante questa fase di valutazione delle attività, un membro del team abbia votato con un 5 e un altro con un 13. Questo è uno dei momenti di confronto più interessanti e importanti di tutto il processo di lavoro. È un momento di confronto perché la persona che aveva lanciato un 13 dovrà spiegare a quella che ha lanciato il 5 come mai pensa che quella attività sia così complicata, mentre la persona che ha lanciato il 5 farà a sua volta la stessa cosa. Questo è un momento molto importante perché aiuta tutto il team a prendere consapevolezza di tutto il lavoro che c'è da fare e permette di evidenziare problematiche o semplificazioni che in quel momento il resto del team non vede. Dopo questo confronto si voterà di nuovo. Se anche questa volta non sono tutti d'accordo, si prenderà la media tra il numero più basso e il numero più alto.
Anche qui, è inutile perdere ulteriore tempo nel cercare di stimare in maniera più precisa possibile una certa attività. In Scrum, come nel resto delle altre metodologie Agile, ogni stima di tempo è una forzatura alla realtà. D'altra parte, nessuno potrà mai prevedere con esattezza tutto quello che si nasconde dietro una certa attività. Per questo le stime vanno prese come tali, e cioè semplici stime. Hanno sì una certa importanza, soprattutto ad alti livelli per il management ad esempio, ma guai a basare tutto il lavoro del team su questo parametro.
Come si vota?
Per votare una certa attività è necessario pensare alla sua complessità. Uso la parola complesso per un motivo. Complesso non vuol dire necessariamente difficile, ma è una parola un pizzico più articolata. Provo a spiegarmi meglio. Possiamo avere quattro tipi di attività:
1. Un'attività che sai bene essere difficile.
2. Un'attività che sai bene essere molto semplice.
3. Un'attività media, che non è né troppo difficile né troppo semplice.
4. Un'attività semplice ma che richiede del tempo per essere completata.
Provo a farvi un esempio. Nello sviluppo dei videogiochi, quando cerchi di comporre un ambiente 3D, hai molti oggetti creati dai modellatori e dai 3D artist che devi posizionare all'interno del tuo ambiente per dargli forma. Ora, questo tipo di attività, posizionare gli oggetti all'interno dell'ambiente, non è un lavoro difficile. Gli oggetti sono già stati creati, lo spazio e i limiti fisici ci sono perché definiti dagli sviluppatori, ma piazzare tutti gli elementi all'interno dello spazio può essere molto complesso. Questo perché posizionare tutti gli elementi può richiedere molto tempo e molta attenzione. Oppure, come dicono in molti, la complessità è un misto tra la difficoltà di portare a termine un certo tipo di attività e quanto quell'attività è noiosa.
Solitamente, per valutare un'attività, può essere molto utile portare all'attenzione dell'intero team alcune attività di esempio: un'attività semplice, un'attività difficile e un'attività noiosa. In questo modo il team è in grado di collocare le attività in esame all'interno del nostro range, certo, sulla scala di Fibonacci.
Ultimo consiglio
Ok, lo so, lo capisco, tutta questa storia può sembrare complicata, ma credetemi, comprendere gli story point in Scrum non è complicato. La cosa veramente complicata da fare invece è abbandonare il classico metodo di valutazione delle attività secondo tempo o giorni uomo. Provate a dimenticarvi di come valutavate prima le attività. Vedrete che dopo un po' di utilizzo, tutto sarà più semplice e vi verrà naturale pensare in termini di story point.
Un ultimo consiglio per voi. Solitamente vedo un errore comune: alcuni team pensano agli story point come al numero di ore necessarie al completamento dell'attività. Questa cosa si legge spesso anche online. I team quindi associano un tot ore per il completamento di un'attività al loro equivalente story point. Che ne so, ad esempio, se una certa attività richiede dieci ore di lavoro per essere portata a termine, loro diranno che l'equivalente punteggio è 8 story point. Se un'attività ne richiede 25 ore per essere portata a termine, avrà un equivalente story point di 13 punti, e così via. Bene, non c'è nulla di più sbagliato. Questa pratica non ha senso. Non usatela, non fatela. Se per qualche motivo preferite stimare una certa attività in ore, allora continuate ad usare le ore e lasciate da parte gli story point. Gli story point sono utili proprio perché le persone hanno difficoltà a stimare in termini assoluti, in particolare è molto difficile stimare il tempo necessario. Noi esseri umani siamo molto più bravi a stimare in termini relativi, e quindi a capire quanto un'attività può essere più complicata rispetto ad un'altra.
Bene, forse qualcuno di voi in questo momento si starà chiedendo: ma se non posso utilizzare il tempo per stimare un'attività, allora come faccio a capire quando quell'attività avrà termine? Proverò a rispondere a questa domanda in uno dei prossimi articoli. La questione è molto interessante e credo debba essere dedicato il giusto tempo per essere approfondita.
Se avete domande o pareri, lasciateli nei commenti. Sarà un piacere aiutarvi a confrontarmi con voi. Grazie per aver letto questo post. Non dimenticate di condividere e, perché no, iscrivetevi al blog. Insieme approfondiremo questo mondo della gestione Agile dei progetti software. Ci vediamo presto. Fino ad allora, ricordate: keep it simple.
Comments