Stima dei costi di una riorganizzazione del processo CI/CD
Come valutare la portata di una revisione completa del processo CI/CD: il lavoro sulla pipeline non prevede una demo, pertanto è opportuno suddividerlo in base a ciò che può essere eliminato. Il progetto della durata di un trimestre che si nasconde nel backlog sotto forma di rifattorizzazione.
I lavori sulla pipeline non prevedono una demo. Si raccomanda di selezionare “quali build possono essere eliminate oggi” per mantenere la stima realistica.
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 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 parzialmente e ogni ingegnere ha un modello mentale diverso su quale delle due utilizzare. La story non è completata perché manca 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 sala
SRE: «Dobbiamo abbandonare la vecchia strategia. Due sprint.»
Titolo: “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 quella vecchia.”
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 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 possa esprimersi con un voto.
Come affettarlo
Si effettui un inventario dei processi ancora in esecuzione sul vecchio sistema. Per ciascun processo: cosa occorre per eliminare la versione precedente? Si tratta di una singola attività. Alcuni casi sono banali (il processo era già stato replicato nella nuova pipeline; è sufficiente 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 nel modo consueto: individuate innanzitutto le incognite (questo lavoro presenta utenti di cui non siamo a conoscenza?), quindi valutate 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à costituita da quindici “2” e un “3” camuffato.
Domande da porsi prima di votare
- Cosa verrà eliminato 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, 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 aver eliminato quella precedente?
- Chi è l’autorità in merito all’affermazione secondo cui “il nuovo canale è la fonte della verità”?
- C’è qualcuno che tiene traccia, settimana dopo 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 storia non supera il controllo di idoneità.
I lavori sulla pipeline vengono eseguiti una volta eliminata la vecchia struttura. Proceda per eliminazione graduale; valuti ogni singola rimozione separatamente.
Si veda suddivisione orizzontale vs verticale per comprendere perché “costruire il nuovo sistema” sia l’asse di suddivisione errato, nonché gli altri esempi di stime efficaci. Avviare una sessione gratuita di Planning Poker una volta che il team disponga di un elenco di elementi da eliminare.