Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
In Azure Boards, il processo Agile usa tipi di elemento di lavoro (WIT) per aiutare il team a pianificare, classificare in ordine di priorità e tenere traccia dello stato di avanzamento. Il processo Agile include epiche, funzionalità, storie utente, attività, problemi e bug. Dopo aver definito i tipi di elementi di lavoro (WIT), è possibile monitorare l’avanzamento aggiornando gli stati degli elementi di lavoro.
Per ottenere visibilità su un portfolio di funzionalità, scenari ed esperienze utente, i proprietari dei prodotti e i responsabili del programma eseguono il mapping delle storie utente alle funzionalità. I team che lavorano negli sprint definiscono quindi le attività che si collegano a tali storie utente. Se non si ha familiarità con il processo Agile, vedere Pianificare e tenere traccia dell'uso di Agile.
Questo articolo illustra come:
- Definire e classificare in ordine di priorità le storie utente.
- Monitora lo stato del flusso di lavoro mentre il lavoro passa da Nuovo a Completato.
- Suddividere le storie nelle attività sprint e stimare il lavoro rimanente.
- Collegare test case e bug per tenere traccia della qualità e dei difetti.
In Azure DevOps Services i tester creano ed eseguono test case nel portale Web. In Azure DevOps Server, i tester possono anche usare Microsoft Test Manager per tenere traccia dei difetti del codice e dei problemi di blocco.
Definire le storie utente
I proprietari di prodotti definiscono e classificano in genere le storie utente che descrivono i requisiti dell'applicazione e gli elementi di lavoro. Il team stima quindi lo sforzo necessario per fornire gli elementi con priorità più alta.
Creare storie utente dal pannello di aggiunta rapida nella pagina Product Backlog. È anche possibile trascinare e rilasciare elementi nella pagina, riordinarli ed eseguire il mapping degli elementi alle funzionalità.
Aprire ogni storia utente per aggiungere dettagli e stimare i punti della storia. Definire Story Points in modo che il team possa usare i grafici di previsione e velocità per stimare gli sprint futuri e le attività lavorative. Assegnando priorità alle storie utente nella pagina backlog (acquisita nel campo Stack Rank ), i proprietari del prodotto indicano quali elementi hanno priorità più alta.
Usare le indicazioni riportate nella tabella seguente e i campi comuni usati nei diversi tipi di elemento di lavoro quando si compila il modulo.
Field
Usage
Per le storie utente, fornire dettagli sufficienti per stimare la quantità di lavoro necessaria per implementare la storia. Concentrarsi sull'utente per cui la funzionalità è destinata, sui risultati che gli utenti vogliono eseguire e sul motivo. Non descrivere come sviluppare la funzionalità. Fornire dettagli sufficienti in modo che il team possa scrivere attività e test case per implementare l'elemento.
Specificare i criteri da soddisfare prima che il bug o la storia utente possa essere chiusa. Prima dell'inizio del lavoro, descrivere i criteri di accettazione del cliente il più chiaramente possibile. Le conversazioni tra il team e i clienti per definire i criteri di accettazione consentono al team di comprendere le aspettative dei clienti. È possibile utilizzare i criteri di accettazione come base per i test di accettazione per valutare in modo più efficace se un elemento è completato in modo soddisfacente.
Area del valore per il cliente affrontata dall'epic, dalla funzionalità, dal requisito o dall'elemento del backlog. I valori includono:
- Architettura: servizi tecnici per implementare funzionalità aziendali che offrono soluzioni.
- Business: (Impostazione predefinita) Servizi che soddisfano le esigenze dei clienti o degli stakeholder e offrono direttamente valore al cliente per supportare l'azienda.
Stimare la quantità di lavoro necessaria per completare una storia utente usando qualsiasi unità numerica di misura preferita dal team. I grafici a velocità Agile e gli strumenti di previsione fanno riferimento ai valori in questo campo. Per ulteriori informazioni, vedere il white paper 'Estimating'.
Valutazione soggettiva della storia utente, della funzionalità o del requisito in relazione all'azienda. I valori consentiti sono i seguenti:
- 1: il prodotto non può essere spedito senza la funzionalità.
- 2: il prodotto non può essere spedito senza la funzionalità, ma il problema non deve essere risolto immediatamente.
- 3: L'implementazione della funzionalità è facoltativa, in base a risorse, tempo e rischio.
Valutazione soggettiva dell'incertezza relativa del completamento riuscito di una storia utente. I valori consentiti sono i seguenti:
- 1 - Alta
- 2 - Medio
- 3 - Bassa
Acquisire commenti nella sezione Discussione
Utilizzare la sezione Discussione per aggiungere ed esaminare i commenti relativi al lavoro eseguito.
La barra degli strumenti dell'editor di testo viene visualizzata sotto l'area di immissione del testo quando si posiziona il cursore in qualsiasi casella di testo che supporta la formattazione del testo.
Note
Un campo elemento di lavoro Discussione non esiste. Per eseguire query sugli elementi di lavoro con commenti dall'area Discussione, filtrare il campo Cronologia. Il contenuto completo del testo immesso nella casella di testo Discussione viene aggiunto al campo Cronologia.
Menzionare un utente, un gruppo, un elemento di lavoro o una richiesta pull
Selezionare una delle icone seguenti per aprire un menu di voci recenti in cui è stato menzionato un utente, collegato a un elemento di lavoro o collegato a una richiesta pull:
È possibile aprire lo stesso menu usando i tasti di scelta rapida: at-mention @, hash tag #e punto esclamativo !.
Immettere un nome o un numero per filtrare l'elenco di menu in modo che corrisponda alla voce. Selezionare la voce da aggiungere. Per inserire un gruppo nella discussione, immettere il simbolo in corrispondenza del simbolo @ seguito dal nome del gruppo, ad esempio un team o un gruppo di sicurezza.
Modificare o eliminare un commento
Per modificare o eliminare i commenti di discussione, selezionare Modifica
o Altre azioni (
) e quindi selezionare Elimina:
Dopo aver aggiornato il commento, selezionare Aggiorna. Per eliminare il commento, confermare l'eliminazione. La scheda Cronologia nel modulo dell'elemento di lavoro mantiene un audit trail completo di tutti i commenti modificati ed eliminati.
Important
Per Azure DevOps Server locale, configurare un server SMTP per i membri del team per ricevere notifiche.
Aggiungere una reazione a un commento
Aggiungere una o più reazioni a un commento scegliendo un'icona emoji in alto a destra di qualsiasi commento. Scegliere tra le icone nella parte inferiore di un commento accanto a eventuali reazioni esistenti. Per rimuovere la tua reazione, scegli la reazione nella parte inferiore del tuo commento. L'immagine seguente mostra un esempio dell'esperienza di aggiunta di una reazione e la visualizzazione di reazioni su un commento.
Salvare un commento senza salvare l'elemento di lavoro
Note
Questa funzionalità è disponibile a partire da Azure DevOps Server 2022.1.
Se si dispone solo delle autorizzazioni per aggiungere alla discussione di un elemento di lavoro, è possibile farlo salvando i commenti. Questa autorizzazione è controllata dai nodi del Percorso area e dal permesso Modifica commenti degli elementi di lavoro in questo nodo. Per altre informazioni, vedere Impostare le autorizzazioni per il monitoraggio del lavoro - Creare nodi figlio, modificare gli elementi di lavoro in un'area o in un percorso di iterazione.
Quando si salvano i commenti, non è necessario salvare l'elemento di lavoro.
Note
Quando si salvano le modifiche apportate al controllo Discussione , viene salvato solo il commento. Non vengono eseguite regole degli elementi di lavoro definite per il tipo di elemento di lavoro.
Tenere traccia dello stato di avanzamento
Man mano che il lavoro procede, aggiornare il campo Stato in modo da riflettere lo stato. Facoltativamente, è possibile specificare un motivo. I campi Stato e Motivo vengono visualizzati nell'area di intestazione del modulo dell'elemento di lavoro:
Stati del flusso di lavoro Agile
Man mano che i team aggiornano gli stati del flusso di lavoro, possono identificare gli elementi nuovi, in corso o completati. La maggior parte delle reti WIT supporta le transizioni avanti e indietro tra stati. I diagrammi seguenti mostrano i principali stati di avanzamento e regressione per User Story, bug e WIT delle attività.
Ecco la progressione tipica del flusso di lavoro per una storia utente:
- Il proprietario del prodotto crea una storia utente nello stato Nuovo con il motivo predefinito, Nuova storia utente.
- Il team aggiorna lo stato della storia su Attivo quando decide di completare il lavoro durante lo sprint.
- La storia passa allo stato Risolto quando il team completa tutte le attività associate e gli unit test superano.
- La storia passa allo stato Chiuso quando il proprietario del prodotto accetta che la storia viene implementata in base al superamento dei criteri di accettazione e dei test di accettazione.
Aggiornare lo stato con la scheda o il tabellone attività
I team possono usare la bacheca per aggiornare lo stato dei requisiti e la bacheca delle attività per aggiornare lo stato delle attività. Il trascinamento degli elementi in una nuova colonna di stato aggiorna i campi Stato e Motivo .
È possibile personalizzare la lavagna per supportare più corsie o colonne. Per altre informazioni, vedere Personalizzare l'esperienza di rilevamento del lavoro.
Associare le storie degli utenti alle funzionalità
Quando si gestisce una suite di prodotti o esperienze utente, potrebbe essere necessario esaminare l'ambito di lavoro e lo stato di avanzamento nel portfolio. Usare funzionalità e mapping dalle storie utente alle funzionalità per tenere traccia di tale rollup.
Usando i backlog del portfolio, è possibile eseguire il drill-down da un backlog a un altro per visualizzare il livello di dettaglio desiderato. Inoltre, utilizzare i backlog del portafoglio per visualizzare un riepilogo del lavoro in corso tra più team quando si configura una gerarchia di team.
Definire le attività
Quando il team gestisce il lavoro negli sprint, usare la pagina di backlog sprint per suddividere il lavoro pianificato in attività distinte.
Immettere il nome dell'attività e stimare lo sforzo nel campo Lavoro :
Quando si usa il processo Agile, i team prevedono il lavoro e definiscono le attività all'inizio di ogni sprint. Ogni membro del team completa quindi un subset di tali attività. Le attività possono includere sviluppo, test e altro lavoro. Ad esempio, uno sviluppatore potrebbe definire attività per implementare storie utente e un tester potrebbe definire attività per scrivere ed eseguire test case.
Quando i team stimano il lavoro in base al numero di ore o giorni, definiscono le attività e i campi Lavoro e attivitàrimanenti (facoltativo).
Field
Usage
Quantità di lavoro stimata necessaria per completare un'attività. In genere, il valore del campo non cambia dopo aver immesso il valore iniziale. È possibile specificare il lavoro in numero di ore o giorni. Al campo non sono associate unità temporali intrinseche.
Quantità di lavoro rimanente per completare un'attività. Man mano che il lavoro procede, aggiornare questo campo. Se si divide un'attività in sottoattività, specificare ore solo per le sottoattività. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team. Questo campo viene usato per calcolare i grafici e i report di SQL Server seguenti:
Quantità di lavoro impiegato per l'implementazione di un'attività.
Selezionare il tipo di attività che questo compito rappresenta mentre il team stima la capacità sprint per attività.
Numero di build del prodotto che incorpora il codice o corregge un bug.
Tenere traccia dello stato di avanzamento dei test
Tenere traccia dello stato di avanzamento dei test usando storie utente e bug per i difetti del codice. Per indicazioni sul rilevamento di altri tipi di problemi, vedere Tenere traccia di altri problemi.
Testare le storie utente
In Azure DevOps Services è possibile creare test case che si collegano automaticamente a una storia utente o a un bug nel portale Web. In Azure DevOps Server è anche possibile usare Microsoft Gestione test. È anche possibile collegare una storia utente a un test case dalla 
scheda Collegamenti.
Il test case contiene più campi, molti dei quali sono automatizzati e integrati con la gestione dei test e il processo di compilazione. Per una descrizione di ogni campo, consultare Query basato sui campi di integrazione di compilazione e test.
La scheda Collegamenti mostra i collegamenti a storie utente e bug in un caso di test. Collegando storie utente e bug ai test case, il team può tenere traccia dello stato di avanzamento dei test per ogni elemento. Questi collegamenti supportano anche le informazioni visualizzate nel report SQL Server Stories Overview.
Tenere traccia dei difetti del codice
Per tenere traccia dei test per i difetti del codice, creare bug dal portale web, da Visual Studio o da Microsoft Test Manager.
Definizioni dei campi comuni di tracciamento del lavoro
Nella maggior parte degli elementi di lavoro vengono visualizzati i campi e le schede seguenti. Ogni scheda viene usata per tenere traccia di informazioni specifiche. Le schede usate comunemente includono 
Cronologia, Collegamenti e 
Allegati.
L'unico campo obbligatorio per tutti i tipi di elemento di lavoro è Title. Quando si salva un elemento di lavoro, il sistema assegna un identificatore univoco, ID. Il modulo evidenzia i campi obbligatori in giallo. Per informazioni su altri campi, vedere Indice dei campi dell'elemento di lavoro.
Note
Altri campi potrebbero essere necessari a seconda delle personalizzazioni apportate al processo e al progetto.
Campo o scheda
Usage
Immettere una descrizione di 255 caratteri o meno. È possibile modificare il titolo in un secondo momento.
Assegnare l'elemento di lavoro al membro del team responsabile dell'esecuzione del lavoro oppure lasciare vuoto e completare l'assegnazione in un secondo momento.
Quando si crea un elemento di lavoro per la prima volta, il campo Stato visualizza automaticamente il primo stato nel flusso di lavoro, ad esempio Nuovo o Non assegnato. Man mano che il lavoro procede, aggiornare lo stato in modo che rifletta lo stato corrente dell'elemento di lavoro.
Quando si crea un elemento di lavoro per la prima volta, impostare il valore reason predefinito, ad esempio Creato o Nuovo elemento di lavoro. Quando lo stato cambia per l'elemento di lavoro, aggiornare il valore Motivo di conseguenza. Ogni stato per l'elemento di lavoro è associato a un valore Reason predefinito.
Seleziona il percorso dell'area associato al prodotto o al team, oppure lasciarlo vuoto e immettere un valore appropriato in un secondo momento. È possibile modificare l'elenco a discesa delle aree disponibili. Per altre informazioni, vedere Definire i percorsi di area e assegnare a un team specifico.
Scegliere lo sprint o l'iterazione in cui completare l'elemento di lavoro oppure lasciare vuoto e assegnare il valore in un secondo momento. È possibile modificare l'elenco a discesa delle iterazioni. Per altre informazioni, vedere Definire i percorsi di iterazione (sprint) e configurare le iterazioni del team.
Visualizzare la cronologia dell'elemento di lavoro per visualizzare tutte le modifiche apportate all'elemento, come acquisito dal sistema. Ogni volta che un elemento di lavoro viene aggiornato, i dettagli vengono aggiunti alla cronologia. Viene visualizzata la data di modifica, l'autore delle modifiche e l'elenco dei campi aggiornati. È anche possibile aggiungere testo formattato al campo Cronologia .
Aggiungere collegamenti per creare connessioni con altri elementi di lavoro. Sono supportati molti tipi di collegamenti, ad esempio collegamenti ipertestuali, insiemi di modifiche, file di origine e altro ancora. Specificare la relazione dell'elemento collegato all'elemento di lavoro, ad esempio Parent, Found in Build o Test Result.
Utilizzare Allegati per includere informazioni di supporto sull'elemento di lavoro. Allegare thread di posta elettronica, documenti, immagini, file di log o altri tipi di file.
Tenere traccia di altri problemi
Usare i problemi per tenere traccia degli eventi che potrebbero bloccare lo stato di avanzamento o impedire la spedizione di una storia utente. Usare i bug per tenere traccia dei difetti del codice. Aggiungere un problema usando il widget Nuovo elemento di lavoro in un dashboard del team o dal menu Nuovo nella pagina Query .
Gli elementi di lavoro aggiunti dal widget vengono automaticamente limitati all'area predefinita e ai percorsi di iterazione del team. Per modificare il contesto del team, vedere Cambiare il contesto del team.
Tenere traccia del valore aziendale
Usare il campo Priorità per distinguere il valore delle storie. È anche possibile aggiungere un campo personalizzato al WIT della storia utente per tenere traccia del valore relativo della storia. Per altre informazioni, vedere Personalizzare un campo per un processo.
Ordine dell'elenco degli arretrati
Il campo Stack Rank tiene traccia della classificazione relativa delle storie utente. Per impostazione predefinita, il modulo dell'elemento di lavoro non mostra questo campo. La sequenza di elementi nella pagina backlog è determinata dalla posizione in cui si aggiungono o spostano gli elementi nella pagina. Durante il trascinamento degli elementi, un processo in background aggiorna il campo Stack Rank .
Personalizzare i tipi di elemento di lavoro
Per la maggior parte dei tipi di elementi di lavoro, è possibile aggiungere campi, modificare il flusso di lavoro, aggiungere regole personalizzate e aggiungere pagine personalizzate al modulo dell'elemento di lavoro. È anche possibile aggiungere tipi di elementi di lavoro personalizzati. Per altre informazioni, vedere Personalizzare un processo di ereditarietà.
Per la maggior parte dei tipi di elementi di lavoro, è possibile aggiungere campi, modificare il flusso di lavoro, aggiungere regole personalizzate e aggiungere pagine personalizzate al modulo dell'elemento di lavoro. È anche possibile aggiungere tipi di elementi di lavoro personalizzati. Per altre informazioni, vedere Personalizzare un processo di ereditarietà o Personalizzare il modello di processo XML locale, a seconda del modello di processo usato dal progetto.