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

  • Articolo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Tutti i flussi di lavoro sono costituiti da stati, transizioni e motivi. I flussi di lavoro vengono definiti per un tipo di elemento di lavoro. Una transizione supporta lo spostamento avanti e indietro tra due stati. Quando si aggiunge uno stato personalizzato, il sistema aggiunge automaticamente transizioni dallo stato personalizzato a tutti gli altri stati ereditati (ad eccezione di Removed).

Ogni stato appartiene a una categoria di stato (definita in precedenza metastate). Le categorie di stato supportano il backlog dello strumento Agile e le visualizzazioni della scheda.

Stati del flusso di lavoro

Gli stati del flusso di lavoro definiscono l'avanzamento di un elemento di lavoro dalla creazione alla chiusura. I quattro stati principali definiti per la storia utente (processo Agile) descrivono la progressione della storia utente. Gli stati del flusso di lavoro sono New, Active, Resolved e Closed. Lo stato Rimosso supporta la rimozione di un elemento di lavoro dalla visualizzazione nel backlog. Per altre informazioni, vedere Spostare, modificare o eliminare elementi di lavoro.

Le progressione e le regressioni naturali per i tipi di elemento di lavoro ( User Story (Agile), issue (Basic) product backlog item (Scrum) e requirement (CMMI) sono illustrate.

Stati del flusso di lavoro: Storia utente, processo Agile

Stati del flusso di lavoro della storia utente, processo Agile

Stati categoria

Gli stati delle categorie determinano il modo in cui gli strumenti di pianificazione Agile e selezionano i widget del dashboard gestiscono ogni stato del flusso di lavoro. Le categorie di stato usate dai backlog, dalle bacheche e dai widget sono Proposte, In corso, Risolte e Completa.

Ecco come vengono mappati gli stati ereditati predefiniti agli stati di categoria per i quattro processi di sistema, inclusi i tipi di elemento di lavoro del piano di test. Gli stati del flusso di lavoro per Test Case, Test Design e Test Suite sono gli stessi in tutti e quattro i processi di sistema.

Categorie

Rilevamento del lavoro

Verifica del test

Proposta: assegnata agli stati associati agli elementi di lavoro appena aggiunti in modo che vengano visualizzati nel backlog. La prima colonna delle bacheche Kanban e delle schede attività viene mappata a una categoria Stato proposto.

Nuovo

Progettazione (test case)

In corso: assegnato agli stati che rappresentano il lavoro attivo. Gli elementi di lavoro assegnati agli stati mappati a questa categoria vengono visualizzati nel backlog (a meno che non si scelga di nasconderli) e costituiscono le colonne centrali nelle schede Kanban.

Attivo (Bug, Epic, Feature, User Story)

Attivo (piano di test) nella pianificazione (gruppo di test) in corso (gruppo di test) pronto (test case)

Risolto: assegnato agli stati che rappresentano una soluzione è stata implementata, ma non ancora verificata. In genere questi stati si applicano ai bug. Gli elementi di lavoro in uno stato di categoria risolto vengono visualizzati nel backlog per impostazione predefinita. Gli strumenti Agile considerano lo stato della categoria Risolta esattamente come lo stato della categoria In corso .

Risolto (bug)

n/d

Completato: assegnato agli stati che rappresentano il lavoro completato. Gli elementi di lavoro il cui stato si trova in questa categoria non vengono visualizzati nel backlog e vengono visualizzati nell'ultima colonna della scheda Kanban. Non è possibile modificare gli stati in questa categoria né aggiungere stati a questa categoria.

Chiuso (Bug, Epic, Feature, User Story)

Chiuso (test case) completato (gruppo di test) inattivo (piano di test)

Rimosso: assegnato allo stato Rimosso. Gli elementi di lavoro in uno stato mappato alla categoria Rimossa sono nascosti dalle esperienze backlog e bacheca.

Rimosso (Epic, Feature, User Story)

n/d

Nota

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche dopo che il valore di Data modifica è maggiore di 183 giorni (circa mezzo anno). È comunque possibile elencare questi elementi usando una query. Se si desidera che vengano visualizzati su un backlog o una lavagna, è possibile apportare una modifica secondaria a essi, che reimposta l'orologio.

Nota

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche dopo che il valore di Data modifica è maggiore di un anno. È comunque possibile elencare questi elementi usando una query. Se si desidera che vengano visualizzati su un backlog o una lavagna, è possibile apportare una modifica secondaria a essi, che reimposta l'orologio.

Campi Attivato per/Data e Risolto per/Data

Il sistema aggiorna questi campi, attivati da, data attivata, risolto per e data risolta, quando si verifica una modifica in base agli stati della categoria del flusso di lavoro corrispondenti. Quando lo stato del flusso di lavoro passa a una categoria di stato In corso , Viene aggiornata la data attivata da e attivata . Quando lo stato del flusso di lavoro passa a una categoria di stato risolto , vengono aggiornati Resolved By e Resolved Date .

Per altre informazioni sul mapping degli stati del flusso di lavoro alle categorie di stato, vedere Come vengono usati gli stati e le categorie di stato del flusso di lavoro in Backlog e Boards.

Nota

La logica che regola i campi descritti di seguito si applica ad Azure DevOps Services, all'aggiornamento di Azure DevOps Server 2020.1 e alle versioni successive.

Poiché questi campi fanno riferimento alle categorie di stato del flusso di lavoro, al momento dell'aggiornamento dei campi viene fatto riferimento agli stati del flusso di lavoro personalizzati. Per altre informazioni sulla personalizzazione, vedere Personalizzare il flusso di lavoro per un processo.

Note aggiuntive:

  • I campi vengono aggiornati ogni volta che un elemento di lavoro passa da qualsiasi stato di categoria diverso da quello impostato. Ad esempio, se si aggiorna un elemento di lavoro da Nuovo a Fisso, i campi Data risolti per/risolti vengono aggiornati. Tuttavia, se si esegue l'aggiornamento da Fixed e Ready for Testing( che si trovano nello stesso stato della categoria), i campi Resolved By/Resolved Date (Data risolta) non vengono aggiornati.
  • Quando si passa all'indietro, ad esempio passando da uno stato Risolto a uno stato Attivo, il sistema cancella i valori per i campi Data risolti per/risolti. Se è stato ottenuto da Attivo a Nuovo, il sistema cancella i valori per i campi Data attivata da/attivato.
  • Non modificare manualmente i valori per questi campi. Sono campi di sistema regolati dalle regole di sistema. Qualsiasi valore che si tenta di impostare viene sovrascritto.

Quando aggiungere uno stato rispetto a una colonna Kanban

Usare entrambe le colonne States e Kanban per tenere traccia dello stato del lavoro. Gli stati del flusso di lavoro vengono condivisi in un progetto mentre le colonne Kanban vengono condivise all'interno di un team. Solo gli amministratori della raccolta di progetti possono aggiungere stati personalizzati, mentre gli amministratori del team possono aggiungere colonne Kanban.

Aggiungere stati personalizzati quando si vuole che tutti i team tengono traccia dello stato in base al flusso di lavoro aziendale adottato dall'organizzazione. Personalizzando il processo, si personalizzano automaticamente i progetti e i tipi di elemento di lavoro che fanno riferimento a tale processo.

L'aggiunta di stati personalizzati per supportare gli stati del flusso di lavoro che più team vogliono tenere traccia consente di evitare la confusione risultante di team diversi che creano query in base a una colonna Kanban. Poiché ogni team può personalizzare le colonne della lavagna Kanban e le corsie, i valori assegnati agli elementi di lavoro visualizzati in schede diverse potrebbero non essere uguali. La soluzione alternativa principale per questo problema consiste nel mantenere la singola proprietà degli elementi di lavoro in base al percorso dell'area del team. Un'altra soluzione alternativa consiste nel formalizzare le colonne aggiungendo stati personalizzati che possono essere condivisi tra team.

Completamento automatico degli elementi di lavoro con richieste pull

Quando si collega un elemento di lavoro a una richiesta pull, è possibile completare automaticamente tali elementi di lavoro al termine della richiesta pull. Per altre informazioni, vedere Completamento automatico degli elementi di lavoro con richieste pull.

Automatizzare le transizioni di stato degli elementi di lavoro

È possibile aggiornare automaticamente lo stato di un elemento di lavoro in base allo stato delle attività figlio. Per altre informazioni, vedere Automatizzare le transizioni di stato degli elementi di lavoro.