Informazioni sui processi predefiniti e sui modelli di processo

  • Articolo

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

Azure Boards offre diversi processi tra cui scegliere per la gestione degli elementi di lavoro. La selezione del processo corretto è essenziale per ottimizzare un flusso di lavoro del progetto e garantirne il successo. In questo articolo vengono esaminati i diversi processi disponibili con Azure Boards. Questo articolo fornisce anche indicazioni su come scegliere il processo 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 predefiniti e nei modelli di processo, ovvero Basic, Agile, Capability Maturity Model Integration (CMMI) e Scrum, sono gli stessi. Sono 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 la sezione Scegliere il modello di processo per la raccolta di progetti in Personalizzare l'esperienza di rilevamento del lavoro. Per accedere alle versioni più recenti dei processi/modelli di processo predefiniti:

  • Modello di processo ereditato: aprire la pagina Processi . Per altre informazioni, vedere Gestire i processi.
  • Modello di processo XML locale:

Processi predefiniti

I processi predefiniti differiscono principalmente nei tipi di elemento di lavoro forniti per la pianificazione e il monitoraggio del lavoro. I processi predefiniti sono:

  • Basic: è il più leggero ed è in un'anteprima selettiva.
  • Scrum: è il prossimo più leggero.
  • Agile: supporta molti termini di metodo Agile.
  • 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 i tipi di elemento di lavoro Issue, Task e Epic per tenere traccia del lavoro.

Le attività supportano il rilevamento del lavoro rimanente.

Tipi di elementi di lavoro di base

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 è ideale per tenere traccia delle storie utente e (facoltativamente) dei bug nella scheda Kanban. È anche possibile 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.

Tipi di elemento di lavoro Agile

Scrum

Scegliere Scrum quando il team esegue le procedure scrum. Questo processo è ideale per tenere traccia degli elementi e dei bug del backlog del prodotto nella scheda Kanban. È anche possibile suddividere gli elementi e i bug del backlog del prodotto 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.

Tipi di elemento di lavoro Scrum

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 è possibile 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.

Tipi di elementi di lavoro CMMI

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. È anche possibile creare un progetto da un processo e quindi personalizzare il progetto.

La tabella seguente riepiloga le principali distinzioni tra i tipi di elemento di lavoro e gli stati usati dai quattro processi predefiniti.

Area di rilevamento

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 (vedere la nota 2)

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

Pianificazione di attività e sprint (vedere la nota 3)

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

Gestione dei backlog di bug (vedere la nota 1)

  • Problema
  • Bug
  • Bug
  • Bug

Gestione dei problemi e dei rischi

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

Note:

  1. 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.
  2. 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.
  3. Definire le attività dal backlog sprint e dal taskboard. Con la pianificazione della capacità, i team possono determinare rapidamente se sono eccessivamente incapsulati o incapsulati per uno sprint.

Stati del flusso di lavoro, transizioni e motivi

Gli stati del flusso di lavoro supportano il rilevamento dello stato del lavoro durante lo spostamento da New uno stato a uno Closed stato o Done . 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 questi tipi di elemento di lavoro usati per tenere traccia dei difetti di 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

Screenshot che mostra gli stati del flusso di lavoro di User Story usando il processo Agile.

Funzionalità

Screenshot che mostra gli stati del flusso di lavoro funzionalità usando il processo Agile.

Epica

Screenshot che mostra gli stati del flusso di lavoro Epic usando il processo Agile.

Bug

Screenshot che mostra gli stati del flusso di lavoro bug usando il processo Agile

Attività

Screenshot che mostra gli stati del flusso di lavoro attività usando il processo Agile

La maggior parte dei tipi di elementi di lavoro 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à trascinandola 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. Vengono visualizzati nelle pagine di backlog sprint, nella bacheca Kanban e nella lavagna delle attività. Inoltre, quando si modifica la visualizzazione backlog portfolio in Mostra elementi backlog, ad esempio per visualizzare le funzionalità per gli elementi backlog del prodotto, gli elementi di lavoro nello Closed stato e Done vengono visualizzati.
  • 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 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.

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

Tipi di elemento di lavoro aggiunti a tutti i processi

I tipi di elemento di lavoro seguenti vengono aggiunti a tutti i processi ad eccezione del processo Basic.

Screenshot che mostra i tipi di elementi di lavoro usati da Test Plans, Responsabili test Microsoft, My Work e 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.

Tipi di elementi di lavoro che supportano l'esperienza di test

I tipi di elemento di lavoro che supportano l'esperienza di test e usano Gestione test e il portale Web vengono collegati usando i tipi di collegamento illustrati nell'immagine seguente.

Screenshot che mostra i tipi di elemento di lavoro di gestione dei test.

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 questi tipi di elemento di lavoro come qualsiasi altro tipo di elemento di lavoro. 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.