Stima dei tempi di implementazione di un feature flag

La storia si limita a lanciare il segnale, tralasciando poi le operazioni di pulizia, le metriche e il dispositivo di spegnimento di emergenza.

Un feature flag non è un meccanismo di distribuzione; è un piccolo prodotto. Richiede un’impostazione predefinita, un percorso di sovrascrittura, una traccia di controllo, un kill switch e un piano di rimozione. La maggior parte di questi elementi non è presente nel ticket originale, che solitamente recita semplicemente “inseritelo in un flag”. Quel ticket rappresenta il punto di controllo, non la funzionalità.

Il preventivo deve tenere conto delle fasi di implementazione (1% → 10% → 50% → 100%), dei parametri che determinano se aumentare o ridurre la copertura in ciascuna fase e del ticket di pulizia che rimuove il flag una volta che la funzionalità è definitiva. I team che non pianificano tale operazione di pulizia finiscono per distribuire, nel giro di un anno, un codice pieno di flag obsoleti, il che costituisce di per sé un debito operativo.

Ciò che viene detto nella sala

Backend: “Incorporare la chiamata in un flag: bastano poche righe.”

SRE: «Quale parametro ci indica che l’implementazione sta procedendo male?»

PM: «Per quali coorti verrà attivato per prime il flag?»

Titolo: “Chi provvederà a rimuovere la bandiera una volta raggiunto il 100%, e quando?”

Backend: “Esiste un kill switch indipendente dal flag?”

Domande da porsi prima di votare

• Modalità di implementazione: rampa lineare, basata su coorti o transizione booleana?
• Valore predefinito nel caso in cui il servizio “flag” risulti inattivo: comportamento precedente o nuovo?
• Indicatori che determinano il passaggio da una fase all’altra: cosa si intende per «andare bene»?
• Il percorso del kill switch è indipendente dal sistema di flag?
• Biglietto di rimozione: da creare in anticipo o “lo faremo più tardi”?
• Registro di controllo: chi ha modificato l’impostazione, quando e perché?

La soluzione è la stessa applicabile alla maggior parte delle storie relative al lancio: split suddividere l’implementazione, il lancio graduale e la pulizia in storie separate, e creare il ticket di rimozione prima di dimenticarsi della sua esistenza.

Un flag è un prodotto di piccole dimensioni. Si prega di stimare la fase di avvio, i parametri di gating e la fase di pulizia, non solo la fase di chiusura.

Si veda Stima dell’implementazione graduale di un limite di velocità per lo stesso modello in cui l’implementazione graduale assorbe il carico di lavoro, nonché gli altri esempi di stima concretizzati. Avviare una sessione gratuita di planning poker una volta definite le fasi.