Leggere in inglese

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, si personalizza un processo ereditato attraverso 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. Qualsiasi aggiornamento apportato a un processo di sistema provoca automaticamente un aggiornamento ai processi ereditati e ai loro sottoprocessi ereditati. Gli aggiornamenti ai processi sono documentati nelle Note di rilascio per Azure DevOps Server.

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 questi passaggi, sarà possibile individuare eventuali effetti negativi che le modifiche apportate al processo potrebbero avere.

Oggetti ereditati e oggetti personalizzati

Ogni processo ereditato creato eredita i WIT definiti 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 consegna alla user story o ai bug WITs.

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 Stato, Motivo, Percorso area e Percorso iterazione.
  • Non è possibile importare o definire un elenco globale come supportato dai modelli di processo XML ospitati e in sede. Per altre informazioni, vedere Definire elenchi globali.

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 relativi al nome della persona, come 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 monitoraggio del lavoro, sul quale è 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. Inoltre, considera l'opzione di mantenere la proprietà unica degli elementi di lavoro in base al percorso dell'area del team o di formalizzare le colonne con stati personalizzati condivisi tra i 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, l'identità utente va copiata nel campo Modificato da.
  • Quando lo stato del flusso di lavoro cambia in Chiuso o Completato, copia 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, cancellare il valore di "Milestone"
  • Quando è stata apportata una modifica al valore di Lavoro rimanente, impostare Lavoro completato come campo obbligatorio
  • Quando il valore di Approved è Vero, rendi 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 all'Area Path

È possibile impedire agli utenti di modificare alcuni elementi di lavoro impostando le autorizzazioni su un percorso di area. Non si tratta di un'impostazione di regola, ma di un'impostazione di autorizzazione. Per ulteriori 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 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 form 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 tre 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.
  • 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.

Personalizzazioni backlog e bacheche

I backlog e le bacheche sono strumenti essenziali dell'Agile per creare e gestire il lavoro di un team. I backlog standard, ovvero backlog di prodotto, iterazione e portfolio, ereditati dal processo di sistema sono completamente personalizzabili. È anche possibile aggiungere backlog di portfolio personalizzati fino ad un totale di cinque backlog di portfolio.

Tipi di backlog

Supporto per la personalizzazione

Backlog ereditati

Backlog di portafoglio personalizzati

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 modificare l'ordine dei 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 personalizzato del backlog di attività:
    • Anche se non è possibile creare un livello di backlog personalizzato specifico per le attività, è 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:

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 seguente pannello di aggiunta rapida per il backlog del prodotto.

Screenshot del backlog del prodotto, Pannello di aggiunta rapida, visualizza WIT predefinito per un livello di backlog

Limiti di oggetto

Per un elenco dei limiti posti al numero di campi, WITs, livelli di backlog e altri oggetti che è possibile personalizzare, consultare Limiti sugli oggetti di rilevamento del lavoro.