Processi predefiniti e modelli di processo

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

Azure Boards offre diversi processi per la gestione degli elementi di lavoro. La selezione del processo corretto consente di ottimizzare il flusso di lavoro del progetto e di impostare il team per il successo. Questo articolo descrive i processi disponibili in Azure Boards e consente di scegliere quello più adatto al 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.

Term Description
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.
Process 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 editor visivo nel portale Web di Azure DevOps.
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.

I tipi di processo predefiniti sono Basic, Agile, Capability Maturity Model Integration (CMMI) e Scrum. Gli oggetti di rilevamento del lavoro nei processi predefiniti e nei modelli di processo sono gli stessi. Questo articolo li riepiloga.

Tip

Con Azure DevOps Server è possibile selezionare il modello di processo ereditato o il modello di processo XML locale. Per altre informazioni, vedere Scegliere il modello di processo per la raccolta di progetti. Per accedere alle versioni più recenti dei processi predefiniti o dei modelli di processo:

Processi predefiniti

I processi predefiniti differiscono principalmente nei tipi di elemento di lavoro che forniscono per la pianificazione e il rilevamento del lavoro. Usare la guida seguente per scegliere il processo più adatto al team:

  • Scegli Basic per un'esperienza più semplice: monitora il lavoro come Epic, Issue e Task.
  • Scegliere Agile se il team usa metodi Agile e si vuole tenere traccia delle storie utente con attività di sviluppo e test separate.
  • Scegli Scrum se il tuo team segue Scrum e tiene traccia degli elementi del backlog di prodotto e dei bug.
  • Scegliere CMMI se il team necessita di una gestione formale dei cambiamenti, un record controllabile di decisioni e verifica dei requisiti, richieste di modifica, rischi e recensioni.

Scegliere il processo corretto

Se non si è certi del processo più adatto al team, usare gli scenari seguenti come punto di partenza:

Scenario Procedura consigliata Perché
Non si ha familiarità con Azure Boards o si vuole il tracciamento più leggero. Basic Tre tipi di elemento di lavoro (Epic, Issue, Task) e un flusso di lavoro sempliceTo Do / Doing / Done.
Il tuo team adotta Agile, tiene traccia delle storie utente e separa lo sviluppo dalle attività di test. Agile Storie utente con tracciamento dei bug separato; stati più articolati (New, Active, Resolved, Closed, Removed).
Il tuo team adotta Scrum con sprint, elementi del backlog di prodotto e impedimenti. Scrum Elementi del backlog di prodotto e bug sulla bacheca; gli stati Approved e Committed corrispondono direttamente alle cerimonie di Scrum.
Si lavora in un ambiente regolamentato che richiede il controllo formale delle modifiche, un record controllabile di decisioni e il rilevamento dei rischi e delle revisioni. CMMI Aggiunge i tipi di elemento di lavoro Requisito, Richiesta di modifica, Rischio e Revisione e supporta attività formali di gestione delle modifiche.

Important

Non è possibile modificare il processo di base di un progetto dopo la creazione del progetto. È possibile personalizzare un processo ereditato per aggiungere campi, stati e tipi di elemento di lavoro oppure creare un nuovo progetto in un processo diverso e spostare elementi di lavoro tra progetti.

Note

La scelta o la personalizzazione di un processo richiede l'appartenenza al gruppo Project Collection Administrators. Per altre informazioni, vedere Informazioni di riferimento rapido sulle autorizzazioni predefinite.

Process Gerarchia degli elementi di lavoro
Basic

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à consentono il monitoraggio del lavoro rimanente.		 Diagramma che mostra i tipi di elemento di lavoro di base in una gerarchia.
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 user story e, facoltativamente, dei bug sulla lavagna. È 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.		 Diagramma che mostra i tipi di elemento di lavoro Agile in una gerarchia.
Scrum

Scegliere Scrum quando il team pratica Scrum. Questo processo è ideale per monitorare sulla scheda gli elementi e i bug del backlog del prodotto. È 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 monitoraggio del lavoro rimanente.		 Diagramma che mostra i tipi di elemento di lavoro Scrum in una gerarchia.
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.		 Diagramma che mostra i tipi di elemento di lavoro CMMI in una gerarchia.

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 soddisfano 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 Basic Agile Scrum CMMI
Stati del flusso di lavoro - Da fare
- In corso
-Fatto		 - Nuovo
- Attivo
- Risolti
- Chiusi
-Rimosso		 - Nuovo
-Approvato
- Confermato
-Fatto
-Rimosso		 - Proposto
- Attivo
- Risolti
- Chiusi
Pianificazione del prodotto (vedere la nota 1) - Problema - Storia utente
- Errore (facoltativo)		 - Elemento del backlog del prodotto
- Bug (facoltativo)		 -Requisito
- Bug (opzionale)
Backlog di portafoglio (vedi nota 2) -Epico -Epico
-Caratteristica		 -Epico
-Caratteristica		 -Epico
-Caratteristica
Pianificazione di attività e sprint (vedere la nota 3) - Compito - Compito
- Errore (facoltativo)		 - Compito
- Bug (facoltativo)		 - Compito
- Bug (facoltativo)
Gestione dei backlog di bug (vedere la nota 1) - Problema -Insetto -Insetto -Insetto
Gestione dei problemi e dei rischi - Problema - Problema -Impedimento - Richiesta di modifica
- Problema
-Rischio
-Recensione

Note

  1. Aggiungere elementi di lavoro dal backlog o dalla scheda del prodotto. Il backlog del prodotto mostra una singola visualizzazione del backlog di lavoro corrente che è possibile riordinare e raggruppare dinamicamente. I proprietari dei prodotti possono classificare in ordine di priorità il lavoro e delineare le dipendenze e le relazioni. 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 si integra in iniziative più ampie. Ogni team configura quali backlog del portfolio appaiono per il loro utilizzo.
  3. Definire le attività dal backlog dello sprint e dal taskboard. Con la pianificazione della capacità, i team possono determinare se sono in capacità eccessiva 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 durante il passaggio dallo stato New allo stato Closed 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.

Important

Transizioni del flusso di lavoro: I flussi di lavoro predefiniti in Azure DevOps supportano transizioni any-state-to-any-state. È possibile personalizzare questi flussi di lavoro per limitare transizioni specifiche in base ai requisiti del team. Per altre informazioni, vedere Personalizzare l'esperienza di rilevamento del lavoro.

Visualizzazione dei flussi di lavoro: Per visualizzare le transizioni di flusso di lavoro supportate per ogni tipo di elemento di lavoro, installare l'estensione State Model Visualization Marketplace. Questa estensione aggiunge un hub del visualizzatore di stato in Boards in cui è possibile selezionare un tipo di elemento di lavoro e visualizzare il modello di stato completo 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

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

Feature

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

Epic

Diagramma che mostra gli stati epici del flusso di lavoro usando il processo Agile.

Bug

Diagramma che mostra gli stati del flusso di lavoro dei Bug usando il processo Agile.

Task

Diagramma che mostra gli stati del flusso di lavoro delle attività, usando il processo Agile.

La maggior parte dei tipi di elementi di lavoro utilizzati dagli strumenti Agile, quelli che appaiono nei backlog e sulle schede, supportano transizioni da qualsiasi stato a qualsiasi altro stato. Aggiornare lo stato di un elemento di lavoro usando la scheda o la lavagna delle attività. Trascinare un elemento di lavoro 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.

Comportamento degli stati Removed, Closed e Done nei backlog

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

  • Closed o Done: gli elementi di lavoro in questo stato non vengono visualizzati nelle pagine backlog o backlog del portfolio, ma vengono visualizzati nelle pagine backlog dello sprint, nella bacheca e nella lavagna delle attività. Quando si modifica la visualizzazione del backlog del portfolio in Mostra elementi del backlog, ad esempio per visualizzare le funzionalità insieme agli elementi del backlog del prodotto, vengono visualizzati anche gli elementi di lavoro negli stati Closed e Done.
  • Removed: Gli elementi di lavoro in questo stato non vengono visualizzati in alcun backlog o board.

Note

Il flusso di lavoro CMMI predefinito non include uno Removed stato. Per rimuovere un elemento di lavoro CMMI dal rilevamento attivo, impostarne lo stato Closed su e scegliere un motivo appropriato(ad esempio, Posticipato o Rifiutato). È possibile personalizzare un processo ereditato per aggiungere uno Removed stato se il team ne ha bisogno.

Il tuo progetto mantiene gli elementi di lavoro finché il progetto è attivo. Anche se si impostano elementi di lavoro su Closed, Doneo Removed, l'archivio dati mantiene un record. È possibile usare questo record per creare query o report.

Note

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche dopo che il valore Data di 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.

Note

Gli elementi di lavoro completati o chiusi non vengono visualizzati nei backlog e nelle bacheche quando il valore di Data di modifica è superiore a 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.

Diagramma che mostra i tipi di elemento di lavoro usati da Piani di test, Microsoft Test Manager, My Work e Feedback.

Il team può creare e lavorare con questi tipi usando lo strumento corrispondente. Questi tipi di elemento di lavoro rimangono nello schema per garantire la compatibilità cronologica. Microsoft Test Manager e l'esperienza Di lavoro personale di Team Explorer sono strumenti legacy che vengono in gran parte sostituiti dal portale Web.

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

Non è possibile creare manualmente elementi di lavoro da queste definizioni di tipo. Vengono 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 collegamento illustrati nell'immagine seguente connettono i tipi di elemento di lavoro che supportano l'esperienza di test e funzionano con Gestione test e il portale Web.

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

Dal portale Web o Microsoft Test Manager è possibile 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 l'esperienza di rilevamento del lavoro.

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 in questo articolo. Per le definizioni di ogni campo di test, vedere Creare una query basata sui campi di integrazione di compilazione e test.

Contenuti correlati

  • Last updated on