Condividi tramite

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 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

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:

  • icona bloccata Processi di sistema , Agile, Basic, Scrum e CMMI, che non sono stati modificati.
  • icona ereditata 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. Gli aggiornamenti ai processi sono documentati nelle 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 del contesto di amministrazione, delle impostazioni dell'organizzazione, dell'elenco di progetti e del processo usato.

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.

Immagine concettuale della gerarchia degli elementi di lavoro del processo Agile.

È 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 esegue la transizione di un progetto a un processo ereditato, è possibile che si verifichino strumenti Agile o elementi di lavoro in uno stato non valido in base agli esempi seguenti:

  • Se si designa un campo come richiesto, gli elementi di lavoro privi di tale campo visualizzano un messaggio di errore. Per procedere con ulteriori modifiche e salvare l'elemento di lavoro, risolvere questi errori.
  • Se si aggiungono, rimuovono o nascondono gli stati del flusso di lavoro per un WIT visualizzato nella scheda, assicurarsi di aggiornare le configurazioni della colonna della scheda per tutti i team definiti nel progetto. Valutare anche la possibilità di mantenere la proprietà singola degli elementi di lavoro in base al percorso dell'area del team o di formalizzare le colonne con stati personalizzati condivisi tra team.

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.

Illustrazione del layout di pagina a 3 colonne per il modulo dell'elemento di lavoro.

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 variano in base al processo di sistema selezionato per creare il processo personalizzato. Le opzioni sono Agile, Basic, Scrum o Capability Maturity Model Integration (CMMI). Per altre informazioni, vedere Stati del flusso di lavoro, transizioni e motivi.

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. Ad esempio, il processo di base Issue WIT include tre stati: To Do, Doing e Done.For example, the Basic process Issue WIT includes three states: To Do, Doing, and Done.
  • Motivi predefiniti per ogni transizione di stato

Tipi di stato

Personalizzazioni supportate

Stati ereditati

Stati personalizzati

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

  • Definire almeno uno stato per le categorie Stato proposto o in corso .

    Nota

    Prima di aggiungere uno stato del flusso di lavoro, vedere Informazioni sugli stati del flusso di lavoro nei backlog e nelle bacheche per informazioni sul mapping degli stati del flusso di lavoro alle categorie di stato.

  • Definire almeno due stati del flusso di lavoro.
  • Definire un massimo di 32 stati del flusso di lavoro per tipo di elemento di lavoro.

Personalizzazioni del flusso di lavoro non supportate

  • Nascondi gli stati ereditati se non vuoi che siano visibili (non puoi modificare il nome, il colore o la categoria).
  • Verificare che nella categoria Stato completato esista un solo stato. L'aggiunta di uno stato personalizzato a questa categoria rimuove o nasconde qualsiasi altro stato.
  • Mantenere il nome degli stati personalizzati così come è; non è possibile modificarli.
  • Usare i motivi predefiniti per le transizioni di stato, ad esempio Spostato allo stato Triaged e Spostato all'esterno dello stato Triaged. Non è possibile specificare motivi personalizzati.
  • Accettare il percorso predefinito dei campi Stato e Motivo nel modulo; non è possibile modificare il posizionamento.
  • Usare i nomi di categoria di stato predefiniti; non è possibile personalizzarle.
  • Nascondi gli stati ereditati se non vuoi che siano visibili (non puoi modificare il nome, il colore o la categoria).
  • Verificare che esista un solo stato nella categoria Stato completato . Il sistema non consente l'aggiunta di qualsiasi stato personalizzato a questa categoria.
  • Mantenere il nome degli stati personalizzati così come è; non è possibile modificarli.
  • Accettare la sequenza naturale di stati nell'elenco a discesa nel modulo dell'elemento di lavoro; non è possibile modificare l'ordine.
  • Usare i motivi predefiniti per le transizioni di stato, ad esempio Spostato allo stato Triaged e Spostato all'esterno dello stato Triaged. Non è possibile specificare motivi personalizzati.
  • Accettare il percorso predefinito dei campi Stato e Motivo nel modulo; non è possibile modificare il posizionamento.
  • Consenti transizioni da qualsiasi stato a un altro; non è possibile limitare le transizioni.

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

Personalizzazioni non supportate:

  • Rimozione di un livello di portfolio ereditato:
    • Anche se non è possibile rimuovere direttamente un livello di portfolio ereditato da un prodotto, sono disponibili due opzioni:
      • Rinominare il livello di portfolio: è possibile rinominare il livello di portfolio ereditato in base alle proprie esigenze.
      • Disabilitare un WIT ereditato: se il livello di portfolio ereditato include wit che non si vuole usare, è possibile disabilitarli. Questa azione impedisce ai team di creare nuovi elementi di lavoro di questi tipi.
  • Inserimento di un livello di backlog:
    • Non è possibile inserire un nuovo livello di backlog all'interno del set esistente di backlog definiti. I livelli di backlog predefiniti sono in genere fissi (ad esempio Epics, Features, User Stories, Tasks) e non è possibile aggiungerne di personalizzati.
  • Riordinare i livelli di backlog:
    • Sfortunatamente, non è possibile riordinare i livelli di backlog. In genere seguono una gerarchia predefinita e la modifica dell'ordine non è supportata.
  • Aggiunta di un WIT a più livelli di backlog:
    • Ogni WIT può appartenere a un solo livello di backlog. Non è possibile aggiungere un WIT a due livelli di backlog diversi contemporaneamente.
  • Creazione di un livello di backlog attività personalizzato:
    • Anche se non è possibile creare un livello di backlog specifico dell'attività personalizzato, è comunque possibile aggiungere wit personalizzati al backlog di iterazione. Ad esempio, è possibile creare un WIT personalizzato denominato "Miglioramento" o "Manutenzione" e associarlo al backlog di iterazione.
  • Gestione dei bug:
  • Aggiunta o rimozione di un WIT ereditato da un backlog:
    • Non è possibile aggiungere o rimuovere direttamente un WIT ereditato da o da un backlog. Ad esempio, l'aggiunta del WIT "Problema" al backlog del prodotto non è supportata.
    • Tuttavia, è possibile:
      • Rinominare il livello di portfolio: se il livello di portfolio ereditato include wit che non si vuole usare, prendere in considerazione la ridenominazione per soddisfare meglio le proprie esigenze.
      • Disabilitare un WIT ereditato: se sono presenti wit ereditati da escludere, è possibile disabilitarli. Questa azione impedisce ai team di creare nuovi elementi di lavoro di questi tipi.
  • Rimozione di un livello di portfolio ereditato:
    • Anche se non è possibile rimuovere un livello di portfolio ereditato da un prodotto, sono disponibili alcune opzioni:
      • Rinominare il livello di portfolio: assegnargli un nome più appropriato.
      • Disabilitare le connessioni WIT ereditate: impedisce ai team di usare reti WIT ereditate specifiche.
  • Inserimento di un livello di backlog:
    • Sfortunatamente, non è possibile inserire un nuovo livello di backlog all'interno del set esistente di backlog definiti. I livelli di backlog predefiniti rimangono fissi (ad esempio Epics, Features, User Stories, Tasks).
  • Riordinare i livelli di backlog:
    • I livelli di backlog seguono in genere una gerarchia predefinita e la modifica dell'ordine non è supportata. Non puoi riordinarli.
  • Aggiunta di un WIT a più livelli di backlog:
    • Ogni WIT (ad esempio, Bug, Attività, Storia utente) può appartenere a un solo livello di backlog. Non è possibile aggiungere un WIT a due livelli di backlog diversi contemporaneamente.
  • Creazione di un livello di attività personalizzato:
    • Anche se non è possibile creare un livello di backlog specifico dell'attività personalizzato, è comunque possibile aggiungere wit personalizzati al backlog di iterazione. Ad esempio, creare un WIT personalizzato denominato "Miglioramento" o "Manutenzione" e associarlo al backlog di iterazione.
  • Gestione dei bug:

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 del backlog prodotto, pannello Di aggiunta rapida, Visualizza WIT predefinito per un livello di backlog

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.