Domande frequenti su Azure Boards

Come membro di un progetto di Azure Boards, è possibile usare la maggior parte delle funzionalità per tenere traccia del lavoro. Le limitazioni per la selezione delle funzionalità sono basate sul livello di accesso e sul gruppo di sicurezza a cui viene assegnato un utente. Altre limitazioni possono essere imposte in base alle autorizzazioni di rilevamento del lavoro o alle regole personalizzate. Per altre informazioni, vedere Autorizzazioni e accesso predefiniti per Azure Boards.

È possibile limitare l'accesso impostando le autorizzazioni per un percorso di area. Per altre informazioni, vedere gli articoli seguenti:

• Impostare le autorizzazioni di rilevamento e pianificazione del lavoro
• Concedere o limitare le autorizzazioni per selezionare le attività

Sì. Le regole condizionali basate sull'appartenenza a utenti o gruppi vengono memorizzate nella cache per il Web browser. Se ti trovi limitato ad aggiornare un elemento di lavoro, probabilmente hai rilevato una di queste regole. Per altre informazioni sulle regole condizionali, vedere Regole e valutazione delle regole. Se la cache archivia regole obsolete, è possibile attendere che la cache del client scada entro tre giorni oppure è possibile cancellare la cache.
Per cancellare la cache, eseguire il comando seguente nella finestra di comando del browser e quindi aggiornare il browser: window.indexedDB.deleteDatabase("wit")

Vedere Strumenti e client che si connettono ad Azure DevOps.

Per un'introduzione agli elementi di lavoro, vedere Informazioni sugli elementi di lavoro.

Per visualizzare tutti gli elementi di lavoro definiti in un progetto, aprire una query e aggiungere due clausole:

• Work Item Type = [Any]
• State = [Any]

Da qui è possibile aggiungere filtri per perfezionare la query. Per altre informazioni, vedere Creare e salvare query gestite con l'editor di query.

Nr. Gli elementi di lavoro possono essere assegnati solo a un singolo utente. Inoltre, è possibile aggiungere un utente disponibile solo dalla selezione utenti.

Il metodo principale per raggruppare il lavoro consiste nell'assegnarlo allo stesso percorso di area. 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. Inoltre, è possibile raggruppare il lavoro in un elemento di lavoro padre usando collegamenti padre-figlio, detti raggruppamenti gerarchici.

Per una descrizione di questi due utilizzi e degli strumenti supportati, vedere Configurazione e personalizzazione di Azure Boards, percorsi di area, team di prodotto e gestione portfolio.

I marcatori cardine non vengono usati nel rilevamento delle attività di Azure Boards, ad eccezione dei piani di recapito. I piani di recapito forniscono una visualizzazione del calendario e consentono di definire un marcatore cardine. Per altre informazioni, vedere Esaminare i piani di recapito del team.

Tuttavia, è possibile usare una o più delle opzioni seguenti per contrassegnare un elemento di lavoro come attività cardine:

• Anteporre o aggiungere la parola Cardine nel titolo dell'elemento di lavoro
• Aggiungere un tag elemento di lavoro con etichetta Cardine
• Aggiungere un campo personalizzato con etichetta Cardine e popolarlo con un elenco di attività cardine
• Collegare elementi di lavoro usando il tipo di collegamento predecessore/successore o correlato a un elemento di lavoro cardine
• Assegnare l'elemento di lavoro cardine allo sprint in cui è destinato al completamento.

È possibile tenere traccia delle dipendenze tra gli elementi di lavoro collegandole usando un tipo di collegamento correlato o un altro tipo di collegamento. Vedere Collegare elementi di lavoro ad altri oggetti.

Se si stanno monitorando le dipendenze tra una o più organizzazioni, è possibile usare Lo strumento di rilevamento delle dipendenze.

Ogni processo definisce quattro livelli di backlog predefiniti: il backlog di iterazione, il backlog dei requisiti, le funzionalità e i backlog epici del portfolio. I tipi di elemento di lavoro aggiunti a ogni livello di backlog sono i tipi di elementi di lavoro naturali per formare relazioni padre-figlio e elementi di lavoro di gruppo in una gerarchia. Per altre informazioni, vedere Organizzare il backlog, eseguire il mapping degli elementi di lavoro figlio ai genitori. Per personalizzare il processo, vedere Personalizzare i backlog o le bacheche, Modificare o rinominare il backlog dei requisiti.

Vedere Modificare in blocco gli elementi di lavoro, Modificare in blocco i campi RTF.

Sì, è possibile impostare il livello di backlog in modo da includere due regole diverse. Prima regola da impostare l'elemento padre come attivo quando uno dei relativi elementi figlio è impostato su attivo. La seconda regola consiste nell'impostare l'elemento padre su risolto o chiuso quando tutti gli elementi figlio vengono chiusi. Queste regole possono essere configurate per il livello di backlog. Per altre informazioni, vedere Automatizzare le transizioni di stato degli elementi di lavoro

Gli elementi di lavoro cambiano automaticamente lo stato dopo che l'amministratore del team ha configurato le regole di automazione nel backlog. Creare regole per impostare automaticamente lo stato su attivo o chiuso a seconda della modifica dello stato dei relativi elementi figlio. Per altre informazioni, vedere Automatizzare le transizioni di stato degli elementi di lavoro.

Le regole vengono attivate solo quando lo stato dell'elemento figlio viene spostato da Nuovo a Attivo o Chiuso. Le regole non vengono attivate quando lo stato dell'elemento figlio passa da Chiuso a Attivo. Attualmente, si tratta di un comportamento previsto da progettazione.

No, le regole vengono applicate a tutti i tipi di elemento di lavoro in tale livello di backlog. Le categorie di stato vengono usate invece di stati perché le categorie di stato sono coerenti in tutti i tipi di elementi di lavoro.

Sì, le regole vengono configurate per ogni livello di backlog. Le regole di automazione nel backlog delle storie utente non influiscono sulle funzionalità o sulle epiche. Tuttavia, è anche possibile configurare le regole separatamente per le funzionalità e le epiche. Per altre informazioni, vedere Automatizzare le transizioni di stato degli elementi di lavoro.

Le regole vengono attivate solo se entrambi gli elementi padre e figlio appartengono allo stesso team. Non vogliamo che le regole vengano attivate automaticamente per gli elementi appartenenti ad altri team. Per altre informazioni, vedere Automatizzare le transizioni di stato degli elementi di lavoro.

Ogni backlog e scheda rappresenta un set filtrato di elementi di lavoro in base al percorso dell'area del team e alle assegnazioni di percorso di iterazione. I backlog elencano gli elementi di lavoro, le schede visualizzano gli elementi di lavoro come schede. Per informazioni sull'applicazione del filtro, vedere Informazioni sui team e sugli strumenti Agile, impostazioni predefinite del team a cui fanno riferimento backlog e bacheche.

Per aggiungere un backlog o una bacheca, aggiungere un team. Ogni team è configurato con un proprio set di backlog e bacheche, come descritto in Informazioni sui team e sugli strumenti Agile. Ogni team può personalizzare questi strumenti Agile.

Azure DevOps impone limiti, ad esempio il numero di elementi di lavoro visualizzati in un backlog o una bacheca, il numero di team che è possibile definire e altro ancora. Per un elenco completo, vedere Rilevamento del lavoro, processo e limiti dei progetti.

Vedere Migrazione e integrazione di Azure Boards.

Ogni backlog elenca un set filtrato di elementi di lavoro in base al percorso di area selezionato del team, ai percorsi di iterazione e ai tipi di elemento di lavoro.

• Backlog prodotto: per impostazione predefinita elenca le storie utente (Agile), Problemi (Basic), Elementi e bug del backlog del prodotto (Scrum) o Requisiti (CMMI). Fornisce opzioni per visualizzare elementi padre, previsione e in corso o elementi figlio completati .
• Backlog portfolio: per impostazione predefinita sono elencate le funzionalità (tutti i modelli di processo) per il backlog Features e Epics (Agile, Scrum e CMMI) per il backlog Epic. Fornisce opzioni per visualizzare elementi padre e in corso o elementi figlio completati .
• Backlog sprint: per impostazione predefinita elenca tutti gli elementi del backlog del prodotto assegnati all'iterazione selezionata, indipendentemente dallo stato. Fornisce opzioni per visualizzare i dettagli di lavoro.

Sì. È possibile assegnare sprint agli elementi di lavoro e filtrare la scheda Kanban in base al percorso di iterazione. Per altre informazioni, vedere Filtrare la scheda Kanban.

Nr. Gli elenchi di controllo delle attività supportano solo il tipo di elemento di lavoro dell'attività.

Azure DevOps non offre una visualizzazione nativa del percorso critico. In parte, come metodologie Agile favorisce un prodotto minimo funzionante (MVP) rispetto a Critical Path Management (CPM). Usando MVP, è possibile identificare il percorso e le dipendenze più brevi assegnando priorità a epiche, funzionalità, storie e attività.

Detto questo, è consigliabile usare Piani di recapito per visualizzare le dipendenze e una visualizzazione del calendario del lavoro.

Se l'organizzazione supporta la connessione a Microsoft Project, potrebbero essere disponibili altre estensioni del Marketplace che supportano la connessione di Azure DevOps a Microsoft Project.

Per altre informazioni di contesto, vedere The Critical Path on Agile Projects and Running a lean startup on Azure DevOps (Percorso critico nei progetti Agile e Esecuzione di un'avvio snella in Azure DevOps).

Nr. I dati immessi per la capacità del team non vengono memorizzati nei normali archivi dati.

Nr. Questa funzionalità non è supportata. Si tratta di una funzionalità suggerita, che è possibile richiamare passando alla pagina Della community degli sviluppatori.

Sì, vedere Query per assegnazione o modifiche del flusso di lavoro, query di modifica della lavagna Kanban.

Sì, aggiungendo l'estensione Query Based Boards Marketplace.

Sì, aggiungendo l'estensione Azure Boards Kanban Tools Marketplace.

Sì, è possibile tenere traccia degli spostamenti delle colonne su una lavagna Kanban usando i campi Board Column e Board Column Done .Yes, you can track column move on a Kanban board by using the Board Column and Board Column Done fields.

Se viene visualizzato l'errore seguente quando si apre la scheda Kanban, è necessario correggere la configurazione. Il motivo principale di questo errore è che gli stati del flusso di lavoro dei tipi di elemento di lavoro aggiunti alla categoria Requisito non vengono mappati alla colonna.

Selezionare Correggi ora per aprire la finestra di dialogo Impostazioni. Nell'esempio seguente vengono aggiunti due nuovi stati: Triaged for bug e Investigate for user story .In the following example, two new states are added: Triaged for bug, and Investigate for user story. Ogni stato viene quindi mappato a una colonna esistente o nuova. Dopo il mapping di ogni stato a una colonna, nella scheda Kanban vengono visualizzati gli elementi di lavoro assegnati a questi stati.

Sì, è possibile aggiungere o rimuovere corsie sulla tavola Kanban. È anche possibile configurare regole di corsia, in cui quando vengono soddisfatte determinate condizioni, Azure Boards sposta automaticamente gli elementi di lavoro in corsie specifiche.

È possibile definire modelli di elemento di lavoro per i team a cui si appartiene. Per definire i modelli di elemento di lavoro per specificare le impostazioni predefinite per i campi selezionati, vedere Usare i modelli per aggiungere e aggiornare gli elementi di lavoro.

La funzionalità per impostare un modello predefinito per un team non è attualmente supportata.

Nr. Questa funzionalità non è attualmente supportata.

Richiesta di esempio: quando si crea un modello, si desidera che la storia utente padre sia predefinita. Non esiste un campo predeterminato nel modello. Questa funzione potrebbe essere sottoposta a una selezione definita dall'utente?

No, non è disponibile alcun supporto nativo per la creazione di modelli di gerarchia. In particolare, non è possibile specificare un elemento di lavoro padre predefinito. È tuttavia possibile copiare rapidamente attività, bug e altri elementi usando Excel per applicare collegamenti padre-figlio in un elenco ad albero. In alternativa, è possibile usare una bacheca Kanban per aggiungere attività figlio, elementi backlog o funzionalità. Per altre informazioni, vedi:

• Aggiungere elenchi di controllo delle attività
• Aggiungere, eseguire e aggiornare i test inline
• Aggiungere funzionalità ed epiche

Nella pagina tipo di elemento di lavoro scegliere l'icona azioni per un modello esistente e selezionare l'opzione Elimina .

Azure Boards si integra con GitHub per Azure DevOps Server 2019 e versioni successive. Per altre informazioni, vedere Azure Boards & GitHub.

Nr. Questa funzionalità non è attualmente supportata.

La configurazione e la personalizzazione di Azure Boards si verificano a livello di progetto e di team. Per una panoramica di quello che è possibile configurare e personalizzare in base a specifiche esigenze aziendali, vedere Configurazione e personalizzazione di Azure Boards.

Per domande frequenti sulla configurazione e la personalizzazione, vedere Domande frequenti su Configurazione e personalizzazione di Azure Boards.

Articoli correlati

• Domande frequenti sulla query
• Limiti di progetti, processi e rilevamento del lavoro
• Domande frequenti sulla configurazione e la personalizzazione di Azure Boards
• Domande frequenti: Lavorare in Excel connesso ad Azure Boards
• Domande frequenti sull'utilizzo dei progetti
• Estensioni di Azure Boards
• Informazioni sui team e sugli strumenti Agile