Flusso di lavoro Agile in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Quando si usa il processo Agile in Azure Boards, i tipi di elementi di lavoro seguenti consentono al team di pianificare e tenere traccia dello stato di avanzamento dei progetti: epiche, funzionalità, storie utente, attività, problemi/bug. Dopo aver definito le connessioni WIT, è possibile usare la scheda per tenere traccia dello stato aggiornando lo stato di tali elementi.
Per ottenere informazioni dettagliate su un portfolio di funzionalità, scenari o esperienze utente, i proprietari dei prodotti e i responsabili dei programmi eseguono il mapping delle storie utente alle funzionalità. Quando un team lavora negli sprint, definiscono attività che si collegano automaticamente alle storie utente. Se non si ha familiarità con il processo Agile, vedere la sezione Pianificare e tenere traccia del lavoro con Agile per iniziare.
Dal portale Web o da Microsoft Test Manager, i tester possono creare ed eseguire test case contro bug e problemi, che vengono usati 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 in pila, che descrivono il lavoro necessario per lo sviluppo di applicazioni, requisiti ed elementi. Il team stima quindi lo sforzo e il lavoro per fornire gli elementi con priorità più alta.
Creare storie utente dal pannello di aggiunta rapida nella pagina del backlog del prodotto. Da tale pagina è anche possibile trascinare gli elementi per riordinarli o eseguirne il mapping alle funzionalità.
È possibile aprire ogni storia utente per fornire altri 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 o le attività di lavoro. Assegnando priorità alle storie utente nella pagina backlog (acquisita nel campo Stack Rank), i proprietari del prodotto possono indicare quali elementi devono essere assegnati con priorità più alta.
Usare le indicazioni riportate nella tabella seguente e i campi comuni usati tra i tipi di elemento di lavoro al termine del modulo.
Campo/scheda
Utilizzo
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 di garantire che il team comprenda 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 del cliente indirizzato dall'elemento epico, funzionalità, requisito o backlog. I valori includono:
- Architettura: servizi tecnici per implementare funzionalità aziendali che offrono una soluzione
- Business: servizi che soddisfano le esigenze dei clienti o degli stakeholder che offrono direttamente valore al cliente per supportare l'azienda (impostazione predefinita)
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 altre informazioni, vedere il white paper Stima .
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.
Una valutazione soggettiva dell'incertezza relativa intorno al 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 all'interno di qualsiasi casella di testo che supporta la formattazione del testo.
Nota
Un campo elemento di lavoro Discussione non esiste. Per eseguire query sugli elementi di lavoro con commenti dall'area Discussione, filtrare nel 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 qualcuno, collegato a un elemento di lavoro o collegato a una richiesta pull. In alternativa, è possibile aprire lo stesso menu immettendo @, #o !.
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 @ 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, scegliere 
Modifica o scegliere l'icona 
azioni e quindi scegliere Elimina.
Nota
La modifica e l'eliminazione di commenti richiede Azure DevOps Server 2019 Update 1 o versione successiva.
Dopo aver aggiornato il commento, selezionare Aggiorna. Per eliminare il commento, confermare che si desidera eliminarlo. Un audit trail completo di tutti i commenti modificati ed eliminati viene mantenuto nella scheda Cronologia del modulo dell'elemento di lavoro.
Importante
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 sorridente nell'angolo superiore destro di qualsiasi commento. In alternativa, 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
Nota
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 Percorso area e dai commenti Modifica elemento di lavoro in questa autorizzazione del nodo . Per altre informazioni, vedere Impostare le autorizzazioni di rilevamento del lavoro, Creare nodi figlio, modificare gli elementi di lavoro in un'area o in un percorso di iterazione.
Dopo aver salvato i commenti, non è necessario salvare l'elemento di lavoro.
Nota
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.
Registrazione dell'avanzamento
Man mano che il lavoro avanza, si modifica il campo Stato per aggiornare lo stato. Facoltativamente, è possibile specificare un motivo. I campi di stato e motivo vengono visualizzati nel modulo dell'elemento di lavoro nell'area di intestazione.
Stati del flusso di lavoro Agile
Quando si aggiorna il flusso di lavoro, i team conoscono gli elementi nuovi, in corso o completati. La maggior parte delle connessioni WIT supporta la transizione sia avanti che indietro da ogni stato del flusso di lavoro. Questi diagrammi mostrano i principali stati di avanzamento e regressione della storia utente, del bug e delle connessioni WIT delle attività.
| Storia utente | Bug | Attività |
|---|---|---|
|
|
|
Di seguito è riportato un tipico avanzamento del flusso di lavoro per una storia utente:
- Il proprietario del prodotto crea una storia utente nello stato Nuovo con il motivo predefinito Nuovo brano utente.
- Il team aggiorna lo stato su Attivo quando decide di completare il lavoro durante lo sprint.
- Una storia utente viene spostata in Risolto quando il team ha completato tutte le attività e gli unit test associati per il passaggio della storia.
- Una storia utente viene spostata nello stato Chiuso quando il proprietario del prodotto accetta che la storia è stata implementata in base ai criteri di accettazione e ai test di accettazione superati.
Aggiornare lo stato con tabellone o schede attività
Teams può usare la bacheca per aggiornare lo stato dei requisiti e taskboard 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.
Eseguire il mapping delle storie utente alle funzionalità
Quando si gestisce una suite di prodotti o esperienze utente, è possibile visualizzare l'ambito e lo stato di avanzamento del lavoro nel portfolio di prodotti. È possibile visualizzare l'ambito e lo stato di avanzamento del lavoro definendo le funzionalità e mappando le storie utente alle funzionalità.
Usando i backlog del portfolio, è possibile eseguire il drill-down da un backlog a un altro per visualizzare il livello di dettaglio desiderato. Usare anche i backlog del portfolio per visualizzare un rollup del lavoro in corso in più team quando si configura una gerarchia di team.
Definizione delle attività
Quando il team gestisce il lavoro negli sprint, può usare la pagina di backlog sprint per suddividere il lavoro da eseguire in attività distinte.
Assegnare un nome all'attività e stimare il lavoro necessario.
Quando si usa il processo Agile, i team prevedono il lavoro e definiscono le attività all'inizio di ogni sprint. Ogni membro del team esegue quindi un subset di tali attività. Le attività possono includere sviluppo, test e altri tipi di lavoro. Ad esempio, uno sviluppatore definisce le attività per implementare le storie utente e un tester definisce le attività per scrivere ed eseguire test case.
Quando i team stimano il lavoro usando ore o giorni, definiscono le attività e i campi Lavoro e attività rimanenti (facoltativo).
Campo/scheda
Utilizzo
Quantità di lavoro stimata necessaria per completare un'attività. In genere, questo campo non cambia dopo l'assegnazione. È possibile specificare il lavoro in ore o in 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. Questo campo viene usato per calcolare i grafici di capacità, il grafico di burn-down sprint e i report di SQL Server seguenti: Burndown e Burn Rate, Remaining Work e Status on All Iterations( 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.
Quantità di lavoro impiegato per l'implementazione di un'attività.
Selezionare il tipo di attività rappresentata da questa attività quando 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 con storie utente e difetti del codice.
Testare le storie utente
Dal portale Web o da Gestione test è possibile creare test case che si collegano automaticamente a una storia utente o a un bug. In alternativa, è possibile collegare una storia utente a un test case dalla 
scheda Collegamenti .
Il test case contiene più campi, molti dei quali automatizzati e integrati con Gestione test e il processo di compilazione. Per una descrizione di ogni campo, vedere Eseguire query in base ai campi di integrazione di compilazione e test.
La scheda (collegamenti) acquisisce i collegamenti alle storie utente e ai bug in un test case. Collegando le storie utente e i bug ai test case, il team può tenere traccia dello stato di avanzamento effettuato durante il test di ogni elemento. Definendo questi collegamenti, si supportano le informazioni visualizzate nel report Di panoramica delle storie.
Tenere traccia dei difetti del codice
È possibile creare bug dal portale Web, Visual Studio o durante i test con Gestione test.
Definizioni per i campi di rilevamento di lavoro comuni
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, ad esempio 
Cronologia, Collegamenti o
Allegati. Queste tre schede forniscono una cronologia delle modifiche, la visualizzazione degli elementi di lavoro collegati e la possibilità di visualizzare e allegare file.
L'unico campo obbligatorio per tutti i tipi di elemento di lavoro è Title. Quando si salva un elemento di lavoro, il sistema lo assegna a un ID univoco. Il modulo evidenzia il campo obbligatorio in giallo. Per informazioni su altri campi, vedere Indice dei campi dell'elemento di lavoro.
Nota
È possibile che siano necessari campi aggiuntivi a seconda delle personalizzazioni apportate al processo e al progetto.
Campo/scheda
Utilizzo
Immettere una descrizione di 255 caratteri o meno. È sempre possibile modificare il titolo in un secondo momento.
Assegnare l'elemento di lavoro al membro del team responsabile dell'esecuzione del lavoro.
Quando viene creato l'elemento di lavoro, per impostazione predefinita Lo stato viene impostato sul primo stato del flusso di lavoro. Man mano che il lavoro procede, aggiornarlo in modo da riflettere lo stato corrente.
Usare prima il valore predefinito. Aggiornarlo quando si modifica lo stato. Ogni stato è associato a un motivo predefinito.
Scegliere il percorso dell'area associato al prodotto o al team oppure lasciare vuoto fino a quando non viene assegnato durante una riunione di pianificazione. Per modificare l'elenco a discesa delle aree, vedere Definire i percorsi di area e assegnarli a un team.
Scegliere lo sprint o l'iterazione in cui il lavoro deve essere completato oppure lasciarlo vuoto e assegnarlo in un secondo momento durante una riunione di pianificazione. Per modificare l'elenco a discesa delle iterazioni, vedere Definire i percorsi di iterazione (sprint) e configurare le iterazioni del team.
Esaminare il audit trail acquisito dal sistema e acquisire informazioni aggiuntive.
Ogni volta che l'elemento di lavoro viene aggiornato, le informazioni vengono aggiunte alla cronologia. La cronologia include la data della modifica, chi ha apportato la modifica e quali campi sono stati modificati. È anche possibile aggiungere testo formattato al campo della cronologia.
Aggiungere tutti i tipi di collegamenti, ad esempio collegamenti ipertestuali, insiemi di modifiche, file di origine e così via.
Questa scheda elenca anche tutti i collegamenti definiti per l'elemento di lavoro.
Condividere informazioni più dettagliate aggiungendo file all'elemento di lavoro, ad esempio thread di posta elettronica, documenti, immagini, file di log o altri tipi di file.
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.
Articoli correlati
- Creare un progetto
- Aggiungere elementi di lavoro per gestire un progetto
- Creare un backlog
- Gestire l'accesso a funzionalità specifiche
- Informazioni sui livelli di accesso e autorizzazioni predefiniti per Azure Boards
Tenere traccia dei problemi
I problemi vengono usati per tenere traccia degli eventi che possono bloccare lo stato di avanzamento o la spedizione di una storia utente. I bug, d'altra parte, vengono usati per tenere traccia dei difetti del codice. È possibile aggiungere un problema dal widget Nuovo elemento di lavoro aggiunto a 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
È possibile usare il campo Priorità per distinguere il valore di varie storie. In alternativa, è possibile aggiungere un campo personalizzato al WIT della storia utente che tiene traccia del valore relativo delle storie. Per informazioni su come, vedere Personalizzare un campo per un processo.
Ordine elenco backlog
Il campo Stack Rank viene usato per tenere traccia della classificazione relativa delle storie utente, ma per impostazione predefinita non viene visualizzato nel modulo dell'elemento di lavoro. La sequenza di elementi nella pagina backlog viene determinata in base alla posizione in cui sono stati aggiunti gli elementi o spostati gli elementi nella pagina. Durante il trascinamento degli elementi, un processo in background aggiorna questo campo.