Stima dei costi per l’aggiornamento di un framework
Come valutare l’aggiornamento di un framework: perché il passaggio a una versione principale costituisce un progetto, non un ticket, e come suddividerlo in storie di cui sia effettivamente possibile stimare la portata.
Gli aggiornamenti di versione principali non sono semplici ticket. Sono progetti.
Le versioni di patch sono ticket. Le versioni minori sono solitamente ticket. Le versioni maggiori (quelle che comportano modifiche incompatibili, cicli di deprecazione, cascate di dipendenze tra componenti e la dicitura “si consiglia di migrare a…” nel changelog) sono progetti, e il planning poker non è lo strumento adeguato per valutarne la portata complessiva. La story che recita «aggiornamento a React 19» o «Postgres 16» non rappresenta il lavoro in sé; è il contenitore che racchiude il lavoro.
Considerare l’aggiornamento come un’unica stima comporta un unico scenario di fallimento: il team assegna un punteggio di 13, esaurisce il tempo a disposizione nella terza settimana e rilascia un codice parzialmente migrato che presenta i bug del nuovo framework e le convenzioni del vecchio framework. La mossa più corretta consiste nel suddividere l’aggiornamento in una sequenza di storie più piccole, ciascuna valutabile in modo indipendente, con l’aggiornamento stesso come progetto ombrello.
Ciò che viene detto nella stanza
Ingegnere: «Il codemod si occupa della maggior parte del lavoro.»
Introduzione: «La maggior parte di cosa? Cosa non è in grado di gestire?»
SRE: “Tutte le nostre dipendenze supportano già la nuova versione?”
Domanda: “Qual è la nostra strategia di test di regressione per il diff?”
PM: “Dovremo rilasciare qualcos’altro in questo sprint, o questo è tutto?”
Domande da porsi prima di votare
- Quante modifiche che comportano incompatibilità sono state apportate al nostro codice (legga il changelog e le conti)?
- Le dipendenze tra elementi supportano la versione di destinazione, oppure si applica il principio della cascata?
- Codemod o manualmente? Qual è la copertura del Codemod?
- Copertura dei test sulle superfici modificate: è adeguata, oppure è opportuno aggiungere prima dei test?
- Qual è la strategia di ripiego qualora le cose dovessero andare male a metà dello sprint?
- Un PR o più PR? Se più di uno, qual è l’ordine di dipendenza?
Il risultato corretto di questa conversazione è spesso: «Questa non è una story, è un progetto, quindi pianifichiamolo in tal senso», per poi suddividerlo in parti che ciascun membro del team possa valutare rispetto a una story di riferimento.
Non attribuite un unico valore numerico a un aggiornamento di grande portata. Suddividetelo in storie, quindi valutatene le dimensioni.
Si vedano le tecniche di stima per lavori più vaghi o di maggiore entità, nonché la stima di un picco di attività di ricerca per l’indagine che dovrebbe precedere la stima. Si consultino gli altri esempi di stima già elaborati.