9 metriche che possono fare la differenza per i team di sviluppo software di oggi

Come ho notato nell’articolo “Perché le metriche non contano nello sviluppo del software (a meno che non le abbini agli obiettivi di business),” la scelta delle metriche richiede una notevole riflessione e attenzione per supportare le domande specifiche a cui un’azienda deve davvero rispondere. Ecco il punto critico: le misurazioni dovrebbero essere progettate solo come un modo per rispondere alle domande aziendali. E queste domande non sono mai, ” Quanti KLOC siamo fino ad ora?”

Questo articolo riprende da dove si era interrotto il precedente, discutendo prima le metriche specifiche che ogni team dovrebbe iniziare a utilizzare, o almeno pianificare di utilizzare presto come un modo per migliorare le prestazioni evidenti. Si noti che il titolo di questo articolo afferma che ci sono “9 metriche che POSSONO fare la differenza…”—perché ciò che è veramente importante, ciò che farà davvero la differenza, è il modo in cui tali metriche vengono effettivamente utilizzate per migliorare il valore aziendale. Che l’uso è a voi. Quindi questo articolo si conclude spiegando come è possibile combinare queste metriche per creare significato, nonché formulare e testare un’ipotesi di valore aziendale.

Inizia misurando le cose giuste

Ecco nove metriche oggettive (contrassegnate da punti elenco) che dovresti monitorare continuamente, per apportare miglioramenti incrementali ai processi e agli ambienti di produzione. I miglioramenti in questi numeri non garantiranno che i livelli di soddisfazione del cliente aumenteranno a passi da gigante. Ma almeno queste sono le cose giuste da misurare. In una sezione successiva di questo articolo, “Mettere tutto insieme,” vedrete perché.

Metriche di processo agile

Per i processi agile e lean, le metriche di base sono leadtime, tempo di ciclo, velocità del team e velocità di apertura/chiusura. Queste metriche aiutano la pianificazione e informano le decisioni sul miglioramento dei processi. Anche se non misurano il successo o il valore aggiunto e non hanno nulla a che fare con la qualità oggettiva del software, dovresti comunque misurarli. Spiegherò perché qui sotto.

• Leadtime—quanto tempo ci vuole per passare dall’idea al software consegnato. Se vuoi essere più reattivo ai tuoi clienti, lavora per ridurre i tempi di consegna, in genere semplificando il processo decisionale e riducendo i tempi di attesa. Leadtime include il tempo di ciclo.
• Tempo di ciclo: quanto tempo è necessario per apportare una modifica al sistema software e consegnarla in produzione. I team che utilizzano la consegna continua possono avere tempi di ciclo misurati in minuti o addirittura secondi invece di mesi.
• Team velocity—quante “unità” di software il team in genere completa in un’iterazione (aka “sprint”). Questo numero deve essere utilizzato solo per pianificare le iterazioni. Confrontare le velocità del team è una sciocchezza, perché la metrica si basa su stime non oggettive. Trattare la velocità come misura di successo è inappropriato e trasformare una velocità specifica in un obiettivo distorce il suo valore per la stima e la pianificazione.
• Tassi di apertura/chiusura: quanti problemi di produzione vengono segnalati e chiusi entro un determinato periodo di tempo. La tendenza generale conta più dei numeri specifici.

Quando una o tutte queste metriche sono fuori dall’intervallo previsto o tendono in direzioni allarmanti, non assumere una causa. Parla con la squadra, prendi l’intera storia e lascia che la squadra decida se c’è motivo di preoccupazione e, in tal caso, come risolverlo.

Non è possibile conoscere o assumere le cause principali dai numeri, ma queste metriche forniscono informazioni su dove i processi essenziali richiedono attenzione. Un alto tasso di apertura e un basso tasso di chiusura attraverso alcune iterazioni, ad esempio, può significare che i problemi di produzione sono attualmente una priorità inferiore rispetto alle nuove funzionalità, o forse che il team è focalizzato sulla riduzione del debito tecnico per risolvere intere classi di problemi, o che l’unica persona che sapeva come risolverli smettere, o qualcos’altro. Non è possibile conoscere o assumere cause alla radice dai numeri.

Production analytics

• Mean time between failures (MTBF)
• Mean time to recover/repair (MTTR)

Entrambi sono misure generali delle prestazioni del sistema software nel suo ambiente di produzione corrente.

• Tasso di crash dell’applicazione: quante volte un’applicazione fallisce diviso per quante volte è stata utilizzata. Questa metrica è correlata a MTBF e MTTR.

Si noti che nessuna di queste tre metriche indica le singole funzionalità o gli utenti interessati. Tuttavia, più piccoli sono i numeri, meglio è. Il moderno software di monitoraggio delle operazioni rende la raccolta di metriche dettagliate su singoli programmi e transazioni abbastanza facile, ma richiede tempo e un’attenta riflessione per impostare intervalli appropriati per avvisi e/o trigger per il ridimensionamento verso l’alto o verso il basso (per sistemi basati su cloud).

Vorremmo che il nostro software non fallisse mai, ma è statisticamente improbabile. Quando il nostro software non riesce, vorremmo che non perdesse mai i dati critici e recuperare istantaneamente, ma che può essere straordinariamente difficile da raggiungere. Se il software è la vostra fonte di entrate, tuttavia, lo sforzo è utile.

Oltre a MTBF e MTTR, le misurazioni a grana più fine si basano su singole transazioni, applicazioni e così via e riflettono il valore aziendale fornito e il costo della riparazione dei guasti. Se l’applicazione di elaborazione delle transazioni si blocca una volta su cento, ma recupera in un secondo o due e non perde alcuna informazione critica, il tasso di crash dell ‘ 1% potrebbe essere abbastanza buono. Ma se ogni crash è di un’app che esegue 100.000 transazioni al giorno, perde una vendita di $100 e costa 5 50 per rimediare al back-end, quel tasso di crash dell ‘ 1% sarà una priorità. Fissarlo avrà un impatto significativo sulla linea di fondo.

Metriche di sicurezza

La sicurezza è un aspetto della qualità del software che viene spesso trascurato fino a tardi (o troppo tardi). Gli strumenti di analisi della sicurezza possono essere utilizzati nel processo di costruzione, oltre a valutazioni più specializzate e stress test. I requisiti di sicurezza sono spesso semplici e di senso comune, ma il team di sviluppo software deve essere consapevole di essi e delle metriche da essi derivate.

L’intera gamma di pratiche di sicurezza e metriche correlate va oltre lo scopo di questo articolo, ma come per le metriche di processo agile e le metriche di produzione, ci sono alcune metriche specifiche che possono significare molto per la soddisfazione complessiva dei clienti.

• Incidenti endpoint-quanti endpoint (dispositivi mobili, workstation, ecc.) hanno sperimentato un’infezione da virus in un dato periodo di tempo?
• MTTR (mean time to repair) – nelle metriche di sicurezza, questo è il tempo tra il rilevamento di una violazione della sicurezza e un rimedio distribuito e funzionante. Come per la metrica MTTR di produzione sopra indicata, l’MTTR di sicurezza deve essere monitorato su intervalli di tempo specifici. Se il valore MTTR si riduce nel tempo, gli sviluppatori stanno diventando più efficaci nel comprendere problemi di sicurezza come i bug e come risolverli.

Per entrambe queste metriche, numeri più piccoli nel tempo significano che ti stai muovendo nella giusta direzione. Meno incidenti endpoint parla da solo. Man mano che il valore MTTR si riduce, gli sviluppatori stanno diventando più efficaci nel comprendere i problemi di sicurezza come i bug e come risolverli.

Puoi trovare altri modi per applicare le metriche di sicurezza allo sviluppo del software negli articoli Application Security for Agile Projects e Security Threat Models: An Agile Introduction.

Una nota sulle metriche del codice sorgente

Oggi è facile collegare uno scanner del codice sorgente nella pipeline di compilazione e produrre risme di metriche oggettive. Ci sono medie empiriche e intervalli suggeriti e argomenti logici sull’importanza relativa di queste metriche. Ma in pratica, questi strumenti sono molto utili per far rispettare gli stili di codifica, contrassegnare determinati anti-pattern e identificare valori anomali e tendenze.

Non vale la pena rimanere appeso ai numeri. Ecco un esempio, a titolo di spiegazione.

Supponiamo di trovare un metodo in una classe con una metrica ridicola, ad esempio una complessità NPATH di 52 milioni. Ciò significa che ci vorrebbero 52 milioni di casi di test per esercitare pienamente ogni percorso attraverso il codice. È possibile refactoring il codice in una struttura più semplice, ma prima di farlo, considerare quale sarebbe l’impatto sul business. È probabile che il vecchio e brutto codice funzioni abbastanza bene (anche se la sua copertura di test potrebbe essere inadeguata). Chiamare l’anti-pattern al team in modo che possano evitare di ripeterlo è un apprendimento prezioso, ma risolverlo probabilmente non sposterebbe l’ago su nessuna metrica aziendale pertinente.

È meglio se il team accetta il livello di conformità e le regole a cui è sottoposto il proprio codice, ma essere consapevoli del fatto che esaminare valori anomali e preoccuparsi dei trend blips può sprecare molto tempo.

Poi mettere tutto insieme: Il successo è la metrica definitiva

La gioia di utilizzare strumenti automatizzati per il monitoraggio e la misurazione metriche di qualità e analisi degli utenti è che si libera il tempo di concentrarsi sulle metriche che contano davvero: metriche di successo.

Come utilizzare le metriche per il successo

Le aziende hanno obiettivi. Gli obiettivi implicano domande, come “Che aspetto ha il successo?”o” In che modo questo influenzerà il comportamento del cliente?”Le domande correttamente quantificate implicano metriche.

In altre parole, le metriche dovrebbero essere utilizzate solo per rispondere a domande, per testare ipotesi che supportano uno specifico obiettivo aziendale. E questo dovrebbe essere fatto solo finché le domande e le risposte aiutano a guidare cambiamenti positivi.

Ora, tutti i progetti in generale non hanno un insieme di obiettivi, domande e ipotesi invarianti e quindi metriche?

Sì, ma solo dal punto di vista del business. Le misure a livello aziendale di cose come il coinvolgimento degli utenti, i tassi di chiusura, la generazione di entrate e così via forniscono un feedback su come l’azienda sta andando nel mondo reale. Le modifiche al software che influiscono sul business influenzeranno anche questi tipi di metriche.

A un livello di risoluzione più fine, ogni funzionalità e storia utente può avere una propria metrica di successo, preferibilmente solo una e direttamente correlata a una misura di valore consegnata al cliente. Completare nove storie su dieci in uno sprint per funzionalità che non vengono mai consegnate è uno spreco, non un successo. Fornire storie che i clienti non vogliono o usano è uno spreco, non un successo. Fornire una storia che migliora alcuni aspetti della felicità degli utenti è un successo. Fornire una storia che dimostrabilmente non migliora il coinvolgimento degli utenti è anche un successo, perché avrai imparato qualcosa che non ha funzionato, invalidato un’ipotesi di business e liberato risorse per perseguire altre strade.

Come formulare un’ipotesi di valore

Un’ipotesi di valore è una dichiarazione su ciò che pensi accadrà come risultato della consegna di una caratteristica specifica. La relazione tra il software, il risultato desiderato e le metriche costituisce l’ipotesi di valore per la funzione (o sistema, o storia, o aggiornamento, ecc.). L’ipotesi dovrebbe esprimere come la metrica mirata dovrebbe cambiare, su quale lasso di tempo e da quanto essere considerato efficace. Dovrai parlare con il team e il product owner, come minimo, per capire la cosa specifica che questa funzione o storia ha lo scopo di creare o migliorare rispetto al business al fine di formulare la sua ipotesi di valore. Potrebbe essere necessario chiedere” perché ” un paio di volte (come un bambino di tre anni) per staccare gli strati di ipotesi non dichiarate; sii paziente. Quando capisci quale dovrebbe essere il valore aziendale, puoi iniziare a porre le domande che ti porteranno alle metriche che rispondono alla domanda.

Ad esempio, una storia “tecnica” per migliorare la velocità di un processo di checkout e-commerce può avere come presupposto di base che un checkout più veloce porterà a più vendite. Ma perché lo pensiamo? Sono un sacco di persone abbandonando i loro carrelli durante il processo di checkout? Se questo è il consenso (perché tale consenso è supportato da dati di base), l’ipotesi del valore potrebbe essere “Crediamo che un processo di checkout più veloce comporterà una diminuzione dei tassi di abbandono del carrello, portando a vendite più elevate e una migliore esperienza utente.”

Probabilmente puoi supporre che gli utenti apprezzeranno il checkout più rapido, ma non fa male chiedere se se ne sono accorti. I tassi di abbandono del carrello e le vendite possono essere misurati prima e dopo che il nuovo processo è in atto, per un periodo di tempo. Se il tasso di abbandono del carrello diminuisce e le vendite aumentano (al di là delle fluttuazioni statistiche), le prove supportano l’ipotesi e si potrebbe considerare se siano giustificati ulteriori miglioramenti della velocità. Se non lo sono, lascia che questa metrica svanisca sullo sfondo (o rimuovila, se distrae) e rivolgi la tua attenzione alla prossima ipotesi. Se il tasso di abbandono del carrello diminuisce ma le vendite rimangono invariate, misurare per un periodo di tempo più lungo o ripensare il legame presunto tra abbandono del carrello e vendite. In altre parole, utilizzare metriche per imparare, e solo fino a quando si rivelano utili per i miglioramenti di guida.

In alcuni casi, l’ipotesi potrebbe essere chiaramente sbagliata, quindi lasciamo cadere le metriche (e annulliamo le modifiche al software!) dopo alcuni giorni. In altri casi, l’ipotesi potrebbe essere corretta, quindi continuiamo a guidare miglioramenti in questo settore per anni.

Sei euristiche per un uso efficace delle metriche

Abbiamo visto come le metriche software soggettive contano molto di più per il successo aziendale rispetto alle tradizionali metriche di qualità oggettive del vecchio. Lo sforzo necessario per trovare e misurare metriche aziendali rilevanti per le funzionalità è superato dalle intuizioni e dalle opportunità di apprendimento acquisite. Le condizioni di business e le opportunità cambiano costantemente, quindi piuttosto che riassumere una formula da seguire, che può essere fragile, ecco sei regole empiriche, o euristiche, per aiutare a mantenere la concentrazione e la flessibilità. Possano aiutare a guidare nel vostro viaggio verso il software di qualità e il successo aziendale!

1. Le metriche non possono raccontarti la storia; solo la squadra può farlo (con una punta di cappello a Todd DeCapula).
2. Confrontare i fiocchi di neve è uno spreco.
3. Puoi misurare quasi tutto, ma non puoi prestare attenzione a tutto.
4. Le metriche di successo aziendale guidano i miglioramenti del software, non il contrario.
5. Ogni caratteristica aggiunge valore; o misurarlo o non farlo.
6. Misura solo ciò che conta ora.