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 voto 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 delle quali possa essere stimata in modo indipendente, con l’aggiornamento stesso come progetto ombrello.
Ciò che viene detto nella sala
Ingegnere: «Il codemod si occupa della maggior parte del lavoro.»
Titolo: “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 è tutto qui?”
Domande da porsi prima di votare
- Quante modifiche che comportano incompatibilità sono state apportate al nostro codice (legga il log delle modifiche 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 ripiegamento qualora le cose dovessero andare male a metà dello sprint?
- Un PR o più? Se più, 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 split suddividerlo in parti che ogni membro del team possa valutare rispetto a una story di riferimento.
Non attribuite un unico numero a un aggiornamento di grande portata. Suddividetelo in “storie”, quindi valutatene le dimensioni.
Si veda tecniche di stima per lavori più vaghi o di maggiore entità, e stima di un picco di ricerca per l’analisi che dovrebbe precedere la stima. Si consultino gli altri esempi di stime già elaborate.