Informazioni sugli stati del flusso di lavoro nei backlog e nelle bacheche

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

I flussi di lavoro sono fondamentali per il modo in cui Azure Boards tiene traccia degli elementi di lavoro. Ogni tipo di elemento di lavoro ha un proprio flusso di lavoro che definisce stati, transizioni e motivi. Le transizioni spostano gli elementi di lavoro in avanti e indietro tra gli stati. Quando si aggiunge uno stato personalizzato, Azure DevOps aggiunge transizioni predefinite in base alle regole del processo.

Azure Boards usa le categorie di stato per applicare il comportamento del flusso di lavoro in modo coerente tra backlog, bacheche e widget. Questo articolo spiega come gli stati vengono associati alle categorie e in che modo tale associazione influisce sulla visibilità degli elementi, sulle colonne della bacheca e sul comportamento della reportistica.

Stati del flusso di lavoro

Gli stati del flusso di lavoro definiscono il modo in cui un elemento di lavoro passa dalla creazione alla chiusura. Nel processo Agile, una storia utente si sposta in genere tra Nuovo, Attivo, Risolto e Chiuso. Per rimuovere un elemento di lavoro dal backlog, usare lo stato Rimosso. Per altre informazioni, vedere Spostare, modificare o eliminare elementi di lavoro.

Il diagramma seguente illustra i percorsi tipici di progressione e regressione per i tipi di elementi di lavoro comuni: storia utente (Agile), problema (Basic), elemento backlog del prodotto (Scrum) e requisito (CMMI).

Stati del flusso di lavoro: Storia utente, processo Agile

Diagramma che mostra gli stati del flusso di lavoro User Story per il processo Agile.

Stati categoria

Le categorie di stato standardzzano il modo in cui gli strumenti di pianificazione Agile e i widget del dashboard interpretano gli stati del flusso di lavoro. Teams esegue il mapping degli stati del flusso di lavoro a questi stati di categoria: Proposto, In corso, Risolto e Completato.

La tabella seguente mostra come gli stati predefiniti ereditati corrispondono agli stati di categoria nei quattro processi di sistema, compresi i tipi di elemento di lavoro del piano di test. I flussi di lavoro Test Case, Test Design e Test Suite usano gli stessi mapping in tutti e quattro i processi.

Categories

Monitoraggio del lavoro

Monitoraggio del test

Proposto: Usare questa categoria per gli stati degli elementi di lavoro appena aggiunti. Gli elementi vengono visualizzati nel backlog e la prima colonna delle bacheche e delle schede attività viene mappata a Proposta.

New

Progettazione (caso di test)

In corso: Usare questa categoria per gli stati di lavoro attivi. Gli elementi vengono visualizzati nel backlog (a meno che non siano nascosti) e corrispondono alle colonne centrali della bacheca.

Attivo ("Bug," "Epic," "Feature," "User Story")

Attivo (piano di test); In pianificazione (Suite di test); In corso (Suite di test); Pronto (Caso di test)

Risolto: Usare questa categoria per gli stati in cui una soluzione viene implementata ma non ancora verificata (comunemente per i bug). Gli elementi contrassegnati come risolti vengono visualizzati nel backlog per impostazione predefinita, possono essere inclusi nei grafici di burndown e in molti strumenti si comportano come «In corso».

Risolto (Bug)

n/a

Completato: Usare questa categoria per gli stati di lavoro completati. Gli elementi non vengono visualizzati nel backlog e sono associati alla colonna finale della bacheca. Ogni tipo di elemento di lavoro può avere un solo stato mappato a questa categoria.

Chiuso (Bug, Epic, Feature, User Story)

Chiuso (Test Case); Completato (Test Suite); Inattivo (Test Plan)

Rimosso: Usare questa categoria con lo stato Rimosso per nascondere gli elementi dalle esperienze di backlog e bacheca.

Rimosso (Epic, Funzionalità, User Story)

n/a

Posizione in cui vengono visualizzati i tipi di elementi di lavoro

Usare la tabella seguente come riferimento rapido per la posizione in cui viene visualizzata ogni categoria di tipo di elemento di lavoro.

Categoria tipo di elemento di lavoro Viene visualizzato su
Requirement Solo scheda prodotto
Feature Solo scheda portfolio di funzionalità
Epic Solo scheda portfolio epica
Custom Solo scheda portfolio personalizzata

Tip

Mappa ogni stato del flusso di lavoro a una colonna della bacheca. Se non viene eseguito il mapping di uno stato, non viene visualizzato nella scheda.

Note

  • I backlog e le bacheche nascondono gli elementi di lavoro completati o chiusi quando la data di modifica risale a più di 183 giorni fa (circa sei mesi).
  • Trova elementi nascosti tramite una query.
  • Mostrare di nuovo un elemento in un backlog o una bacheca apportando una modifica minore per aggiornare la Data di modifica.

Note

  • I backlog e le bacheche nascondono gli elementi di lavoro completati o chiusi quando il valore Changed Date risale a più di un anno fa.
  • Trova elementi nascosti eseguendo una query.
  • Mostrare nuovamente un elemento in un backlog o una bacheca apportando un aggiornamento minimo per aggiornare la Data di modifica.

Campi Attivato per/Data e Risolto per/Data

Il sistema aggiorna questi campi: Attivato da, Data attivata, Risolto per e Data risolta, in base alle modifiche dello stato della categoria del flusso di lavoro:

  • Quando lo stato del flusso di lavoro passa a una categoria In corso , il sistema aggiorna Attivato da e Data attivata.
  • Quando lo stato del flusso di lavoro passa a una categoria risolta , il sistema aggiorna Resolved By e Resolved Date.

Per altre informazioni sul mapping degli stati del flusso di lavoro alle categorie di stato, vedere Modalità di utilizzo degli stati e delle categorie di stato del flusso di lavoro in Backlog e Boards.

Note

Questa logica si applica ad Azure DevOps Services, all'aggiornamento di Azure DevOps Server 2020.1 e alle versioni successive.

Poiché questi campi fanno riferimento a categorie di stato del flusso di lavoro, qualsiasi stato del flusso di lavoro personalizzato che aggiungi attiverà anche gli aggiornamenti dei campi. Per altre informazioni, vedere Personalizzare il flusso di lavoro per un processo.

Note aggiuntive

  • I campi vengono aggiornati ogni volta che un elemento di lavoro passa da uno stato di categoria diverso da quello impostato. Ad esempio, se si sposta un elemento di lavoro da Nuovo a Fisso, i campi Risolto da/Data di risoluzione vengono aggiornati. Se passi da Corretto a Pronto per i test, che appartengono allo stesso stato di categoria, i campi Risolto da/Data di risoluzione non vengono aggiornati.
  • Quando si cambia all'indietro, come da uno stato Risolto a uno stato Attivo, il sistema cancella i campi Risolto da/Data di risoluzione. Se si passa da Attivo a Nuovo, il sistema cancella i campi Attiva per/Data attivata .
  • Non modificare manualmente questi valori di campo. Questi campi sono campi di sistema regolati dalle regole di sistema e Azure DevOps sovrascrive tutti i valori manuali.

Quando aggiungere uno stato rispetto a una colonna

Usa insieme stati e colonne per tenere traccia dello stato del lavoro, ma usali ciascuno per un ambito diverso:

  • Stato: logica del flusso di lavoro a livello di Project condivisa tra i team.
  • Colonna: visualizzazione della bacheca a livello di team.

Gli utenti con autorizzazioni per la modifica del processo (in genere gli amministratori della raccolta di progetti o gli editor di processo delegati) possono aggiungere stati personalizzati. Gli amministratori del team e gli amministratori di Project possono aggiungere colonne della lavagna.

Aggiungere stati personalizzati quando i team necessitano di una definizione del flusso di lavoro condivisa per query, report e coerenza tra team. Gli stati personalizzati si propagano ai tipi di elemento di lavoro che fanno riferimento al processo.

Aggiungere o modificare le colonne quando un team necessita di una visualizzazione specifica della lavagna del lavoro senza modificare il flusso di lavoro condiviso.

Per evitare confusione, mantenere la proprietà degli elementi di lavoro allineata ai percorsi dell'area del team o standardizzare i flussi di lavoro condivisi con stati personalizzati quando più team seguono lo stesso processo.

Completare automaticamente gli elementi di lavoro con richieste pull

Quando si collega un elemento di lavoro a una richiesta pull, Azure DevOps può completare automaticamente l'elemento di lavoro collegato al termine della richiesta pull. Per altre informazioni, vedi Completare automaticamente gli elementi di lavoro con richieste pull.

Automatizzare le transizioni di stato degli elementi di lavoro

In Azure DevOps è possibile aggiornare automaticamente lo stato di un elemento di lavoro padre in base allo stato delle attività figlie. Per informazioni dettagliate, vedere Automatizzare le transizioni di stato degli elementi di lavoro.

Contenuti correlati

Modello di processo di ereditarietà

Modello di processo XML locale

Widget del dashboard

  • Last updated on