Stima dei tempi necessari per l'aggiornamento di una

Le patch e le versioni minori sono solo rumore. Le versioni maggiori nelle N librerie corrispondono a N picchi: si deve stimare il caso peggiore, non la media.

Gli aggiornamenti delle dipendenze si presentano in due forme che appaiono identiche nell’output del gestore di pacchetti. La prima: una serie di patch e aggiornamenti minori che il team dovrebbe raggruppare, sottoporre alla suite di test e unire in un’unica, noiosa richiesta di pull. Si tratta di una richiesta di tipo 1, talvolta di tipo 2, e l’unico motivo per votarla è confermare che il team concordi sul fatto che sia noiosa. La seconda tipologia: un aggiornamento maggiore che interessa una o più librerie, in cui il changelog presenta una sezione dedicata alle «modifiche che comportano incompatibilità» e il team è tenuto a leggerla. È questa la storia che si nasconde in bella vista. Il team le assegna un voto pari a 3 perché «è solo un aggiornamento» e la rilascia con un voto pari a 13 tre sprint dopo.

Questo non è un aggiornamento del framework. Un aggiornamento del framework è una libreria su cui avete pianificato il lavoro per un trimestre; il team sa che si tratta di un progetto. Un aggiornamento delle dipendenze è invece quel ticket di manutenzione presentato in sordina da qualcuno perché la scansione di sicurezza ha segnalato sei librerie, e nessuno ha letto i log delle modifiche. La trappola sta nella distribuzione: delle sei versioni, quattro sono banali, una riguarda un’esportazione rinominata e una è una riprogettazione completa dell’API. La stima che ne calcola la media è errata in entrambi i sensi.

Ciò che viene detto nella stanza

Ingegnere A: «Sono sei dossi. Due a testa. Tredici in totale.»

Titolo: “Sono tutti minorenni?”

Ingegnere A: «Tre minori, tre maggiori.»

Ingegnere B: «Qualcuno ha letto i log delle modifiche principali?»

Ingegnere A: «…mi lasci dare un’occhiata.»

Titolo: «Non disponiamo ancora di una stima. Abbiamo registrato tre picchi.»

L’introduzione è corretta. Non esiste un unico dato numerico per questa vicenda, poiché non esiste un’unica vicenda. I piccoli intoppi vanno considerati come un insieme a sé stante; ogni intoppo di rilievo costituisce un picco a sé stante finché qualcuno non abbia letto il log delle modifiche e non sappia cosa non funziona.

Domande che vale la pena porsi prima di votare

Quanti aggiornamenti ci sono stati e qual è la ripartizione tra aggiornamenti principali, secondari e patch?
Qualcuno ha letto i log delle modifiche relativi alle versioni principali?
Qualcuna di queste si trova nelle librerie di proprietà del team, anziché in quelle dei fornitori?
Esiste un conflitto di dipendenza transitiva che ne impone il verificarsi simultaneo?
Qual è la procedura di ripristino nel caso in cui uno degli aggiornamenti causi un’interruzione della produzione?
Il team di sicurezza ha una scadenza, oppure si tratta di un debito tecnico?

Se la risposta alla domanda «Qualcuno ha letto i log delle modifiche?» è «no», la stima non è attendibile. Prevedete un picco limitato per ogni aggiornamento significativo, individuate cosa non funziona effettivamente, quindi ricalcolate la stima dell’implementazione sulla base di quanto avete riscontrato.

Non valutate gli aggiornamenti delle dipendenze limitandovi a contare i numeri di versione. Leggete prima i log delle modifiche, poi valutate ciò che avete riscontrato.

Si veda la stima di un aggiornamento del framework per la variante relativa alla versione principale di una singola libreria, nonché gli altri esempi pratici di stima. Avviare una sessione gratuita di Planning Poker dopo che gli spike avranno chiarito quali saranno effettivamente le modifiche.