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:
- Installare o eseguire l'aggiornamento alla versione più recente di Azure DevOps Server
- Scaricare il file modello compresso usando Gestione modelli di processo. Sarà necessario usare una versione di Visual Studio con lo stesso livello di versione di Azure DevOps Server. È possibile installare gratuitamente la versione più recente di Visual Studio Community .
- È possibile accedere alle versioni più recenti dei modelli di processo predefiniti installati in Azure DevOps Server, ad esempio:
%programfiles%/Azure DevOps Server 2020/Tools/Deploy/ProcessTemplateManagerFiles/1033
. Per le descrizioni di ogni file e cartella, vedere Panoramica dei file modello di processo.
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.
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.
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.
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.
Se sono necessari più di due o tre livelli di backlog, aggiungere altro in base al modello di processo usato:
- Ereditarietà: personalizzare i backlog o le bacheche per un processo
- XML ospitato o XML locale: aggiungere backlog di portfolio
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
Funzionalità
Epica
Bug
Attività
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
, Closed
o 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
, Done
o 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.
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 Steps Shared 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.
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.
Articoli correlati
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: nel corso del 2024 verranno dismessi i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedere:Invia e visualizza il feedback per