Condividi tramite

Configurare e personalizzare Azure Boards

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

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/iterazione, i tipi di elementi di lavoro (WIT), i flussi di lavoro e il comportamento della lavagna.

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

Note

La maggior parte delle indicazioni qui si applica sia alle distribuzioni cloud che locali. Alcune funzionalità( ad esempio, rollup, analisi e strumenti di pianificazione portfolio) sono solo cloud.

Considerazioni chiave

Prima di modificare le impostazioni, decidere come lavoreranno i team e cosa deve vedere la gestione. Considerare:

  • Progetto e struttura del team: quanti team, gerarchia del percorso dell'area e visualizzazioni di rollup sono necessari?
  • Iterazioni: cadenza degli sprint, raggruppamento delle release e orizzonte di previsione.
  • Schema degli elementi di lavoro: quali wit useranno i team (Funzionalità, Storie/Problemi/PBI, Attività, Epiche)?
  • Esigenze di creazione di report: quali campi, rollup e visualizzazioni di analisi devono essere disponibili?
  • Personalizzazioni: campi personalizzati, flussi di lavoro e wit influiscono su bacheche, backlog e report.
  • Autorizzazioni e governance: chi può modificare i processi, gli alberi delle aree/iterazioni e le impostazioni del team?

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

Tipi di elementi di lavoro e 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.

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.

Usare WIT personalizzati e backlog di portfolio quando sono necessari livelli aggiuntivi di pianificazione, ad esempio Obiettivi e Risultati Chiave.

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

Scegliere uno di questi approcci di rilevamento di alto livello in base alle procedure del team:

  • Solo attività : non consigliato. Offre una priorità limitata e nessuna pianificazione del portfolio.
  • Requisiti con attività secondarie: valido per i team Scrum che stimano e tengono traccia del tempo.
  • Solo requisiti: valido per i team Kanban o Scrumban che non tengono traccia del tempo.
  • Requisiti raggruppati in WIT portfolio: usare quando più team necessitano di rollup e calendari tra team.

Spiegare l'approccio scelto per i team e aggiornare la documentazione del processo.

Aree, iterazioni e configurazione del 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.

Raccomandazioni:

  • Creare gerarchie di percorsi di area che riflettono il modo in cui i manager vogliono segnalare i rollup.
  • Assegnare a ogni team un'area predefinita e una sottoscrizione di iterazione in modo che gli elementi di lavoro ereditino il contesto corretto.
  • Usare cadenze di iterazione coerenti tra i team che lavorano insieme.

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

Contenuto correlato:

Mostra i bug sulle 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. 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. Usare piani di recapito e sequenze temporali delle funzionalità per visualizzare pianificazioni e dipendenze tra team.

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

Per la pianificazione tra team, utilizzare i Piani di consegna e, ove opportuno, le estensioni della timeline delle funzionalità.

Bacheche, colonne e flussi di lavoro

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

  • Aggiungere stati del flusso di lavoro personalizzati a WIT (influisce su tutti i team).
  • Aggiungere colonne alle lavagne del team (influisce solo su quel team).
  • Esegui attentamente le mappature da stato a colonna per mantenere la coerenza della reportistica, ad esempio i diagrammi di flusso cumulativi.

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.

Raccomandazioni:

  • Limitare i campi personalizzati a quelli che supportano la creazione di report o l'automazione.
  • Utilizzare campi numerici personalizzati per le somme di rollup; utilizzare picklist per la creazione di report coerenti.
  • Tenere presente che i campi a livello di processo vengono condivisi tra 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 wit e flussi di lavoro influisce su molti strumenti:

  • I nuovi WIT a livello di requisito vengono visualizzati nei product backlog e possono essere visualizzati nei sprint backlog.
  • Le nuove connessioni WIT a livello di attività vengono visualizzate nei taskboard.
  • Teams deve aggiornare le bacheche e i mapping per visualizzare wit personalizzati.

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

Controllare chi cambia processi, alberi di area/iterazione e configurazione del team.

  • Modifiche a livello di processo: amministratori o utenti della raccolta di progetti con autorizzazioni di processo appropriate.
  • Modifiche a livello di progetto (aree/iterazioni): amministratori del progetto o utenti con autorizzazioni per i nodi.
  • Modifiche a livello di team: amministratori del team o amministratori del progetto.

Contenuto correlato:

Rilevamento del tempo e pianificazione dello sprint

Usare i campi Lavoro rimanente, Stima originale e Lavoro completato per la pianificazione dello sprint e la gestione della capacità. Se si tiene traccia del tempo per la fatturazione o altri scopi, valutare le estensioni del Marketplace per un supporto più avanzato per il rilevamento del tempo.

Contenuto correlato:

Elenco di controllo pratico per gli amministratori

  • Decidere il processo e la strategia WIT (ereditare o personalizzare).
  • Area di progettazione e gerarchie di iterazione.
  • Configurare i team e impostare le sottoscrizioni predefinite per aree/iterazioni.
  • Creare le cartelle e le autorizzazioni di query condivise necessarie.
  • Aggiungere colonne di rollup e widget del dashboard richiesti dai dirigenti.
  • Testare le modifiche con un team prima di applicare gli aggiornamenti su vasta scala.
  • Comunicare le modifiche e aggiornare il wiki del progetto.

Contenuti correlati

  • Last updated on