17 Metriche Agile importanti di cui il tuo team dovrebbe occuparsi

Le metriche sono state a lungo oggetto di dibattito da parte degli agilisti.

Nonostante il fatto che lo sviluppo agile sia empirico a causa della fornitura continua di software di qualità, gli uffici PMO, i project manager e i clienti richiedono ancora rapporti dettagliati sullo stato come farebbero per qualsiasi progetto basato su cascata. Sebbene le esigenze aziendali siano una delle ragioni per la supervisione, lo stesso sviluppo agile contribuisce a un livello di incertezza che alcune persone vogliono sempre definire.

Nel tentativo di invertire questa tendenza, molti agilisti sostengono che le misurazioni non dovrebbero essere utilizzate affatto e che solo la produzione del software stesso dovrebbe essere considerata il parametro del successo. I fautori di questo approccio sostengono che i team di sviluppo e i project manager giocheranno istintivamente il sistema manipolando le storie degli utenti e le stime in modo tale da produrre una parvenza di alta efficienza e nascondere i problemi reali. Tuttavia, c'è un adagio che afferma ciò che viene misurato, viene fatto.

Il motivo principale per cui si verifica questo gioco è che le organizzazioni fanno troppo affidamento su una o due metriche invece di disporre di una soluzione di metrica completa. In questo articolo, discuteremo le metriche che hanno dimostrato di produrre la migliore intelligenza disponibile su prestazioni, qualità, valore e persino agilità del team. Parleremo anche di alcune metriche di cui potresti non aver mai sentito parlare, basate sulle ultime ricerche e sui casi di studio più innovativi.

A cosa servono le metriche agili?

Le metriche agili vengono utilizzate per tenere traccia dello stato, della qualità, della produttività, dell'efficienza, del valore e persino dell'agilità stessa. Soprattutto, vengono utilizzati per informare le decisioni aziendali. Indipendentemente dal tipo di progetto a cui stai lavorando, la rendicontazione sarà sempre importante sia per gli stakeholder esterni che interni. Le metriche possono influire sulle decisioni a tutti i livelli, dalla gestione del prodotto alla gestione del personale e, in quanto tali, devono essere accurate, informative e imparziali. Prima di immergerci nelle metriche, dobbiamo prima stabilire una base su cui si basano tutte queste misurazioni.

Il triangolo di ferro contro il triangolo agile

Negli approcci basati su piani, le misurazioni erano basate sul vecchio "triangolo di ferro" di portata, programma e costo. Quasi ogni metrica rientra in una di queste tre categorie. Nel mondo agile, questo triangolo è stato capovolto. I progetti sono definiti fornendo valore e qualità entro determinati vincoli. Il budget o il costo è solo uno di questi vincoli, tra gli altri, invece di essere un obiettivo primario per la consegna.

È importante qui comprendere la relazione tra valore e qualità. Molte persone lottano con la definizione del valore. In primo luogo, ci sono due tipi di qualità: intrinseca ed estrinseca.

• La qualità intrinseca si riferisce alla percezione interna del prodotto da parte dei team di sviluppo, test e gestione. Di solito è illustrato con le metriche dei difetti, che descriviamo più avanti.
• La qualità estrinseca è la qualità del prodotto così come viene percepita dall'utente finale. Quanto bene il prodotto si adatta alle loro esigenze e soddisfa le aspettative. Un altro termine per questa qualità estrinseca è valore.

Quindi, è importante capire che la qualità rappresentata nel triangolo agile è una qualità intrinseca o interna dal punto di vista dello sviluppo, mentre il valore nel triangolo è in realtà una forma di qualità estrinseca. Comprendere questa relazione è importante per sviluppare buone misure agili.

17 metriche agili chiave da monitorare

Il seguente elenco di diciassette metriche combina le metriche agili più utilizzate e consolidate nel tempo con misure più recenti basate su ricerche recenti. Il punto chiave qui è che qualsiasi soluzione di metrica agile dovrebbe essere completa.

Affidarsi solo a uno o due non fornirà un quadro completo di ciò che sta accadendo. L'errore più grande che molti manager fanno è concentrarsi troppo su due o tre, o solo su una metrica per l'intero progetto. Alcune organizzazioni non usano altro che velocità o bruciano i grafici.

Che tu ci creda o no, succede. Una buona soluzione metrica dovrebbe coprire tutti e tre i punti del triangolo agile. Questi 17 ti daranno gli strumenti per fare proprio questo e molto altro.

Tempo bloccato

Il tempo bloccato è definito come la quantità di tempo in cui una particolare user story, o talvolta un'attività, viene bloccata. La risoluzione dei blocchi è fondamentale per facilitare il flusso di lavoro in un ambiente agile e questa metrica può aiutare a misurare la quantità di tempo necessaria per risolverli. I bloccanti dovrebbero essere risolti opportunamente.

L'aumento del tempo bloccato potrebbe significare che una user story non è stata scomposta correttamente o che esiste una dipendenza da una risorsa esterna non pianificata. Il tempo bloccato può essere ridotto con una più attenta scomposizione della user story, definizione delle priorità e pianificazione dello sprint.

Slancio commerciale

Molte delle metriche discusse qui sono in circolazione da un po' di tempo. La maggior parte si concentra a livello di progetto, team o WIP (work in progress). Tuttavia, poiché la tecnologia è più integrata nella nostra vita quotidiana e i mercati di tali prodotti diventano iperaccelerati, le organizzazioni sono alla ricerca di metriche più sofisticate in grado di identificare le tendenze del mercato, misurare il miglioramento dei processi, prevedere la concorrenza e, in sostanza, misurare l'agilità. Lo slancio degli affari è uno di quelli. Lo slancio in questo contesto può essere espresso come il totale dei punti della storia per un rilascio moltiplicato per la sua sequenza temporale.

Man mano che un'organizzazione diventa più agile, guadagna slancio con ogni rilascio. I tempi di ciclo tendono ad accorciarsi e le aspettative sulla consegna crescono. Lo slancio aziendale può essere utilizzato per il market timing o come indicatore dello stato di salute di una particolare linea di prodotti o programma. Se lo slancio inizia a diminuire, questo è un indicatore per il management che un particolare mercato sta iniziando a svilupparsi e che è necessario sviluppare una nuova linea di prodotti. Le organizzazioni agili devono cercare continuamente nuovi mercati per rimanere competitive.

Copertura del codice

La copertura del codice è una misura della quantità di codice effettivamente eseguita durante il test. Questo è in genere strumentato e calcolato come parte di una strategia di test automatizzata. La metrica dovrebbe fornire la percentuale complessiva di codice eseguito durante ciascuna fase di test (unità, sistema, ecc.) e il totale di tutte le fasi.

La copertura del codice non deve essere utilizzata in modo improprio come indicatore dell'efficacia del test di un prodotto. Piuttosto, l'obiettivo di questa metrica è facilitare l'automazione dei test e monitorare la consegna continua. Le misurazioni della garanzia della qualità dovrebbero includere una varietà di parametri, non ultimo dei quali sono i casi di difetti discussi in seguito.

Grafico di controllo

A volte indicato come diagramma di comportamento del processo o diagramma di Shewhart, un diagramma di controllo monitora le prestazioni di un processo per determinare se è sotto controllo o fuori controllo, a seconda dei limiti di controllo superiore, inferiore e medio che sono stati impostati.

Questi limiti vengono calcolati stimando la deviazione standard dei dati del campione, moltiplicando tale deviazione per tre, quindi aggiungendola alla media per creare il limite superiore e sottraendola dalla media per creare il limite inferiore. L'asse Y del grafico è il numero di occorrenze o problemi in un particolare campione mentre l'asse X enumera ogni campione. Le carte di controllo sono nate nella produzione come forma di controllo della qualità e sono in circolazione da quasi 100 anni.

Popolare tra i discepoli six sigma, le carte di controllo possono misurare il fallimento o il successo del controllo qualità o di altri processi di produzione. Sebbene non siano rese popolari nel mondo agile, le carte di controllo potrebbero essere utilizzate per misurare i difetti rilevati per iterazione o rilascio per identificare problemi di test di QA o per misurare i tempi di ciclo su una serie di versioni per garantire che rientrino a livelli accettabili.

Diagramma di flusso cumulativo

Un diagramma di flusso cumulativo illustra quanto lavoro, segmentato per tipo, viene assegnato a un team nel tempo. Il suo scopo è monitorare il flusso di lavoro in tutto il sistema. In questo diagramma, il lavoro è suddiviso in diversi tipi, ad esempio: da fare, in corso e terminato. Potrebbe anche essere suddiviso in requisiti, sviluppo, test e così via. Comunque sia segmentato, il diagramma di flusso cumulativo mostra una linea per ogni tipo di lavoro, con il numero di elementi di lavoro sull'asse Y e sull'asse X in funzione del tempo.

Un buon flusso è illustrato da tutte queste linee che corrono in parallelo. Se una delle linee subisce un forte rialzo, o incrocia un'altra, ciò potrebbe indicare un collo di bottiglia. Raggiungere un buon flusso è il concetto centrale dietro il kanban. Il diagramma di flusso cumulativo aiuta a identificare i colli di bottiglia per facilitare il flusso continuo e garantire che WIP non perda il controllo in nessun punto del sistema.

Tempo di ciclo

Il tempo di ciclo può essere definito come il tempo necessario per produrre una versione software, dall'ideazione al completamento. Insieme al lead time e alla velocità, il tempo di ciclo è un ottimo indicatore di alto livello della salute agile e del successo della trasformazione agile. Man mano che un'organizzazione avanza nel suo viaggio agile, i tempi di ciclo dovrebbero diminuire gradualmente, in genere fino a sei mesi o molto meno. L'aumento del tempo di ciclo, soprattutto se osservato in modo coerente su una o due versioni, dovrebbe essere motivo di preoccupazione e revisione.

Epico e rilascio burndown

I grafici di burndown epici e di rilascio sono simili al sempre popolare burndown dello sprint discusso di seguito. Un diagramma di burndown illustra quanto lavoro rimane per un determinato periodo di tempo o, in questo esempio, per una certa epopea. Nello sviluppo agile, un'epica è una storia utente più ampia composta da storie utente più piccole o blocchi di lavoro.

Man mano che il lavoro viene completato, il numero di storie degli utenti nell'epopea viene gradualmente ridotto fino a raggiungere lo zero. Questo può essere utile nei casi in cui devono essere raggiunte tappe fondamentali per soddisfare i requisiti contrattuali e fatturare al cliente. Allo stesso modo, un burndown del rilascio può tenere traccia dell'avanzamento del lavoro impegnato per un rilascio specifico. Questo può essere utilizzato per garantire una consegna puntuale o identificare la necessità di modificare una scadenza in anticipo.

Distribuzioni non riuscite

Una distribuzione non riuscita è quella che si traduce in uno dei seguenti:

• Servizio che influisce sull'interruzione
• Non soddisfa le aspettative dei clienti, spesso con conseguente rifiuto del rilascio.
• Influisce gravemente sull'usabilità, sul funzionamento o sull'esperienza dell'utente del prodotto.
• Risulta in un rollback alla versione precedente.

Ovviamente il tasso di distribuzione fallita, visualizzato come percentuale delle distribuzioni totali, dovrebbe essere ridotto al minimo. Qualsiasi picco in questa metrica dovrebbe essere motivo di preoccupazione. I tassi di modifica e le occorrenze dei difetti dovrebbero essere rivisti per isolare le cause principali.

Tempi di consegna

Il lead time misura il tempo necessario per completare un'attività, dal momento in cui viene creata fino al punto in cui è terminata. In breve, identifica quanto tempo ci vuole per portare a termine le cose. Popolare tra i professionisti del kanban, questa metrica può aiutare a identificare le efficienze per spostare le attività più velocemente attraverso il sistema. Può anche essere utilizzato come metrica di alto livello per determinare l'efficacia della distribuzione continua. Il tempo di consegna, insieme al tempo di ciclo e alla velocità, possono essere utilizzati insieme per fornire una visione olistica delle prestazioni di consegna.

Punteggio netto del promotore (NPS)

Un punteggio netto del promotore ha lo scopo di aiutare a valutare la soddisfazione del cliente. Di solito viene calcolato sulla base dei dati ottenuti tramite un sondaggio. L'obiettivo è scoprire quanti clienti consiglierebbero il tuo prodotto. La percentuale di intervistati che vota "no" viene sottratta dai votanti "sì" per creare il punteggio.

Oltre a misurare la soddisfazione dei clienti, il punteggio netto del promotore può aiutare a identificare i clienti più disposti a collaborare su prodotti o tecnologie innovative per versioni future. Tali clienti possono diventare un vantaggio competitivo poiché il loro feedback e supporto possono aiutare le aziende a immettere nuovi prodotti sul mercato prima della concorrenza.

Intelligenza di qualità

All'inizio dell'articolo abbiamo discusso del triangolo agile e della parte che la qualità gioca in esso. L'intelligence sulla qualità può assumere molte forme, ma in genere è composta da una varietà di metriche di rilevamento dei difetti. I difetti possono essere monitorati in base a dove e quando si verificano, alla loro frequenza e gravità.

Uno dei più popolari è il tasso di fuga dei difetti, che è il rapporto tra i difetti riscontrati dal cliente e il numero totale di difetti scoperti in una liberatoria. Sebbene un numero elevato di difetti debba essere rilevante, indipendentemente da come vengono rilevati, è sempre meglio individuarli prima che lo faccia il cliente.

Bruciare lo sprint

I grafici di burndown dello sprint forniscono una misura giornaliera del lavoro completato e del lavoro che resta da fare in un determinato sprint. Confronta la quantità di lavoro completata con le stime originali. A causa della natura empirica dello sviluppo agile, il valore del diagramma di burndown è piuttosto limitato.

Nonostante la sua popolarità, molti allenatori agili si stanno allontanando dall'usarlo come prima. Può servire come una buona guida o punto di riferimento per dove i team di sviluppo si oppongono ai loro impegni, ma dovrebbe essere usato insieme ad altre metriche per avere un quadro completo di cosa sta succedendo.

Portata

La quantità di prodotto (numero di articoli di lavoro) consegnata al cliente in una determinata unità di tempo viene definita produttività. Questo potrebbe essere misurato mensilmente, trimestralmente, per versione, iterazione e così via. Il valore in questa metrica è che può essere utilizzata per determinare la quantità di software che può essere fornita per un periodo di tempo specifico. Può anche essere utilizzato per tenere traccia della coerenza della consegna dal punto di vista del team e dell'organizzazione.

L'analisi empirica dei dati storici può essere utilizzata per prevedere le prestazioni di consegna. Più dati storici sono disponibili, più accurate saranno le proiezioni. Soprattutto, questa metrica può essere utilizzata anche per prevedere le entrate, dato che il valore della funzionalità fornita è ben compreso in termini finanziari. Affinché questa metrica funzioni, la definizione di "fatto" deve essere ben definita. Solo il software consegnato al cliente soddisfa questo requisito.

Valore consegnato

All'inizio dell'articolo abbiamo discusso di come il valore consista nella qualità estrinseca, ovvero nella percezione del prodotto da parte dell'utente finale. In che modo il prodotto influisce sull'attività del cliente? Le buone metriche agili si basano sui risultati e, nel mondo degli affari, ciò si traduce in genere in dollari e centesimi. Proprio come assegniamo punti storia a ciascuna storia utente come modo per stimare il lavoro necessario, possiamo anche aggiungere punti valore come misura relativa per indicare cosa ottiene l'utente finale quando il lavoro è terminato.

Un modo per farlo è con un grafico di burn-up che illustra il numero di punti valore accumulati man mano che ogni storia viene completata. I punti valore possono essere assegnati a ciascuna storia o caratteristica in base alla percezione del cliente durante la creazione dei criteri di accettazione. Il reddito previsto (o denaro risparmiato) per il cliente sul progetto può essere diviso per il numero totale di punti valore nella versione.

Ad esempio, se ci sono 200 punti valore in un progetto e ci si aspetta che il cliente guadagni 1 milione di dollari di entrate, allora ogni punto valore vale $ 5.000. La somma totale di ogni storia e il loro valore accumulato possono essere illustrati nel grafico di burn up. Sebbene l'impatto effettivo del prodotto possa non essere evidente fino a quando non viene rilasciato, questo metodo può fornire informazioni finanziarie convincenti sia per il management che per i clienti.

Velocità

La velocità è probabilmente la prima metrica di cui molti di noi sentono parlare dopo essere stati introdotti allo sviluppo agile. Sebbene sia probabilmente la metrica agile più popolare, è anche la più utilizzata in modo improprio. I team di sprint sono noti per la velocità di gioco perché è così ampiamente utilizzata per riportare le loro prestazioni. La velocità è definita come la quantità di software prodotta in ogni iterazione o sprint. Questa quantità è solitamente espressa come story point e il software prodotto deve essere una porzione di codice funzionale pronta per la produzione.

I team spesso giocano alla velocità manipolando le dimensioni e la stima delle storie degli utenti o scomponendo il lavoro in orizzontale anziché in verticale, creando storie per le modifiche al database, il lavoro front-end, il middleware e altro ancora. per eliminare le dipendenze dagli altri e ottenere credito per il completamento del lavoro. Il problema con questo approccio è che questo tipo di user story sono in realtà attività e, sebbene i team ottengano credito, il valore aziendale per il cliente non è stato raggiunto.

La velocità di gioco può essere prevenuta utilizzando una miriade di altre metriche come controllo e bilanciamento l'una contro l'altra. Troppo spesso le organizzazioni fanno affidamento esclusivamente sulla velocità o su un insieme molto piccolo di metriche invece di una suite più ampia di misurazioni per formare una soluzione PPM, programma e gestione dei progetti.

Vorticità (agile)

Una domanda con cui molti agilisti e project manager lottano è "quanto siamo agili?" In effetti, la ricerca della risposta alla misurazione dell'agilità stessa è stata il Santo Graal degli agilisti ovunque. La vorticità agile è una nuova misura che fa proprio questo. Sulla base di oltre 10 anni di ricerca di casi studio, la vorticità agile è stata sviluppata attraverso un sofisticato metodo qualitativo chiamato grounded theory.

Utilizzando una serie completa di misure, l'agilità del mercato e del processo organizzativo può essere misurata l'una rispetto all'altra per determinarne la vorticità o il punto in cui convergono. Zero vorticità significa che l'agilità dell'organizzazione è all'altezza del mercato. Elevata vorticità significa che il mercato si sta muovendo molto più velocemente della tua organizzazione o dei tuoi team, e quindi c'è molto lavoro da fare. L'infografica di seguito mostra questa relazione utilizzando un esperimento mentale vorticoso per illustrare i mercati iperaccelerati di oggi.

Età dell'oggetto di lavoro

Un elemento di lavoro potrebbe essere definito come un pacchetto di lavoro, funzionalità utilizzabili o, come sarebbe nella maggior parte dei contesti agili, una storia utente. L'orologio inizia a ticchettare sull'età di un oggetto di lavoro non appena viene concepito per la prima volta. Tenere traccia dell'età degli elementi di lavoro, indipendentemente dal fatto che siano in corso o che si trovano nell'arretrato, può aiutare a identificare i problemi con i requisiti.

Se un oggetto di lavoro sembra invecchiare rispetto ai suoi simili perché viene spostato da uno sprint all'altro, potrebbe esserci un problema con la decomposizione. Forse ha bisogno di essere ridefinito o meglio compreso? Potrebbe essere necessario eliminare o ridefinire gli elementi di lavoro che restano nell'arretrato per lunghi periodi.

La pulizia continua del backlog è fondamentale per la pianificazione e la definizione delle priorità dello sprint. Un numero crescente di requisiti obsoleti nell'arretrato potrebbe causare problemi con il modo in cui i requisiti vengono sviluppati e scomposti. Una cattiva gestione dei requisiti è una delle principali cause di errore nelle trasformazioni agili.

Requisiti scritti in modo errato possono rendere estremamente difficili la definizione delle priorità e la stima, con conseguente indebitamento tecnico fuori controllo, basso utilizzo delle funzionalità e perdite finanziarie. Lo sviluppo di requisiti ben compresi, prioritari e di alto valore è una forma d'arte e poco compreso anche dai migliori agilisti. In effetti, è probabilmente uno dei maggiori ostacoli al successo della trasformazione agile.

Conclusione

In questo articolo abbiamo stabilito le basi per le metriche agili, la necessità di una soluzione completa e 17 consigli per crearne una. Indipendentemente dal fatto che utilizzi tutte le misurazioni discusse o solo un sottoinsieme, è importante che qualsiasi soluzione consideri l'audience per i dati. Alcune metriche, come la velocità, sono meglio conservate all'interno dei team di Scrum. Altre metriche come la vorticità agile e lo slancio aziendale sono progettate rispettivamente per la gestione esecutiva o di prodotto.

Assicurati sempre di comprendere appieno e comunicare accuratamente ciò che dicono le metriche e di seguire dove portano i dati. Un modo per guidare e supportare buone metriche è con un robusto framework agile.