Procedure consigliate per la gestione dei progetti Agile

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Azure Boards offre una scelta di strumenti di pianificazione Agile, molti dei quali funzionano in combinazione tra loro. Questo articolo fornisce una guida introduttiva per i project manager nuovi in Azure Boards. Se l'utente e i team vogliono adottare un approccio di rilevamento minimo per pianificare e gestire i progetti, iniziare con questa guida. Inoltre, se si passa dalla gestione dei progetti a cascata ai metodi Agile, iniziare con questa guida.

Nota

Se il team si impegna a praticare metodi Kanban o Scrum, vedere Informazioni su Boards e Kanban o esercitazioni per l'implementazione di Scrum.

La maggior parte delle indicazioni contenute in questo articolo è valida sia per il cloud che per le versioni locali. Tuttavia, alcune delle funzionalità incluse in questo articolo, ad esempio Rollup, Analytics e alcuni strumenti di pianificazione portfolio, sono attualmente disponibili solo per il cloud.

Configurare i team

Azure Boards offre a ogni team un set di strumenti Agile per pianificare e tenere traccia del lavoro. Ogni progetto definisce un team predefinito, che è possibile iniziare immediatamente a usare. Se si hanno diversi team di sviluppo o funzionalità, è consigliabile definire un team in Azure DevOps per ogni team di funzionalità. In questo modo, ogni team può lavorare in modo autonomo collaborando tra loro.

Suggerimenti sulle procedure consigliate

  • Configurare i team lungo i flussi di valore che l'organizzazione vuole distribuire.
  • Definire un team per ogni gruppo di sviluppo da 6 a 12 sviluppatori.
  • Configurare i team di sviluppo per supportare il rollup ai team delle funzionalità di gestione dei progetti.

Per altre informazioni sulla configurazione dei team, vedere:

Configurare gli sprint

Gli sprint specificati dai percorsi di iterazione vengono definiti per un progetto e quindi selezionati dai team. La frequenza di uno sprint può variare da una settimana a quattro settimane o più. È anche possibile definire sprint all'interno di una gerarchia che include i training di rilascio. Si assegna il lavoro agli sprint che i team si impegnano a recapitare alla fine dello sprint. Questi strumenti di Azure Boards si basano sulle assegnazioni di sprint ai backlog sprint, agli taskboard e ai piani di previsione e recapito di un team.

Suggerimenti sulle procedure consigliate

  • Definire una cadenza sprint per l'uso da parte di tutti i team all'interno del gruppo di prodotti.
  • Definire almeno sei o più iterazioni che supportano la pianificazione per i prossimi 6-12 mesi.
  • Determinare in che modo i team usano le iterazioni per gestire gli elementi di backlog.
    • Il lavoro sprint non assegnato viene assegnato al backlog predefinito.
    • Il lavoro sprint non assegnato viene assegnato a uno sprint di backlog futuro designato.

Per altre informazioni sulla configurazione degli sprint, vedere:

Scegliere i tipi di elemento di lavoro

Determinare i tipi di elemento di lavoro che il team può usare per acquisire i requisiti dei clienti e il lavoro di sviluppo. Se il progetto è basato sul processo Agile, è consigliabile usare i tipi di elemento di lavoro User Story, Bug e Feature.

Se il progetto si basa su un altro processo, ad esempio Basic, Scrum o CMMI, sono disponibili le opzioni seguenti. Ogni team determina come vogliono tenere traccia dei bug.

L'immagine seguente mostra la gerarchia per l'elemento di lavoro del backlog del processo Agile:

  • Le storie utente e le attività vengono usate per tenere traccia del lavoro.

  • I bug tengono traccia dei difetti del codice.

  • Le epiche e le funzionalità vengono usate per raggruppare il lavoro in scenari più grandi.

    Diagramma che mostra i tipi di elemento di lavoro Agile.

Ogni team può configurare la modalità di gestione degli elementi di lavoro bug, allo stesso livello degli elementi di lavoro della storia utente o dell'attività, configurando l'impostazione Utilizzo dei bug . Per altre informazioni sull'uso di questi tipi di elemento di lavoro, vedere Processo Agile.

Nota

I requisiti specificano le aspettative degli utenti per un prodotto software. In Azure Boards i requisiti sono definiti dagli elementi di lavoro visualizzati nel backlog del prodotto. Corrispondono ai tipi di elemento di lavoro User Story (Agile), Product backlog item (Scrum), Issue (Basic) o Requirement (CMMI) in base al processo selezionato per il progetto. Appartengono anche alla categoria Requisiti, che gestisce i tipi di elemento di lavoro visualizzati nel backlog del prodotto.

Suggerimenti sulle procedure consigliate

  • Usare il tipo di elemento di lavoro Funzionalità per acquisire le funzionalità dei clienti da spedire.
  • Aggiungere rapidamente funzionalità o requisiti dal backlog e compilare i dettagli in un secondo momento.
  • Usare il tipo elemento di lavoro Requisito per suddividere le funzionalità nel lavoro di cui è proprietario il team di sviluppo. Inoltre:
    • Per Agile, usare il tipo di elemento di lavoro User Story.
    • Per Basic, usare il tipo di elemento di lavoro Problema.
    • Per Scrum, usare il tipo di elemento di lavoro Elemento backlog prodotto.
    • Per CMMI, usare il tipo di elemento di lavoro Requisito.
  • Usare il tipo di elemento di lavoro Bug per acquisire i difetti del codice.
  • Eseguire il mapping dei requisiti alle funzionalità per tenere traccia dello stato di avanzamento a livello di gestione del progetto.
  • Requisiti di dimensione da completare all'interno di uno sprint.
  • Ridimensionare le funzionalità da completare all'interno di uno sprint o di più sprint.
  • Ridimensionare gli elementi di lavoro Epic da recapitare trimestralmente o a un obiettivo cardine.
  • Consentire agli sviluppatori di usare la categoria Attività per suddividere il lavoro in base alle esigenze.

I project manager gestiscono le funzionalità e il team di sviluppo gestisce i requisiti. Quando si esegue il mapping usando i collegamenti padre-figlio, si ottiene visibilità sullo stato di avanzamento delle funzionalità. A ogni elemento di lavoro aggiunto al backlog del team viene assegnato automaticamente il percorso di area predefinito e il percorso di iterazione impostati per il team.

Se sono presenti iniziative o scenari di dimensioni maggiori che richiedono la spedizione di diverse funzionalità, raggrupparli nella categoria Epic usando i collegamenti padre-figlio.

Per altre informazioni sui tipi di elementi di lavoro, vedere:

Creare il piano di prodotto

Creare il piano di prodotto usando il backlog delle funzionalità. Il team di sviluppo crea quindi il piano di prodotto usando il backlog del prodotto. Periodicamente, è consigliabile rivedere e perfezionare i piani di prodotto.

Backlog delle funzionalità

I project manager avviano il piano di prodotto aggiungendo funzionalità al backlog delle funzionalità. Ogni funzionalità deve rappresentare un risultato finale spedibile che soddisfa le esigenze di un cliente.

Screenshot che mostra un backlog delle funzionalità.

Backlog di prodotto

I team di sviluppo aggiungono storie utente al backlog del prodotto in modo che alla storia utente venga assegnato automaticamente il percorso di area predefinito e l'iterazione del team. È quindi possibile eseguire il mapping di tali storie in ogni funzionalità che rappresenta il lavoro necessario per implementare la funzionalità. Ogni storia utente deve essere ridimensionata in modo che possa essere completata all'interno di uno sprint.

Screenshot che mostra un backlog del prodotto.

Perfezionare ogni backlog

Esaminare periodicamente ogni backlog eseguendo le attività seguenti:

  • Definire il lavoro da eseguire.
  • Riordinare gli elementi di lavoro usando il metodo di trascinamento della selezione in modo che vengano visualizzati in ordine di priorità.
  • Aprire gli elementi di lavoro e aggiungere dettagli.
  • Assegnare il lavoro ai membri del team o agli sprint.
  • Acquisire il debito tecnico e il lavoro non di avanzamento necessari per supportare un ecosistema sano di consegna.
  • Eseguire il mapping di operazioni non corrispondenti alle funzionalità a cui appartiene.
  • Stimare le dimensioni dei requisiti per determinare la velocità del team e supportare la previsione (facoltativa).

Suggerimento

È possibile monitorare la velocità del team in base alle stime assegnate al lavoro completato o a un semplice conteggio degli elementi di lavoro completati durante gli sprint. Per usare la funzionalità Previsione, è necessario assegnare un valore al campo Story Points, Effort o Size . Se non si vogliono stimare i requisiti, è sufficiente assegnare un valore pari a 1 alle stime dei requisiti e quindi usare lo strumento Previsione in base a un conteggio degli elementi di lavoro.

Suggerimenti sulle procedure consigliate

  • Perfezionare periodicamente il backlog.
  • Assicurarsi che le funzionalità e i requisiti siano dimensionati in modo appropriato.
  • Definire i criteri di accettazione e la definizione delle operazioni eseguite per le funzionalità e il lavoro.
  • Eseguire il mapping del lavoro non mappato alle funzionalità.
  • Impostare le opzioni di visualizzazione per supportare le attività di backlog da eseguire.
  • Prevedere il backlog.

Per altre informazioni, vedi:

Usare i tag per supportare query e filtri

Con i tag degli elementi di lavoro, i membri del team possono assegnare tag ad hoc agli elementi di lavoro. È possibile usare questi tag per filtrare backlog e bacheche. È anche possibile usarli per eseguire query sugli elementi di lavoro. Per rendere utili i tag al team, fornire indicazioni generali sul modo in cui il team deve usare i tag. Valutare la possibilità di documentare queste linee guida in una posizione centrale, ad esempio il wiki del progetto.

L'immagine seguente illustra una scheda Kanban filtrata sulla parola chiave Web che visualizza le schede con il Web tag .

Screenshot che mostra una scheda Kanban filtrata usando la ricerca con parole chiave.

Suggerimenti sulle procedure consigliate

  • Disporre di un criterio sul modo in cui i team usano i tag.
  • Indicare come usare i tag per supportare query, filtri e report.
  • Prendere in considerazione l'uso di tag per identificare le dipendenze tra team o tra progetti.

Per altre informazioni, vedi:

Pianificazione delle previsioni e delle attività cardine

Per ottenere informazioni dettagliate sulle funzionalità che possono essere fornite quando, usare lo strumento Previsione. Questo strumento richiede di fornire stime al campo Story Points, Effort o Size per ogni requisito. Se si vuole prevedere un semplice conteggio degli elementi di lavoro, assegnare il valore 1 alle stime dei requisiti.

Ordinare il backlog delle funzionalità nell'ordine di priorità

In qualità di project manager, è consigliabile avere sempre il backlog delle funzionalità in ordine di priorità, che comunica al team di sviluppo le funzionalità più importanti da completare per prime.

In questo caso, il backlog delle funzionalità mostra la sequenza di funzionalità da spedire.

Screenshot che mostra un backlog delle funzionalità ordinato in base all'elemento padre della funzionalità.

Ordinare il backlog dei requisiti in base alle funzionalità padre

Prima di tutto, si vuole assicurarsi di completare i requisiti necessari per la spedizione delle funzionalità. Come illustrato nell'immagine seguente, il backlog dei requisiti viene ordinato in base alle funzionalità da spedire. L'ordinamento presuppone che tutti i requisiti di una funzionalità siano completi per la spedizione. Inoltre, i punti story vengono assegnati a ogni storia utente.

Screenshot che mostra un backlog dei requisiti ordinato in base all'elemento padre della funzionalità.

Prevedere il backlog dei requisiti

Con le stime assegnate a ogni requisito, è possibile impostare una velocità del team. Nell'esempio seguente si specifica 12 per la velocità, che equivale a indicare che in media il team può completare 12 punti storia per sprint. Lo strumento Forecast mostra i requisiti e le funzionalità che il team può completare entro i sei sprint successivi. Quando si usa lo strumento di pianificazione, è possibile assegnare rapidamente i requisiti agli sprint previsti.

Per visualizzare l'immagine completa, fare clic sull'immagine da espandere. Scegliere l'icona icona di chiusura di chiusura da chiudere.

Screenshot che mostra la previsione di un backlog dei requisiti ordinato in base all'elemento padre della funzionalità.

Ottenere stime valide e avere velocità prevedibili del team sono obiettivi utili del team per il miglioramento del processo.

Aggiornare la scheda Funzionalità

Con una previsione di quando viene fornita una funzionalità, è possibile aggiornare il percorso di iterazione di ogni funzionalità. Assegnare rapidamente valori a una funzionalità aggiungendo tali campi alla scheda sulla scheda kanban, come illustrato nell'immagine seguente.

Screenshot che mostra una scheda Funzionalità con percorsi di iterazione aggiornati.

Pianificazione cardine

I marcatori cardine non vengono usati nel rilevamento delle attività di Azure Boards, ad eccezione dei piani di recapito. I piani di recapito forniscono una visualizzazione del calendario e consentono di definire un marcatore cardine. È possibile usare una o più delle opzioni seguenti per contrassegnare un elemento di lavoro come attività cardine:

Gestire le dipendenze

In Microsoft Project le attività che dipendono dal completamento di altre attività collegandole. Per gestire le dipendenze in Azure Boards, è possibile aggiungere collegamenti simili aggiungendo tipi di collegamento predecessore/successore agli elementi di lavoro. Aggiungere questi collegamenti dalla finestra di dialogo Aggiungi collegamento per un elemento di lavoro.

Azure Boards supporta molti tipi di collegamento per tenere traccia del lavoro correlato. Scegliere i tipi di collegamento Predecessore/Successore per tenere traccia dell'uso delle dipendenze. Un modo rapido per collegare gli elementi di lavoro consiste nell'aggiungere un tag agli elementi di lavoro che partecipano alla produzione o all'utilizzo delle dipendenze. Creare una query basata sul tag e quindi aggiungere i collegamenti necessari.

Nella finestra di dialogo Aggiungi collegamento seguente viene illustrato come due elementi di lavoro sono collegati usando il tipo di collegamento Successore.

Screenshot che mostra la finestra di dialogo Aggiungi collegamento con il tipo di collegamento Successore.

Visualizzare le relazioni tra elementi di lavoro

È possibile visualizzare le dipendenze e identificare le dipendenze che presentano problemi con i piani di recapito. Come illustrato nell'immagine seguente, è possibile attivare o disattivare la visualizzazione delle linee di dipendenza tra gli elementi di lavoro collegati. Per altre informazioni, vedere Tenere traccia delle dipendenze usando i piani di recapito.

Screenshot che mostra le righe di dipendenza tra diversi elementi di lavoro.

Con l'estensione Marketplace visualizzazione elementi di lavoro, è possibile visualizzare le relazioni di collegamento tra diversi elementi di lavoro, come illustrato nell'immagine seguente.

Per visualizzare l'immagine completa, fare clic sull'immagine da espandere. Scegliere l'icona icona di chiusura di chiusura da chiudere.

Screenshot che mostra Visualizza relazioni tra elementi di lavoro.

Minimum Viable Product vs. Critical Path Management

Azure Boards non offre una visualizzazione nativa del percorso critico. Le metodologie Agile favoriscono un MVP (Minimum Viable Product) rispetto alla gestione dei percorsi critici. Usando MVP, è possibile identificare il percorso e le dipendenze più brevi assegnando priorità ai tipi di elemento di lavoro Epic, Feature, User Story e Task. Per altre informazioni di contesto, vedere Il percorso critico nei progetti Agile e Esecuzione di un'avvio snella in Azure DevOps.

Suggerimenti sulle procedure consigliate

  • Aggiungere un dependency tag agli elementi di lavoro che partecipano alla gestione delle dipendenze.
  • Usare i tipi di collegamento predecessore/successore per tenere traccia delle dipendenze del lavoro di proprietà di altri team o all'interno di altri progetti.
  • Creare query per tenere traccia, aggiungere e valutare le dipendenze.
  • Usare i piani di recapito per visualizzare le dipendenze da altri team.
  • Usare l'estensione Marketplace visualizzazione elementi di lavoro per visualizzare le dipendenze per un elemento di lavoro specifico all'interno del modulo dell'elemento di lavoro.

Nota

Le estensioni del Marketplace non sono funzionalità supportate di Azure Boards, quindi non sono supportate dal team del prodotto. Per domande, suggerimenti o problemi che si verificano quando si usano queste estensioni, vedere le pagine di estensione corrispondenti.

Per altre informazioni, vedi:

Lavorare negli sprint

Gli sprint consentono al team di sviluppo di concentrarsi sul completamento di un set di lavoro predefinito. Il lavoro assegnato a uno sprint viene visualizzato nel backlog sprint del team. I backlog sprint sono definiti solo per i backlog dei prodotti, non per i backlog del portfolio.

Grafico a burndown sprint

Aggiornando lo stato del lavoro quotidianamente in uno sprint, è possibile tenere traccia dello stato di avanzamento dello sprint con il grafico burndown Sprint, come illustrato nell'immagine seguente.

Screenshot che mostra un grafico burn-down di Analytics Sprint.

Suggerimenti sulle procedure consigliate

Per ogni sprint, eseguire le attività seguenti:

  • Pianificare ogni sprint con il team.
  • Usare il backlog sprint del team per esaminare i risultati finali dello sprint.
  • Assicurarsi che ogni elemento di lavoro sprint sia assegnato a un membro del team.
  • Assicurarsi che ogni elemento di lavoro sia limitato all'ambito del completamento all'interno dello sprint.
  • Assicurarsi che i criteri di accettazione per il lavoro siano ben definiti e compresi.
  • Aggiornare lo stato degli elementi di lavoro sprint man mano che il lavoro passa da Nuovo a Attivo a Stato completato, monitorando il burndown dello sprint.
  • Controllare con altri team le dipendenze da cui dipende il lavoro del team.
  • Monitorare lo stato di avanzamento dello sprint usando il grafico burn-down sprint.

Per altre informazioni, vedi:

Esaminare lo stato di avanzamento e i risultati finali delle funzionalità

I tre strumenti principali da usare per esaminare lo stato di avanzamento e i risultati finali sono:

  • Scheda Kanban
  • Funzionalità di backlog con colonne di rollup
  • Piani di recapito

Scheda Kanban

La scheda Funzionalità è un'altra posizione in cui esaminare lo stato di avanzamento e garantire il flusso continuo dei risultati finali. L'immagine seguente illustra una scheda Funzionalità personalizzata, incluse le colonne in corso, ad esempio Altre informazioni, On Deck, In Progress e Customer Rollout. Queste colonne forniscono un insieme più naturale di stati, poiché le caratteristiche vengono proposte, studiate, progettate, sviluppate e quindi distribuite nell'ambiente di produzione.

Per visualizzare l'immagine completa, fare clic sull'immagine da espandere. Scegliere l'icona icona di chiusura di chiusura da chiudere.

Screenshot che mostra una scheda Funzionalità con colonne personalizzate.

Aggiornamento cumulativo

Un modo rapido e visivo per monitorare lo stato di avanzamento è dal backlog delle funzionalità. Aggiungendo la colonna barra di stato rollup, è possibile visualizzare la percentuale di elementi di lavoro completati per ogni funzionalità, come illustrato nell'immagine seguente.

Screenshot che mostra un backlog delle funzionalità che mostra l'opzione di colonna delle barre di stato.

Piani di recapito e più risultati finali del team

Per esaminare le funzionalità distribuite in più team, configurare un piano di recapito. I piani di recapito offrono una bacheca interattiva per esaminare una pianificazione del calendario di storie o funzionalità che diversi team prevedono di offrire.

Screenshot con callout dei piani di recapito.

Elementi del piano interattivo

Suggerimenti sulle procedure consigliate

  • Personalizzare la scheda Kanban delle funzionalità per supportare i processi del team.
  • Aggiungere campi alle schede in modo da poter aggiornare i valori in modo rapido e semplice.
  • Aggiornare il percorso di iterazione (sprint) delle funzionalità man mano che si ottiene chiarezza su quando vengono spediti.
  • Esaminare la scheda Funzionalità per esaminare lo stato, i blocchi/problemi/rischi/modifiche e lo stato dell'aggiornamento.
  • Usare la funzionalità di filtro per concentrarsi su elementi contrassegnati, funzionalità assegnate da, sprint specifici e altro ancora.
  • Aggiungere colonne di rollup al backlog delle funzionalità per monitorare lo stato di avanzamento complessivo in base al completamento del conteggio degli elementi di lavoro.
  • Usare i piani di recapito per esaminare le funzionalità per diversi team per discutere le dipendenze tra team.

Per altre informazioni, vedi:

Miglioramento del processo

Il miglioramento continuo è al centro dei metodi Agile. Per migliorare i processi, è necessario avere obiettivi condivisi e un piano condiviso. Per avviare attività di miglioramento del processo, è consigliabile aggiungerle tramite procedure regolari. È possibile che si desideri:

  • Pianificare gli sprint.
  • Impostare gli obiettivi dello sprint.
  • Eseguire analisi retrospettive regolari.

Quando si impostano gli obiettivi, tenere presenti le domande seguenti:

  • Cosa stai imparando sui tuoi clienti? Cosa sapere.
  • Quali dati viene misurato? È utilizzabile? Quali dati devono essere misurati?
  • Qual è il flusso dei risultati finali? È come previsto? Dove è possibile apportare miglioramenti?
  • I membri del team sono autorizzati a fare il meglio? Quali strumenti o informazioni potrebbero aiutarli a migliorare?
  • Quanto bene sono le informazioni condivise? Quanto sono i team che collaborano?
  • Quanto bene è il team che gestisce il debito tecnico e chiude i bug?

Alcuni degli strumenti Agile che è possibile usare per supportare il miglioramento del processo sono la velocità del team, i dashboard del team e l'estensione Retrospettiva del Marketplace.

Velocità del team

Dal grafico Velocità del team è possibile ottenere informazioni sul modo in cui il team sta pianificando ed eseguendo uno sprint. Come illustrato nell'esempio seguente, il grafico Velocity mostra il conteggio pianificato, completato, completato in ritardo e numero incompleto di elementi di lavoro per diversi sprint. Teams può esaminare questo grafico per determinare il livello di stima e esecuzione e il modo in cui potrebbero migliorare.

Screenshot che mostra un grafico velocità team di esempio.

Dashboard del team

Teams può definire uno o più dashboard per condividere informazioni e monitorare i dati in tempo reale sullo stato di avanzamento del lavoro.

Screenshot che mostra un dashboard del team di esempio.

Suggerimenti sulle procedure consigliate

  • Identificare gli obiettivi di miglioramento del processo che il team può accettare, annotarli ed esaminarli periodicamente.
  • Usare i dashboard del team per condividere periodicamente informazioni e grafici di rilevamento del lavoro, che l'utente e il team esaminano periodicamente.
  • Chiedere al team di identificare almeno un obiettivo sprint correlato al miglioramento del processo durante le riunioni di pianificazione dello sprint.
  • Condurre analisi retrospettive regolari per acquisire ciò che è andato bene, ciò che non è andato bene e le azioni per migliorare.
  • Mantenere una bacheca di rilevamento dei miglioramenti, ad esempio quella disponibile con l'estensione Retrospettiva marketplace.

Per altre informazioni, vedi:

Passaggi successivi

Configurare e personalizzare Azure Boards

Articoli del settore