KPI per i team di sviluppo software – Arragonán – Dani Latorre

Come parte del mio lavoro nell’ultimo anno, ho cercato di spingere la cultura del miglioramento continuo nelle diverse squadre con cui ho lavorato . Sia su questioni di strumenti tecnici e competenze, come in quelli della comunicazione e del coordinamento, con determinate restrizioni e dipendenze che cadono dal nostro margine di influenza.

Iniziamo dall’assunzione che meglio le pratiche del team sono, la migliore capacità di consegna avrà. Che si traduce in una maggiore adattabilità ai cambiamenti, un migliore mantenimento del software con il passare del tempo e forse una maggiore motivazione della squadra con il suo lavoro.

Oltre alle tipiche sensazioni soggettive di miglioramento, Abbiamo dovuto pensare agli indicatori che ci permettono di ottenerlo davvero. Ad un certo punto, inizierebbe anche a voler avere visibilità dall’esterno delle squadre, quindi ho dovuto girarsi e ordinare idee.

Stavo preparando una presentazione per spiegare internamente come stavamo lavorando, dove Pensavo che dovremmo passare attraverso un miglioramento continuo, i diversi KPI che potremmo osservare e le esigenze che sarebbero coperte con una buona capacità di consegna.

Slide di una presentazione con il La visione di cosa, come una squadra dovrebbe essere coperta: adattabilità relativa all'attività commerciale, consegnando presto, evitando la rilavorazione, un buon ux ed evitando bug il più possibile

“Dimmi come mi prendo e Ti dirò come mi comporlo “

Non conosco l’origine, ma con queste cose ricordo sempre questo detto. Devi camminare con un occhio con quali indicatori (non obiettivi) misureremo . Inoltre, dovremo usare diversi per compensare la promozione di strani comportamenti che false quelle metriche.

con l’uso Normale degli strumenti, concordando solo alcune convenzioni, il successivo sfruttamento dei dati può essere facilitato a estrarre le metriche. Le origini dati per gli indicatori sono:

  • il codice
  • il repository di automazione e il server
  • gli strumenti di gestione
  • il Prodotto stesso

Indicatori di codice

Gli strumenti di analisi del codice statico ci danno numeri su debito tecnico che esiste. Non dovremmo perdere di vista questi indicatori e dedicare il tempo per analizzare e creare una pulizia specifica di volta in volta. A volte vengono risolti con soluzioni semplici e altri nascondono problemi di progettazione che non sono così ovvi.

La copertura del test è uno degli indicatori più comuni, più interessante in questo caso è quello di vedere cosa non è coperto. E come di solito è discusso, dobbiamo camminare con attenzione perché è un indicatore facile da falsificare se è cercato come bersaglio.

In un dato momento, inoltre, potrebbe essere utilizzato il test di mutazione (controllare che un test è rotto quando si modifica il codice di produzione) per avere un indicatore della qualità dei test dell’unità.

Indicatori del repository e server di automazione

Ci sono indicatori piuttosto interessanti che possono essere rimossi Dai repository e dai server di automazione, anche se soprattutto dipendono dalle convenzioni di utilizzo.

Tuttavia, un indicatore sempre valido e che penso che dovrebbe essere osservato è la frequenza di integrazione.

L’integrazione continua è una pratica (che nessun strumento) come popolare come interpretato erroneamente, poiché fino al lavoro che hai fatto o sta facendo una persona con il principale ramo di sviluppo e una build è completata, non lo stiamo facendo.

Fino a quando non hai finito correttamente La costruzione di un artefatto del software, non sappiamo se tutto è corretto. Più frequenza, feedback in precedenza e meno incertezza.

In caso di utilizzo di rami, è anche interessante vedere la durata della durata dei rami. Più tempo, aumento del rischio di conflitti o di altri problemi durante l’integrazione.

e se vengono utilizzate richieste di tiro / unione, c’è anche una manciata di indicatori che in un dato momento possono estrarre gli odori relativi alla capacità di consegna : Numero di commenti, tempo rimanente, numero di rifiuti …

Indicatori di strumenti di gestione

Strumenti di gestione, oltre a servire come radiatore di informazioni per conoscere la situazione del prodotto e aiutano a coordinare il lavoro, sono una buona fonte di informazioni sugli indicatori del processo di lavoro.

Per osservare la capacità dell’intera squadra in un insieme di affettare verticale è molto utile conoscere il tempo di ciclo . Ad un periodo di ciclo più breve, maggiore è la nostra capacità di consegna. È il momento in cui ci vuole da quando inizia a lavorare su qualcosa che contribuisce al valore (ad esempio una storia utente) fino a quando non accade.

È normale che ad un certo punto degli strumenti di gestione è possibile osservare le diverse implementate che sono state apportate, dove possiamo ottenere la frequenza della distribuzione. Ovviamente, più frequentemente, meglio.

Sebbene il nostro tempo di ciclo fosse breve e la frequenza di alta implementazione, sarebbe possibile che il nostro prodotto sia fragile a causa dei bug. Questo è il motivo per cui l’indicatore dei bug rilevato e risolto dalla versione / implementazione è un’altra metrica da prendere in considerazione.

A seconda del momento e dello scenario in cui viene trovato un prodotto, penso anche l’indicatore di Il tempo di consegna, il tempo passato da quando viene chiesto qualcosa di nuovo fino a quando non viene distribuito in produzione. Questa sarebbe una conseguenza dei precedenti 3 indicatori e delle dimensioni dello stack del prodotto.

Come immagino che ci sia qualcuno che può perdere gli indicatori sulle stime, digitare la storia iterazione dei punti della storia. A mio parere, hanno un componente molto soggettivo e variabile da utilizzare come indicatore di cambiamento nella capacità di consegna di un computer.

indicatori del prodotto stesso

in aggiunta a Un altro tipo di strumentazione per lo più più meticolosa che i membri del gruppo del team di gestione del prodotto o del design, il team di sviluppo dovrebbe essere in grado di osservare il numero e la percentuale dell’uso della funzionalità, che alla fine definisce il successo o meno del lavoro di tutti.

La cosa più interessante di questo indicatore è che combinata con altre metriche può aiutare a prendere decisioni sull’evoluzione del prodotto. Come ad esempio, questo scenario:

  1. ha rilevato problemi di prestazioni molto gravi in una parte del prodotto.
  2. Nota che la percentuale di utilizzo della funzionalità interessata da tali problemi è Residua.
  3. Abbiamo deciso di non risolverlo al momento, ma lo riflettiamo nella pila del prodotto come una piccola priorità.
  4. Configurano un avviso per rilevare un aumento della percentuale di utilizzo di tale funzionalità.

Un altro indicatore importante è il tasso di arredo del prodotto, quante volte viene rilevato un errore o un errore per quantità di utilizzo, che ci consente di sapere quanto è stabile a il prodotto è. E mescolato con la funzionalità Usa indicatore numeri, ci consente di rilevare i punti problematici.

A seconda del contesto del prodotto e del business, possiamo eventualmente estrarre altri indicatori pertinenti di operazioni e supporto che sono Una conseguenza dell’uso del prodotto.

misura senza perdere la messa a fuoco

questi sono molti kpis diversi. È interessante osservarli perché possono essere utilizzati per rilevare gli odori su problemi e opportunità di miglioramento, ma sono troppi per cercare di migliorare tutto alla volta.

per evitare diluire e non finire a tutti , dovremmo scegliere e concentrarci in un paio di questi indicatori ogni volta, a seconda della situazione di ogni squadra.

E anche se è allettante farlo, eviterebbe felicemente usando questi indicatori per celebrare gli obiettivi , così come per valutare diverse attrezzature.

Non dimentichiamo che lo scopo di misurare questi indicatori è osservare l’evoluzione al momento di una squadra che lavora su un particolare prodotto e contesto.

Leave a Comment

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *