Configurare e personalizzare Azure Boards

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Personalizzare Azure Boards in base ai processi e alle esigenze del portfolio del team. Questo articolo descrive le attività e le considerazioni consigliate per gli amministratori che configurano la struttura dell'area e dell'iterazione, i tipi di elementi di lavoro (WIT), i flussi di lavoro e il comportamento della scheda.

Usare questo articolo per decidere come organizzare il progetto prima di personalizzare le bacheche, i backlog e le impostazioni del team.

Se si conoscono già le attività di configurazione desiderate, iniziare con questi articoli:

Note

La maggior parte delle indicazioni si applica sia ai servizi Azure DevOps che alle Azure DevOps Server. Alcune funzionalità, ad esempio Analisi e pianificazione recapito, variano in base alla versione o all'installazione. I piani di recapito sono incorporati in Azure DevOps Server 2022 e versioni successive e sono stati precedentemente disponibili come estensione del Marketplace.

Suggerimento

È possibile usare l'intelligenza artificiale per facilitare le attività di Azure DevOps. Per iniziare, vedere Abilitare l'assistenza IA con Azure DevOps MCP Server.

Considerazioni chiave

Usare queste domande per definire la configurazione scelta.

Area Domande a cui rispondere
Progetto e struttura del team Quanti team sono necessari, quale gerarchia di percorsi di area e quali visualizzazioni di rollup ti servono?
Iterazioni Quale frequenza di sprint, raggruppamento di rilascio e orizzonte previsionale funzionano meglio?
Schema elemento di lavoro Quali wit devono usare i team (Funzionalità, Storie/Problemi/PBI, Attività, Epiche)?
Esigenze di creazione di report Quali campi, rollup e visualizzazioni di analisi devono essere disponibili?
Personalizzazioni In che modo campi, flussi di lavoro e WIT personalizzati influiscono su bacheche, backlog e report?
Autorizzazioni e governance Chi può modificare processi, alberi ad area/iterazione e impostazioni del team?

Documentare le scelte in modo che i team li applichino in modo coerente nel progetto.

Scegli i tipi di elementi di lavoro e i backlog del portfolio

Scegliere un processo (Agile, Basic, Scrum o CMMI) quando si crea un progetto. Ogni processo definisce un set predefinito di wit e livelli di portfolio/backlog. È possibile aggiungere WIT personalizzati e backlog del portfolio per supportare l'organizzazione.

Questo diagramma mostra la gerarchia di backlog del processo Agile:

Diagramma che mostra i tipi di elemento di lavoro Agile.

  • Usare storie utente e attività per tenere traccia del lavoro.
  • Usare i bug per tenere traccia dei difetti del codice.
  • Usa iniziative e funzionalità per raggruppare il lavoro in scenari più ampi.

Ogni team può configurare se gestire i bug allo stesso livello degli elementi di lavoro della storia utente o delle attività. Usare l'impostazione Lavorare con i bug. Per altre informazioni sull'uso di questi tipi di elemento di lavoro, vedere Processo Agile.

Usare wit personalizzati e backlog del portfolio quando sono necessari livelli di pianificazione aggiuntivi, ad esempio obiettivi e risultati chiave o quando i team necessitano di un livello di rollup superiore alle funzionalità.

Screenshot che mostra un progetto che aggiunge Obiettivi e Risultati Chiave come backlog personalizzati del portfolio.

Confrontare gli approcci di rilevamento

Scegliere il modello di rilevamento più adatto al modo in cui i team pianificano e segnalano il lavoro.

Avvicinarsi Usa quando Compromesso
Solo attività È necessario un semplice rilevamento delle attività con una piccola gerarchia Definizione delle priorità limitata e nessuna pianificazione del portfolio
Requisiti con le attività figlie I team scrum stimano il lavoro e lo tengono traccia negli sprint Più gerarchia da gestire
Solo requisiti I team Kanban o Scrumban non tengono traccia del tempo Minore dettaglio a livello di attività
Requisiti raggruppati sotto i WIT del portfolio Più team necessitano di rollup e visualizzazioni del calendario tra team Richiede una progettazione iniziale del processo

Spiegare il modello scelto per i team e aggiornare la documentazione del processo in modo che tutti usino lo stesso modello.

Configurare aree, iterazioni e team

Usare i percorsi di area per partizionare il lavoro in base a prodotto, funzionalità o area aziendale. Usare percorsi di iterazione per sprint, versioni o traguardi.

Raccomandazione Motivo
Creare gerarchie di percorsi di area che riflettono il modo in cui i manager vogliono segnalare i rollup Consente la creazione di report di rollup accurati tra i livelli dell'organizzazione
Assegna a ciascun team un'area predefinita e una sottoscrizione standard per l'iterazione Gli elementi di lavoro ereditano automaticamente il contesto corretto
Utilizzare cadenze di iterazione coerenti tra i team che consegnano insieme Semplifica la pianificazione e il rilevamento delle dipendenze tra team

Screenshot che mostra i percorsi di area e le assegnazioni del team.

Contenuto correlato:

Visualizzare bug nelle bacheche e nei backlog

Ogni team decide se i bug vengono visualizzati nel backlog del prodotto come requisiti o vengono monitorati come attività associate ai requisiti. I team che usano Scrum spesso mostrano bug nel backlog. I team che usano Agile o CMMI possono scegliere se i bug vengono visualizzati nei backlog. Il processo Basic non usa il tipo di elemento di lavoro Bug; usa invece Issue. Per modificare la modalità di visualizzazione dei bug per un team, aggiornare le impostazioni del team:

Mantenere i criteri del team coerenti in modo che le query, le bacheche e i rollup si comportino in modo prevedibile.

Visualizzazioni rollup e portfolio

Aggiungere colonne di rollup ai backlog per visualizzare barre di stato, conteggi o somme per gli elementi figlio. Usa Delivery Plans per esaminare le pianificazioni e le dipendenze tra team. Se si usa una visualizzazione di tipo roadmap, ad esempio l'estensione Sequenza temporale delle funzionalità, chiamarla separatamente nelle linee guida per il progetto.

Screenshot che mostra le barre di rollup dello stato in un backlog.

Per la pianificazione tra i team, usa Delivery Plans e qualsiasi estensione tipo roadmap standardizzata dalla tua organizzazione.

Bacheche, colonne e flussi di lavoro

Gli stati del flusso di lavoro degli elementi di lavoro determinano le colonne della scheda predefinite.

Action Ambito Considerazione
Aggiungere stati del flusso di lavoro personalizzati a WIT Influisce su tutti i team Le modifiche vengono visualizzate in tutte le bacheche del team usando tale WIT
Aggiungere colonne alle bacheche del team Influisce solo sul team Utile per i passaggi del flusso di lavoro specifici del team
Mappature da stato a colonna Influisce sulla creazione di report Eseguire il mapping con attenzione per mantenere l'accuratezza del diagramma di flusso cumulativo

Contenuto correlato:

Campi personalizzati e creazione di report

I campi personalizzati consentono di acquisire dati specifici del progetto. Possono abilitare rollup e report ma si applicano a tutto il processo.

Raccomandazione Motivo
Limitare i campi personalizzati a quelli che supportano la creazione di report o l'automazione Riduce l'ingombro e gli oneri di manutenzione.
Usare campi numerici personalizzati per le somme di rollup Abilita il monitoraggio del progresso e la pianificazione della capacità
Usare elenchi di selezione per report coerenti Impedisce incoerenze nei dati derivanti da inserimenti di testo libero
Tenere presente che i campi a livello di processo vengono condivisi Le modifiche influiscono su tutti i progetti nella raccolta o nell'organizzazione

Note

È possibile definire fino a 1.024 campi per processo.

WIT personalizzati e modifiche al processo

L'aggiunta o la modifica di tipi di elementi di lavoro (WIT) e flussi di lavoro influiscono su molti strumenti.

Change Dove appare Azione richiesta
Nuovi WIT a livello di requisito Backlog del prodotto, possibilmente backlog dello sprint Configurare i livelli di backlog
Nuovi wit a livello di attività Schede attività Aggiornare le impostazioni del pannello attività
Tipi di WIT personalizzati Lavagne della squadra Aggiornare le tavole e le mappature delle colonne

Importante

Le modifiche a livello di processo influiscono su tutti i team. Limitare le modifiche che causano interruzioni e comunicarle in anticipo.

Autorizzazioni e chi può modificare ciò che

Controlla chi può modificare i processi, gli alberi di area e di iterazione e la configurazione del team.

Tipo di modifica Chi può apportare modifiche
Livello di processo Amministratori della raccolta di progetti o utenti con permessi per i processi
Livello di progetto (aree e iterazioni) Amministratori del progetto o utenti con autorizzazioni per i nodi
Livello del team Amministratori del team o amministratori di progetti

Contenuto correlato:

Rilevamento del tempo e pianificazione dello sprint

Usare i campi di rilevamento del lavoro che corrispondono al modello di pianificazione del processo e del team:

Campo Uso comune
Lavoro rimanente Tenere traccia dello sforzo lasciato per completare un'attività o un elemento sprint.
Stima originale Acquisisci la stima iniziale quando il team vuole un riferimento iniziale.
Lavoro completato Registrare lo sforzo già impiegato per un'attività.

Se si tiene traccia del tempo per la fatturazione o la creazione di report, valutare le estensioni del Marketplace per un supporto più avanzato per il rilevamento del tempo.

Contenuto correlato:

Elenco di controllo pratico per gli amministratori

Usare l'elenco di controllo seguente quando si configura o si esamina la configurazione di Azure Boards.

Phase Task
Pianificazione Decidere la strategia del tipo di processo e dell'elemento di lavoro (ereditare o personalizzare)
Pianificazione Aree di progettazione e gerarchie di iterazione
Configurazione Configurare i team e impostare le sottoscrizioni predefinite di area e iterazione
Configurazione Creare le cartelle di query condivise necessarie e le relative autorizzazioni
Configurazione Aggiungere colonne di rollup e widget del dashboard necessari ai dirigenti
Convalidare Implementare le modifiche in via sperimentale con un team prima di applicare gli aggiornamenti su larga scala.
Comunicare Documentare le modifiche e aggiornare il wiki del progetto

Contenuti correlati

  • Last updated on