Configurare e personalizzare Azure Boards

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

Questo articolo fornisce indicazioni per configurare e personalizzare Azure Boards. È consigliabile leggere questo articolo se si ha l'incarico di amministratore di un progetto per diversi team e di supportare gli obiettivi aziendali seguenti:

  • Supporto delle visualizzazioni di gestione portfolio
  • Visualizzare le visualizzazioni del calendario per aggiornare lo stato e lo stato di avanzamento
  • Tenere traccia delle dipendenze tra team o progetti
  • Tenere traccia delle stime temporali o del lavoro effettivo completato

Nota

Questo articolo si applica alle Azure DevOps Services. La maggior parte delle linee guida è 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 del portfolio, sono attualmente disponibili solo per il cloud.

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

Cosa considerare?

Quando si configurano o si personalizzano gli strumenti di rilevamento del lavoro, è consigliabile prendere in considerazione gli strumenti usati dai team e come usarli. Indipendentemente dal fatto che i team seguano Scrum, Kanban o una combinazione di Scrumban, è possibile sfruttare al meglio gli strumenti di Azure Boards comprendendo le dipendenze che hanno sulle configurazioni e le personalizzazioni.

Gli elementi principali da considerare durante la struttura del progetto sono:

A livello di progetto:

  • Numero di team da definire
  • Come strutturare i percorsi di area per supportare le visualizzazioni di gestione portfolio
  • Personalizzazioni dei campi
  • Personalizzazioni del tipo di elemento di lavoro o tipi di elementi di lavoro personalizzati
  • Personalizzazioni del backlog portfolio
  • Personalizzazioni del flusso di lavoro

A livello di team:

  • Come si userà il backlog del prodotto per pianificare e classificare in ordine di priorità il lavoro
  • Indipendentemente dal fatto che si tengono traccia dei bug come requisiti o come attività o che non usino bug
  • Indica se si useranno o meno le attività per tenere traccia del tempo e della capacità
  • Come si useranno i livelli di backlog portfolio
  • Come si informerà la gestione superiore dello stato, dello stato e dei rischi

Dopo aver determinato come si useranno i blocchi predefiniti e gli strumenti di rilevamento del lavoro, è necessario apportare le configurazioni e le personalizzazioni necessarie per supportare l'azienda e comunicare con i team come usare gli strumenti.

Tipi di elementi di lavoro e backlog portfolio

La prima scelta effettuata nel rilevamento del lavoro è il processo selezionato durante la creazione di un progetto. Per un confronto di ogni processo, vedere Scegliere un processo. Ogni processo, Agile, Basic, Scrum e CMMI, supporta una gerarchia set di tipi di elementi di lavoro. Questa gerarchia supporta un backlog del prodotto e uno o più backlog del portfolio.

I tipi di elemento di lavoro predefiniti per ogni processo supportato sono illustrati nelle schede seguenti. I tipi di elemento di lavoro backlog corrispondono alla categoria Requisiti. Le attività corrispondono alla categoria Attività.

L'immagine seguente mostra la gerarchia dell'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 e epiche e funzionalità vengono usati per raggruppare il lavoro in scenari più grandi.

Immagine concettuale, tipo di elemento di lavoro Agile.

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

È possibile aggiungere tipi di elementi di lavoro personalizzati a ogni livello e persino aggiungere backlog di portfolio personalizzati. Ecco, ad esempio, un progetto che ha aggiunto Obiettivi e Risultati chiave come tipi di elemento di lavoro personalizzati e backlog di portfolio corrispondenti al processo Scrum.

Obiettivi e risultati chiave come backlog di portfolio aggiuntivi

Una delle scelte principali dei team è la scelta dei tipi di elemento di lavoro usati per tenere traccia del 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é classificare in ordine di priorità 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 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 proprio 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 dall'elemento figlio è facoltativa. Gli sviluppatori possono aggiungerli semplicemente 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 tipi di elementi di lavoro portfolio, ad esempio epiche e funzionalità

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

Configurare e personalizzare le opzioni

La tabella seguente indica le aree che è possibile configurare e personalizzare e gli strumenti interessati da tali personalizzazioni. Ogni area viene personalizzata 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 Azure Boards, report nel contesto: Rilevamento lavoro e Piani (Agile su larga scala).

Configurare o personalizzare

Strumenti standard

Analisi

Strumenti di pianificazione del portfolio

  • Schede>Tutti gli strumenti
  • Backlog Tutti gli>strumenti
  • Sprint Tutti gli>strumenti
  • Diagramma di flusso cumulativo
  • Velocità
  • Tendenza di burndown
  • Piani di recapito
  • Sequenza temporale delle funzionalità
  • Roadmap epica
  • Piani di portafoglio (Beta)
  • Pianificazione dello>sprint dei backlog
  • Backlog Sprints>
  • >Capacità sprint sprint
  • Taskboard Sprints>
  • Velocità
  • Tendenza di burndown
  • Piani di recapito
  • Sequenza temporale delle funzionalità
  • Roadmap epica
  • Piani di portafoglio (Beta)

Mostra bug nelle schede backlog & (Team)
Tipi di elementi di lavoro personalizzati, backlog prodotto (Processo)
Tipi di elemento di lavoro personalizzati, Taskboard (Processo)

  • Scheda Prodotto board>
  • Backlog del>prodotto
  • Strumento di mapping dei> backlog
  • Backlog Sprints>
  • Taskboard Sprints>
  • Velocità

Tipi di elementi di lavoro personalizzati, backlog portfolio (Processo)
Backlog aggiuntivi del portfolio (Processo)

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

Flusso di lavoro personalizzato (processo)

  • Scheda Prodotto board>
  • Bacheche>di portfolio
  • Taskboard Sprints>
  • Diagramma di flusso cumulativo

Campo personalizzato (processo)

  • Scheda Prodotto board>
  • Bacheche>di portfolio

Percorsi di area, team di prodotti e gestione del portfolio

I percorsi di area vengono usati per raggruppare gli elementi di lavoro in base a prodotti, 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 quando si vuole 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 padreing in un tipo di elemento di lavoro portfolio, come descritto in precedenza in questo articolo. I due non si escludono a vicenda. Si notino le distinzione tra i due usi:

  • Percorsi di area assegnati a un team determinano quali elementi di lavoro vengono visualizzati in una visualizzazione team: backlog del prodotto, backlog del portfolio, piani di recapito o altro strumento di pianificazione del portfolio
  • Raggruppamento di elementi di lavoro in una funzionalità padre o epiche determinano quali visualizzazioni di rollup sono supportate e come il lavoro viene visualizzato in uno strumento di pianificazione del portfolio

È anche possibile assegnare tag agli elementi di lavoro per raggrupparli per scopi di query e filtro. Quindi, quando si strutturano i team e i progetti, si vuole assicurarsi di comprendere come usare questi strumenti di raggruppamento per supportare le esigenze aziendali. Le scelte influisce 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 flat di percorsi di area. Tuttavia, se si vuole creare una gerarchia di team, si vuole creare una gerarchia ad albero dei percorsi dell'area. Per altre informazioni, vedere Configurare una gerarchia di team.

Per usare gli strumenti seguenti, i team devono sottoscrivere i percorsi di area:

Percorsi di area e assegnazioni di team

Per ogni progetto vengono definiti un team predefinito e un percorso di area predefinito. Per i team di piccole dimensioni, un singolo team è sufficiente per iniziare a pianificare e tenere traccia del lavoro. Man mano che le organizzazioni crescono, tuttavia, è utile aggiungere team per supportare la loro capacità di gestire il backlog e gli sprint.

Ecco un esempio di percorsi di area e l'assegnazione 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.

  • Si creano percorsi di area gerarchici per supportare sottocategorie di funzionalità e aree di prodotto
  • Per fornire visualizzazioni portfolio, si assegnano due o più percorsi di area e si includono sottoaree a un team di gestione portfolio
  • I percorsi di area assegnati a un team determinano quali elementi di lavoro vengono filtrati in una visualizzazione team: backlog del prodotto, backlog del portfolio, piani di recapito o altri strumenti di pianificazione del portfolio
  • Il raggruppamento di elementi di lavoro in una funzionalità padre o in un'epica determina quali visualizzazioni di rollup sono supportate e come funziona in una visualizzazione calendario, ad esempio Sequenza temporale delle funzionalità e Roadmap epica

Prima di aggiungere team, è consigliabile leggere gli articoli seguenti:

Consigli:

  • Considerare le visualizzazioni che la gestione superiore può voler visualizzare e come supportarli 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 richiederanno due o più sprint per completare
  • Definire i requisiti per il lavoro che possono essere eseguiti in un singolo sprint e 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

  • Gli elementi di lavoro possono essere assegnati solo a un singolo utente. Pertanto, quando si definiscono gli elementi di lavoro, prendere in considerazione il numero di elementi di lavoro necessari per assegnare il lavoro a coloro a cui verrà assegnato l'incarico di completare il lavoro.
  • Scegliere il campo Nome nodo come opzione di colonna per visualizzare il nodo area foglia in un elenco backlog o scheda scheda scheda.
  • 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 Azure Boards supporta una visualizzazione filtrata degli elementi di lavoro in base al percorso dell'area e/o al percorso di iterazione. È anche possibile applicare filtri aggiuntivi in base a parole chiave, assegnazione, tipo di elemento di lavoro e altro ancora.

Considerare i bug come requisiti o attività

Ogni team può scegliere come gestire i bug. Alcuni team amano tenere traccia dei bug insieme ai requisiti del backlog. Altri team amano tenere traccia dei bug come attività eseguite a supporto di un requisito. I bug vengono quindi visualizzati nella scheda 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 basato sui processi Agile o CMMI, i bug non vengono visualizzati automaticamente nel backlog.

Comunicare con il team per determinare come 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.

Aggiungere tipi di elementi di lavoro di sistema a un backlog

Se si vogliono tenere traccia di problemi o ostacoli insieme ai requisiti o in un backlog del portfolio, è possibile aggiungerli al processo ereditato personalizzato. Per informazioni dettagliate, vedere Personalizzare i backlog o le bacheche (processo di ereditarietà).

Rollup, gerarchia e gestione portfolio

Le colonne di rollup consentono di visualizzare barre di stato o totali di campi numerici o 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.

In questo esempio viene visualizzato 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 in base agli elementi di lavoro.

Inoltre, i nuovi piani di recapito supportano visualizzazioni rollup di epiche, funzionalità e altri backlog di 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 due settimane, tre settimane o un mese. Per altre informazioni sui percorsi di iterazione, vedere Informazioni sui percorsi di iterazione e dell'area.

I percorsi di iterazione possono essere un semplice elenco semplice o raggruppati in attività cardine di rilascio, come illustrato nell'immagine seguente.

Screenshot dei percorsi di iterazione, raggruppati.

Nota

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.

Rilevamento dell'ora

La maggior parte delle organizzazioni che seguono i processi Scrum usano stime del tempo per la pianificazione della capacità sprint. Azure Boards strumenti supportano completamente il tempo di rilevamento per questo scopo. Il campo principale usato è il campo Lavoro rimanente dell'attività, 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, ovvero stima originale, lavoro completato, lavoro rimanente, per l'uso nel tempo di rilevamento. A tale scopo, è possibile usarli. Tuttavia, Azure Boards offre un supporto nativo limitato per il rilevamento del tempo. È invece consigliabile usare un'estensione del Marketplace per supportare i requisiti aggiuntivi di rilevamento del tempo.

Nota

I campi Stima originale, Lavoro completato, Lavoro rimanente 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 influisce su tutti i team

Qualsiasi modifica apportata a un processo applicato a un progetto influisce su tutti i team del progetto. Molte modifiche non causano molte interruzioni ai team supportati. Tuttavia, alcune operazioni sono descritte in questa sezione.

Campi personalizzati

L'aggiunta di campi personalizzati a un tipo di elemento di lavoro non influisce su uno strumento specifico. I campi vengono semplicemente visualizzati negli elementi di lavoro corrispondenti. Se si aggiunge un campo numerico personalizzato, tuttavia, è possibile usarlo per supportare il rollup nei backlog e negli strumenti di creazione di report seguenti:

Nota

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

Tipi di elementi di lavoro personalizzati

Quando si apportano una o più delle personalizzazioni seguenti, si influisce sugli strumenti del team come indicato.

  • Aggiungere un tipo di elemento di lavoro personalizzato alla categoria Requisito:
  • Aggiungere un tipo di elemento di lavoro personalizzato alla categoria Attività:
  • Aggiungere un tipo di elemento di lavoro personalizzato alla categoria Epic o Feature:
  • Aggiungere un livello di backlog portfolio personalizzato

Quando si aggiunge un tipo di elemento di lavoro personalizzato (WIT) a una delle categorie di rilevamento di lavoro seguenti, si influisce sugli strumenti del team nei modi seguenti:

  • Categoria attività:
    • 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 taskboard
  • Categoria di requisiti:
    • 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
  • Categoria epica o funzionalità:
    • 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

In alcuni casi, i team vogliono tenere traccia dello stato del lavoro che superano questi stati predefiniti. Il supporto viene fornito per questo in uno dei due modi seguenti:

  • Aggiungere stati del flusso di lavoro personalizzati al tipo di elemento di lavoro\
    • Questa opzione influisce su tutti i team e richiede che aggiornino la configurazione della scheda Kanban
  • Aggiungere colonne a una scheda 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.

Screenshot del diagramma di flusso cumulativo.

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 impatto ampio, le modifiche sono limitate alle persone seguenti che dispongono delle autorizzazioni necessarie.

Modifiche a livello di processo

Per creare, modificare o gestire i processi ereditati e applicarli ai progetti, è necessario essere membri del gruppo Amministratori raccolta progetti. 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 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 autorizzazioni seguenti impostate su Consenti:

  • Crea nodi figlio
  • Eliminare questo nodo
  • Modifica questo nodo
  • Visualizzare le autorizzazioni in questo nodo

Per altre informazioni, vedere gli articoli seguenti:

Modifiche a livello di team

Tutti gli strumenti del team possono essere configurati da un amministratore del team o da un membro del gruppo Amministratori progetto.

Gli amministratori del team hanno l'incarico di eseguire 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 informazioni dettagliate sulla configurazione di backlog e bacheche, vedere Gestire e configurare gli strumenti del team.

Successiva attività da provare