Su AZ-400 le metriche non sono un esercizio di reporting: sono un requisito di design. La domanda d’esame non è “come aggiungo un widget”, ma “dato questo comportamento che l’organizzazione vuole correggere, quale metrica lo cattura, da quale fonte dati arriva e in quale artefatto la rappresento”. Diamo per acquisiti i meccanismi di base e concentriamoci sulle decisioni di design e sui trade-off, sia in Azure DevOps sia in GitHub.

Scegliere la metrica: il dominio determina la fonte dati

Il primo errore architetturale è scegliere il widget prima della fonte dati. In Azure DevOps il grosso della reportistica passa da Analytics, il servizio che copre work tracking, pipeline, test management e dati di version control. Analytics è una copia curata dei dati, ottimizzata per letture e aggregazioni: non è uno store real-time e introduce fino a 30 secondi di ritardo rispetto alla modifica originale. Questa è una decisione di design, non un dettaglio: Analytics è la piattaforma giusta per trend e retrospettive, mai per l’alerting operativo, che appartiene a strumenti di monitoraggio.

La seconda leva è dove la metrica vive. I widget su dashboard coprono il caso “il team guarda ogni giorno”, gli Analytics views e le query OData il caso “serve una definizione custom o un incrocio fra domini”, Power BI il caso “serve unire Azure DevOps con altre sorgenti aziendali”, con connettori tra cui Analytics views, OData query e OData feed. Regola pratica: si sale di livello solo quando quello sotto non basta, perché ogni report custom è debito di manutenzione.

Terzo vincolo, decisivo negli scenari enterprise: Analytics rispetta i permessi dell’utente autenticato, incluse le area path. Una dashboard “unica per tutti” può quindi mostrare numeri diversi a persone diverse. Se serve un dato di governance omogeneo, la risposta non è un widget di team ma un report pubblicato da una vista con perimetro esplicito.

Cycle time e lead time: cosa misurano davvero

Le due metriche sono spesso confuse, e l’esame gioca proprio su questo. Il lead time è il tempo trascorso da quando un work item viene creato fino a quando raggiunge uno stato della categoria Completed: misura l’esperienza del richiedente, incluso il tempo in coda nel backlog. Il cycle time parte dal primo ingresso in una categoria In Progress (o Resolved) e finisce nella categoria Completed: misura l’efficienza del processo una volta che il team ha davvero iniziato.

La conseguenza di design più importante è che entrambe si appoggiano alle state category (Proposed, In Progress, Resolved, Completed), non ai nomi degli stati. Se un processo custom mappa male i propri stati sulle categorie, le metriche non sono imprecise: sono sbagliate in modo silenzioso. Prima di discutere di target, si valida la mappatura degli stati e delle colonne di board.

Altri comportamenti che vale la pena conoscere prima di promettere numeri a uno stakeholder:

  • Sui work item riattivati il cycle time parte dal primo ingresso in In Progress e finisce all’ultimo ingresso in Completed, includendo quindi anche il tempo trascorso in stato chiuso prima della riattivazione. Il rework non viene nascosto, e un picco anomalo spesso significa proprio questo.
  • I widget Cycle Time e Lead Time sono scatter plot con media, linea di media mobile e banda di deviazione standard. Il valore di design non è la media: è l’ampiezza della banda, cioè la prevedibilità. Una media bassa con deviazione alta è una promessa di consegna che non puoi mantenere.
  • Ogni widget è configurato su un singolo team e su un backlog level o work item type, con periodo rolling (flusso continuo) oppure start date (perimetro fisso, tipico di Scrum e Scrumban). Per confrontare più team il widget non basta: serve un report Analytics.

Il cumulative flow diagram è complementare, non alternativo: non espone valori discreti di lead o cycle time, ma mostra il WIP e i punti in cui il flusso si accumula. La documentazione Microsoft è esplicita sulla correlazione: più WIP significa cycle e lead time più lunghi. Design rule: cycle e lead time per misurare la prevedibilità, CFD per diagnosticare dove il flusso si rompe, WIP limit sulla board come intervento correttivo.

Delivery, testing e security: quando il widget basta e quando no

Sul lato delivery, Azure Pipelines offre report nativi sui run: pass rate con i task che falliscono più spesso, duration con i task più lenti, e il report sui test failure, tutti filtrabili per intervallo di date e per branch. La scelta di design è la granularità: se il problema è “la pipeline è lenta” il duration report identifica il task, se è “non ci fidiamo della suite” servono i test analytics.

Per la vista di rilascio i widget si differenziano per domanda: Deployment status risponde a “in quali ambienti è arrivata questa build e con quale pass rate dei test”, Release Pipeline Overview a “qual è lo stato dei rilasci”, Build History a “quanto sono stabili e lunghe le build”. Il widget Requirements quality mappa invece i requisiti sui risultati di test più recenti: è la risposta agli scenari di compliance.

In ecosistema GitHub la separazione è netta e viene chiesta: le usage metrics di GitHub Actions riguardano i minuti consumati (quindi costo e limiti di piano), mentre le performance metrics riguardano tempi di esecuzione, tempi di coda e failure rate. Il tempo di coda è la metrica che distingue un problema di capacità dei runner da un problema di codice: nessuna ottimizzazione del workflow risolve una coda. Entrambe le famiglie sono consultabili a livello di organizzazione e di repository, con un permesso dedicato per la vista di organizzazione.

Per la security, il security overview di GitHub offre viste tra cui overview dei trend, risk, coverage ed enablement, aggregabili a livello di repository, organizzazione ed enterprise. La decisione è la stessa di sempre: coverage risponde a “quanti repository hanno la protezione attiva”, risk a “quali alert chiudiamo per primi”. Sono due conversazioni con due sponsor diversi.

Time to recovery: la metrica che devi costruire

Il time to recovery è il caso in cui la domanda d’esame è più insidiosa, perché nel catalogo dei widget out-of-box non esiste una voce dedicata. Vanno valutate tre strade, in ordine crescente di fedeltà e di costo.

La più economica è modellare gli incidenti come work item e puntargli contro il widget Cycle Time: da “preso in carico” a “chiuso”. Funziona, a patto di accettare il proxy (il work item chiuso non coincide con il servizio ripristinato) e a patto che il tipo sia presente in un backlog, altrimenti il widget non lo espone.

La strada intermedia è una query OData su Analytics, portata su Power BI, che incroci dati di Boards e Pipelines per una definizione aziendale precisa, per esempio dal run fallito al run di ripristino andato a buon fine. Qui si paga in manutenzione ciò che si guadagna in aderenza al processo reale.

La strada più fedele usa la telemetria di monitoraggio, perché solo lì si osserva il ripristino del servizio dal punto di vista dell’utente. Il compromesso tipico da architetto è ibrido: la definizione autorevole vive nel monitoraggio, e la dashboard di team la richiama con i widget informativi disponibili, tra cui Markdown ed Embedded Webpage per pagine che consentono l’incapsulamento in iframe.

Trappole tipiche d’esame

  • “Il management chiede quanto tempo passa fra la richiesta del cliente e la consegna” → lead time, non cycle time: il cycle time esclude proprio l’attesa in backlog che spesso è il collo di bottiglia.
  • “Il team consegna in media in tempo ma le stime saltano di continuo” → non guardare la media: guarda la deviazione standard sul widget di cycle time e gli outlier, che segnalano problemi di processo.
  • “Bisogna capire in quale fase il lavoro si accumula” → cumulative flow diagram più WIP limit; i widget di cycle e lead time dicono quanto, non dove.
  • “Serve un report che confronti più team e unisca dati di Azure DevOps con una sorgente esterna” → Power BI via Analytics views o OData; i widget Analytics di Boards sono scoped su un singolo team.
  • “Le build sono in coda per ore dopo l’ultimo hiring” → performance metrics di GitHub Actions, non le usage metrics: il problema è capacità dei runner, non consumo di minuti.
  • “Serve un alert immediato quando un servizio degrada” → non è un caso da Analytics, che ha latenza di aggiornamento: appartiene al monitoraggio.
  • “Dimostrare a un auditor che ogni requisito ha test associati” → widget Requirements quality, non il Test Results Trend, che mostra andamenti e non tracciabilità.