3 rapporti di burndown agili e come usarli

Le pratiche agili, per chi non lo sapesse e per i meno informati, a volte possono apparire come metodologie di sviluppo software e di gestione dei progetti ad hoc. La verità è molto diversa.

Uno dei 12 principi del software agile afferma: "Le migliori architetture, requisiti e progettazione emergono da team che si auto-organizzano", ma la maggior parte delle organizzazioni che applicano pratiche agili, inclusi Scrum e Kanban, applicano alcuni rigori e rituali significativi. Ad esempio, molte organizzazioni implementano pratiche di pianificazione agile tra cui la stima del punto della storia, gli standard di architettura e le discipline di gestione dei rilasci per migliorare l'impatto aziendale, la qualità e l'affidabilità dei rilasci delle applicazioni.

La maggior parte dei team sceglie di utilizzare uno strumento agile come Jira Software o Azure DevOps per gestire i backlog, gli sprint e la collaborazione tra i team agili. Lo scopo principale di questi strumenti è gestire centralmente i requisiti, lo stato dello sprint, il flusso di lavoro e la collaborazione tra i membri del team agile e più team agili. Tuttavia, maggiore è il rigore che le organizzazioni mettono nell'utilizzo di questi strumenti, più questi strumenti possono aiutare i leader e i team a identificare i problemi, riferire alle parti interessate sullo stato e migliorare la loro esecuzione.

Uno dei rapporti predefiniti più comuni è il rapporto di burndown. Poiché le pratiche agili consentono ai proprietari dei prodotti di ridefinire le priorità del backlog in base al feedback dei clienti, i report tradizionali come i diagrammi di Gantt non riescono a catturare la natura fluida dell'esecuzione agile. Fondamentale per il grafico burndown è che tiene conto del lavoro completato, del nuovo lavoro aggiunto all'ambito e di altre modifiche dell'ambito. Il grafico Burndown può fornire una rapida immagine di come le squadre stanno avanzando verso i loro obiettivi.

Lettura di un grafico burndown sprint di base

I grafici Burndown di solito hanno il tempo sull'asse xe le stime sull'asse y. Molti team stimano in story point, ma molti strumenti agili possono rappresentare graficamente i burndown in base al numero di storie o stime in ore. Per questo articolo, presumo che vengano utilizzati gli story point.

Il report Burn-down dello sprint traccia il numero di story point che rientrano nell'ambito dell'intervallo di tempo. Man mano che il team completa le storie, il grafico mostra come stanno "bruciando" l'elenco delle storie e altri tipi di lavoro (problemi in Jira, tipi di elementi di lavoro in Azure DevOps) fino al completamento del lavoro o al termine dello sprint. Quando le squadre completano il lavoro impegnato nello sprint, la linea tracciata interseca l'asse x, indicando che tutto è stato fatto.

Lo sprint burndown è il più semplice da concettualizzare. Il primo giorno dello sprint, il team si impegna ad alcune storie e al numero totale di story point. Se rivedi il grafico del burndown di quel giorno, dovresti vedere un singolo punto sull'asse y che rappresenta il numero di punti su cui la squadra si è impegnata nel giorno zero dello sprint.

Man mano che le storie vengono contrassegnate come completate, lo sprint burndown mostra il numero di punti rimanenti da completare.

Come viene utilizzato in pratica uno sprint burndown? Un burndown sano mostra una curva lineare e idealmente esponenziale fino a zero. Se la curva ha una pendenza piatta nella prima parte di uno sprint, può indicare blocchi o molto lavoro in corso e che lo sprint potrebbe essere a rischio. Un burndown piatto o con pendenza lenta può essere molto problematico se vengono eseguiti molti test su storie con codice completo e se il lavoro di test non può iniziare fino agli ultimi giorni dello sprint.  

Un burndown di sprint in rapida discesa è generalmente una buona cosa, ma può indicare che il team non si sta impegnando o ha scelto di affrontare solo storie più piccole nello sprint.

I burndown epici tengono traccia dei progressi rispetto ai driver aziendali e tecnici

I burndown degli sprint sono molto utili per monitorare l'esecuzione a breve termine e aiutano i team a soddisfare con successo gli impegni di sprint. Per monitorare meglio i progressi rispetto agli obiettivi a lungo termine, i burndown epici e di rilascio forniscono la visibilità necessaria.

I burndown epici funzionano meglio quando i team definiscono diversi sforzi a lungo termine, come l'implementazione delle principali funzionalità degli utenti finali, strategie di debito tecnico, miglioramenti delle prestazioni o evoluzioni dei processi. Per sfruttare i burndown epici, il backlog dovrebbe avere:

  • Tra cinque e 15 epopee che dureranno almeno diversi mesi e richiederanno sei o più sprint per essere completati.
  • Caratteristiche, storie e trame della storia che si susseguono sotto l'epica e rappresentano un piano di alto livello da eseguire sull'epica.
  • Stime di alto livello, idealmente in story point per ogni storia o stub di storia che si accumula sotto l'epica.

Una volta che questi sono in atto, l'epico burndown traccia le modifiche a questo piano. Il suo asse x rappresenta gli sprint e l'asse y rappresenta la stima totale delle storie e degli stub della storia assegnati all'epopea. Nell'epico grafico burndown di Jira Software, vedi un grafico a barre con un colore che rappresenta le storie completate nello sprint e un secondo che mostra i punti della storia aggiunti. I punti storia aumentano quando nuove storie o stub di storia vengono aggiunti all'epica o quando le stime cambiano.

Esistono diversi modi per utilizzare l'epic burndown chart:

  • Illustra la velocità di completamento delle caratteristiche e delle storie rispetto al piano. Quando i piani sono accurati e la velocità della squadra coerente, può fornire un indicatore quando il lavoro dell'epopea è completato.
  • La maggior parte dei piani agili non è completa ei team aggiungono, modificano e rimuovono storie in base al feedback degli utenti finali, alla scoperta di complessità tecniche e per affrontare il debito tecnico introdotto durante il viaggio. Il burndown epico indica quindi quanto lontano dal piano si basa l'epica su quanto sta crescendo il backlog rispetto al completamento sprint per sprint.
  • I burndown epici aiutano anche a confrontare gli sforzi su più sprint e valutare quanto lavoro di pianificazione e consegna viene svolto in un epico rispetto ad altri.

I burndown dei rilasci informano i team se i rilasci raggiungeranno la data e l'ambito

I team avanzati che automatizzano completamente le pipeline di distribuzione con integrazione continua, test continui e distribuzione continua potrebbero non aver bisogno di burn-down di rilascio. I team che distribuiscono frequentemente dovrebbero tenere traccia delle funzionalità e delle storie legate al rilascio, ma il burndown del rilascio non è molto utile poiché spesso tiene traccia dei progressi per sprint.

Per altri team che seguono le pratiche di gestione dei rilasci e standardizzano sui rilasci multisprint, il burndown del rilascio può essere lo strumento più importante del proprietario del prodotto e del team.

Il burndown della versione è simile al burndown epico tranne che invece di tenere traccia delle funzionalità, delle storie e degli stub della storia assegnati a un'epica, il burndown della versione mostra cosa è assegnato a una versione. L'asse e le barre sono quindi identiche ai burndown epici.

I team che utilizzano i burndown di rilascio possono quindi tenere traccia dell'ambito e della sequenza temporale per un rilascio. Le squadre che sono in pista vedranno una pendenza bruciata fino all'asse x con una pendenza coerente con la velocità della squadra. Le versioni che potrebbero deviare dal binario hanno una pendenza minore o descrivono più punti della storia aggiunti (quando viene aggiunto più ambito alla versione) rispetto a ciò che viene completato.

Jira Software ti aiuta con queste proiezioni. Supponendo che il team abbia lavorato al progetto per almeno tre sprint, Jira Software calcolerà una velocità media del team e predirà lo sprint finale per un rilascio basato su questa velocità.

Gli sprint, epic e release burndown offrono ai team alcuni strumenti facili da usare per allinearsi agli obiettivi. Quando i team hanno una comprensione condivisa dell'ambito, concordano le priorità, pianificano diversi sprint in anticipo e taggano le storie nel loro backlog in modo appropriato, i burndown raccontano se la pianificazione e l'esecuzione sono allineate con gli obiettivi. Quando non lo sono, sono uno strumento basato sui dati che può alimentare la discussione su quali aggiustamenti potrebbero essere necessari.