Condividi tramite

Informazioni sulla configurazione e la personalizzazione di Azure Boards

  • Articolo

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

È possibile configurare e personalizzare Azure Boards in molti modi, per gestire meglio il portfolio, le dipendenze e il monitoraggio. È consigliabile eseguire le attività descritte in questo articolo, in particolare per gli amministratori responsabili della gestione dei progetti multi-team.

Accesso rapido alle attività comuni:

Personalizza le schede | Gestisci colonne | Accelera il lavoro con le corsie | Configura il tuo backlog.

Nota

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.

Se si è appena iniziato come amministratore del progetto, vedere anche Introduzione come amministratore.

Considerazioni

Per sfruttare al meglio Azure Boards, comprendere come i team usano gli strumenti e le funzioni (ad esempio Scrum, Kanban e Scrumban) e le relative dipendenze da configurazioni e personalizzazioni. La tabella seguente riepiloga gli elementi principali da considerare durante la struttura del progetto.

Livello progetto

  • Quanti team si vogliono definire
  • Come strutturare i percorsi di area per supportare le visualizzazioni di gestione portfolio
  • Personalizzazioni dei campi
  • Tipi di elementi di lavoro personalizzati (WIT)
  • Personalizzazioni del backlog del portafoglio
  • Personalizzazioni del flusso di lavoro

Livello del team

  • Come usare il backlog del prodotto per pianificare e classificare in ordine di priorità il lavoro
  • Sia che si traccino i bug come requisiti o come attività, o che non si utilizzino affatto
  • Indica se si usano o meno attività per tenere traccia del tempo e della capacità
  • Come utilizzare i livelli del backlog di portfolio
  • Come informare l'alta dirigenza del progresso, dello stato e dei rischi

Personalizzare i blocchi predefiniti e gli strumenti di monitoraggio del lavoro per supportare le esigenze aziendali e comunicare le linee guida sull'utilizzo al team.

Tipi di elementi di lavoro e backlog del portfolio

Quando si crea un progetto in Azure Boards, si seleziona prima di tutto un processo. Ogni processo (Agile, Basic, Scrum e CMMI) supporta una gerarchia di tipi di elementi di lavoro (WITs), inclusi i backlog di prodotto e di portafoglio. Le WIT predefinite per ogni processo sono elencate nelle schede corrispondenti, con backlog sotto Requisiti e task sotto Task.

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

Diagramma che mostra i tipi di elemento di lavoro Agile.

  • Le storie utente e le attività vengono usate per tenere traccia del lavoro.
  • I bug tengono traccia dei difetti del codice.
  • Le epics e le funzionalità sono usate per raggruppare il lavoro in scenari più grandi.

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à. Usare l'impostazione Lavorare con i bug. Per altre informazioni sull'uso di questi tipi di elemento di lavoro, vedere Processo Agile.

È possibile aggiungere wit personalizzati a ogni livello e persino aggiungere backlog personalizzati del portfolio. Ecco, ad esempio, un progetto che ha aggiunto obiettivi e risultati chiave come wit personalizzati e backlog del portfolio corrispondenti al processo Scrum.

Obiettivi e risultati chiave come backlog aggiuntivi del portafoglio

I team possono scegliere quali WIT usano per tenere traccia del proprio lavoro. La tabella seguente riepiloga le opzioni principali, l'utilizzo consigliato e le attività e gli strumenti supportati.

Opzioni di rilevamento del lavoro

Attività e strumenti supportati

Solo attività

Non consigliato
Non è possibile immettere rapidamente nuove attività in un backlog né assegnare priorità a un backlog di attività. Inoltre, non è disponibile alcun supporto per le visualizzazioni del calendario, le visualizzazioni tra team o la pianificazione del portfolio

Requisiti con le attività dipendenti dall'elemento figlio

Supporta i metodi Scrum
Consigliato per i team che seguono i metodi Scrum e vogliono tenere traccia del tempo associato al lavoro.

Molti team iniziano a usare i metodi Scrum per tenere traccia e pianificare il lavoro usando gli strumenti disponibili tramite l'hub Sprints. Gli strumenti Sprint supportano la stima e il rilevamento del lavoro rimanente e l'uso della pianificazione della capacità. Se non si prevede di usare questi strumenti, l'aggiunta di attività dipendenti dal figlio è facoltativa. Gli sviluppatori possono aggiungerli come elenco di controllo degli elementi necessari per completare una storia utente o un requisito di backlog.

Requisiti solo, ad esempio storie utente (Agile), problemi (Basic), elementi backlog del prodotto (Scrum), requisiti (CMMI)

Supporta i metodi Kanban e Scrumban
Consigliato per i team che seguono i metodi Kanban o Scrumban, stimare il lavoro usando Story Points, Effort o Size e non tenere traccia del tempo associato al lavoro.

Requisiti raggruppati in WIT di portfolio, ad esempio epiche e funzionalità

Supporta visualizzazioni del calendario, visualizzazioni tra team e pianificazione portfolio
Consigliato per le organizzazioni con diversi team che vogliono visualizzare rollup e visualizzazioni del calendario associate a più team e sfruttare tutti gli strumenti di pianificazione del portfolio.

Opzioni per configurare e personalizzare

La tabella seguente illustra le aree che è possibile configurare e personalizzare e gli strumenti interessati da tali personalizzazioni. È possibile personalizzare ogni area a livello organizzazione, progetto o team, come indicato, o una combinazione di due. Per una descrizione degli strumenti Standard, degli strumenti di analisi e degli strumenti di pianificazione del portfolio, vedere Informazioni su Azure Boards, report nel contesto: Rilevamento del lavoro e Piani (Agile su larga scala).

Configurare o personalizzare

Strumenti standard

Analisi

Strumenti di pianificazione portfolio

Percorsi di area, configurazione del progetto e sottoscrizioni del Team (Progetto, Team)

  • Boards>Tutti gli strumenti
  • Arretrati>Tutti gli strumenti
  • Sprints>Tutti gli strumenti
  • Diagramma di flusso cumulativo
  • Velocità
  • Tendenza burndown
  • Piani di consegna
  • Sequenza temporale delle funzionalità
  • Epica Roadmap
  • Piani portfolio (Beta)

Percorsi di iterazione, configurazione del progetto e sottoscrizione del team (Progetto, Team)

  • Backlog>Pianificazione sprint
  • Sprint> Backlog di sprint
  • Sprints>Capacità sprint
  • Bacheca attività Sprint
  • Velocità
  • Tendenza burndown
  • Piani di consegna
  • Sequenza temporale delle funzionalità
  • Tabella di marcia epica
  • Piani portfolio (Beta)

Mostra bug nei backlog e nelle bacheche (Team)
WIT personalizzati, backlog del prodotto (processo)
WIT personalizzati, Tabellone attività (Processo)

  • Bacheche di prodotti> Bacheca di prodotto
  • Backlog del>prodotto
  • Strumento di mappatura dei backlog>
  • Sprints>Backlog degli sprint
  • Bacheca>attività Sprint
  • Velocità

Wit personalizzati, backlog portfolio (processo)
Altri backlog del portfolio (Processo)

  • Bacheche>Bacheche del portfolio
  • Backlog del>portfolio di backlog
  • Strumento di mappatura dei backlog>
  • Velocità

Flusso di lavoro personalizzato (processo)

  • Bacheche> Pannello dei prodotti
  • Bacheche>Bacheche del portfolio
  • Schermata>attività Sprint
  • Diagramma di flusso cumulativo

Campo personalizzato (processo)

  • Bacheche>Bacheca del prodotto
  • Bacheche>Bacheche portfolio

Percorsi di area, team di prodotto e gestione portfolio

Usare percorsi di area per raggruppare gli elementi di lavoro per prodotto, funzionalità o aree aziendali e per supportare i team responsabili del lavoro assegnato a tali aree. È possibile definire un insieme gerarchico di percorsi di area o un insieme piatto. In genere, si definisce un set gerarchico di percorsi di area per supportare una gerarchia aziendale che vuole tenere traccia dello stato di avanzamento di diversi team.

Percorsi di area e raggruppamento gerarchico

I due modi principali per raggruppare gli elementi di lavoro sono in base al percorso dell'area e raggruppandoli sotto un WIT portfolio, come descritto in precedenza in questo articolo. I due non si escludono a vicenda. Ecco le differenze:

  • I percorsi di area assegnati a un team determinano gli elementi di lavoro visualizzati in una visualizzazione team: backlog del prodotto, backlog portfolio, piani di recapito o altro strumento di pianificazione portfolio
  • Il raggruppamento di elementi di lavoro in una funzionalità padre o in un'epica determina quali visualizzazioni di rollup sono supportate e il modo in cui il lavoro viene visualizzato in uno strumento di pianificazione portfolio

È anche possibile assegnare tag agli elementi di lavoro per raggrupparli per scopi di query e filtro. Pertanto, quando si strutturano i team e i progetti, assicurarsi di comprendere come usare questi strumenti di raggruppamento per supportare le esigenze aziendali. Le scelte effettuate influiscono sull'uso degli strumenti di pianificazione del portfolio.

Strumenti che dipendono dai percorsi dell'area

Per eseguire le attività seguenti, è necessario definire i percorsi di area:

Suggerimento

È possibile definire la struttura del percorso area e assegnare percorsi area ai team. In alternativa, è possibile aggiungere un team e creare allo stesso tempo il percorso dell'area con il nome del team. Se i team sono completamente indipendenti, creare una struttura piatta di percorsi di area. Tuttavia, se si vuole creare una gerarchia di team, è necessario creare una gerarchia ad albero dei percorsi di area. Per altre informazioni, vedere Configurare una gerarchia di team.

Per usare gli strumenti seguenti, i team devono associarsi ai percorsi di aree.

Percorsi di area e assegnazioni di squadra

Ogni progetto ha un team predefinito e un percorso di area predefinito. In alcuni casi, c'è un solo team per pianificare e tenere traccia del lavoro. Con l'aumentare delle dimensioni delle organizzazioni, tuttavia, è possibile aggiungere altri team per gestire il backlog e gli sprint.

L'esempio seguente mostra i percorsi di area e le relative assegnazioni ai team, che supportano le visualizzazioni di gestione portfolio per i team di gestione degli account e di distribuzione dei servizi.

Schermata dei percorsi di area e delle assegnazioni del team.

Per altre informazioni, vedere gli articoli seguenti:

Raccomandazioni:

  • Prendere in considerazione ciò di cui l'alta dirigenza ha bisogno e come fornirle il miglior supporto.
  • Valutare come si vuole usare il rollup sia per un team che per la gestione del portfolio
  • Definire epiche e scenari per iniziative di grandi dimensioni che richiedono due o più sprint per essere completate
  • Creare percorsi di area gerarchici per supportare le sottocategorie di funzionalità e aree di prodotto
  • Definire i requisiti per il lavoro che possono essere eseguiti in un singolo sprint e che possono essere assegnati a un singolo utente
  • Definire le attività per tenere traccia di dettagli più granulari o quando si vuole tenere traccia del tempo dedicato al lavoro

Suggerimento

  • È possibile assegnare un elemento di lavoro solo a un singolo utente. Quando si definiscono gli elementi di lavoro, considerare il numero di elementi di lavoro necessari e gli utenti a cui assegnarli.
  • Scegli il campo Node Name come opzione di colonna per visualizzare il nodo area fogliare in un elenco backlog o scheda. Per altre informazioni, vedere Personalizzare le schede.
  • Non creare collegamenti padre-figlio tra elementi di lavoro dello stesso tipo, ad esempio story-story, bug-bug, task-task.

La maggior parte degli strumenti di Azure Boards supporta una visualizzazione filtrata degli elementi di lavoro in base al percorso dell'area o al percorso di iterazione. È anche possibile applicare altri filtri in base a parole chiave, assegnazione, WIT e altro ancora.

Bug come requisiti o attività

Ogni team può scegliere come gestire i bug. Alcuni team amano tenere traccia dei bug insieme ai requisiti nel backlog. Altri team amano tenere traccia dei bug come attività eseguite a supporto di un requisito. I bug vengono quindi visualizzati sulla bacheca delle attività.

Se si usa il processo Scrum, la configurazione predefinita consiste nel tenere traccia dei bug insieme agli elementi del backlog del prodotto (PBI). Se si lavora in un progetto in base ai processi Agile o CMMI, i bug non vengono visualizzati automaticamente nel backlog.

Determinare con il team come si vogliono gestire i bug. Modificare quindi le impostazioni del team di conseguenza.

Suggerimento

Dopo aver aggiornato un backlog o una bacheca e non vedere i bug dove li si aspetta, rivedere Come i backlog e le bacheche visualizzano elementi gerarchici (annidati). Solo i nodi foglia degli elementi annidati vengono visualizzati nei taskboard sprint.

Tipi di Elemento di Lavoro di sistema in un backlog

Per tenere traccia dei problemi, degli ostacoli e dei requisiti nel backlog di un portfolio, aggiungili al tuo processo ereditato e personalizzato. Per altre informazioni, vedere Personalizzare i backlog o le bacheche (processo di ereditarietà).

Rollup, gerarchia e gestione del portafoglio

Le colonne di rollup consentono di visualizzare gli indicatori di stato o i totali dei campi numerici oppure gli elementi discendenti all'interno di una gerarchia. Gli elementi discendenti corrispondono a tutti gli elementi figli all'interno della gerarchia. È possibile aggiungere una o più colonne di rollup a un backlog di prodotto o portfolio.

Di seguito viene mostrato Lo stato di avanzamento di tutti gli elementi di lavoro, che visualizza le barre di stato per gli elementi di lavoro ascendenti in base alla percentuale di elementi discendenti chiusi.

Screenshot del backlog, barre di avanzamento che mostrano il riepilogo per elementi di lavoro.

Piani di consegna supportano visualizzazioni rollup di epic, funzioni e altri backlog personalizzati del portfolio.

Screenshot che mostra la vista di riepilogo dei progressi dei piani di consegna di quattro scenari.

Percorsi di iterazione, sprint, rilasci e controllo delle versioni

I percorsi di iterazione supportano i processi Scrum e Scrumban in cui il lavoro viene assegnato a un periodo di tempo impostato. I percorsi di iterazione consentono di raggruppare il lavoro in sprint, attività cardine o in un altro periodo specifico dell'evento o relativo al tempo. Ogni iterazione o sprint corrisponde a un intervallo di tempo regolare definito cadenza sprint. Le cadenza tipiche dello sprint sono di due settimane, tre settimane o un mese. Per altre informazioni, vedere Informazioni sui percorsi di area e di iterazione.

I percorsi di iterazione possono essere un elenco piatto o raggruppati sotto traguardi di rilascio, come illustrato nell'immagine seguente.

Screenshot dei percorsi di iterazione raggruppati.

Anche se i percorsi di iterazione non influiscono sugli strumenti della scheda, è possibile usare i percorsi di iterazione come filtro sulle schede. Per altre informazioni, vedere Filtrare la scheda.

Definire i percorsi di iterazione e assegnarli ai team quando si vogliono usare gli strumenti seguenti:

Suggerimento

Se un team non ha sottoscritto o selezionato un percorso di iterazione, tale percorso di iterazione non verrà visualizzato in una visualizzazione o uno strumento del team.

Monitoraggio del tempo

La maggior parte delle organizzazioni che seguono i processi Scrum usano stime del tempo per la pianificazione della capacità sprint. Gli strumenti di Azure Boards supportano completamente il tempo di rilevamento per questo scopo. Il campo principale usato è il campo dell'attività Remaining Work , che in genere viene zero alla fine dello sprint.

Tuttavia, alcune organizzazioni richiedono il rilevamento del tempo per supportare altri scopi, ad esempio per la fatturazione o la gestione dei record di allocazione del tempo. I valori di tempo per il lavoro stimato e il lavoro completato sono di interesse. I processi Agile e CMMI forniscono questi campi—Original Estimate, Completed Work, Remaining Work—per tenere traccia del tempo. È possibile usarli a tale scopo. Azure Boards offre tuttavia un supporto nativo limitato per il rilevamento del tempo. Prendere invece in considerazione l'uso di un'estensione del Marketplace per supportare gli altri requisiti di rilevamento del tempo.

Nota

I Original Estimatecampi , Completed Work, Remaining Work sono stati progettati per supportare l'integrazione con Microsoft Project. Il supporto per l'integrazione con Microsoft Project è deprecato per Azure DevOps Server 2019 e versioni successive, incluso il servizio cloud.

Modifiche che influenzano tutti i team

Qualsiasi modifica apportata a un processo in un progetto influisce su tutti i team del progetto. Molte modifiche non disturbano i team che sostengono, ma le seguenti modifiche lo fanno.

Campi personalizzati

Quando si aggiungono campi personalizzati a un WIT, non influisce direttamente su uno strumento specifico. Questi campi diventano invece visibili all'interno degli elementi di lavoro corrispondenti. Ad esempio, se si introduce un campo numerico personalizzato, è possibile usarlo per i calcoli di rollup sui backlog. È anche possibile usare questo campo personalizzato con gli strumenti di creazione report seguenti. Pertanto, mentre l'effetto non è specifico dello strumento, migliora la capacità di personalizzare gli elementi di lavoro in base alle esigenze del progetto.

Nota

Tutti i campi predefiniti e personalizzati vengono condivisi in tutti i progetti di una raccolta o di un'organizzazione. È previsto un limite di 1024 campi che è possibile definire per un processo.

WIT personalizzati

Nella tabella seguente vengono illustrati gli effetti quando si aggiunge un WIT personalizzato a una categoria specifica.

Attività

Requisito

Epica o funzionalità

  • Gli elementi di lavoro figlio del nuovo WIT vengono visualizzati nel backlog del prodotto
  • Gli elementi di lavoro basati sul nuovo WIT vengono visualizzati nei backlog sprint e nelle schede attività
  • Gli elementi di lavoro basati sul nuovo WIT vengono visualizzati nel backlog del prodotto e sulla \board.
  • Ogni team deve configurare la \board per supportare il nuovo WIT
  • Gli elementi di lavoro basati sul nuovo WIT vengono visualizzati nei backlog e nelle bacheche del portfolio corrispondenti
  • Ogni team deve configurare le \boards per supportare il nuovo WIT
  • I nuovi wit potrebbero non essere visualizzati in uno o più degli strumenti di pianificazione del portfolio

Flusso di lavoro personalizzato

Ogni processo supporta un flusso di lavoro predefinito. Questo flusso di lavoro definisce le colonne predefinite visualizzate nelle bacheche e negli sprint Taskboard.

Stati del flusso di lavoro: Storia utente, processo Agile

Stati del flusso di lavoro della user story, processo Agile

A volte, i team vogliono tenere traccia dello stato del lavoro che supera questi stati predefiniti. Il supporto viene fornito in uno dei modi seguenti:

  • Aggiungere stati del flusso di lavoro personalizzati al WIT: questa opzione influisce su tutti i team e richiede che aggiornino la configurazione della scheda.
  • Aggiungere colonne a una lavagna: questa opzione influisce solo sul team che aggiunge le colonne.

Entrambi gli stati del flusso di lavoro e le colonne vengono visualizzati nel diagramma di flusso cumulativo per un team. I singoli utenti possono scegliere le colonne visualizzate nel grafico. Per altre informazioni, vedere Diagramma di flusso cumulativo.

Chi può apportare modifiche?

Poiché le impostazioni a livello di processo, a livello di progetto e a livello di team possono avere un effetto ampio, le modifiche sono limitate agli utenti con le autorizzazioni necessarie seguenti.

Cambiamenti a livello di processo

Per creare, modificare o gestire i processi ereditati e applicarli ai progetti, è necessario essere membri del gruppo Amministratori della raccolta di progetti . In alternativa, avere le autorizzazioni corrispondenti Crea processo, Elimina processo, Modifica processo, o Eliminare un campo dall'organizzazione impostato a Consenti. Vedi Imposta autorizzazioni e accesso per il monitoraggio delle attività, Personalizza un processo ereditato.

Per altre informazioni, vedere gli articoli seguenti:

Modifiche a livello di progetto

Per aggiungere percorsi di area o percorsi di iterazione, essere membro del gruppo Project Administrators .

In alternativa, per aggiungere, modificare e gestire percorsi di area o percorsi di iterazione in un nodo specifico, è necessario disporre di una o più delle seguenti autorizzazioni impostate su Consenti:

  • Creare nodi figli
  • Eliminare questo nodo
  • Modificare questo nodo
  • Visualizzare le autorizzazioni in questo nodo

Per altre informazioni, vedere gli articoli seguenti:

Modifiche a livello di team

Per configurare gli strumenti del team, devi essere un amministratore del team o un membro del gruppoAmministratori di Progetto.

Gli amministratori del team eseguono le operazioni seguenti:

  • Aggiungere membri al team
  • Sottoscrivere percorsi di area e iterazione
  • Configurare backlog e altre impostazioni comuni del team
  • Configurare le bacheche
  • Gestire le notifiche del team

Per ulteriori informazioni sulla configurazione di backlog e bacheche, vedere Gestire e configurare gli strumenti del team.

Passaggi successivi

Inizia come amministratore