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 CI/CD sono le storie meno ben definite 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 di ampia portata». Dopo tre sprint, la vecchia pipeline è ancora in funzione parallelamente a quella nuova, i due sistemi sono configurati solo parzialmente e ogni ingegnere ha un modello mentale diverso su quale dei due utilizzare. La story non è completata perché non esiste una definizione di «completato»: le pipeline non vengono semplicemente rilasciate, ma 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à del nostro lavoro.”

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

Lead: «Esatto. Quindi avremo finito quando potremo cancellare quello vecchio.»

Ecco qual è la mossa giusta. La “storia” non è “costruire la nuova pipeline” — il team probabilmente l’ha realizzata mesi fa, durante un progetto sperimentale svolto nel tempo libero da qualcuno. La storia è «eliminare la vecchia pipeline». Finché il vecchio sistema di compilazione 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é creazione fornisce al team una definizione di «completato» su cui può esprimersi.

Come affettarlo

Fate un inventario dei processi ancora in esecuzione sul vecchio sistema. Per ciascun processo: cosa occorrerebbe per eliminare la vecchia versione? Ecco una storia. 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 presentare 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 nel modo consueto: 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. La storia che era stata definita «13, rifattorizzazione, grande» era in realtà costituita da quindici «2» e un «3» camuffato.

Domande che vale la pena porsi prima di votare

• Cosa verrà cancellato una volta terminata questa storia?
• Quali lavori dipendono ancora dal vecchio sistema?
• Esiste forse un utente della vecchia pipeline di cui non siamo a conoscenza — un team esterno, 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 lavori 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. Procedete per fasi, valutando separatamente ogni singola rimozione.

Si veda suddivisione orizzontale vs verticale per comprendere perché “costruire il nuovo sistema” rappresenti un asse di suddivisione errato, nonché gli altri esempi di stime effettuate. Avviare una sessione gratuita di planning poker una volta che il team disponga di un elenco delle rimozioni.