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à

Yes. 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.

No. Gli elementi di lavoro possono essere assegnati solo a un singolo utente. Also, you can only add a user that is available from the people picker.

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:

• Prepend or append the word Milestone in the title of your work item
• 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.

If you're tracking dependencies across one or more organizations, you might want to use the Dependency Tracker.

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.

• Product backlog: By default lists User Stories (Agile), Issues (Basic), Product Backlog Items and Bugs (Scrum), or Requirements (CMMI). Provides options to show Parents, Forecast, and In Progress or Completed child items.
• Portfolio backlog: By default lists Features (all process models) for the Features backlog, and Epics (Agile, Scrum, and CMMI) for the Epic backlog. Provides options to show Parents and In Progress or Completed child items.
• Sprint backlog: By default lists all product backlog items assigned to the selected iteration, regardless of status. Provides options to show Work details.

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

No. 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à.

That said, we recommend that you use Delivery Plans to view dependencies and a calendar view of work.

If your organization supports connection to Microsoft Project, you might find more Marketplace extensions that support connection of Azure DevOps to 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).

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

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

Yes, see Query by assignment or workflow changes, board change queries.

Yes, by adding the Query Based Boards Marketplace extension.

Yes, by adding the Azure Boards Kanban Tools Marketplace extension.

Yes, you can track column moves on a board by using the Board Column and Board Column Done fields.

Se viene visualizzato l'errore seguente quando si apre la scheda, è necessario correggere la configurazione. The main reason for this error is that the workflow states of work item types added to the Requirement category aren't mapped to the column.

Selezionare Correggi ora per aprire la finestra di dialogo Impostazioni . 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 vengono visualizzati gli elementi di lavoro assegnati a questi stati.

Yes, you can add or remove swimlanes on your board. È 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.

No. Questa funzionalità non è attualmente supportata.

Example request: When creating a template, I would like the Parent User Story to be defaulted. There isn't a predetermined field in the template. Would/could this function be under a user-defined selection?

No, non è disponibile alcun supporto nativo per la creazione di modelli di gerarchia. In particolare, non è possibile specificare un elemento di lavoro padre predefinito. You can, however, quickly copy tasks, bugs, and other items using Excel to apply parent-child links in a tree list. In alternativa, è possibile usare una bacheca 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

From the work item type page, choose the actions icon for an existing template and select the Delete option.

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

No. 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.

Related content

• Query FAQs
• 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