Padroneggiare gli indicatori DORA: una guida pratica alla distribuzione del software

Padroneggiare gli indicatori DORA: una guida pratica alla misurazione e al miglioramento della distribuzione del software

6 minuti di lettura

freya fusion

Misurazione degli indicatori DORA

Raccolta dei dati: manuale vs. automatizzata

La raccolta automatizzata dei dati è il modo migliore per evitare metriche imprecise che potrebbero portare a decisioni aziendali errate. Tuttavia, l'automazione di ogni parametro coinvolto nel calcolo di una metrica potrebbe non essere possibile a causa di alcuni vincoli. In tali casi, è opportuno concordare un approccio manuale che sia ragionevole e in linea con gli standard del settore.

Tempi di consegna:

Misurato in base al tempo impiegato da una funzionalità per passare dalla fase di richiesta aziendale a quella di produzione. È possibile misurarlo utilizzando diversi strumenti in ogni fase.

Automatizzare i test e le distribuzioni(pipeline CI/CD).
Ridurre le dimensioni dei lotti(modifiche più piccole e più frequenti).
Migliorare i processi di revisione e approvazione del codice.
Monitorare i colli di bottiglia(ad esempio, QA lunghi, approvazioni manuali)

Metodo manuale:

Qualora non fossero disponibili gli strumenti o i plugin necessari per il calcolo automatico del lead time, è possibile ricorrere a un approccio manuale. È possibile calcolaremanualmente il lead timein Azure DevOps (ADO) o in sistemi simili utilizzando estratti di dati grezzi. Ecco una procedura dettagliata:

Estrazione dei dati

Fonte: Query degli elementi di lavoro ADO o API.

Ambito di applicazione:

Filtra perfunzionalità/user story contrassegnatecome«Completate» (ovvero, implementate in produzione).

Estratto:

Data di creazione(quando è stata richiesta la voce di lavoro).
Data di chiusura/completamento(quando contrassegnato come "Fatto").

Formula per calcolare il tempo di consegna di una funzionalità/user story:

Tempo di elaborazione ( per articolo) = Data di chiusura - Data di creazione

Formula per calcolare la media a livello di progetto

Tempo medio di consegna = Somma (Tempo di consegna per articolo) ÷ Numero totale di articoli

* Nota: nei casi in cui le attività pianificate vengano create in anticipo, l'indicatore del lead time non rifletterebbe fedelmente la situazione; in tali casi, è possibile utilizzare il tempo di ciclo come indicatore alternativo.

Frequenza di distribuzione:

Calcola il numero di distribuzioni in produzione in un determinato periodo (ad esempio, al giorno, alla settimana o al mese).

Estrazione dei dati:

Utilizza strumenti CI/CD (ad esempio GitHub Actions) per registrare il numero di distribuzioni.

Formula per la frequenza di distribuzione:

Numero totale di implementazioni/Numero di mesi

Formula per calcolare la media a livello di progetto:

Numero di implementazioni del progetto / Numero di mesi

*Nota: in base alla definizione del settore, le distribuzioni di hotfix non vengono conteggiate nel numero totale delle distribuzioni.

Tasso di guasti:

Cosa si intende per "distribuzione non riuscita"?

Rollback (ripristino di una versione a causa di problemi).
Hotfix (correzioni urgenti successive all'implementazione).

Metodo di tracciamento:

Integrare con gli errori di distribuzionedella pipeline CI/CD (ad es. Jenkins, GitHub Actions) per segnalare gli errori.
Utilizzare strumenti di gestionedegli incidenti (ad es. ADO, Jira, ServiceNow).

Formula per calcolare il tasso di insuccesso:

Numero di modifiche non riuscite ÷ Numero totale di modifiche × 100.

Metodo manuale:

Per calcolare il numero di modifiche non riuscite, è possibile utilizzare il numero di segnalazioni di assistenza classificate come«Bug software». Dividendo questo valore per il numero totale di modifiche rilasciate si ottiene il CFR.

Le organizzazioni devono provvedere alla classificazione periodica degli incidenti affinché l'indicatore risulti accurato.

Tempo medio di ripristino (MTTR):

Cosa si intende per "tempo di recupero"?

Inizio:quando viene rilevato il guasto (attivazione dell'allarme).
Fine:quando il sistema è stato completamente ripristinato (ad es. rollback completato, hotfix applicato).

Metodo di tracciamento:

Strumenti di gestione degli incidenti(ad es. ADO, Jira).
Sistemi di monitoraggio(ad es. CloudWatch, Prometheus) per registrare i tempi di risoluzione.

Formula per calcolare l'MTTR:

Somma dei tempi di ripristino ÷ Numero di guasti

Metodo manuale:

È possibile calcolare la somma dei tempi di ripristino sulla base degli incidenti di assistenza classificati come«Bug software». Come numeratore si può utilizzare la differenza in giorni tra la «Data di creazione» e la «Data di chiusura».

Il numero di incidenti classificati come«bug software»può essere utilizzato come denominatore.

Integrazione tra ADO, CI/CD e sistemi di monitoraggio

La raccolta periodica di questi dati e la loro ottimizzazione aiutano le organizzazioni a migliorare l'efficienza dei propri processi di rilascio del software.

Disporre di strumenti e plugin efficaci e integrarli consente di automatizzare la maggior parte di queste attività, generare metriche e prendere le decisioni più appropriate.

Azure DevOps (ADO) fornisce i metadata per l'acquisizione dei dati grezzi necessari al calcolo di queste metriche. Il team DevOps deve effettuare un' attenta valutazione tenendo conto delle future esigenze aziendali.

Strumenti di visualizzazione e dashboard

Azure DevOps (ADO) offre funzionalità di dashboard con questi metadata e widget per acquisire alcune di queste metriche. Tuttavia, per generare metriche accurate è essenziale assicurarsi che metadata aggiornati per ogni elemento di lavoro.

È possibile utilizzare strumenti alternativi come Power BI e Grafana per migliorare la visualizzazione dei dati e la creazione di report destinati agli stakeholder.

Sfide e aspetti da considerare per le organizzazioni

Raccolta dei dati e utilizzo degli strumenti

Integrità dei dati e limiti degli strumenti

Sfide:

Fonti di dati non uniformi:le pipeline DevSecOps attingono dati da strumenti diversi (sistemi CI/CD, scanner, strumenti di tracciamento degli incidenti), causando discrepanze temporali, falsi positivi o lacune.
Distorsione dovuta alla segnalazione manuale:gli indicatori compilati manualmente (ad esempio, le segnalazioni di incidenti) spesso non sono standardizzati, il che distorce le tendenze comel'MTTR(tempo medio di ripristino).

Soluzione:

Garantire la tracciabilità:utilizzare metadata immutabili metadata ad esempio,gli ID delle pipeline di Azure DevOps o i commit Git) per estrarre i dati relativi alle modifiche al codice.
Convalida tramite correlazione tra strumenti:combinare i dati provenienti da SonarQube (qualità del codice), ADO per segnalare le anomalie e gli standard di settore per convalidare i dati delle metriche

Disponibilità di strumenti e plugin

Sfida:

Le organizzazioni potrebbero non avere accesso a strumenti DevSecOps integrati (ad esempio, scanner SAST/DAST, strumenti di monitoraggio delle distribuzioni) oppure avere difficoltà a sostenere i costi delle licenze.

Soluzione:

SfruttaAzure DevOps Marketplaceper i plugin (ad esempio,OWASP ZAP,SonarQube).
Quando il budget è limitato, ricorrete adalternative open source.

Configurazione di ADO per l'acquisizione Metadata

Sfida:

I dati grezzi di ADO (build, release, attività) richiedono un'adeguata etichettatura/collegamento per generare metriche qualiil Lead Timeola frequenza di distribuzione.

Soluzione:

Rendere obbligatori i campi obbligatorinei work item e negli aggiornamenti periodici
Utilizzale viste di ADO Analyticsoi connettori di Power BIper interrogare metadata della pipeline.

Aggiornamenti efficaci relativi alle modifiche dello stato delle attività

Sfida:

Gli aggiornamenti manuali dello stato (ad es. Da "Completato" a "Approvato") causano ritardi nelle metriche comeil tempo di ciclo.

Soluzione:

Automatizza le transizioniutilizzandoi webhookADO oAzure Functions(ad esempio, aggiornamento automatico al momento del merge delle PR).
Mappare gli stati allefasi del DevSecOps(ad esempio, lo stato "Revisione della sicurezza" prima della distribuzione).

Dati insufficienti per generare metriche

Sfida:

I dati sparsi (ad esempio, implementazioni sporadiche, numero ridotto di incidenti per progetto) distorcono le tendenze.

Soluzione:

Definire soglie minime(ad es. «Monitorare solo se >5 casi nella categoria "bug software"»).

Indicatori che non consentono di prendere decisioni

Sfida:

Le metriche di facciata (ad esempio, «MTTR di 120 giorni») non stimolano l'azione.

Soluzione:

Concentrarsi suindicatori orientati ai risultatie supportati da dati sufficienti

Resistenza organizzativa e uso improprio

Resistenza organizzativa

Sfide:

Paura di essere smascherati:i team potrebbero opporre resistenza alle metriche che mettono in luce le inefficienze (ad esempio,unelevatotasso di fallimento delle modifichedovuto a rifiuti per motivi di sicurezza).
Sovraccarico di strumenti:l'introduzione di nuovi strumenti DevSecOps, metadata acquisire e dei plugin (ad es. scanner SAST) può suscitare resistenze se percepita come un elemento di disturbo o superfluo.
Incentivi disallineati:la dirigenza privilegia un indicatore rispetto ad altri. Il solo «lead time» può indurre in errore

Strategie di mitigazione:

I parametri del telaio come strumenti di miglioramento:
- Sottolineare in che modo questi indicatori aiutano l'organizzazione nel lungo periodo e consentono di confrontare o misurare le prestazioni
Indicatori pilota:
- Iniziate con progetti non critici per dimostrarne il valore prima di procedere all'implementazione a livello aziendale e concentratevi su indicatori che offrano un valore aggiunto per l'azienda.

Obiettivi a lungo termine dell'organizzazione vs. risultati derivati dagli indicatori

Sfida:

Disallineamento:l'ottimizzazione degli indicatori a breve termine (ad esempio, il miglioramentodella frequenza di implementazione) può entrare in conflitto con gli obiettivi a lungo termine (ad esempio, la riduzione del debito tecnico, la maturità in materia di conformità).
Metriche di facciata contro creazione di valore:i team potrebbero dare la priorità a metriche che sembrano positive piuttosto che a risultati significativi.

Soluzione:

Mappare le metriche ai temi strategici:

Collegare gli indicatori (ad es.il lead time) agli obiettivi aziendali (ad es. «Tempi di immissione sul mercato più rapidi per i prodotti soggetti a requisiti normativi»).

Sfida:

Insidie legate alle metriche nella definizione della roadmap: concentrarsi eccessivamente su una singola metrica (ad es.l'MTTR) può portare a trascurare problemi sistemici (ad es. un'automazione dei test inadeguata).

Soluzione:

Portafogli metrici ponderati:

Concilia gli indicatori con gli obiettivi a lungo termine dell'organizzazione (ad es. frequenza di implementazione), la stabilità (tasso di fallimento delle modifiche) e i tempi di consegna

Conciliare gli indicatori di performance con la cultura del team

I rischi culturali dell'eccesso di metriche

Sfide:

Paura della misurazione:i team potrebbero percepire gli indicatori come una forma di sorveglianza, il che può causare stress e esaurimento.
Aggirare il sistema:la pressione per raggiungere gli obiettivi (ad esempio,la frequenza di distribuzione) può incentivare l'adozione di scorciatoie (ad esempio, saltare le scansioni di sicurezza).
Soffocamento dell'innovazione:un'attenzione eccessiva agli indicatori può scoraggiare la sperimentazione (ad esempio, il timore che le implementazioni fallite incidanosul tasso di fallimento dei cambiamenti).

Soluzione:

La sicurezza psicologica prima di tutto:
- Sottolinea che gli indicatori sonostrumenti diagnostici, non valutazioni delle prestazioni.
- Promuovere l'importanza di "imparare dagli errori" (ad esempio, analisi post-incidente che miglioranoil MTTR).
Progettazione delle metriche guidata dal team:
- Coinvolgere gli ingegneri nella scelta degli indicatori (ad esempio, lasciare che siano loro a decidere se dare priorità alLead Timeoal Cycle Timerispetto al tasso di fallimento delle modifiche).

Indicatori vs. competenze del team e fabbisogno formativo

Lacune nelle capacità che ostacolano le metriche

Sfida:

I team non dispongono delle competenze necessarie per migliorare gli indicatori chiave (ad esempio,tempi di elaborazionelunghi dovuti alla scarsa familiarità con gli strumenti di sicurezza)

Soluzioni:

Segmentazione basata su metriche di competenza:
- Esempio: monitorare separatamentei tempi di elaborazioneper i team che adottano nuovi strumenti SAST
Formazione «just-in-time»:
- Automatizzare i trigger di formazione (ad esempio, seil tasso di pipeline fallite per motivi di sicurezzaè superiore al 15%, assegnare una formazione modulare).
Indicatori di mentoring:
- Misurare la percentuale di sessioni di pair programmingper favorire la condivisione delle conoscenze.

Indicatori che non tengono conto della crescita del team

Sfida:

Dare troppa importanza agli indicatori di output (ad esempio,la frequenza delle implementazioni) significa sottovalutare lo sviluppo delle competenze.

Soluzioni:

Bilanciare gli indicatori di rendimento e di crescita:
- Abbinarela frequenza di implementazionealla percentuale del team che contribuisce al codice della pipeline.
Indicatori relativi al percorso professionale:
- Esempio: monitorare la percentuale di ingegneri che conducono revisioni di sicurezzaper promuovere il senso di responsabilità.