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
Usare la sezione Discussione per collaborare agli elementi di lavoro aggiungendo ed esaminando i commenti.
Quando si posiziona il cursore in una casella di testo che supporta la formattazione, viene visualizzata la barra degli strumenti dell'editor rtf.
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
Usa una delle icone seguenti per aprire gli elementi recenti di persone, elementi di lavoro o pull request:
È possibile aprire lo stesso menu con i tasti di scelta rapida: at-mention @, hashtag #e punto esclamativo !.
Immettere un nome o un numero per filtrare l'elenco e quindi selezionare l'elemento da aggiungere. Per menzionare un gruppo, immettere @ seguito dal nome del gruppo, ad esempio un team o un gruppo di sicurezza.
Modificare o eliminare un commento
Per aggiornare o rimuovere uno dei commenti, selezionare Modifica
o selezionare Altre azioni (
) e quindi selezionare Elimina:
Dopo aver modificato un commento, selezionare Aggiorna. Per rimuovere un commento, confermare l'eliminazione. La scheda Cronologia gestisce un audit trail di tutti i commenti modificati ed eliminati.
Important
Per le Azure DevOps Server locali, configurare un server SMTP in modo che i membri del team possano ricevere notifiche.
Aggiungere una reazione a un commento
Aggiungere una o più reazioni a un commento selezionando un'emoji nel commento. Per rimuovere la reazione, selezionare di nuovo la stessa reazione. L'immagine seguente mostra un esempio di aggiunta e 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. Le schede comuni includono 
Cronologia, Collegamenti e 
Allegati.
Per tutti i tipi di elemento di lavoro, Title è l'unico campo universalmente obbligatorio. Quando si salva un elemento di lavoro, Azure DevOps assegna un ID univoco. I campi obbligatori sono evidenziati in giallo. Per altri campi, vedere Indice dei campi elemento di lavoro.
Note
Altri campi potrebbero essere necessari in base alle personalizzazioni del processo e del progetto.
| Campo o scheda | Usage |
|---|---|
| Title | Immettere una breve descrizione (fino a 255 caratteri). È possibile modificare il titolo in un secondo momento. |
| Assegnato a | Assegnare l'elemento di lavoro alla persona responsabile del completamento o lasciarlo non assegnato fino a quando la proprietà non è chiara. |
| State | Al momento della creazione, Stato è impostato per impostazione predefinita sul primo stato del flusso di lavoro (ad esempio Nuovo o Non assegnato). Aggiornalo man mano che il lavoro procede. |
| Reason | Il motivo spiega perché l'elemento si trova nello stato corrente. I valori predefiniti variano in base al tipo di elemento di lavoro e al processo. |
| Area | Selezionare il percorso dell'area per il prodotto o il team. Per informazioni dettagliate, vedere Definire i percorsi di area e assegnarli a un team. |
| Iteration | Selezionare lo sprint/iterazione per il completamento pianificato. Per informazioni dettagliate, vedere Definire i percorsi di iterazione (sprint) e configurare le iterazioni del team. |
|
Scheda Cronologia |
Visualizzare il log delle modifiche completo per l'elemento di lavoro, inclusi i campi autore, data e aggiornamento. È anche possibile aggiungere testo formattato in Cronologia. |
|
Scheda Collegamenti |
Aggiungere relazioni ad altri artefatti, ad esempio elementi di lavoro padre/figlio, insiemi di modifiche, file di origine o risultati dei test. |
|
Scheda Allegati |
Aggiungere file di supporto, ad esempio documenti, immagini, log o thread di posta elettronica. |
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, aggiornare il flusso di lavoro, definire regole personalizzate, aggiungere pagine personalizzate e creare 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, aggiornare il flusso di lavoro, definire regole personalizzate, aggiungere pagine personalizzate e creare 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.