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 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 adatto 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ù onesta consiste nel suddividere l’aggiornamento in una sequenza di storie più piccole, ciascuna delle quali 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: «Dobbiamo rilasciare qualcos’altro in questo sprint, o è tutto qui?»
Domande che vale la pena porsi prima di votare
- Quante modifiche che comportano incompatibilità si applicano 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 — pianifichiamolo in tal senso», per poi split suddividerlo in parti che ciascun 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à elaborati.