Senza categoria

Il modo giusto per definire le metriche agili

Le metriche agili sono misurazioni utilizzate per monitorare i progressi e il successo di un team di progetto agile.

Le metriche, se definite nel modo giusto, forniscono approfondimenti sulle prestazioni, la qualità, l’efficienza dei test o l’efficacia complessiva del team e su come si evolve nel tempo.

L’obiettivo finale delle metriche agili è aiutare i team a identificare le aree di miglioramento e a prendere decisioni basate sui dati che porteranno a prodotti migliori man mano che il team avanza.

La maggior parte delle volte, le aziende definiscono metriche che sono metriche di vanità o numeri grezzi, che crescono piacevolmente da sinistra a destra. Potrebbero avere un bell’aspetto su alcuni dashboard, ma di solito sono inutili per il team stesso.

Il loro scopo non è quello di aiutare in alcun modo il team, ma piuttosto di compilare alcuni rapporti per la leadership e poi concludere con alcune decisioni strategiche. Sfortunatamente, è poi la squadra che non capisce perché esiste questa particolare decisione.

In un recinto per soddisfare tali metriche sbagliate, i team quindi falsificano i propri processi per far sembrare buone le metriche. Ma il rendimento della squadra non migliora affatto.

Metriche di base

Esistono molti modi per separare le metriche. Forse il più basilare è dall’alto verso il basso e dal basso verso l’alto.

➡️ Dall’alto verso il basso significa: noi dirigenti creeremo per voi metriche che vogliamo che tutti voi soddisfiate e il vostro obiettivo finale è quello di inserirvi nelle aree verdi di quelle. Non ci importa se tu – una squadra come loro o no; questo è ciò che vogliamo tracciare.

➡️ Dal basso verso l’alto significa: noi, il team, dobbiamo migliorare in quelle aree e, per questo, dobbiamo concentrarci su queste cose. Pertanto, definiamo metriche che ci consentiranno di monitorare i progressi del team verso i nostri obiettivi e possiamo dimostrare a te – leadership come esattamente ha migliorato il nostro lavoro nel tempo.

Definizione di buona metrica

Allora, cosa dovrebbe contenere una buona metrica o come descriverla?

La proprietà più importante è la modifica del comportamento. Ciò significa che ogni volta che guardi l’esito della metrica, è chiaro cosa deve cambiare all’interno del team per ottenere miglioramenti.

Allora deve essere semplice. Se non riesci a spiegarlo con poche semplici frasi in modo che tutti gli ascoltatori interessati possano capire, allora qualcosa non va davvero bene.

Una buona metrica è comparabile nel tempo. Scatta un’istantanea dei risultati in un momento, quindi fallo di nuovo qualche tempo dopo. Mettili uno accanto all’altro. Se non riesci a confrontare i due risultati tra loro, dovresti ripensare a questa metrica.

Infine, meglio dei numeri puri, ove possibile, rendilo un rapporto o una percentuale. “10 nuovi difetti aperti durante lo sprint” non diranno molto. Dipende se normalmente ne hai uno o 100.

Ecco alcuni esempi di metriche che ritengo soddisfino tutti questi criteri di definizione. Hanno in mente specificamente i team Agile. Esistono tre categorie principali: prestazioni, qualità e morale.

Categorie di metriche

Metriche delle prestazioni

L’obiettivo è capire quanto è bravo il team a mettersi al passo con le storie commesse all’interno di uno sprint. Per valutare se l’impegno eccessivo non è normale o se le storie di riporto sono uno standard da uno sprint all’altro.

Dal punto di vista delle prestazioni agili, il team deve sforzarsi di fornire il contenuto dello sprint pianificato a cui il team si è impegnato all’inizio dello sprint.

Ciò non significa che non saremo flessibili nello scambio di storie durante lo sprint. Ma dovrebbe essere sempre una trattativa che porti a uno scambio, non a un’aggiunta. La capacità del team non crescerà solo perché qualcuno ha aggiunto nuove storie all’interno dello sprint.

Portiamo questa metrica per fare attenzione a questi casi e guidare tutti i membri del team a proteggere la capacità che hanno per lo sprint.

Questo costruisce l’affidabilità e la prevedibilità della squadra.

#1. Capacità di sprint vs Punti storia consegnati

Guarda la cronologia della capacità dello sprint rispetto ai contenuti dei punti della storia (SP) forniti durante gli sprint.

  • Piccole deviazioni da uno sprint all’altro vanno bene. Enormi salti in qualsiasi direzione segnalano che qualcosa non va.
  • Total Sprint Capacity – il giorno disponibile di un membro del team ne aggiunge uno alla Total Capacity. Ad esempio, se il team ha 10 persone e tutte saranno disponibili in pieno sprint, allora la capacità totale per lo sprint è 100.

Verifica la capacità dello sprint rispetto agli SP completati da uno sprint all’altro. Se il team (durante la pianificazione) si sta impegnando per una quantità significativamente maggiore di SP di quanto il team possa normalmente completare, aumenta questo rischio per il team.

L’obiettivo sarà quello di avere un SP totale pianificato uguale o inferiore al totale di SP completati per sprint.

Puoi comunque avere più SP completati del previsto se il team ha completato (verso la fine dello sprint) tutte le storie pianificate e il team ha ancora la capacità di portare avanti la storia aggiuntiva.

  • Se il team consegna ripetutamente meno SP del previsto, il team deve modificare la sua pianificazione e prendere meno SP nello sprint successivo.

Strumenti come monday.com, Atlassian Jira o Asana forniscono tutti un modo semplice per salvare ed estrarre story point per ogni storia negli sprint. Possono persino generarlo automaticamente per te dopo ogni pianificazione dello sprint.

#2. Grafico Burndown

Questa è una delle metriche che probabilmente la maggior parte dei team di mischia ha nascosto da qualche parte nella dashboard. Sono d’accordo che potrebbe anche sembrare una cosa inutile da avere. La squadra raramente lo prende in considerazione. Piuttosto, al manager piace sottolineare come le storie appaiono da un livello alto e come non stanno progredendo bene (poiché sono tutte aperte per l’intero sprint).

Quello che vorrei sottolineare è che, nonostante ciò, tu come squadra dovresti andare a controllare il grafico del burndown per il tuo bene. Se tutte le storie sono aperte per l’intero sprint e chiuse solo l’ultimo giorno dello sprint, ciò crea incertezza all’interno del team e verso il completamento degli obiettivi dello sprint.

  • Rivedi la tua sprint board per le storie completate.
  • Verificare con il team per determinare perché le piccole storie sono ancora aperte, anche se sono iniziate all’inizio dello sprint.
  • Lavora con il team per costruire quella mentalità, non per tenere aperte le storie più a lungo del necessario.
  • Il grafico di burndown ideale è solitamente uno stato teorico. Tuttavia, più ci avviciniamo, più efficace sarà la gestione della storia.

Strumenti di gestione agile come Asana possono generare automaticamente un grafico di burndown per ogni sprint.

Fonte: www.asana.com

#3. Completamento obiettivo sprint

Tiene traccia della percentuale di Sprint Goals che hai completato durante ogni sprint.

Documenti gli Sprint Goals separatamente, ad esempio, sulla pagina Confluence/Jira, per ogni sprint. Lo stato sarà assegnato indipendentemente dal fatto che siano stati raggiunti o meno durante lo sprint.

Anche se il team non ha completato tutte le storie all’interno di uno sprint, potrebbe comunque raggiungere lo Sprint Goal (ad esempio, mancano solo le storie secondarie).

Mireremo al 100% del completamento degli Sprint Goals in ogni sprint. In caso contrario, scopri cosa sta impedendo il team.

  • Se ci sono troppi argomenti paralleli in ogni sprint, riducine la quantità.
  • Se durante lo sprint vengono aggiunte troppe storie ad hoc, riducilo in modo che non influisca sugli obiettivi dello sprint originale.
  • Se gli obiettivi dello sprint sono troppo grandi o troppo impegnativi, rendilo più semplice. In ogni caso non ha senso avere grandi obiettivi di sprint senza raggiungerli entro la fine dello sprint.

Metriche sulla qualità del codice

Questo monitorerà quanto è buono il codice nel tempo. Aiuta a mantenere sani i processi di sviluppo e riduce il tempo dedicato alla risoluzione dei problemi. O il tempo di inattività dello sviluppatore causato dall’attesa dell’esecuzione del codice durante le attività di sviluppo e test.

Fonte: azuredevopslabs.com

#1. Test automatici

Crea unit test automatizzati dagli sviluppatori per ogni modifica apportata.

  • Misura la copertura del codice mediante test automatizzati: usa Azure Pipelines o SonarCloud per eseguire i test. Punta a una copertura dell’85%. Oltre il 90% non è realmente efficiente.
  • Assicurati che la creazione automatizzata di unit test faccia parte della definizione di fatto per le nuove storie.
  • Resta al passo con la vecchia copertura del test del codice come parte delle storie di debito tecnico nell’arretrato.

#2. Complessità del codice

Valuta le complicazioni inutili che il codice sta ottenendo nel tempo e risolvilo attivamente con storie di debiti tecnici. O impedire che accadano, se possibile.

Definisci standard di codice e linee guida per educare gli sviluppatori a seguirli. Assicurati che si attengano alle regole di codifica per ridurre al minimo l’irragionevole aumento della complessità del codice. Aggiornare regolarmente le linee guida sulla base dell’esperienza del team.

Identifica gli odori del codice: indicatori di potenziali problemi nel codice, come codice duplicato, metodi lunghi e variabili inutilizzate.

Le revisioni tra pari devono garantire che gli standard del codice vengano applicati al codice appena creato.

Usa strumenti come dashboard e report di Azure Ado o SonarCloud per rilevare problemi di codice.

#3. Passaggi manuali nella distribuzione

Tieni traccia di quanti passaggi manuali il team deve eseguire per rilasciare il codice negli ambienti di test o di produzione.

  • Il nostro obiettivo sarà quello di raggiungere lo 0 qui nel tempo.
  • Crea storie di debito tecnico, se necessario, per portare la pipeline di distribuzione/rilascio fino alla roadmap di automazione. Riduci gradualmente i passaggi manuali rimanenti nei processi da uno sprint all’altro.

Metriche morali

Questa è una metrica per tenere traccia di come il team si sente riguardo al proprio lavoro e ai processi che affrontano quotidianamente.

#1. Adempimento retrospettivo Sprint

Puoi tenere traccia di quanti elementi di azione sono stati effettivamente completati nello sprint successivo.

  • Lo Scrum Master raccoglierà i risultati della riunione retrospettiva nelle pagine del team per tenere traccia degli elementi di azione concordati.
  • Il team avrebbe quindi tenuto traccia dei progressi.
  • La gestione del progetto può quindi verificare se gli elementi di azione stanno progredendo o cosa impedisce al team di completarli. Quindi modificare l’ambiente per consentire al team di progredire negli elementi di azione concordati.

Almeno il 33% o 1 (a seconda di cosa è più alto) degli elementi di azione dello sprint precedente verrà adottato negli sprint successivi.

Se è inferiore, sono necessarie modifiche per consentire al team di implementare i miglioramenti concordati.

Gli strumenti di gestione del progetto contengono modelli pronti all’uso per attività retrospettive di sprint. Ecco un esempio da monday.com:

Fonte: monday.com

#2. Collaborazione di squadra

Programmazione delle coppie di binari.

  • Forma una coppia naturale per storia per lavorare insieme, condividendo osservazione, conoscenza e successo. Crea attività secondarie nelle storie di proprietà di diversi membri del team.

Tieni traccia delle revisioni del codice dalle iniziative dei colleghi.

  • Ai colleghi viene chiesto o intraprendono azioni proattive per rivedere l’output della storia di qualcun altro.

La metrica può essere estratta dalla bacheca monday.com/Asana/Jira dalle attività secondarie.

Almeno il 50% delle storie nello sprint deve essere condiviso dai membri del team. Se è inferiore, indaga sui motivi e intraprendi azioni laddove ha senso.

Per revisioni tra pari volontarie, tieni traccia delle storie con attività secondarie dedicate. All’inizio, il 20% delle storie di codice riviste in questo modo è un buon inizio. Gradualmente durante gli sprint, dovrai incoraggiare e motivare il team a lavorare in modo più collaborativo e aumentarlo verso il 50% delle storie di codice per sprint come obiettivo.

#3. Debito tecnico vs. Storie di nuove funzionalità

Fonte: atlassian.com

Dare al team l’opportunità di risolvere i propri debiti aumenterà la soddisfazione del team per il proprio lavoro.

  • Al contrario, l’accumulo di problemi di debito tecnologico senza un piano per risolverli progressivamente demotiva il team nel tempo. E la soluzione diventerà più instabile, complessa e difficile da risolvere senza una sostanziale rielaborazione.

Il team sa meglio cosa non funziona bene con la soluzione, anche se le parti interessate o gli utenti finali non lo vedono. Tali storie hanno il maggiore impatto sul team di sviluppo stesso. Per le parti interessate, potrebbero essere invisibili. Ecco perché è importante dare al team la possibilità di lavorare su storie che li aiutino a sgombrare le attività di sviluppo.

L’obiettivo è tenere traccia di quante storie di debiti tecnici sollevati vengono risolte nel tempo e se l’arretrato di tali storie cresce o meno.

Il team può etichettare le storie come TechDebt nel backlog e dare loro la priorità dal team, in modo che possano andare in cima ed essere selezionate negli sprint.

A seconda dello stato in cui si trova il progetto e del numero di debiti tecnologici identificati nel backlog, potresti voler assicurarti che il backlog TechDebt non cresca di oltre il 10% da uno sprint all’altro.

Dai la priorità alle storie di debito tecnologico e includile negli sprint per tenere sotto controllo la crescita del debito arretrato tecnologico in modo che il team possa lavorare sulle storie di debito tecnologico il 10-20% delle volte ogni sprint.

Parole finali

Ogni progetto alla fine avrà bisogno di alcune metriche, sia perché la leadership vuole averle o perché il team decide di misurare il proprio successo.

Il meglio che puoi fare è iniziare a costruire la tua libreria di metriche pronte per essere raccolte e utilizzate; prima è meglio è. E mentre lo fai, assicurati di scegliere sempre soprattutto metriche che cambiano il comportamento.

Successivamente, controlla i processi malsani che possono rovinare il tuo sprint.