Misura il sistema di consegna

Parti dalla decisione da prendere

Un team vuole sapere se l’AI migliora la consegna. Contare le righe generate risponde a un’altra domanda. Definisci il risultato utile e le condizioni di qualità prima di scegliere una metrica.

Per un servizio fittizio di esportazione, il risultato desiderato è consegnare in modo affidabile modifiche accettate con meno impegno totale. Registra preparazione, implementazione, revisione, correzione e attesa. Includi modifiche fallite o abbandonate.

Usa un servizio con un confine chiaro. Unire un sito sperimentale e un servizio critico di pagamento può produrre un numero che non spiega nessuno dei due. Descrivi il contesto prima di confrontare periodi o team.

Usa le definizioni attuali

Il modello attuale di consegna di DORA contiene cinque metriche. Il loro ambito è la prestazione della consegna, non il valore di ogni funzionalità o il contributo individuale. Definizioni delle metriche DORA.

Una dashboard può usare un’altra definizione. Leggila prima di interpretare il risultato. La documentazione attuale dei deployment di Taiga descrive quattro metriche ricavate dai record di deployment del fornitore. La misura del recupero usa un deployment successivo riuscito. Non è una registrazione completa di ogni incidente in produzione. Definizioni Taiga.

Esamina una sequenza fittizia di modifiche

Supponi che un servizio esegua dodici deployment in un mese. Otto consegnano modifiche pianificate. Quattro riparano problemi dei rilasci precedenti. Il conteggio è dodici, ma conta la composizione.

Nel mese successivo, il team esegue dieci deployment: nove modifiche pianificate e una riparazione. Meno deployment possono coesistere con più lavoro utile. Queste cifre illustrano l’interpretazione; non sono un benchmark delle prestazioni.

Esamina anche la distribuzione. Una lunga attesa di revisione può scomparire nella media. Una misura di recupero da un solo guasto è una prova debole dell’affidabilità futura. Riporta il numero di osservazioni e le eccezioni rilevanti.

Associa il flusso alle conseguenze

Usa i segnali del servizio per verificare se i cambiamenti nella consegna influiscono sugli utenti. Una pipeline più veloce non basta se le esportazioni falliscono più spesso. Usa uno SLO adeguato o un’altra misura di risultato ben definita. Indicazioni sugli SLO.

Impegno di revisione e rilavorazioni aiutano a spiegare il risultato. Se l’AI accorcia l’implementazione ma produce diff ampi, la revisione può diventare il vincolo. Se ottenere ambienti richiede giorni, programmare più velocemente può incidere poco sul tempo totale di consegna.

Scegli un miglioramento che affronti il vincolo osservato. Per esempio, fornisci un ambiente di test gestito o riduci le dimensioni di una modifica. Definisci una metrica di qualità di controllo, così il team può rilevare un apparente guadagno di velocità causato da verifiche più deboli.

Mantieni utile la misurazione

Evita classifiche individuali basate sul numero di PR o sul codice generato. Possono premiare la divisione artificiale del lavoro, l’elusione di manutenzione difficile o lo spostamento del lavoro di revisione sui colleghi.

Esamina il risultato con le persone responsabili del servizio completo. Registra cosa è cambiato nello strumento, nella composizione del lavoro, nel team e nell’ambiente. Considera il confronto prima/dopo come una prova con limiti, non una dimostrazione automatica di causalità.

Lo scopo è una decisione successiva migliore. Una piccola misura affidabile che porta a un miglioramento verificato è più utile di una grande dashboard senza significati concordati.

Esercitati con dieci modifiche

Questo dataset fittizio separato registra dieci modifiche pianificate. Tutti gli orari sono UTC nella data indicata. Un campo di correzione vuoto significa che nel dataset non è stata registrata alcuna correzione.

Confronta il tempo tra codice pronto e inizio revisione, poi tra accettazione e rilascio. Individua l’attesa visibile più lunga. Indagane la causa prima di definirla evitabile. Questi orari non misurano l’impegno attivo né indicano quando sia iniziato un incidente. Un rilascio correttivo da solo non dimostra il tempo di recupero da un deployment fallito.

Scarica il dataset fittizio (CSV)