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:

Personalizzare le schede Gestisci colonne Expedite work with swimlanes Configure your backlog .Customize cards | Manage columns | Expedite work with swimlanes | Configure your 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 project Amministrazione istrator, 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 portfolio
  • Personalizzazioni del flusso di lavoro

Livello team

  • Come usare il backlog del prodotto per pianificare e classificare in ordine di priorità il lavoro
  • Sia che si tengono traccia dei bug come requisiti o come attività o che non usino bug
  • Indica se si usano o meno attività per tenere traccia del tempo e della capacità
  • Come si usano i livelli di backlog portfolio
  • Come informare la gestione superiore dello stato, 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 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 wit, inclusi backlog di prodotti e portfolio. Le connessioni WIT predefinite per ogni processo sono elencate nelle schede corrispondenti, con backlog in Requisiti e attività in Attività.

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.

È 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 portfolio

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 team (Progetto, Team)

  • Boards>Tutti gli strumenti
  • Backlog Tutti gli>strumenti
  • Sprint tutti gli>strumenti
  • Diagramma di flusso cumulativo
  • Velocità
  • Tendenza burndown
  • Piani di recapito
  • Sequenza temporale delle funzionalità
  • Roadmap epica
  • Piani portfolio (Beta)

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

  • Pianificazione sprint>backlog
  • Backlog sprint sprint>
  • >Capacità sprint sprint
  • Schermata>attività Sprint
  • Velocità
  • Tendenza burndown
  • Piani di recapito
  • Sequenza temporale delle funzionalità
  • Roadmap epica
  • Piani portfolio (Beta)

Mostra bug nei backlog e nelle bacheche (team)
Wit personalizzati, backlog prodotto (processo)
Wit personalizzati, Tabellone attività (processo)

  • Bacheche di prodotti boards>
  • Backlog del>prodotto
  • Strumento di mapping backlog>
  • Backlog sprint sprint>
  • Schermata>attività Sprint
  • Velocità

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

  • Bacheche portfolio di bacheche>
  • Backlog del>portfolio di backlog
  • Strumento di mapping backlog>
  • Velocità

Flusso di lavoro personalizzato (processo)

  • Bacheche di prodotti boards>
  • Bacheche portfolio di bacheche>
  • Schermata>attività Sprint
  • Diagramma di flusso cumulativo

Campo personalizzato (processo)

  • Bacheche di prodotti boards>
  • Bacheche portfolio di bacheche>

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 set gerarchico di percorsi di area o un set flat. 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 genitoriandoli in 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 dipendenti dal percorso dell'area

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

Suggerimento

È possibile definire la struttura del percorso dell'area e assegnare percorsi di area ai team. In alternativa, è possibile aggiungere un team e creare il percorso dell'area con il nome del team in quel momento. Se i team sono completamente indipendenti, creare un set piatto 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 sottoscrivere percorsi di area:

Percorsi di area e assegnazioni di team

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.

Screenshot dei percorsi di area e delle assegnazioni del team.

Per altre informazioni, vedere gli articoli seguenti:

Raccomandazioni:

  • Prendere in considerazione le esigenze di gestione superiore e come supportarle al meglio
  • 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 accettano due o più sprint da completare
  • 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.
  • Scegliere il Node Name campo come opzione di colonna per visualizzare il nodo dell'area foglia in un elenco backlog o scheda 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 nella 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 vengono visualizzati bug in cui sono previsti, vedere Come i backlog e le bacheche visualizzano elementi gerarchici (annidati). Solo i nodi foglia degli elementi annidati vengono visualizzati nei taskboard sprint.

Wit di sistema in un backlog

Per tenere traccia dei problemi o degli ostacoli insieme ai requisiti o in un backlog del portfolio, aggiungerli al processo ereditato personalizzato. Per altre informazioni, vedere Personalizzare i backlog o le bacheche (processo di ereditarietà).

Rollup, gerarchia e gestione del portfolio

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 figlio 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 stato che mostrano il rollup per elementi di lavoro.

I piani di recapito supportano visualizzazioni rollup di epiche, funzionalità e altri backlog del portfolio personalizzati.

Screenshot che mostra la visualizzazione rollup dello stato dei piani di recapito di quattro scenari.

Percorsi di iterazione sprint versioni 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 iterazione e area.

I percorsi di iterazione possono essere un elenco semplice o raggruppati in attività cardine 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 Kanban, è possibile usare i percorsi di iterazione come filtro nelle schede. Per altre informazioni, vedere Filtrare la scheda Kanban.

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.

Registrazione oraria

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 WorkRemaining Workper l'uso nel tempo di rilevamento. È 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.

Elaborare le modifiche che influiscono su tutti i team

Qualsiasi modifica apportata a un processo in un progetto influisce su tutti i team del progetto. Molte modifiche non causano molte interruzioni ai team che supportano, ma le modifiche seguenti.

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 nella scheda Kanban
  • Ogni team deve configurare la bacheca Kanban per supportare il nuovo WIT
  • Gli elementi di lavoro basati sul nuovo WIT vengono visualizzati nei backlog del portfolio e nelle bacheche Kanban corrispondenti
  • Ogni team deve configurare le bacheche Kanban 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 Kanban e negli sprint Taskboard.

Stati del flusso di lavoro: Storia utente, processo Agile

Stati del flusso di lavoro della storia utente, 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 Kanban.
  • Aggiungere colonne a una lavagna Kanban: questa opzione influisce solo sul team che aggiunge le colonne.

Entrambi gli stati del flusso di lavoro e le colonne Kanban 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.

Modifiche a livello di processo

Per creare, modificare o gestire processi ereditati e applicarli ai progetti, è necessario essere membri del gruppo Project Collection Amministrazione istrators. In alternativa, è necessario disporre delle autorizzazioni corrispondenti Crea processo, Elimina processo, Modifica processo o Elimina un campo dall'organizzazione impostato su Consenti. Vedere Impostare le autorizzazioni e l'accesso per il rilevamento del lavoro, Personalizzare un processo ereditato.

Per altre informazioni, vedere gli articoli seguenti:

Modifiche a livello di progetto

Per aggiungere percorsi di area o percorsi di iterazione, è necessario essere membri del gruppo Project Amministrazione istrators.

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

  • Creare nodi figlio
  • 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, è necessario essere un amministratore del team o un membro del gruppo Project Amministrazione istrators.

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 Kanban
  • Gestire le notifiche del team

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

Passaggi successivi

Introduzione come amministratore