Cinque migliori KPI di ingegneria del software, e come vengono ingannati

Di Bill Harding,Programmatore/CEO
Pubblicato il 31 marzo 2020.Ultimo aggiornamento 17 aprile 2020.

Quando si parla di KPI ingegneristici, ci sono due verità contraddittorie che si sentono spesso:

Quello che si misura migliora.-Peter Drucker

E

Quando una misura diventa un obiettivo, cessa di essere una buona misura.-La legge di Goodhart

Entrambe queste affermazioni descrivono in parte i KPI di ingegneria, ma prese insieme implicano che è possibile usare la misurazione per migliorare. Come può un manager guidato dai dati colmare questo divario?

La cattiva notizia è che ci vuole un certo impegno per imparare, specialmente per coloro che provengono da ruoli distanti (cioè non tecnici). La buona notizia è che le metriche scelte con cura possono continuare a funzionare nonostante il “diventare un obiettivo”. Infatti, per molte delle metriche che raccomanderemo, più un dipendente “gioca con il sistema”, più gli interessi a lungo termine del business sono serviti. L’obiettivo finale è una metrica che continua a funzionare bene mentre viene “giocata”. Ci sono cinque metriche che soddisfano questa barra.

Target audience: Manager con spirito d’azione

Ogni manager che ha provato a strappare un maggior numero di ticket completati dal suo team di ingegneri conosce la lotta: vogliono intraprendere azioni giuste, basate sui dati, che migliorino la loro velocità. Sanno che prendere decisioni basate sull’istinto è costoso e non scalabile. Eppure, quando guardano la loro lista di cose da fare, è piena di compiti che sembrano più urgenti di “migliorare la misurazione”. In pratica, abbracciare la misurazione spesso avviene dopo un fallimento catastrofico, come una build di rilascio difettosa o il notare che uno sviluppatore non ha chiuso nessun ticket in un mese.

Anche quando è chiaro che la misurazione deve avvenire, è ambiguo da dove iniziare. Si può cercare su Google “engineering KPIs”, cliccare sull’intera prima pagina di risultati e rimanere incerti sui prossimi passi da fare. Prendiamo come esempio la tanto decantata metrica “Team Velocity”. Quasi tutti i risultati di Google raccomandano di misurare la “Team Velocity”, ma nessuno vuole dire se viene misurata in… biglietti chiusi? Linee di codice? Punti storia? Qualunque cosa sia, i manager non hanno tempo per capirlo. Hanno bisogno di passare da questa montagna di 15.000 piedi di teoria a qualcosa che possono capire, di cui fidarsi e di cui beneficiare… preferibilmente subito.

La premessa organizzativa di questo articolo è che tu sei un manager che vuole capire la metrica dell’ingegneria del software abbastanza bene da rendere il tuo team più efficace. Essere un manager significa che siete troppo occupati per imparare la teoria, tranne quando si ricollega direttamente a come potete beneficiare di quella teoria.

Le metriche devono essere pratiche per le aziende reali da provare

Prima di scrivere questo articolo, abbiamo digerito le metriche proposte dai primi 20 risultati di Google nel campo delle metriche del software. Come potreste immaginare, ogni fonte aveva le proprie teorie su quali metriche fossero più importanti. I loro articoli spesso raggruppavano le metriche in gruppi come “metriche di processo” e “metriche di progetto”. Seguiremo il loro spunto sul raggruppamento delle metriche, ma i nostri gruppi saranno “metriche di qualità” e “tutto il resto”.

Ecco cosa si qualifica come metrica di qualità:

  • Valore aziendale.È possibile tracciare una linea retta dalla metrica => valore aziendale creato?
  • Misurabile.Possiamo definire un numero specifico e le sue unità di misura (es, punti, percentuale), in modo che possa essere monitorato nel tempo e correlato a eventi ed esperimenti?
  • Azionabile.Può informare regolarmente le azioni che portano a risultati positivi? Preferibilmente con un minimo di falsi positivi?
  • Disponibile/conveniente.Un team medio di ingegneria del software può avere accesso a questa metrica senza cambiare i processi di sviluppo esistenti?
  • Popolare.Ha un seguito sufficiente per essere ben documentato e credibile?
  • L’inclusione nel secchio delle “Metriche di qualità” richiede tutte e cinque le condizioni di cui sopra, più una risposta soddisfacente alla nostra domanda: se ci fidiamo di questa metrica e gli sviluppatori la ottimizzano, cosa succede dopo? Nei nostri anni passati a costruire e iterare la nostra metrica di sviluppo (“Line Impact”), abbiamo imparato che i sottoprodotti tossici sono una conseguenza attesa della misurazione, a meno che la metrica sia allineata con precisione al valore aziendale a lungo termine.Come esempio, mostreremo in seguito come gli sviluppatori che cercano di manipolare la metrica “Lead Time” causano una ridotta trasparenza per il management.

    KPI di ingegneria della qualità

    Qui ci sono cinque metriche del software che hanno tutte le carte in regola per aiutare i manager a gestire un team più efficiente.

    🏦 OKR-driven

    Esempio di modello OKR

    Uno dei tanti esempi di modelli OKR disponibili tramite Weekdone su Okrexamples.com

    Qualunque lista che sia focalizzata sulla massimizzazione del valore aziendale dovrebbe iniziare qui. Aziende leader come Google usano gli OKR come asse principale su cui valutare gli ingegneri senior. Lo svantaggio delle metriche OKR-driven è che sono, per definizione, specifiche ai particolari del business. Questo rende impossibile generalizzare una formula con cui catturarli, o generalizzare il percorso con cui verranno giocati.

    Come giocarli? Il rischio che gli OKR vengano giocati è basso dato che sono solitamente business-centric. Il pericolo principale delle metriche guidate dagli OKR è che, poiché sono tipicamente formulate una tantum (o periodicamente), sono forse meno affidabili delle metriche che sono state verificate per anni. Ci sono sempre possibili casi limite in agguato: per esempio, impostare un OKR per “introdurre meno di 10 bug al mese” potrebbe essere giocato non lanciando nessuna nuova funzionalità. Supponendo che entrambe le parti agiscano in buona fede, il gioco dell’OKR dovrebbe in pratica essere raro.

    Come ottenerlo? Tramite cruscotti di misurazione esistenti, o lavorando con aziende comeWeekdone che aiutano a fornire ispirazione all’OKR.

    📐Line Impact

    Esempio di KPI ingegneristico Line Impact: metrica affidabile del codice sorgente

    10 repo graficizzati dal loro Line Impact, una metrica che quantifica il ritmo al quale il codice sorgente si evolve, immagine cortesia GitClear

    Line Impact è una metrica progettata per misurare quanta energia cognitiva viene messa nello sviluppo del software.Questo video offre una spiegazione illustrata di come ciò sia possibile. La spiegazione breve è che Line Impact cancella tutta l’attività interstiziale (“churn”) che accade quando una caratteristica viene sviluppata, lasciando un’incarnazione concentrata del lavoro che ha avuto luogo. Line Impact è conservato attraverso i linguaggi, così ci vuole una quantità consistente di tempo per generare Line Impact se lo sviluppatore sta scrivendo Java, Python, Javascript, o qualsiasi altro importante linguaggio di programmazione (30+ supportati).

    In termini di valore aziendale, Line Impact è parallelo agli Story Points: illustra come il costo di un compito fluttua a seconda dello sviluppatore a cui è assegnato. Da questo, un manager impegnato può usare il rapporto Domain Experts per abbinare Jiras agli esperti della materia, il che può accelerare drasticamente la velocità del prodotto.

    Come giocare? Qualsiasi metrica che rivendica “Lines of Code” (LoC) come fonte di dati (come fa Line Impact) merita di essere affrontata con cautela. Implementato senza cura, le sottili imperfezioni nell’elaborazione vengono ingigantite in un rumore che esclude il segnale.Ecco perché GitClear ha costruito i migliori strumenti di revisione del codice sul mercato: in modo che i manager e gli sviluppatori possano rivedere come Line Impact viene distribuito su una base per-commit, per-file.La trasparenza è un potente antidoto per combattere il gioco.

    Una protezione aggiuntiva arriva sotto forma di notifiche che si attivano quando uno sviluppatore contribuisce al lavoro ad una velocità insolita. Queste e altre misure hanno reso sufficientemente difficile giocare a Line Impact che GitClear non ha ancora ricevuto un cliente che riferisca che Line Impact è stato giocato con successo dal suo team.Detto questo, sarebbe falso affermare che la metrica è in qualche modo impermeabile al gioco, quindi ecco una lista di percorsi noti con cui accumulare rapidamente Line Impact. Il succo è che se uno sviluppatore scrive test, cancella il vecchio codice e aggiunge documentazione, guadagnerà una quota sovradimensionata di Line Impact. Se ti piace, i prezzi partono da $9 per sviluppatore attivo.Guarda un breve video esplicativo su Line Impact qui.Disponibile la versione on prem.

    🎲 Story Points

    KPI di ingegneria: Jira burndown report

    Story Point-based “release burndown” report, disponibile via Jira

    Story Points potrebbe rivendicare di essere il più “classico” dei KPI di ingegneria. Ci sono molti modi diversi per calcolare gli Story Point. Tutte le forme si riconducono ad una stima del tempo atteso dagli sviluppatori per completare qualche compito. I manager possono usare gli Story Points per calcolare i costi impliciti di un compito, per esempio, se uno sviluppatore guadagna $10k/mese, il biglietto è stimato a 10 Story Points = metà del mese, allora il costo è $10,000 * 0.5 = $5,000.Usando qualche versione di quel calcolo aiuta a dare priorità ai compiti basati su quali danno il più alto rapporto di Valore Proiettato/Costo di Implementazione Proiettato.

    Come giocarlo? La maggior attenzione qui è su come gli Story Points vengono calcolati. Il modo più semplice per “giocare” con gli Story Points è che il team di sviluppatori distorca la scala di valutazione, di solito verso una sovrastima della difficoltà. Un’opzione per risolvere questo problema è permettere ai compiti di essere selezionati in un “mercato dei compiti”, dove i compiti sopravvalutati possono essere distribuiti equamente tra gli sviluppatori per mantenere la calibrazione relativa. Un altro modo per affrontarlo è ricalibrare regolarmente la costante usata per tradurre gli Story Points in “giorni di sviluppo”. Si noti che poiché l’implementazione degli Story Points spesso differisce per team, non è consigliabile usarli per confrontare le prestazioni di più team.

    Come ottenerli? Quasi ogni issue tracker da questo lato di GitHub permette di specificare gli Story Points. In termini di visualizzazione, Jira fornisce un “next-gen velocity report” dedicato allo scopo di mostrare gli Story Point completati nel tempo, ma offre anche un “release burndown report” che usa gli Story Point per stimare come il team sta seguendo i suoi obiettivi per lo sprint. GitClear offre anche grafici rudimentali (per il momento) che illustrano gli Story Point completati nel tempo.

    🐞 Bug Rate / Escaped Defects

    Questa metrica è definita in vari modi da varie fonti, ma tutti arrivano alla stessa domanda essenziale: quanti bug stanno uscendo nel mondo, e quanto bene stiamo rispondendo ad essi?Stackify lo riferisce in termini numerici specifici:

    Il vostro tasso di fuga dei difetti è espresso come una percentuale basata su quanti difetti trovate prima che vadano in produzione o quanti lo fanno, come preferite. Ogni progetto software e ogni team sarà diverso, ma suggeriamo di sforzarsi di trovare il 90% di tutti i difetti prima che vadano in produzione.

    La definizione di Stackify presuppone che uno designi un campo nel suo issue tracker per catturare in quale fase di sviluppo si è verificato il bug. Per i team che non hanno il tempo di impostare e tracciare le fasi di sviluppo, una definizione sostitutiva può essere:

    Quanto spesso il codice scritto in una nuova caratteristica diventa codice cambiato nel corso della risoluzione di un bug?

    Una risposta legata ai dati a questa domanda è fornita agli utenti di GitClear, ma è difficile da calcolare manualmente (se non sei un utente di GitClear).Una misura di ripiego garantita e disponibile del tasso di bug può essere “qual è il rapporto tra bug creati e bug risolti”?

    Come giocare? Uno sviluppatore può prendere più ticket piccoli, ma ogni ticket introduce un rischio incrementale di bug se non sta attento. Il rischio di usare il Bug Rate è che ha bisogno di un contrappeso per il “progresso” come Story Points o Line Impact, altrimenti uno sviluppatore potrebbe soffermarsi su un singolo problema per l’intero sprint, assicurandosi un tasso di bug dello 0%.

    Come ottenerlo? Se il tuo team ha la larghezza di banda per etichettare i problemi in base alla fase di sviluppo in cui si sono verificati, allora gliEscaped Defects possono essere calcolati manualmente attraverso qualsiasi issue tracker. GitClear è un’altra opzione disponibile per calcolare la percentuale di caratteristiche che diventano bug.

    ✅ Pull Request Completion Rate

    Example engineering KPI Pull Requests: stats on GitClear

    A sampling of the pull request stats provided by GitClear

    What percentage of pull requests were closed within a week from being opened? Questa domanda è più granulare, come “il team è impegnato a rispondere prontamente alle nuove richieste di pull”, “sono in grado di cooperare” e “gli sviluppatori hanno lucidato il loro codice prima di presentarlo per il merge?”

    Come giocare? Superare il test “Pull request completion rate” significa chiudere sempre le PR entro una settimana. Questo è relativamente difficile da giocare, ma deve essere controbilanciato da una forza propulsiva come Story Points o Line Impact, altrimenti tutti gli incentivi del team saranno di lucidare il lavoro piuttosto che spedirlo (o sottoporlo a revisione PR).

    Come ottenerlo?Tutti i fornitori di Engineering Insight “di marca” (GitClear, Pluralsight, Code Climate, Pinpoint) offrono statistiche che illustrano l’efficienza del processo di richiesta di pull di un team.Aiutiamo a confrontare i fornitori qui.

    Menzioni d’onore

    Sotto le metriche “top tier”, troviamo un tier interstiziale. Queste sono metriche che possiedono caratteristiche desiderabili accanto a importanti carenze. Possono ancora fornire valore, a patto che un manager sappia abbastanza da tener conto delle loro limitazioni.

    Lead Time/Cycle Time

    Grafico del lead time come visualizzato tramite Azure Devops

    Mentre è elencato (due volte!) nella lista delle Top 5 Metrics diPluralsight, il Cycle Time è una buona idea che è altamente suscettibile al gioco.

    Il “Lead Time” è più spesso definito come “Qual è l’intervallo tra quando un compito è archiviato nel tracker dei problemi e quando è consegnato al cliente? Il suo cugino, “Cycle Time”, è un sottoinsieme del Lead Time, definito come “il tempo tra quando il team del prodotto l’ha tirato fuori dalla coda e quando ha raggiunto la produzione.”

    Come giocarlo? La performance del Lead Time dipende in una certa misura dal meccanismo con cui le Jira vengono archiviate, il che significa che la sua applicabilità tra i team è bassa. Il Cycle Time dipende dalle convenzioni con cui il committer sceglie di fare il suo primo commit. Così, questa metrica è facile da giocare se uno sviluppatore salva i suoi commit localmente e li rilascia in una raffica di lavoro immediatamente prima di presentare il PR. Questo fallimento è ciò che relega il Cycle Time alla sezione “Menzioni d’onore”. Inoltre non è ideale: incentivando uno sviluppatore a salvare i propri commit senza spingere, è impossibile per i compagni di squadra intervenire mentre il lavoro è in corso.Questo effetto collaterale riduce la trasparenza tra un manager e i suoi sviluppatori.

    Come ottenerlo? Azure Devops Services fornisce il grafico di cui sopra.Jira offre anche una versione di esso.Tutte le principali offerte di Engineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementano qualche versione del calcolo del Lead Time.

    Test coverage

    Tentare di catturare qualche misura di test coverage è un obiettivo ragionevole da considerare. Tuttavia, non è proprio una metrica Top Tier per due motivi:

  1. È una soluzione incompleta. Un test adeguato deve includere test funzionali e di integrazione insieme ai test unitari, e nessuna soluzione automatizzata può sapere quali pagine devono essere visitate all’interno dell’app o del sito web, questo richiede ancora una direzione umana
  2. È molto difficile da collegare alle metriche di business top-line. La copertura dei test è degna di essere valutata come parte del piano di uno sviluppatore capo per monitorare la qualità del codice, ma non si collega al valore del business abbastanza direttamente da fare il taglio da solo. Una metrica correlata ma più funzionale al business per tracciare i difetti del codice è “Bug Rate / Escaped Defects.”

Metriche “Everything Else”

La lista sopra è relativamente corta se paragonata al corpus di metriche del passato che sono state proposte da altri autori.Per amor di completezza, rivediamo alcune delle metriche più comunemente menzionate altrove, e perché non hanno fatto il taglio.

Team Velocity

Questa è stata una delle metriche più popolari citate da altri articoli. È raccomandata daTechBeacon,InfoPulse,eSeaLights.io.Tuttavia, gli autori sembrano diffidenti nel definire le unità di questa importante metrica.TechBeacon la definisce come “quante ‘unità’ di software la squadra tipicamente completa in un’iterazione”. Non sotangibile. InfoPulse non prova a specificare le unità. SeaLights dice che le unità sono “Story Points”. Così, concludiamo che la nozione di “velocità” è adeguatamente catturata da Story Points, o Line Impact per procura.

Code Churn

Il CEO di GitPrime (ora acquisito da Pluralsight) era tra quelli che sostenevano di considerare il Code Churn.Noi sosteniamo in risposta che le implicazioni del Code Churn sono tutte sulla mappa, che rende molto difficile agire su un alto churn. Le metriche devono essere perseguibili.

Release/Sprint Burndown

SeaLights e InfoPulse raccomandano di prestare attenzione a come un team sta tendendo verso i loro obiettivi di sprint.Siamo d’accordo che questo è importante, ma è già coperto dalla sezione “Story Points” sopra.

Tempo medio di riparazione / Tempo medio tra i guasti

Tra la manciata di articoli che promuovono queste metriche, nessuno si avventura nel descrivere in quali unità si basa la metrica, o quale servizio può essere usato per raccogliere questi punti dati.La ricerca trova che Atlassian offre un articolo di aiuto sull’argomento.Se questo articolo non fosse già lungo 2.500 parole, MTTR potrebbe entrare nella sezione “Menzioni d’onore”. Ma non è facile da collegare al valore di business, e non è semplice per un team medio accedervi senza cambiare la propria routine.

Abbiamo dimenticato qualcosa?

Leave a Reply

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.