«Facciamo un grafico del tempo di ciclo» tende a trasformarsi in un piccolo progetto a sé. Azure DevOps non ne disegna uno pronto all'uso, quindi il passo successivo di solito è collegare Power BI al feed OData di Analytics o a una vista di Analytics, costruire un report e trovare un posto dove ospitarlo e condividerlo: più un posto Power BI Pro per chiunque debba aprirlo. È un percorso perfettamente valido se usi già Power BI per altri report, o se hai bisogno di combinare i dati di Azure DevOps con numeri provenienti da altrove. Ma è molto lavoro di impostazione, se tutto ciò che volevi era vedere quanto tempo richiede il lavoro del tuo team.
Di cosa ha davvero bisogno un grafico del tempo di ciclo
Riducendolo all'essenziale, una vista utile sul tempo di ciclo ha bisogno di quattro cose: un timestamp di inizio e fine per ogni elemento, basato sulla mappatura delle fasi del flusso di lavoro del tuo stesso team (non un'ipotesi generica su cosa significhi «in corso»); una suddivisione per tipo di lavoro, perché un bug e una funzionalità di più settimane non appartengono alla stessa riga; un'idea della dispersione, non solo una media: una mediana e un percentile più alto, così un elemento molto lento non può trascinare silenziosamente il numero principale; e un modo per sapere quando è onesto, se il campione è piccolo. Niente di tutto questo richiede uno strumento di BI generico. Richiede di leggere la cronologia degli elementi di lavoro che Azure DevOps ha già e di eseguire lo stesso calcolo, in modo coerente, ogni volta che apri la schermata.
La vista Tempo di ciclo
È esattamente ciò che fa la vista Tempo di ciclo di Agile Gauge: un punto per ogni elemento consegnato negli ultimi sei sprint, suddiviso in lavoro pianificato, bug ed esplorazione, con linee di riferimento per la mediana e l'85° percentile. Quando un gruppo non ha abbastanza elementi consegnati da rendere significative quelle linee, semplicemente non vengono disegnate, invece di essere estrapolate silenziosamente da tre punti dati e presentate come se avessero un significato.
Ogni punto è un elemento di lavoro reale
Un grafico a dispersione che non riesce a rispondere a «quale elemento era quello?» è di poca utilità in una conversazione reale. Fai clic su un punto qualsiasi, su una riga qualsiasi della tabella accanto al grafico, o su una delle linee dei percentili, e si apre un pannello condiviso dell'elemento che mostra esattamente quali elementi di lavoro ci sono dietro, incluso il percorso reale di ciascun elemento attraverso le fasi mappate del tuo team: dove si è fermato, e per quanto tempo. La tabella accanto al grafico esiste per lo stesso motivo: non esiste un modo accessibile per navigare un grafico a dispersione con la sola tastiera, quindi la tabella non è una cortesia, è la risposta alla stessa domanda che il grafico sta rappresentando.
Perché una mediana e un 85° percentile, non una sola media
Un unico tempo di ciclo medio nasconde proprio la cosa più utile da sapere: quanto sia realmente coerente il team. Due team possono registrare la stessa media e trovarsi in situazioni completamente diverse: uno che finisce quasi tutto in una fascia ristretta, l'altro che finisce la maggior parte degli elementi rapidamente ma ne trascina alcuni per settimane. La mediana ti dice come appare un elemento tipico; l'85° percentile ti dice su cosa pianificare per gli elementi che non vanno lisci. Nessuna delle due linee viene disegnata finché non c'è abbastanza lavoro consegnato in quel gruppo da sostenerla: un team con tre bug consegnati in questa finestra vedrà i punti e la tabella, ma non una linea di percentile inventata da tre punti e presentata come se fosse una misurazione stabile.
Leggere lo sprint, non solo i punti
Sopra il grafico, una striscia di lettura riporta gli stessi valori con le loro variazioni rispetto alla finestra precedente, più una riga di affidabilità che dichiara apertamente quanto ci si possa fidare dei numeri attuali dato il campione che li sostiene. I filtri per gruppo e per finestra restringono la vista a un tipo di lavoro specifico o a un diverso intervallo di sprint: passare il filtro di gruppo a «Bug», ad esempio, risponde a «i nostri bug sono davvero più veloci delle nostre funzionalità, o è solo un'impressione» senza che nessuno debba ricorrere a un foglio di calcolo. Un pulsante Esporta CSV è presente per il momento in cui qualcuno vuole davvero consegnare i numeri grezzi a qualcun altro: anche, se è lì che si finisce, per un report Power BI tutto tuo.
Dove questo non sostituisce Power BI
Questa vista non vuole essere uno strumento di reportistica generico, e non dovrebbe esserlo. Se hai bisogno di combinare i dati di Azure DevOps con numeri provenienti da altri sistemi, costruire report cross-progetto completamente personalizzati, o se la tua organizzazione fa già affidamento su una presenza Power BI, il percorso nativo Analytics e Power BI resta la scelta giusta: è esattamente per questo che è stato costruito. A cosa serve la vista Tempo di ciclo di Agile Gauge è invece la richiesta molto più comune: «mostrare subito il tempo di ciclo del nostro team, senza che nessuno debba avviare un progetto di reportistica per arrivarci».
Come arrivarci
Non c'è nessuna connessione OData da configurare né alcun report da costruire prima di vedere qualcosa. Una volta impostata in Configurazione la mappatura delle fasi del flusso di lavoro del tuo team, un passaggio da fare una sola volta, da cui dipende ogni vista dell'hub, Tempo di ciclo legge i tuoi ultimi sei sprint e disegna il grafico. Se non hai ancora toccato Configurazione, la schermata te lo dice apertamente, invece di indovinare una mappatura e mostrarti numeri basati su un'ipotesi.
Agile Gauge legge direttamente dalla tua stessa organizzazione Azure DevOps: niente viene copiato su un server da noi gestito. Avvia una prova di 14 giorni, tutte le funzionalità, nessuna carta richiesta.