Glossario delle metriche di engineering e agile
I termini che i team di engineering usano per pianificare, stimare, misurare e migliorare — definiti in linguaggio semplice, con approfondimenti collegati dove disponibili nei nostri corsi gratuiti e nel blog.
34 termini · 6 sezioni · Pubblicato a luglio 2026
Consegna e Flusso
7 terminiCycle time
Il cycle time è il tempo che intercorre da quando si inizia a lavorare su un elemento fino al suo completamento: il cronometro parte quando qualcuno inizia l'elemento e si ferma quando è completato. Misura l'efficienza interna del team, e la sua variazione conta tanto quanto la media. Un team i cui elementi variano da 3 a 5 giorni è molto più prevedibile di uno che varia da 1 a 30.
Lead time
Il lead time è il tempo totale da quando il lavoro viene richiesto fino alla consegna al cliente. Equivale al cycle time più il tempo di attesa in coda, e le code spesso rappresentano l'80% o più del totale. Il lead time è ciò che i clienti sperimentano; il cycle time è ciò che il team controlla direttamente. Entrambi contano, e i team che vedono solo il cycle time sottostimano drasticamente quanto tempo richiede davvero la consegna.
Throughput
Il throughput è il numero di elementi di lavoro che un team completa per unità di tempo, ad esempio otto funzionalità per sprint. Misura il tasso di output e la capacità di un sistema di consegna. A differenza della velocity, il throughput conta gli elementi completati anziché i punti stimati, il che lo rende una quantità misurata invece che stimata.
Altro: Throughput e Invecchiamento degli Elementi di Lavoro (Fondamenti Kanban)
Limite WIP
Un limite WIP è un tetto al numero di elementi di lavoro che un team consente in corso contemporaneamente. È la pratica kanban più controintuitiva: facendo meno cose alla volta, si completa di più complessivamente, perché la Legge di Little collega direttamente il lead time alla quantità di lavoro nel sistema. I limiti WIP sono esperimenti, non calcoli; inizia da qualche parte e aggiusta.
Legge di Little
La Legge di Little è una relazione della teoria delle code, dimostrata da John Little nel 1961, che afferma che il lead time è uguale al work in progress diviso per il throughput. Per qualsiasi sistema stabile, ridurre il WIP accorcia il lead time senza che nessuno lavori più velocemente. Un team che completa 10 elementi a settimana con 40 in corso impiega in media 4 settimane per elemento; limitare il WIP a 20 dimezza questo tempo a 2.
Altro: La Legge di Little: La Matematica del Flusso (Fondamenti di Kanban)
Blocco
Un blocco è qualsiasi cosa che impedisce a un elemento di lavoro o a una persona di fare progressi: una dipendenza da un altro team, un guasto tecnico, requisiti poco chiari, risorse mancanti o un fornitore esterno. I blocchi non menzionati o poco discussi sono tra i maggiori ostacoli al raggiungimento degli obiettivi di sprint, motivo per cui portarli alla luce è la parte più preziosa di qualsiasi standup.
Debito tecnico
Il debito tecnico è il costo accumulato di scorciatoie nel codice, ogni "lo sistemerò dopo" che non si realizza mai. Come il debito finanziario, matura interessi: il codice disordinato richiede più tempo per essere modificato, nasconde bug e rallenta i nuovi membri del team. Il refactoring continuo è il modo in cui i team riducono il debito prima che si accumuli in una base di codice ingestibile.
Stima e Pianificazione
4 terminiStory point
Gli story point sono un'unità di stima relativa che combina sforzo, complessità e incertezza piuttosto che tempo. Una storia da 5 punti richiede circa il doppio dello sforzo di una storia da 2 punti, ma non necessariamente il doppio delle ore. Le scale comuni includono Fibonacci (1, 2, 3, 5, 8, 13), potenze di 2 e taglie (S, M, L), dove gli intervalli tra i valori forzano una scelta genuina.
Velocity
La velocity è il numero di story point che un team completa per sprint, utilizzata per trasformare stime relative in previsioni. La logica è "il tempo di ieri": un team che ha fatto una media di 25 punti probabilmente ne completerà circa 25 nel prossimo sprint. La velocity è uno strumento di pianificazione, non una metrica di produttività; impostare obiettivi su di essa porta i team semplicemente a gonfiare le loro stime.
Planning poker
Il planning poker è una tecnica di stima in cui tutti stimano un elemento di lavoro privatamente e rivelano nello stesso momento, eliminando l'ancoraggio al primo numero pronunciato. La dispersione è il segnale: un 3 unanime significa comprensione condivisa e si procede, mentre una divisione tra 2 e 13 significa che due persone stanno immaginando lavori fondamentalmente diversi.
Altro: La Stima Minima Utile (Fondamenti di Consegna Software)
Sprint
Uno sprint è un'iterazione di lunghezza fissa di un mese o meno che funge da battito cardiaco di scrum e contiene tutti gli altri eventi scrum. Gli sprint si susseguono senza interruzioni, ciascuno ha un obiettivo di sprint che fornisce focus e ciascuno dovrebbe terminare con un incremento potenzialmente rilasciabile. Una durata costante dello sprint crea ritmo e prevedibilità.
Cerimonie
5 terminiRetrospettiva
Una retrospettiva è una riunione ricorrente del team che esamina come il team ha lavorato insieme durante l'ultimo sprint e produce un piano di miglioramento. I partecipanti sono solo i membri del team, senza stakeholder, e il risultato è un piccolo insieme di miglioramenti attuabili. È il cuore del miglioramento continuo: saltarla significa che il team smette di migliorare.
Standup (daily scrum)
Uno standup, chiamato daily scrum nello scrum, è un evento quotidiano di 15 minuti in cui gli sviluppatori esaminano i progressi verso l'obiettivo dello sprint e adattano il piano per la giornata. È coordinamento, non reportistica: il risultato è un piano aggiornato, e i blocchi emergono qui ma vengono risolti dopo, non durante la riunione.
Standup asincrono
Uno standup asincrono è uno standup che avviene senza una riunione sincrona: gli aggiornamenti vengono generati automaticamente dall'attività già registrata in strumenti come Jira, Linear, GitHub e GitLab, oppure inviati per iscritto secondo i tempi di ciascuno. Il principio è semplice: se il lavoro è già registrato da qualche parte, le persone non dovrebbero doverlo ripetere.
Elemento di azione
Un elemento di azione è un impegno specifico e assegnato a cambiare qualcosa, tipicamente prodotto da una retrospettiva. La maggior parte muore in silenzio: un sondaggio della community PMI ha rilevato che quasi due terzi dei team implementano meno del 25% degli elementi di azione delle loro retrospettive. Ogni elemento abbandonato è una piccola promessa non mantenuta, e abbastanza promesse non mantenute insegnano a un team a smettere di sollevare problemi.
Altro: Perché 2/3 degli Elementi di Azione delle Retrospettive Muoiono
Sicurezza psicologica
La sicurezza psicologica è la convinzione di poter esprimere domande, preoccupazioni, errori o dissenso senza punizioni o umiliazioni. Non significa essere gentili; significa abilitare la franchezza. Il Project Aristotle di Google ha scoperto che la sicurezza psicologica era il fattore predittivo numero uno dei team ad alte prestazioni, più importante del talento individuale.
Altro: Creare Sicurezza Psicologica (Scrum Master Essentials)
Misurazione e Metriche
10 terminiMetriche DORA
Le metriche DORA sono quattro misure delle prestazioni di consegna del software: frequenza di deployment, lead time per le modifiche, tasso di fallimento delle modifiche e tempo medio di ripristino. Provengono dal programma DevOps Research and Assessment alla base della ricerca Accelerate e dei report annuali State of DevOps, che rilevano costantemente che i performer d'élite rilasciano più velocemente con meno fallimenti. Misurate in isolamento, sono strumentazione piuttosto che insight.
Frequenza di deployment
La frequenza di deployment è la metrica DORA che misura quanto spesso un team rilascia codice in produzione. Può essere calcolata automaticamente dalle pipeline CI/CD come GitHub Actions, GitLab CI/CD e Bitbucket Pipelines. Oltre al numero grezzo, è prova di throughput reale: un team che effettua deployment frequenti con qualità stabile sta dimostrando consegna, non solo chiusura di ticket.
Tempo di consegna delle modifiche
Il tempo di consegna delle modifiche è la metrica DORA che misura quanto tempo impiega il codice dal commit all'esecuzione in produzione. Tempi di consegna lunghi di solito risalgono a WIP elevato, dimensioni batch grandi o colli di bottiglia nelle revisioni piuttosto che a codifica lenta, quindi questa metrica si legge meglio insieme ai segnali di flusso già presenti nei dati di gestione del progetto.
Tasso di fallimento delle modifiche
Il tasso di fallimento delle modifiche è la metrica DORA che misura la percentuale di deployment in produzione che causano un fallimento che richiede rimedio. È un segnale di qualità: i picchi spesso correlano con tempistiche affrettate, nuovi contributori o modifiche all'infrastruttura, motivo per cui il numero è più utile quando collegato al contesto dello sprint che lo spiega.
Tempo medio di ripristino (MTTR)
Il tempo medio di ripristino, o MTTR, è la metrica DORA che misura quanto tempo ci vuole per ripristinare il servizio dopo un fallimento in produzione. Un ripristino veloce segnala una forte risposta agli incidenti e una profonda familiarità con il codebase, motivo per cui l'MTTR si legge come un segnale di ownership e operazioni piuttosto che un puro numero di velocità.
Efficacia dello sviluppatore
L'efficacia dello sviluppatore è una misura che indica se il lavoro di un ingegnere crea risultati durevoli, non quanta attività genera. Simyl Flow la valuta attraverso sei dimensioni: Consegna, Flusso, Qualità, Collaborazione, Ownership e Adattabilità. Il punteggio multidimensionale resiste alla manipolazione e la misurazione rimane orientata ai risultati: nessun tracciamento delle battiture, nessuna sorveglianza dell'uso degli strumenti e i profili individuali sono privati per impostazione predefinita.
Produttività dello sviluppatore vs. efficacia dello sviluppatore
La produttività dello sviluppatore e l'efficacia dello sviluppatore sono misure diverse: la produttività conta l'attività (commit, righe di codice, ticket chiusi) mentre l'efficacia misura i risultati, se il lavoro consegnato ha creato valore durevole. La distinzione è importante perché le metriche di attività invitano alla sorveglianza e alla manipolazione, mentre l'efficacia deduce dai risultati invece di tracciare l'uso degli strumenti e favorisce il coaching rispetto al giudizio.
Health score
Un health score è una valutazione da 0 a 100, con voti in lettere da A a F, che riassume la salute dello sprint di un team attraverso le sei dimensioni di efficacia. Il suo compito è chiudere il ciclo di miglioramento: dopo che una retrospettiva cambia il modo in cui il team lavora, il trend dell'health score mostra se quel cambiamento ha effettivamente fatto la differenza.
Legge di Goodhart
La legge di Goodhart è l'osservazione, che prende il nome dall'economista britannico Charles Goodhart, secondo cui "quando una misura diventa un obiettivo, cessa di essere una buona misura". Nell'ingegneria appare come manipolazione delle metriche: puntare alla velocity e le stime si gonfiano; puntare alle storie chiuse e il lavoro viene segnato come completato prima che sia effettivamente fatto. La dashboard rimane verde mentre la consegna soffre.
Altro: I Sette Peccati Capitali delle Metriche di Ingegneria
Metriche di vanità
Le metriche di vanità sono numeri che aumentano senza correlare con i risultati di business: commit al giorno, righe di codice, story point completati, PR unite. Sono allettanti perché facili da raccogliere e producono grafici soddisfacenti, ma creano incentivi perversi e un'illusione di visibilità. Il test: se questo numero raddoppia, il valore di business raddoppia?
Altro: I Sette Peccati Capitali delle Metriche di Ingegneria
Metodi
5 terminiScrum
Scrum è un framework agile leggero per sviluppare prodotti complessi, fondato sull'empirismo: trasparenza, ispezione e adattamento. Definisce tre ruoli (product owner, scrum master, sviluppatori), cinque eventi inclusi lo sprint e la retrospettiva, e tre artefatti. La Guida Scrum è di sole 13 pagine perché scrum è intenzionalmente incompleto: un framework con guardrail, non una metodologia passo-passo.
Kanban
Kanban è un metodo adattivo per gestire il lavoro di conoscenza che visualizza il flusso di lavoro, limita il lavoro in corso ed evolve il processo in modo incrementale. La sua filosofia è "inizia da dove sei": nessun ruolo prescritto, nessun evento richiesto, nessuna iterazione fissa. È nato dal Toyota Production System ed è stato adattato per il software da David J. Anderson negli anni 2000.
Extreme Programming (XP)
Extreme Programming (XP) è una metodologia agile, stabilita dal libro del 1999 di Kent Beck Extreme Programming Explained, che è prescrittiva riguardo alle pratiche di ingegneria dove scrum resta silente: scrivi prima i test, programma in coppia, refactorizza continuamente e integra molte volte al giorno. I suoi cinque valori sono comunicazione, semplicità, feedback, coraggio e rispetto.
Pair programming
Il pair programming è quando due sviluppatori lavorano insieme a una postazione: uno digita (il driver) mentre l'altro osserva, pensa avanti e naviga. La ricerca citata nella letteratura XP rileva che le coppie producono codice con circa il 15% in meno di difetti impiegando solo circa il 15% di tempo in più, effettivamente code review continua più diffusione della conoscenza nel team.
Test-driven development (TDD)
Il test-driven development (TDD) è la pratica di scrivere un test che fallisce prima di scrivere codice di produzione, ripetuta in un ciclo rosso-verde-refactor: scrivi un test che fallisce, scrivi il codice minimo per farlo passare, poi pulisci mentre i test restano verdi. Il TDD è una tecnica di design mascherata da tecnica di testing; il pensiero che produce i test è il punto.
AI e Strumenti
3 terminiMCP (Model Context Protocol)
MCP, il Model Context Protocol, è un protocollo aperto che consente agli assistenti AI come Claude e ChatGPT di connettersi direttamente a strumenti e fonti di dati esterni. Simyl Flow espone 17 strumenti MCP di sola lettura su 8 domini, coprendo standup, retrospettive, metriche e action item, così gli assistenti AI adottati da un team possono verificare se stanno effettivamente aiutando.
Altro: Integrazioni assistenti AI
Workflow exhaust
Il workflow exhaust sono i dati strutturati che i tuoi strumenti esistenti già emettono come effetto collaterale del lavoro normale: cronologia dei commit, revisioni PR, transizioni dei ticket ed esecuzioni delle pipeline CI/CD. Il principio alla base del termine: i dati necessari per misurare la delivery esistono già; il problema non è mai stato la disponibilità, ma il fatto che risiedessero in silos disconnessi dal contesto che li rende significativi.
Ship and stick
Ship and stick è un framework di misurazione che pone due domande su qualsiasi cambiamento nel modo di lavorare di un team, che si tratti di un nuovo strumento, processo o assistente AI: il lavoro è stato rilasciato e ha continuato a creare valore in produzione? I suoi indicatori vitali includono il tasso di rework (revert e hotfix), la traiettoria della qualità nel tempo e la prevedibilità della delivery, letti insieme piuttosto che in isolamento.
Le definizioni sono la parte facile
Sapere cosa significa cycle time non è lo stesso che conoscere il tuo. Simyl Flow calcola queste metriche dagli strumenti che il tuo team già usa e mostra se i tuoi cambiamenti stanno funzionando.