Stima dei tempi necessari per l'aggiornamento di una dipendenza

Le patch e le versioni minori sono rumore. Le versioni maggiori nelle N librerie corrispondono a N picchi: si stimi 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.

Non si tratta di un aggiornamento del framework. Un aggiornamento del framework consiste in una libreria per la quale 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 di natura banale, una riguarda un’esportazione rinominata e una rappresenta 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 vengono raggruppati in un unico ticket; ogni intoppo di maggiore entità costituisce un picco a sé stante, finché qualcuno non abbia letto il changelog e non abbia individuato la causa del malfunzionamento.

Domande da porsi prima di votare

• Quanti aggiornamenti sono previsti e qual è la ripartizione tra aggiornamenti principali, secondari e correttivi?
• 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 ciò che effettivamente non funziona, quindi ricalcolate la stima dell’implementazione sulla base di quanto avete riscontrato.

Non valutate gli aggiornamenti delle dipendenze basandovi semplicemente sull’aumento dei numeri di versione. Leggete prima i log delle modifiche, poi valutate ciò che avete riscontrato.

Si veda la stima relativa all’aggiornamento del framework per la variante con versione principale a libreria singola, nonché gli altri esempi di stime già elaborati. Si avvii una sessione gratuita di “planning poker” dopo che gli spike avranno chiarito quali siano effettivamente le modifiche da apportare.