6_Nando_Storypoints

The podcast episode discusses the origin and misuse of story points in agile software development teams. Story points were initially used to estimate the time required for implementing user stories. However, the use of ideal days and load factors led to confusion and misunderstandings with stakeholders. The main purpose of story points was to determine the amount of work that could be completed in each iteration, not to predict when a story would be ready. The concept of velocity, which measures the average number of story points completed in past iterations, should not be used to compare teams or set unrealistic goals. Estimating and comparing story points between different teams is also problematic, as each team has its own capabilities and pace. Despite these issues, story points can still be useful for generating discussions within the team and promoting reflection on the variability of effort required for different stories. Se avete lavorato in un team di sviluppo software agile, vi sarete probabilmente imbattuti negli story points. In questo episodio parleremo della loro genesi, delle motivazioni alla base della loro introduzione ripercorrendo usi, e purtroppo spesso anche abusi, dagli albori fino ai giorni nostri. Sono Ferdinando Santa Croce e questo è il Reloaded Podcast. Mi piace dire che potrei aver inventato gli story point e se l'ho fatto, ora ne sono dispiaciuto. Inizia così un articolo dalla firma di Ron Jeffries, uno dei padri fondatori di Xtreme Programming e uno tra gli attori del manifesto per lo sviluppo agile del software. Le user stories, come sappiamo, sono un'idea di XP. Nel tempo anche i praticanti di Scrum hanno fatto uso di questo strumento e quando in Scrum si parla di story, si parla normalmente anche di story points, ovvero di quell'unità di misura a strata e a vulsa da una connotazione temporale con cui le storie vanno dimensionate. In XP le storie erano inizialmente stimate, udite udite, in termini di tempo. Sorpresi, vero? Per ogni storia, i team erano soliti indicare il numero di giorni necessari per la loro implementazione. Questi giorni, però, erano giorni ideali, ovvero ipotetiche giornate in cui nessuna interruzione avrebbe distratto le coppie di programmatori dal loro lavoro di sviluppo. Ovviamente, i giorni ideali sono, per l'appunto, ideali. Quelli che i primi team XP facevano era quindi moltiplicare questi giorni ideali per un fattore di carico, che nel caso dei primi storici team XP oscillava intorno al numero 3. Ci volevano in sostanza tre giorni reali per completare una storia stimata 1. Nemmeno in scrittura e raffinamento delle storie, i team parlavano genericamente di giorni, convertendo spesso l'aggettivo ideale. Questo generava confusione negli interlocutori del business, che a un certo punto non capivano come mai dovevano ad esempio aspettare due settimane per ottenere una storia stimata a tre giorni. Così, come racconta Ron Jefferson in persona, sul suo suggerimento, i team hanno a un certo punto smesso di parlare di giorni, iniziando a chiamare genericamente points questi numeri associati alle storie. Ma a cosa servivano questi numeri? È importante sottolineare l'uso per il quale questi story points furono inizialmente concepiti. Lavorando per iterazione, i team avevano bisogno di capire quanta roba poteva essere messa in lavorazione nell'iterazione successiva. Per fare questo serviva una dimensione dell'iterazione, ad esempio una settimana. E serviva una dimensione degli sviluppi richiesti affinché fosse possibile riempire l'iterazione con un carico di lavoro sostenibile. Né troppo tanto, né troppo poco. Questo era in buona sostanza l'utilizzo che si faceva di questo strumento. Il ramarico del buon Ron è dovuto all'uso improprio che è stato fatto nel tempo degli story points. Vediamo insieme alcuni di questi impropri utilizzi. 1. Utilizzare gli story points per determinare quando una storia sarà pronta Ron Jeffries afferma questo. Penso che usare per prevedere quando avremo finito sia, nella migliore delle ipotesi, ingenuo. Nei meeting di pianificazione è prassi comune stilare un elenco di funzionalità essenziali, ragionarci per un po' e poi decidere quali definiranno la prossima release del nostro prodotto. La domanda che scatta automaticamente al termine, ovviamente, è quando sarà pronto tutto questo? La risposta, per dirla con il sbore, è che fare previsioni è molto difficile, soprattutto quando queste riguardano il futuro. Possiamo, nella migliore delle ipotesi, offrire una forchetta temporale. Possiamo di sicuro lavorare per migliorare la nostra comprensione delle richieste e in alcune aree, in alcuni momenti, vale la pena farlo, ma non sono di certo le stime che ci aiutano in questo. Per fare previsioni accurate serve esperienza e per costruire esperienza occorre ripetere, ripetere e ripetere ancora la stessa attività. Ad esempio, un corridore abituale sa dirci quanto tempo impiega per correre 10 km su una pista pianeggiante. Lo fa due volte a settimana da anni. Ma se già provassimo a chiedergli quanto ci metterebbe a fare 10 km in un bosco qualsiasi, lo metteremmo in difficoltà. Qual è il dislivello? C'è un setiero battuto? Ci sono ostacoli? Ha piovuto di recente? Queste potrebbero essere alcune delle domande che ci farebbe, giustamente. La pallata in cui spesso cadiamo è considerare lo sviluppo software come un'attività ripetitiva. Del resto il prodotto è lo stesso e le tecnologie pure. Aggiungere un pezzetto di volta in volta sarà pur prevedibile, no? La questione è che ogni pezzetto è diverso. A volte più, a volte meno, ma sempre diverso. E vorrebbe invedere, quale azienda sarebbe contenta di sviluppare 10 volte la stessa funzionalità? E anche le persone che ci lavorano sono diverse. A volte sono più esperte e a volte meno. I team cambiano assetto nel corso degli anni. Le persone vanno e vengono. A non parlare delle tecnologie. Se proprio vogliamo fare previsioni, servono dati statistici di altra natura. Servono metriche. E purtroppo sono ancora rari i team che ne raccolgono con costanza e disciplina. L'unica metrica usata è spesso la cosiddetta velocity, che può al massimo aiutare il team a riempire con un numero sufficiente di storie la prossima iterazione, ma non certo prevedere una data di consegno. Riassumendo, più che sforzarsi di diventare più bravi a prevedere il futuro, obiettivo che personalmente trovo tanto divertente quanto irraggiungibile, credo sia meglio trovare modi migliori per fornire costantemente piccoli incrementi di valore. Ai nostri clienti garantiamo la capacità di adattamento, l'abilità nel gestire il cambio di priorità nel interno di un backlog concordato, col fine di inserire nel prossimo rilascio il maggior numero possibile di cose buone. Le stime, sia che si tratti di story point, di orsetti gommosi o persino di tempo, ostacolano questo obiettivo. Punto numero due, la velocity, la peggior metrica mai inventata. Si parlava poco anzi di velocity e di come questo dato possa al massimo essere utile per riempire le iterazioni. Quando dico al massimo lo dico perché ad un certo punto, quando il team riesce a suddividere l'attività da svolgere in piccoli bocconi, riempire un'iterazione diventa un mero esercizio di conteggio. Quante story abbiamo fatto mediamente nelle ultime tre iterazioni? Sette? Ok, vorrà dire che alla prossima iterazione ne prenderemo… sette. La velocity, invece, ci conduce spesso in ulteriori trappole. Oltre a paragonare i team, affermando o anche solo pensando che un team con una maggiore velocity sia più efficiente di un altro, porta al rincorso di un valore sempre più alto. Abbiamo fatto 30 punti, ma se ci impegniamo potremo arrivare fino a 50. Ho sentito affermazioni simili più e più volte, e quasi sempre con le migliori intenzioni. Come sappiamo, però, di buone intenzioni, la strecata è la via verso l'inferno. Daroccare la velocity è un attimo, basta aumentare le stime, e quando i team vengono messi sotto pressione iniziano a farlo più o meno intenzionalmente. Fintanto che PO, PM e chi vive ai margini del team non se ne accorge, tutto fila liscio. Ma dopo un po' succede che qualcuno mangia la proverbiale foglia, e lì iniziano i problemi. Si generano fraintendimenti, le persone si sentono prese in giro, e il disagio aumenta ulteriormente. Così come aumentano bug, imperfezioni, a scapito di qualità del prodotto e valore rilasciato. E' forse questo che ci insegna l'agilità? No, la risposta semplice è no, della maniera più assoluta. Terzo punto, sovrapporre stime e risultati reali. Perché? Dobbiamo essere bravi a stimare. Un'altra deplicabile usanza consiste nel verificare se la stima effettuata si è rivelata esatta, confrontando la previsione con l'effettivo risultato ottenuto. E quando la stima si rivela inesatta, quando il team fa meno punti del previsto, ecco che scatta la fatidica frase, DOBBIAMO ESSERE PIÙ BRAVI A STIMARE. Il tema è che le storie poi non nascono per fare previsioni di rilascio, ne abbiamo già parlato. Le storie poi rappresentano la dimensione di una storia, ricavata rapidamente per confronto. La chiave sta nell'individuare le cose più importanti e metterle nella prossima iterazione, stando attenti a mantenere sostenibile il passo. E per fare tutto questo non c'è bisogno di stime. Le stime spesso distraggono il team e il management dallo scopo centrale che è quello di offrire di iterazione in iterazione il maggior valore possibile ai propri utenti. Punto numero quattro, CONFRONTARE GLI STORY POINT TRA DIVERSI TEAM Le aziende che sviluppano prodotti software dispongono spesso di numerosi team. Le competenze all'interno dei team possono essere diverse, ci sono competenze molto verticali e altre più trasversali. In questo scenario alcune storie sono potenzialmente sviluppabili a diversi team. E questo è un bene perché permette di distribuire meglio il carico di lavoro. Può capitare quindi che una storia già stimata da un team venga assegnata ad un altro team. E può capitare che il nuovo team decida di rivedere la stima, spesso aumentandolo. Questo risulta strano agli occhi dei non-tecnici i quali agiscono chiedendo uniformità tra le stime. E qui iniziano i problemi. Ogni team ha le sue peculiarità, le sue capacità e il suo ritmo. Ciò che una persona molto esperta può fare in un giorno potrebbe richiedere due o tre giorni per una persona mediamente preparata. Ciò che un team farebbe in tre giorni potrebbe consumare molto più tempo in un altro team. E questo è normale. Cercare di standardizzare gli story point non è solo inutile, ma spesso risulta dannoso. Il team A fa 50 punti di interazione, il team B solo 30, abbiamo un problema di performance. Questo potrebbe essere il pensiero che scatta nella nostra mente, se non si fa attenzione ad inventare questi generi di ragionamenti. Ma allora, alla fine, ti vedete i story point? Non hanno nessuna utilità? No, io credo che a qualcosa possano servire. Servono sicuramente a generare discussioni all'interno del team. Ogni volta che una persona giudica in modo differente la stessa storia, abbiamo l'occasione per scambiarsi informazioni e risolvere dubbi. Se ci troviamo a lavorare contemporaneamente story di 3 punti e story di 30 punti, abbiamo un'altra occasione per riflettere. Le story tutto uguali sono spesso un miraggio, ma qualcosa si può sempre fare per renderlo almeno confrontabile. Un team che accette e quindi si mette nelle condizioni di lavorare story che vanno ad esempio da 3-8 punti ha sicuramente un vantaggio rispetto a un team che non riesce a limitare la variabilità di impegno richiesto. Parlerei per ora di questo tema, ma purtroppo il nostro tempo è scaduto. Vi ringrazio per l'ascolto, sarò felice di ricevere le vostre considerazioni e di continuare a chiacchierate in altre occasioni. Al prossimo episodio e a presto!