Configurare e personalizzare le Azure Boards

Azure Boards

Questo articolo fornisce indicazioni per configurare e personalizzare le Azure Boards. È consigliabile leggere questo articolo se si è in grado di eseguire l'amministrazione di un progetto per diversi team e di supportare gli obiettivi di business seguenti:

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

Nota

Questo articolo si applica a Azure DevOps Services. La maggior parte delle linee guida è valida sia per le versioni 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 Project, vedere anche Introduzione come amministratore.

Cosa prendere in considerazione?

Quando si configurano o si personalizzano gli strumenti di rilevamento del lavoro, è opportuno prendere in considerazione gli strumenti che i team usano e il modo in cui li useranno. 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 nelle configurazioni e nelle 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 dell'area per supportare le viste di gestione del portfolio
  • Personalizzazioni dei campi
  • Personalizzazioni dei tipi di elemento di lavoro o tipi di elementi di lavoro personalizzati
  • Personalizzazioni del backlog del 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
  • Se si tiene traccia dei bug come requisiti o come attività oppure se non si usano bug
  • Se si useranno o meno le attività per tenere traccia di tempo e capacità
  • Come si useranno i livelli di backlog del portfolio
  • Informazioni su come informare la gestione superiore dello stato, dello stato e dei rischi

Dopo aver determinato come si useranno gli strumenti e i blocchi predefiniti per il rilevamento del lavoro, sarà necessario apportare le configurazioni e le personalizzazioni necessarie per supportare l'azienda e comunicare ai team come devono usare gli strumenti.

Tipi di elementi di lavoro e backlog del 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 di 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 vengono visualizzati 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 degli elementi di lavoro del backlog del processo Agile. Le storie utente e le attività vengono usate per tenere traccia del lavoro, i bug rilevano i difetti del codice e le epiche e le funzionalità vengono usate 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 elementi di lavoro, vedere Processo Agile.

È possibile aggiungere tipi di elementi di lavoro personalizzati a ogni livello e anche aggiungere backlog portfolio personalizzati. In questo caso, ad esempio, è un progetto che ha aggiunto Objectives e Key Results come tipi di elementi di lavoro personalizzati e i backlog del portfolio corrispondenti al processo Scrum.

Obiettivi e risultati chiave come backlog del portfolio aggiuntivi

Una delle scelte principali dei team è la scelta dei tipi di elemento di lavoro che usano 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é assegnare priorità a un backlog di attività. Inoltre, non è disponibile alcun supporto per le visualizzazioni calendario, le visualizzazioni tra team o la pianificazione del portfolio

Requisiti con attività dipendenti da elementi 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.

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

Supporta i metodi Kanban e Scrumban
Consigliato per i team che seguono i metodi Kanban o Scrumban, stimano il lavoro usando story point, effort o size e non tiene traccia del tempo associato al lavoro.

Requisiti raggruppati in tipi di elementi di lavoro del portfolio, ad esempio epiche e funzionalità

Supporta visualizzazioni calendario, visualizzazioni tra team e pianificazione del portfolio
Consigliato per le organizzazioni con diversi team che vogliono visualizzare rollup e visualizzazioni 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 influenzati da tali personalizzazioni. Ogni area viene personalizzata a livello di organizzazione, Project 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 (Agilesu larga scala).

Configurare o personalizzare Strumenti standard Analisi Strumenti di pianificazione del portfolio
Percorsi di area, configurazione del progetto e sottoscrizioni del team (Project, Team)
  • Boards>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 portfolio (Beta)
  • Rilevamento delle dipendenze
Percorsi di iterazione, configurazione del progetto e sottoscrizione del team (Project, Team)
  • Backlog>pianificazione sprint
  • Sprint>backlog sprint
  • Sprint>sprint
  • Sprint>taskboard
  • Velocità
  • Tendenza di burndown
  • Piani di recapito
  • Sequenza temporale delle funzionalità
  • Roadmap epica
  • Piani di portfolio (Beta)
  • Rilevamento delle dipendenze
Visualizzare i bug nelle bacheche dei backlog & (Team)
Tipi di elemento di lavoro personalizzati, backlog del prodotto (processo)
Tipi di elementi di lavoro personalizzati, Taskboard (Processo)
  • Boards>scheda Prodotto
  • Backlog>backlog del prodotto
  • Strumento di mapping> backlog
  • Sprint>backlog sprint
  • Sprint>taskboard
  • Velocità
Tipi di elemento di lavoro personalizzati, backlog portfolio (processo)
Backlog del portfolio aggiuntivi (processo)
  • Boards>portfolio
  • Backlog>backlog del portfolio
  • Strumento di mapping> backlog
  • Velocità
Flusso di lavoro personalizzato (processo)
  • Boards>scheda Prodotto
  • Boards>portfolio
  • Sprint>taskboard
  • Diagramma di flusso cumulativo
  • Rilevamento delle dipendenze
Campo personalizzato (Processo)
  • Boards>scheda Prodotto
  • Boards>portfolio

Percorsi di area, team di prodotti e gestione del portfolio

I percorsi di area vengono usati 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 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 il percorso dell'area e l'elemento padre 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 differenze tra i due utilizzi:

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

È anche possibile assegnare tag agli elementi di lavoro per raggrupparli a scopo di query e filtro. Pertanto, quando si strutturano i team e i progetti, è necessario assicurarsi di comprendere come si useranno 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 percorsi di area:

Suggerimento

È possibile definire la struttura del percorso dell'area e assegnare percorsi di area ai team. In caso contrario, è 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, è necessario creare una gerarchia ad albero di 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 del team

Per ogni progetto sono 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. Con l'aumentare delle organizzazioni, tuttavia, è utile aggiungere team per supportare la capacità di gestire il backlog e gli sprint.

Di seguito è riportato un esempio di percorsi di area e di assegnazione ai team, che supportano le visualizzazioni di gestione del portfolio per i team di gestione degli account e di recapito dei servizi.

Percorsi di area e assegnazioni del team

  • È possibile creare percorsi di area gerarchici per supportare sottocategorie di funzionalità e aree di prodotto
  • Per fornire visualizzazioni portfolio, assegnare due o più percorsi di area e includere sottoaree a un team di gestione del 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 distribuzione o altro strumento di pianificazione del portfolio
  • Il raggruppamento di elementi di lavoro in una funzionalità padre o in una funzionalità epica determina quali visualizzazioni di rollup sono supportate e come viene visualizzato il lavoro in una visualizzazione calendario, ad esempio Sequenza temporale delle funzionalità ed Epic Roadmap

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

Consigli:

  • Considerare le visualizzazioni che la gestione superiore può voler visualizzare e come supportarle al meglio
  • Considerare come si vuole usare il rollup sia per la gestione di un team che per la gestione del portfolio
  • Definire epiche e scenari per iniziative di grandi dimensioni che avranno due o più sprint da completare
  • Definire i requisiti per il lavoro che è possibile eseguire 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

  • Gli elementi di lavoro possono essere assegnati solo a un singolo utente. Pertanto, quando si definiscono gli elementi di lavoro, considerare il numero di elementi di lavoro necessari per assegnare il lavoro agli utenti a cui verrà assegnato il compito di completare il lavoro.
  • Scegliere il campo Nome nodo come colonna per visualizzare il nodo dell'area foglia in un elenco di backlog o in una scheda della scheda.
  • Non creare collegamenti padre-figlio tra elementi di lavoro dello stesso tipo, ad esempio storia, bug-bug, attività-attività.

La maggior 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. Ad alcuni team piace tenere traccia dei bug insieme ai requisiti nel backlog. Ad altri team piace tenere traccia dei bug come attività eseguite a supporto di un requisito. I bug vengono quindi visualizzati nella relativa scheda attività.

Se si usa il processo Scrum, la configurazione predefinita consente di 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.

Parlare 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 i bug previsti, vedere Come i backlog e le bacheche visualizzano gli elementi gerarchici (annidati). Nei riquadri attività sprint vengono visualizzati solo i nodi foglia degli elementi annidati.

Aggiungere tipi di elementi di lavoro di sistema a un backlog

Se si vogliono tenere traccia di problemi o impedimenti 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 del portfolio

Le colonne di rollup consentono di visualizzare gli barre di avanzamento o i totali dei campi numerici o degli 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 del prodotto o del portfolio.

Qui 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 che sono stati chiusi.

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 del portfolio personalizzati.

Screenshot che mostra la visualizzazione rollup dello stato di avanzamento 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 altro periodo specifico dell'evento o correlato al tempo. Ogni iterazione o sprint corrisponde a un intervallo di tempo regolare definito cadenza sprint. Le cadenze tipiche dello sprint sono di due settimane, tre settimane o un mese. Per altre informazioni sui percorsi di iterazione, vedere Informazioni sui percorsi di area e iterazione.

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

Percorsi di iterazione, raggruppati

Nota

Anche se i percorsi di iterazione non influiscono sugli strumenti della lavagna Kanban, è possibile usare i percorsi di iterazione come filtro sulle lavagna. Per altre informazioni, vedere Filtrare la bacheca 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 in uno strumento del team.

Rilevamento dell'ora

La maggior parte delle organizzazioni che segue i processi Scrum usa stime del tempo per la pianificazione della capacità sprint. Azure Boards strumenti supportano completamente il tempo di rilevamento a questo scopo. Il campo principale usato è il campo Lavoro rimanente dell'attività, che in genere viene azzerato 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 — Stima originale, Lavoro completato, Lavoro rimanenteda usare nel — tempo di rilevamento. È possibile usarli a tale scopo. Tuttavia, Azure Boards 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 e Lavoro rimanente sono stati progettati per supportare l'integrazione con Microsoft Project. Il supporto dell'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 applicato a un progetto influisce su tutti i team del progetto. Molte modifiche non causeranno molte interruzioni per i team che supportano. Tuttavia, alcune di queste 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 tuttavia si aggiunge un campo numerico personalizzato, è possibile usarlo per supportare il rollup nei backlog e gli 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 influiscono 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 Epico o Funzionalità:
  • Aggiungere un livello di backlog del portfolio personalizzato

Quando si aggiunge un tipo di elemento di lavoro personalizzato (WIT) a una delle categorie di rilevamento del 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 lavagne attività
  • Categoria di requisiti:
    • Gli elementi di lavoro basati sul nuovo WIT vengono visualizzati nel backlog del prodotto e nella lavagna 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ù 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 sprint.

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 è disponibile 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 aggiorneranno la configurazione della bacheca Kanban
  • Aggiungere colonne a una lavagna Kanban
    • Questa opzione influisce solo sul team che aggiunge le colonne

Sia gli stati del flusso di lavoro che le colonne Kanban vengono visualizzati nel diagramma Flow per un team. Gli utenti possono scegliere le colonne da visualizzare nel grafico.

Diagramma di flusso cumulativo

Per altre informazioni, vedere Diagramma di flusso cumulativo.

Who apportare modifiche?

Poiché le impostazioni a livello di processo, a livello di progetto e di team possono avere un impatto ampio, le modifiche sono limitate alle persone seguenti che hanno le autorizzazioni necessarie.

Modifiche a livello di processo

Per creare, modificare o gestire processi ereditati e applicarli ai progetti, è necessario essere un membro del gruppo Project Collection Administrators. In caso contrario, è 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:

Project a livello di codice

Per aggiungere percorsi di area o percorsi di iterazione, è necessario essere un membro del gruppo Administrators Project o Project Collection Administrators.

In caso contrario, per aggiungere, modificare e gestire percorsi di area o percorsi di iterazione in un nodo specifico, è necessario avere ottenuto 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 Administrators Project o Project Collection Administrators.

Gli amministratori del team hanno il compito di eseguire le operazioni seguenti:

  • Aggiungere membri al team
  • Sottoscrivere percorsi di area e iterazione
  • Configurare i 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