Stima dei tempi necessari per una revisione completa del processo CI/CD

Il lavoro sulla pipeline non prevede una demo. Si suggerisce di suddividere il lavoro in base a “quali build possono essere eliminate oggi” per mantenerne la valutabilità.

Le revisioni del CI/CD sono le storie meno ben definite presenti nel backlog. Non presentano alcun risultato visibile per l’utente, nessuna demo, né screenshot che qualcuno possa inserire nelle note di rilascio. Si tratta di un lavoro di natura strutturale: sostituire una pipeline con un’altra, migrare un sistema di build, consolidare tre test runner in uno solo, passare da uno script shell creato ad hoc a un file di workflow adeguato. Il team è consapevole che tale lavoro deve essere svolto. Il team sa anche che richiederà un trimestre e che, dall’esterno dell’organizzazione ingegneristica, quel trimestre risulterà invisibile.

La modalità di fallimento della stima è prevedibile. Il team assegna un punteggio di 13 perché «si tratta di un refactoring, è un lavoro impegnativo». Dopo tre sprint, la vecchia pipeline è ancora in funzione parallelamente a quella nuova, i due sistemi sono configurati solo in parte e ogni ingegnere ha un modello mentale diverso su quale delle due utilizzare. La storia non è completata perché non esiste una definizione di «completato»: le pipeline non vengono «consegnate»; vengono adottate, e l’adozione è una questione distinta dal semplice fatto che «la novità esista».

Ciò che viene detto nella stanza

SRE: «Dobbiamo abbandonare la vecchia strategia. Due sprint.»

Introduzione: “Qual è la definizione di ‘completato’?”

SRE: “…quello nuovo funziona.”

Titolo: “Il nuovo modello è già in grado di svolgere metà dei nostri compiti.”

Backend: “Ma quello vecchio funziona ancora per l’altra metà.”

Lead: “Esatto. Quindi avremo finito quando potremo cancellare quello vecchio.”

Ecco il punto. La “storia” non è “costruire la nuova pipeline”; il team probabilmente l’ha realizzata mesi fa, nel corso di un progetto sperimentale svolto nel tempo libero da qualcuno. La storia è «eliminare la vecchia pipeline». Finché il vecchio sistema di build non sarà stato eliminato, la riorganizzazione non sarà completata; si tratta di un’infrastruttura parallela con tutti i costi e nessun beneficio. Definire la storia come rimozione anziché come creazione fornisce al team una definizione di «completato» su cui può esprimersi.

Come affettarlo

Si effettui un inventario dei processi ancora in esecuzione sul vecchio sistema. Per ciascun processo: cosa occorrerebbe per eliminare la versione precedente? Si tratta di una singola attività. Alcuni casi sono banali (il processo era già stato replicato nella nuova pipeline; basta rimuovere il vecchio file YAML). Altri richiedono un impegno concreto (la suite di test presenta un percorso hardcoded; la fase di distribuzione dipende da una vecchia variabile d’ambiente). Ogni rimozione rappresenta una piccola parte che il team può consegnare e mostrare in una demo. «Abbiamo eliminato il Jenkinsfile per il servizio di autenticazione» è un risultato che può essere presentato in una demo.

Ogni rimozione può essere stimata secondo la consueta procedura: individuare innanzitutto le incognite (questo lavoro presenta utenti di cui non siamo a conoscenza?), quindi stimare la rimozione confrontandola con una rimozione di riferimento già implementata. La maggior parte delle sezioni si attesta su 2 o 3 punti. Quella che era stata definita «13, rifattorizzazione, grande» era in realtà quindici «2» e un «3» sotto mentite spoglie.

Domande da porsi prima di votare

• Cosa verrà eliminato una volta terminata questa storia?
• Quali professioni dipendono ancora dal vecchio sistema?
• Esiste forse un utente della vecchia pipeline di cui non siamo a conoscenza, come ad esempio un team esterno o un’attività pianificata?
• Qual è la procedura di ripristino nel caso in cui la nuova pipeline presenti un regresso dopo l’eliminazione di quella precedente?
• Chi è l’autorità in merito all’affermazione secondo cui «il nuovo canale è la fonte della verità»?
• C’è qualcuno che tiene traccia, settimana per settimana, di quali processi vengono eseguiti sul vecchio sistema e quali su quello nuovo?

Se la risposta alla domanda «cosa viene eliminato?» è «nulla in questo sprint», il team si trova ancora nella fase di infrastruttura parallela e la story non supera il controllo di idoneità.

I lavori sulla pipeline vengono eseguiti una volta eliminata la versione precedente. Proceda per fasi, valutando separatamente ogni singola rimozione.

Si veda la sezione “Suddivisione orizzontale vs verticale” per comprendere perché “realizzare il nuovo sistema” rappresenti un asse di suddivisione errato, nonché gli altri esempi di stime efficaci. Una volta che il team disponga di un elenco delle funzionalità da eliminare, avvii una sessione gratuita di Planning Poker.