Informazioni sulla personalizzazione dei processi e sui processi ereditati

  • Articolo

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

Per personalizzare il sistema di rilevamento del lavoro, personalizzare un processo ereditato tramite l'interfaccia utente amministrativa per l'organizzazione. Tutti i progetti che usano un processo ereditato ottengono le personalizzazioni apportate a tale processo. D'altra parte, è possibile configurare gli strumenti Agile, ovvero backlog, sprint, bacheche Kanban e Taskboard, per ogni team.

Importante

Per personalizzare un progetto locale o aggiornare i file di definizione XML per supportare la personalizzazione, vedere Modello di processo XML locale. Questo articolo si applica solo ad Azure DevOps Services e azure DevOps Server 2019.

Sono disponibili diverse personalizzazioni che è possibile apportare. I principali sono l'aggiunta di tipi di elementi di lavoro personalizzati (WIT) o la modifica di un WIT esistente per aggiungere campi personalizzati, modificare il layout o modificare il flusso di lavoro.

Nota

È possibile esaminare le modifiche apportate a un processo ereditato tramite il log di controllo. Per altre informazioni, vedere Accedere, esportare e filtrare i log di controllo.

Di seguito è riportato un indice per tali attività che è possibile eseguire per personalizzare un processo ereditato. Alcune opzioni degli elementi ereditati sono bloccate e non possono essere personalizzate.

Sistemi e processi ereditati

Verranno visualizzati due tipi di processi:

  • locked icon Processi di sistema , Agile, Basic, Scrum e CMMI, che non sono stati modificati.
  • inherited icon Processi ereditati, che è possibile personalizzare e che ereditano le definizioni dal processo di sistema da cui sono state create. I processi di sistema sono di proprietà e aggiornati periodicamente da Microsoft. Tutti gli aggiornamenti apportati a un processo di sistema causano automaticamente un aggiornamento ai processi ereditati e ai relativi processi ereditati figlio. Aggiornamenti ai processi sono documentati in Note sulla versione per Azure DevOps Server.

Nota

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

Inoltre, tutti i processi vengono condivisi. Ovvero, uno o più progetti possono usare un singolo processo. Anziché personalizzare un singolo progetto, è possibile personalizzare un processo. Le modifiche apportate al processo aggiornano automaticamente tutti i progetti che usano tale processo. Dopo aver creato un processo ereditato, è possibile personalizzarlo, crearne uno basato su di esso, crearne una copia e modificare i progetti esistenti per usarlo.

Ad esempio, come illustrato nell'immagine seguente, viene visualizzato un elenco di progetti definiti per l'organizzazione fabrikam . La seconda colonna mostra il processo usato da ogni progetto. Per modificare le personalizzazioni del progetto Fabrikam Fiber , è necessario modificare il processo MyScrum (che eredita dal processo di sistema Scrum ). Tutte le modifiche apportate al processo MyScrum aggiornano anche altri progetti che usano tale processo. Non è possibile personalizzare il progetto di test di query , d'altra parte, fino a quando non viene modificato in un processo che eredita da Agile.

Screenshot of Admin context, Organization settings, Project list and the process they use.

Restrizioni per il nome del processo

I nomi dei processi devono essere univoci e 128 caratteri Unicode o meno. Inoltre, i nomi non possono contenere i caratteri seguenti: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Per rinominare un processo, aprire ... menu di scelta rapida per il processo e scegliere Modifica.

Modificare il processo di riferimento di un progetto

Se si vuole cambiare il processo usato da un processo di sistema a un altro, è possibile farlo. Per apportare queste modifiche, è necessario creare un processo ereditato in base al processo a cui si vuole passare. Ad esempio, vengono fornite istruzioni per supportare le modifiche seguenti:

Seguendo le indicazioni fornite negli articoli elencati sopra, è anche possibile apportare modifiche aggiuntive, ad esempio da CMMI a Agile o Agile a CMMI.

Prima di apportare questa modifica, è consigliabile acquisire familiarità con il processo in cui si sta modificando. I processi di sistema sono riepilogati in Informazioni sui processi e sui modelli di processo.

Procedure consigliate per apportare modifiche

Apportare modifiche a un processo ereditato è semplice e sicuro. Tuttavia, è sempre consigliabile testare tali modifiche prima di applicarle a un progetto attivo. Seguendo questa procedura è possibile che si verifichino effetti negativi sulle modifiche apportate al processo.

Oggetti ereditati e oggetti personalizzati

Ogni processo ereditato creato eredita le connessioni WIT definite nel processo di sistema: Basic, Agile, Scrum o CMMI. Ad esempio, il processo Agile fornisce bug, attività, storia utente, funzionalità, epica, problema e wit correlati ai test.

Conceptual image of Agile process work item hierarchy.

È possibile aggiungere campi e modificare il flusso di lavoro e il modulo dell'elemento di lavoro per tutti i tipi di elementi di lavoro ereditati visualizzati nella pagina Tipi di elemento di lavoro. Se non si vuole che gli utenti creino un WIT, è possibile disabilitarlo. Inoltre, è possibile aggiungere wit personalizzati.

Personalizzazioni dei campi

I campi definiti nel processo di sistema vengono visualizzati con un'icona ereditata, a indicare che è possibile apportare modifiche limitate nel processo ereditato.

I campi vengono definiti per tutti i progetti e i processi dell'organizzazione. Ciò significa che qualsiasi campo personalizzato definito per un WIT in un processo può essere aggiunto a qualsiasi altro WIT definito per un altro processo.

Tipo di campo

Supporto per la personalizzazione

Campi ereditati

Campi personalizzati

Controllo personalizzato

Quando si aggiungono campi personalizzati, tenere presenti i limiti seguenti:

  • È possibile definire un massimo di 64 campi per ogni WIT
  • È possibile definire un massimo di 512 campi per processo

Inoltre, è possibile aggiungere un campo esistente a un altro WIT all'interno del processo. Ad esempio, è possibile aggiungere la data di scadenza alla storia utente o alle connessioni WIT di bug.

Cosa non è possibile personalizzare

  • Non è possibile modificare il nome o il tipo di dati del campo dopo averlo definito
  • Non è possibile modificare l'area grigia nel modulo in cui si trovano i campi State, Reason, Area Path e iterazione
  • Non è possibile importare o definire un elenco globale supportato dai modelli di processo XML ospitati e LOCALI. Per altre informazioni, vedere Definire elenchi globali.
  • Non è possibile modificare il nome o il tipo di dati del campo dopo averlo definito
  • Non è possibile modificare l'area grigia nel modulo in cui si trovano i campi State, Reason, Area Path e iterazione
  • Per quanto riguarda le liste di selezione, attualmente non è possibile eseguire queste operazioni:
    • Modificare l'elenco di selezione di un campo ereditato, ad esempio il campo Attività o Disciplina
    • Modificare l'ordine degli elenchi di selezione, gli elenchi di selezione visualizzati in ordine alfabetico
  • Non è possibile modificare il testo della Guida Descrizione dei campi ereditati
  • Importare o definire un elenco globale supportato dai modelli di processo XML ospitati e XML locali. Per altre informazioni, vedere Definire elenchi globali.

Nota

Con il processo ereditato, non è possibile modificare le elenchi di selezione dei campi predefiniti, ad esempio Attività, Stato automazione, Disciplina, Priorità e altri.

Elenchi di selezione configurabili

Gli elenchi di selezione seguenti sono configurati per ogni progetto e non personalizzabili tramite un processo ereditato.

Gli elenchi di selezione associati ai campi nome persona, ad esempio Assegnato a e Modificato da, vengono gestiti in base agli utenti aggiunti a un progetto o a un team.

È possibile rinominare un campo o modificarne il tipo di dati?

La ridenominazione di un campo o la modifica del tipo di dati non sono azioni supportate. Tuttavia, è possibile modificare l'etichetta visualizzata per un campo nel modulo dell'elemento di lavoro dalla scheda Layout. Quando si seleziona il campo in una query, è necessario selezionare il nome del campo e non l'etichetta del campo.

È possibile eliminare o ripristinare un campo eliminato?

È possibile eliminare un campo e ripristinarlo in un secondo momento. L'eliminazione di un campo elimina tutti i dati associati a tale campo, inclusi i valori cronologici. Dopo l'eliminazione, è possibile ripristinare il campo e recuperare i dati usando l'API REST Fields - Update.

Anziché eliminare un campo, è possibile nascondere o rimuovere il campo da un modulo dell'elemento di lavoro. Per informazioni dettagliate, vedere Aggiungere e gestire campi, Mostrare, nascondere o rimuovere un campo.

Che cos'è un campo? Come vengono usati i nomi dei campi?

Ogni tipo di elemento di lavoro è associato a 31 campi di sistema e a diversi campi più specifici del tipo. Gli elementi di lavoro vengono usati per pianificare e tenere traccia del progetto.

Ogni campo supporta il rilevamento di una parte di informazioni sul lavoro da eseguire. I valori assegnati a un campo vengono archiviati nell'archivio dati di rilevamento del lavoro che è possibile creare query per determinare lo stato e le tendenze.

Per le descrizioni e l'utilizzo di ogni campo definito per i processi di sistema principali, ovvero i processi di sistema Scrum, Agile e CMMI, vedere Indice dei campi dell'elemento di lavoro.

Nomi dei campi

Un nome di campo dell'elemento di lavoro identifica in modo univoco ogni campo dell'elemento di lavoro. Assicurarsi che i nomi dei campi siano compresi nelle linee guida seguenti:

  • I nomi dei campi devono essere univoci all'interno dell'organizzazione o della raccolta di progetti
  • I nomi dei campi devono avere un massimo di 128 caratteri Unicode
  • I nomi dei campi non possono contenere spazi iniziali o finali, né due o più spazi consecutivi
  • I nomi dei campi devono contenere almeno un carattere alfabetico
  • I nomi dei campi non possono contenere i caratteri seguenti: .,;'`:~\/\*|?"&%$!+=()[]{}<>.

Poiché tutti i campi sono definiti per l'organizzazione, non è possibile aggiungere un campo personalizzato con lo stesso nome di campo già esistente nell'organizzazione o aggiunto a un WIT in un altro processo ereditato.

Nota

Quando si modifica un progetto per l'uso di un processo ereditato, è possibile che uno o più strumenti Agile o elementi di lavoro vengano visualizzati in uno stato non valido. Ad esempio:

  • Se si imposta un campo obbligatorio, gli elementi di lavoro con tale campo non definito mostrano un messaggio di errore. Sarà necessario risolvere gli errori per apportare modifiche aggiuntive e salvare l'elemento di lavoro.
  • Se si aggiungono o rimuovono/nascondino gli stati del flusso di lavoro di un WIT visualizzato nella scheda Kanban, sarà necessario aggiornare le configurazioni della colonna della scheda Kanban per tutti i team definiti nel progetto.

Regole personalizzate e regole di sistema

Ogni WIT, bug, attività, storia utente e così via, ha diverse regole di sistema già definite. Alcuni sono semplici, ad esempio rendendo obbligatorio il campo Titolo o impostando un valore predefinito per il campo Area valore. Inoltre, una serie di regole di sistema definiscono le azioni da eseguire quando cambia lo stato di un flusso di lavoro.

Esistono ad esempio diverse regole per copiare l'identità utente corrente nelle condizioni seguenti:

  • Quando un elemento di lavoro viene modificato, copiare l'identità utente nel campo Modificato da
  • Quando lo stato del flusso di lavoro passa a Chiuso o Fatto, copiare l'identità utente nel campo Chiuso da.

Importante

Le regole di sistema predefinite assumono precedenti rispetto a qualsiasi regola personalizzata definita dall'utente che la sovrascriverebbe.

Le regole personalizzate forniscono supporto per diversi casi d'uso aziendali, consentendo di andare oltre l'impostazione di un valore predefinito per un campo o di renderlo obbligatorio. Le regole consentono di cancellare il valore di un campo, copiare un valore in un campo e applicare valori in base alle dipendenze tra valori di campi diversi.

Con una regola personalizzata, è possibile definire una serie di azioni in base a condizioni specifiche. Ad esempio, è possibile applicare una regola per supportare questi tipi di scenari:

  • Quando viene definito un valore per Priority, impostare rischio come campo obbligatorio
  • Quando viene apportata una modifica al valore di Release, deselezionare il valore di "Cardine"
  • Quando è stata apportata una modifica al valore di Lavoro rimanente, impostare Lavoro completato come campo obbligatorio
  • Quando il valore di Approved è True, impostare Approvato da un campo obbligatorio
  • Quando viene creata una storia utente, impostare i campi seguenti obbligatori: Priorità, Rischio e Sforzo

Suggerimento

Non è possibile definire una formula usando una regola. Tuttavia, è possibile trovare una soluzione adatta alle proprie esigenze con l'estensione Power Automate o TFS Aggregator (Servizio Web) Marketplace. Vedere anche Rollup del lavoro e altri campi.

Per informazioni dettagliate sulla definizione di regole personalizzate, vedere Regole e valutazione delle regole.

Limitare la modifica dei campi selezionati per i gruppi di utenti selezionati

Usando una delle due condizioni seguenti, è possibile selezionare i campi necessari per un utente di un gruppo di sicurezza o che non sono membri di un gruppo di sicurezza.

  • current user is a member of a group...
  • current user is not a member of a group...

Ad esempio, è possibile impostare il campo Titolo o Stato Di sola lettura per utenti o gruppi selezionati.

Limitare la modifica degli elementi di lavoro in base al percorso area

È possibile impedire agli utenti di modificare gli elementi di lavoro selezionando elementi di lavoro impostando le autorizzazioni per un percorso area. Non si tratta di un'impostazione di regola, ma di un'impostazione di autorizzazione. Per altre informazioni, vedere Creare nodi figlio, modificare gli elementi di lavoro in un percorso di area.

Personalizzazioni del tipo di elemento di lavoro (WIT)

Ecco le opzioni di personalizzazione per le connessioni WIT ereditate e personalizzate.

Tipo di elemento di lavoro

Supporto per la personalizzazione

Tipi di elementi di lavoro ereditati

Tipi di elementi di lavoro personalizzati

Cosa non è possibile personalizzare

  • Non è possibile aggiungere o rimuovere un WIT ereditato da o da un backlog
  • Non è possibile modificare la posizione di un campo ereditato all'interno del layout del modulo. È tuttavia possibile nascondere il campo in un'area del modulo e aggiungerlo altrove nel modulo.
  • Non è possibile rimuovere il livello di portfolio ereditato dal prodotto (ma è possibile rinominarli)
  • Non è possibile modificare il nome di un WIT personalizzato.

Personalizzazioni dei moduli degli elementi di lavoro

È possibile apportare le personalizzazioni seguenti a un modulo WIT.

Tipo di gruppo o di pagina

Supporto per la personalizzazione

Gruppi ereditati

Gruppi personalizzati

Pagine ereditate

Pagine personalizzate

Layout e ridimensionamento

Il layout del modulo Web è organizzato in tre colonne, come illustrato nell'immagine seguente.

Illustration of 3-column page layout for work item form.

Se si aggiungono solo gruppi e campi alle prime due colonne, il layout riflette un layout a due colonne. Analogamente, se si aggiungono solo gruppi e campi alla prima colonna, il layout riflette un layout a una colonna.

Il modulo Web viene ridimensionato a seconda della larghezza disponibile e del numero di colonne nel layout. Alla larghezza massima, nella maggior parte dei Web browser, ogni colonna all'interno di una pagina viene visualizzata all'interno della propria colonna. Man mano che la larghezza di visualizzazione diminuisce, ogni colonna viene ridimensionata proporzionalmente come segue:

  • Per tre colonne: 50%, 25%e 25%
  • Per due colonne: 66% e 33%
  • Per una colonna: 100%.

Quando la larghezza della visualizzazione non contiene tutte le colonne, le colonne vengono visualizzate in pila all'interno della colonna a sinistra.

Personalizzazioni del flusso di lavoro

È possibile personalizzare il flusso di lavoro di qualsiasi tipo di elemento di lavoro (WIT) nascondendo gli stati ereditati o aggiungendo stati personalizzati. Gli stati ereditati differiscono in base al processo di sistema ( Agile, Basic, Scrum o CMMI), scelto da cui creare il processo personalizzato.

Ogni flusso di lavoro predefinito per ogni WIT definisce tra due e quattro stati e specifica le operazioni del flusso di lavoro seguenti:

  • Transizioni avanti e indietro tra ogni stato
  • Motivi predefiniti per ogni transizione di stato

Ad esempio, il processo Basic, Issue WIT è caratterizzato dai tre Stati, To Do, Doing e Done, e transizioni illustrate nell'immagine seguente.

Basic Process, Issue work item type, workflow state model

Tipi di stato

Personalizzazioni supportate

Inherited icon Stati ereditati

Stati personalizzati

Gli stati del flusso di lavoro devono essere conformi alle regole seguenti

  • È necessario definire almeno uno stato per le categorie Stato proposto o in corso

    Nota

    Prima di aggiungere uno stato del flusso di lavoro, vedere Stati del flusso di lavoro e categorie di stato per informazioni sul mapping degli stati del flusso di lavoro alle categorie di stato.

  • È necessario definire almeno due stati del flusso di lavoro
  • È possibile definire un massimo di 32 stati del flusso di lavoro per tipo di elemento di lavoro

Personalizzazioni del flusso di lavoro non supportate

  • Non è possibile modificare uno stato ereditato (non è possibile modificarne il nome, il colore o la categoria), ma è possibile nasconderlo
  • È possibile avere un solo stato nella categoria Stato completato . Se si aggiunge uno stato personalizzato alla categoria Completato, qualsiasi altro stato viene rimosso o nascosto
  • Non è possibile modificare il nome di uno stato personalizzato
  • Non è possibile specificare un motivo per uno stato. I motivi predefiniti sono invece definiti, ad esempio Spostato allo stato Triaged, Spostato all'esterno dello stato Triaged
  • Non è possibile modificare la posizione dei campi Stato e Motivo nel modulo
  • Non è possibile personalizzare i nomi delle categorie di stato
  • Non è possibile modificare uno stato ereditato (non è possibile modificarne il nome, il colore o la categoria), ma è possibile nasconderlo
  • È possibile avere un solo stato nella categoria Stato completato . Il sistema non consente l'aggiunta di qualsiasi stato personalizzato a questa categoria
  • Non è possibile modificare il nome di uno stato personalizzato
  • Non è possibile modificare l'ordine degli stati, gli stati vengono elencati nella relativa sequenza naturale in base alla categoria di stato all'interno dell'elenco a discesa di un modulo elemento di lavoro
  • Non è possibile specificare un motivo per uno stato. I motivi predefiniti sono invece definiti, ad esempio Spostato allo stato Triaged, Spostato all'esterno dello stato Triaged
  • Non è possibile modificare la posizione dei campi Stato e Motivo nel modulo
  • Non è possibile limitare le transizioni, tutte le transizioni vengono definite da qualsiasi stato a un altro stato.

Personalizzazioni backlog e bacheche

I backlog e le bacheche sono strumenti Agile essenziali per la creazione e la gestione del lavoro per un team. I backlog standard, ovvero backlog di prodotto, iterazione e portfolio, ereditati dal processo di sistema sono completamente personalizzabili. È anche possibile aggiungere backlog portfolio personalizzati per un totale di cinque backlog portfolio.

Tipi di backlog

Supporto per la personalizzazione

Backlog ereditati

Backlog personalizzati del portfolio

Cosa non è possibile personalizzare

  • Non è possibile rimuovere un livello di portfolio ereditato dal prodotto (ma è possibile rinominare il livello portfolio ed è possibile disabilitare un tipo di elemento di lavoro ereditato)
  • Non è possibile inserire un livello di backlog all'interno del set esistente di backlog definiti
  • Non è possibile riordinare i livelli di backlog
  • Non è possibile aggiungere un tipo di elemento di lavoro a due livelli di backlog diversi
  • Non è possibile creare un livello di backlog attività personalizzato, anche se è possibile aggiungere wit personalizzati al backlog di iterazione
  • Non è possibile aggiungere il WIT bug a qualsiasi livello di backlog. Il sistema consente invece a ogni team di decidere come gestire i bug. Per altre informazioni, vedere Visualizzare i bug nei backlog e nelle bacheche.
  • Non è possibile aggiungere o rimuovere un WIT ereditato da o da un backlog, ad esempio non è possibile aggiungere il WIT del problema al backlog del prodotto
  • Non è possibile rimuovere un livello di portfolio ereditato dal prodotto (ma è possibile rinominare il livello portfolio ed è possibile disabilitare un tipo di elemento di lavoro ereditato)
  • Non è possibile inserire un livello di backlog all'interno del set esistente di backlog definiti
  • Non è possibile riordinare i livelli di backlog
  • Non è possibile aggiungere un tipo di elemento di lavoro a due livelli di backlog diversi
  • Non è possibile creare un livello di attività personalizzato, anche se è possibile aggiungere tipi di elementi di lavoro personalizzati al backlog di iterazione
  • Non è possibile aggiungere il WIT bug a qualsiasi livello di backlog. Il sistema consente invece a ogni team di decidere come gestire i bug. Per altre informazioni, vedere Visualizzare i bug nei backlog e nelle bacheche.

Nota

Alcune funzionalità richiedono l'installazione dell'aggiornamento di Azure DevOps Server 2020.1. Per altre informazioni, vedere Note sulla versione di Azure DevOps Server 2020 Update 1 RC1, Boards.

Quando si modifica il WIT predefinito per un livello di backlog, il WIT viene visualizzato per impostazione predefinita nel pannello di aggiunta rapida. Ad esempio, Customer Ticket viene visualizzato per impostazione predefinita nel pannello di aggiunta rapida seguente per il backlog del prodotto.

Screenshot of Product backlog, Quick Add Panel, Displays Default WIT for a backlog level

Limiti di oggetto

Per un elenco dei limiti posti per il numero di campi, wit, livelli di backlog e altri oggetti che è possibile personalizzare, vedere Limiti degli oggetti di rilevamento del lavoro.