Informazioni sui processi predefiniti e sui modelli di processo

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

Azure Boards offre diversi processi tra cui scegliere per la gestione degli elementi di lavoro. La selezione del processo corretto è essenziale per ottimizzare il flusso di lavoro e garantire il successo di un progetto. In questo articolo vengono esaminati i diversi processi disponibili in Azure Boards e vengono fornite indicazioni su come scegliere quello più adatto per il progetto.

Quando si crea un progetto, si sceglie un modello di processo o di processo in base al modello di processo per cui è stata creata l'organizzazione o la raccolta. Prima di scegliere un processo per il progetto, è necessario comprendere i termini seguenti.

Termine Descrizione
Modello di processo Fa riferimento al modello usato per supportare i progetti creati per un'organizzazione o una raccolta di progetti. È supportato un solo modello di processo per un progetto alla volta.
Processo Definisce i blocchi predefiniti del sistema di rilevamento degli elementi di lavoro e supporta il modello di processo di ereditarietà per Azure Boards. Questo modello supporta la personalizzazione dei progetti tramite un'interfaccia utente What You Get (WYSIWYG).
Modello di processo Definisce i blocchi predefiniti del sistema di rilevamento degli elementi di lavoro e di altri sottosistemi a cui si accede tramite Azure DevOps. I modelli di processo vengono usati solo con i modelli di processo XML ospitati e XML locali. È possibile personalizzare i progetti modificando e importando i file di definizione XML del modello di processo.

Gli oggetti di rilevamento del lavoro contenuti nei processi e nei modelli di processo predefiniti, ovvero Basic, Agile, Capability Maturity Model Integration (CMMI) e Scrum, sono gli stessi e riepilogati in questo articolo.

Suggerimento

Con Azure DevOps Server è possibile scegliere tra il modello di processo ereditato o il modello di processo XML locale. Per altre informazioni, vedere Personalizzare l'esperienza di rilevamento del lavoro, Scegliere il modello di processo per la raccolta di progetti. Per accedere alle versioni più recenti dei processi/modelli di processo predefiniti:

  • Per Modello di processo ereditato: aprire la pagina Processo dalle impostazioni delle organizzazioni. Per altre informazioni, vedere Gestire i processi.
  • Per il modello di processo XML locale:

Suggerimento

Per accedere alle versioni più recenti dei modelli di processo predefiniti:

  • Installare o eseguire l'aggiornamento alla versione più recente di TFS.
  • Scaricare il file modello compresso usando Gestione modelli di processo. È necessario usare una versione di Visual Studio con lo stesso livello di versione di TFS. È possibile installare gratuitamente la versione più recente di Visual Studio Community .
  • È possibile accedere alle versioni più recenti dei modelli di processo predefiniti installati in TFS 2018 qui: %programfiles%/TFS 16.0/Tools/Deploy/ProcessTemplateManagerFiles/1033 Per le descrizioni di ogni file e cartella, vedere Panoramica dei file modello di processo.

Processi predefiniti

I processi predefiniti differiscono principalmente nei tipi di elementi di lavoro (WIT) che forniscono per la pianificazione e il monitoraggio del lavoro.

Basic è il più leggero ed è in un'anteprima selettiva. Scrum è il prossimo più leggero. Agile supporta molti termini di metodo Agile e CMMI offre il supporto massimo per i processi formali e la gestione delle modifiche.

Nota

Il processo Basic è disponibile con Azure DevOps Server 2019 Update 1 e versioni successive.

Base

Scegliere Basic quando il team vuole il modello più semplice che usa Problemi, Attività ed Epiche per tenere traccia del lavoro.

Le attività supportano il rilevamento del lavoro rimanente.

Basic work item types


Agile

Scegliere Agile quando il team usa metodi di pianificazione Agile, tra cui Scrum, e tiene traccia separatamente delle attività di sviluppo e test. Questo processo funziona bene se si vogliono tenere traccia delle storie utente e (facoltativamente) bug nella scheda Kanban o tenere traccia di bug e attività nella lavagna delle attività.

Per altre informazioni sulle metodologie Agile, vedere Agile Alliance.

Le attività supportano il rilevamento della stima originale, del lavoro rimanente e del lavoro completato.

Agile work item types


Scrum

Scegliere Scrum quando il team esegue le procedure scrum. Questo processo è ideale per tenere traccia degli elementi di backlog del prodotto (PBI) e bug nella scheda Kanban. Suddividere anche i pbi e i bug nelle attività nella lavagna delle attività.

Questo processo supporta la metodologia Scrum definita dall'organizzazione Scrum.

Le attività supportano solo il rilevamento del lavoro rimanente.

Scrum work item types


CMMI

Scegliere CMMI quando il team segue metodi di progetto più formali che richiedono un framework per il miglioramento del processo e un record controllabile delle decisioni. Con questo processo, tenere traccia dei requisiti, modificare richieste, rischi e revisioni.

Questo processo supporta le attività formali di gestione delle modifiche. Le attività supportano il rilevamento della stima originale, del lavoro rimanente e del lavoro completato.

CMMI work item types


Se sono necessari più di due o tre livelli di backlog, aggiungere altro in base al modello di processo usato:

Principali distinzioni tra i processi predefiniti

I processi predefiniti sono progettati per soddisfare le esigenze della maggior parte dei team. Se il team ha esigenze insolite e si connette a un server locale, personalizzare un processo e quindi creare il progetto. In alternativa, creare un progetto da un processo e quindi personalizzare il progetto.

Nella tabella seguente sono riepilogate le principali distinzioni tra le connessioni WIT e gli stati usati dai quattro processi predefiniti.

Area di rilevamento

Di base

Agile

Scrum

CMMI


Stati del flusso di lavoro

  • Attività
  • In corso
  • Fatto
  • Nuovo
  • Attive
  • Risolto
  • Chiusa
  • Rimosse
  • Nuovo
  • Approvato
  • Commit eseguito
  • Fatto
  • Rimosse
  • Proposto
  • Attive
  • Risolto
  • Chiusa

Pianificazione del prodotto (vedere la nota 1)

  • Problema
  • Storia utente
  • Bug (facoltativo)
  • Elemento backlog prodotto
  • Bug (facoltativo)
  • Requisito
  • Bug (facoltativo)

Backlog portfolio (2)

  • Epica
  • Epica
  • Funzionalità
  • Epica
  • Funzionalità
  • Epica
  • Funzionalità

Pianificazione di attività e sprint (3)

  • Attività
  • Attività
  • Bug (facoltativo)
  • Attività
  • Bug (facoltativo)
  • Attività
  • Bug (facoltativo)

Gestione del backlog di bug (1)

  • Problema
  • Bug
  • Bug
  • Bug

Gestione dei problemi e dei rischi

  • Problema
  • Problema
  • Impedimento
  • Problema
  • Rischio
  • Revisione

  • Aggiungere elementi di lavoro dal backlog del prodotto o dalla scheda Kanban. Il backlog del prodotto mostra una singola visualizzazione del backlog di lavoro corrente che può essere riordinato e raggruppato in modo dinamico. I proprietari dei prodotti possono definire rapidamente la priorità del lavoro e delineare dipendenze e relazioni. Inoltre, ogni team può configurare la modalità di visualizzazione dei bug nei backlog e nelle bacheche.
  • Definire una gerarchia di backlog del portfolio per comprendere l'ambito del lavoro in più team e vedere come il lavoro viene eseguito in iniziative più ampie. Ogni team configura i backlog del portfolio visualizzati per l'uso.
  • Definire le attività dal backlog sprint e dal taskboard. Con la pianificazione della capacità, i team possono determinare rapidamente se sono oltre o sotto capacità per uno sprint.

Stati del flusso di lavoro, transizioni e motivi

Gli stati del flusso di lavoro supportano il rilevamento dello stato del lavoro man mano che passa da un nuovo stato a uno stato chiuso o completato. Ogni flusso di lavoro è costituito da un set di stati, dalle transizioni valide tra gli stati e dai motivi per la transizione dell'elemento di lavoro allo stato selezionato.

Importante

Per Azure DevOps Services e Azure DevOps Server 2019, le transizioni predefinite del flusso di lavoro supportano qualsiasi stato a qualsiasi transizione di stato. Personalizzare questi flussi di lavoro per limitare alcune transizioni. Per altre informazioni, vedere Personalizzare gli oggetti di rilevamento del lavoro per supportare i processi del team.

Visualizzare anche le transizioni di flusso di lavoro supportate per ogni tipo di elemento di lavoro installando l'estensione State Model Visualization Marketplace. Questa estensione aggiunge un nuovo hub in Boards con etichetta State Visualizer. In tale pagina scegliere un tipo di elemento di lavoro e visualizzare il modello di stato del flusso di lavoro.

I diagrammi seguenti mostrano la tipica progressione in avanti di tali reti wit usate per tenere traccia dei difetti del lavoro e del codice per i tre processi predefiniti. Mostrano anche alcune regressioni agli stati precedenti e le transizioni agli stati rimossi. Ogni immagine mostra solo il motivo predefinito associato alla transizione.

Storia utente

User story workflow states, Agile process

Funzionalità

Feature workflow states, Agile process

Epica

Epic workflow states, Agile process

Bug

Bug workflow states, Agile process

Attività

Task workflow states, Agile process

La maggior parte dei wit usati dagli strumenti Agile, quelli visualizzati nei backlog e nelle schede, supportano transizioni any-to-any. Aggiornare lo stato di un elemento di lavoro usando la lavagna Kanban o la lavagna attività trascinandolo nella colonna di stato corrispondente.

Modificare il flusso di lavoro per supportare altri stati, transizioni e motivi. Per altre informazioni, vedere Personalizzare l'esperienza di rilevamento del lavoro.

Stati degli elementi di lavoro

Quando si modifica lo stato di un elemento di lavoro in Removed, Closedo Done, il sistema risponde come segue:

  • Closed / Done: gli elementi di lavoro in questo stato non vengono visualizzati nelle pagine backlog e backlog del portfolio. Tuttavia, vengono visualizzate nelle pagine backlog sprint, nella lavagna Kanban e nella lavagna delle attività. Inoltre, quando si modifica la visualizzazione backlog del portfolio per visualizzare gli elementi backlog, ad esempio per visualizzare Funzionalità per gli elementi backlog prodotto, vengono visualizzati gli elementi di lavoro nello stato chiuso e completato.
  • Removed: gli elementi di lavoro in questo stato non vengono visualizzati in alcun backlog o scheda.

Il progetto mantiene gli elementi di lavoro purché il progetto sia attivo. Anche se si impostano elementi di lavoro su Closed, Doneo Removed, l'archivio dati mantiene un record. Usare un record per creare query o report.

Nota

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche una volta che la data modificata è maggiore di 183 giorni (circa mezzo anno). È comunque possibile elencare questi elementi usando una query. Se si vuole che vengano visualizzati in un backlog o una bacheca, è possibile modificarli leggermente in modo da reimpostare l'orologio.

Nota

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche dopo che la data modificata è maggiore di un anno. È comunque possibile elencare questi elementi usando una query. Se si vuole che vengano visualizzati in un backlog o una bacheca, è possibile modificarli leggermente in modo da reimpostare l'orologio.

Se è necessario eliminare definitivamente gli elementi di lavoro, vedere Rimuovere o eliminare elementi di lavoro.

Wit aggiunti a tutti i processi

Le connessioni WIT seguenti vengono aggiunte a tutti i processi, ad eccezione del processo Basic.

Work item types used by Test Plans, Microsoft Test Managers, My Work, and Feedback

Il team può creare e lavorare con questi tipi usando lo strumento corrispondente:

Tool Tipi di elemento di lavoro
Microsoft Test Manager Test Plan, Test Suite, Test Case Shared StepsShared Parameters
Richiedere commenti e suggerimenti Feedback Request, Feedback Response
Lavoro personale (da Team Explorer), Revisione codice Code Review Request, Code Review Response

Gli elementi di lavoro di queste definizioni di tipo non devono essere creati manualmente e vengono quindi aggiunti alla Hidden Types categoria. I tipi di elemento di lavoro aggiunti alla Hidden Types categoria non vengono visualizzati nei menu che creano nuovi elementi di lavoro.

WiT che supportano l'esperienza di test

WiT che supportano l'esperienza di test e funzionano con Gestione test e il portale Web vengono collegati insieme usando i tipi di collegamento illustrati nell'immagine seguente.

Test management work item types

Dal portale Web o da Microsoft Test Manager, visualizzare i test case definiti per un gruppo di test e visualizzare i gruppi di test definiti per un piano di test. Tuttavia, questi oggetti non sono connessi tra loro tramite tipi di collegamento. Personalizzare queste connessioni WIT come qualsiasi altro WIT. Per altre informazioni, vedere Personalizzare gli oggetti di rilevamento del lavoro per supportare i processi del team.

Se si modifica il flusso di lavoro per il piano di test e il gruppo di test, potrebbe essere necessario aggiornare la configurazione del processo come descritto qui. Per le definizioni di ogni campo di test, vedere Eseguire query in base ai campi di integrazione di compilazione e test.