Gestire i tipi di elemento di lavoro e il flusso di lavoro del processo Scrum
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Per pianificare un progetto software e tenere traccia dei difetti software tramite Scrum, i team usano l'elemento backlog del prodotto (PBI) e i tipi di elemento di lavoro bug (WIT). Per ottenere informazioni dettagliate su un portfolio di funzionalità, scenari o esperienze utente, proprietari di prodotti e responsabili di programmi possono eseguire il mapping di PBI e bug alle funzionalità. Quando i team lavorano negli sprint, definiscono attività che si collegano automaticamente a PBI e bug.
Nota
Se non si ha familiarità con il processo Scrum, vedere Informazioni su Sprint, Scrum e gestione dei progetti.
I tester possono creare ed eseguire test case e creare bug per tenere traccia dei difetti del codice usando il portale Web o Microsoft Test Manager. Gli ostacoli tengono traccia dei problemi di blocco.
Definire pbi e bug
Quando si definisce un elemento di backlog del prodotto, concentrarsi sul valore ottenuto dai clienti ed evitare descrizioni del modo in cui il team sviluppa la funzionalità. Il proprietario del prodotto può classificare in ordine di priorità il backlog del prodotto in base al valore aziendale, allo sforzo e alla dipendenza relativa da altri elementi di backlog. Man mano che i requisiti aziendali si evolvono, il backlog del prodotto. In genere, i team specificano i dettagli solo per gli elementi con priorità più alta o gli elementi assegnati allo sprint corrente e successivo.
È possibile creare pbi e bug dal pannello di aggiunta rapida nella pagina del backlog del prodotto.
Successivamente, è possibile aprire ogni PBI o bug per fornire altri dettagli e stimare lo sforzo. Inoltre, assegnando priorità ai PBI e ai bug nella pagina backlog (acquisita nel campo Priorità backlog), i proprietari del prodotto possono indicare quali elementi devono essere assegnati con priorità più alta.
Quando si definisce Il lavoro per pbi e bug, è possibile usare i grafici delle funzionalità di previsione e velocità per stimare gli sprint futuri o le attività lavorative. Quando si definisce il valore business, i proprietari dei prodotti possono specificare priorità separate dalla classificazione dello stack di backlog modificabile.
Usare i campi e i campi seguenti usati in comune tra i tipi di elemento di lavoro quando si completa il modulo dell'elemento di lavoro. Per altre informazioni, vedere Gestire i bug.
Campo/scheda
Utilizzo
Stimare la quantità di lavoro necessaria per completare un PBI usando qualsiasi unità di misura preferita dal team, ad esempio punti di storia o tempo. È necessario un valore numerico.
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 .
Specificare un numero che acquisisce il valore relativo di un PBI rispetto ad altri PBI. Maggiore è il numero, maggiore è il valore aziendale.
Fornire dettagli sufficienti per stimare la quantità di lavoro necessaria per implementare l'elemento. 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.
Definire il significato di "Operazione completata" descrivendo i criteri che il team deve usare per verificare se il PBI o la correzione di bug è stata completamente implementata.
Prima di iniziare il lavoro su un PBI o un bug, descrivere i criteri per l'accettazione del cliente il più chiaramente possibile. Le conversazioni tra il team e i clienti per determinare i criteri di accettazione consentono di garantire una comprensione comune all'interno del team per soddisfare le aspettative dei clienti. I criteri di accettazione possono essere usati come base per i test di accettazione in modo che il team possa valutare in modo più efficace se un elemento è stato completato in modo soddisfacente.
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 RTF viene visualizzata sotto l'area di immissione del testo. Viene visualizzato quando si seleziona ogni casella di testo che supporta la formattazione del testo.
Nota
Non esiste un campo Elemento di lavoro Discussione . Per eseguire query sugli elementi di lavoro con i commenti immessi nell'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
Per aprire un menu delle voci recenti effettuate per menzionare qualcuno, collegarsi a un elemento di lavoro o collegarsi a una richiesta pull, selezionare 
o 
o immettere @, #o .!
Immettere un nome o un numero e i filtri dell'elenco di menu in modo che corrispondano alla voce. Scegliere la voce da aggiungere. Per inserire un gruppo nella discussione, immettere @ e il 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, scegliere 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, è necessario configurare un server SMTP per consentire ai membri del team di 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. Nessuna regola dell'elemento di lavoro definita per il tipo di elemento di lavoro eseguito.
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 scrum
Quando si aggiorna lo stato, 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 illustrano i principali stati di avanzamento e regressione delle reti WIT pbi, bug e attività.These diagrams show the main progression and regression states of the PBI, bug, and task WIT.
| Elemento del backlog di prodotto | Bug | Attività |
|---|---|---|
|
|
|
I pbi e i bug seguono questa progressione tipica del flusso di lavoro:
- Il proprietario del prodotto crea un PBI o un tester crea un bug nello stato Nuovo con il motivo predefinito, Nuovo elemento backlog
- Il proprietario del prodotto sposta l'elemento in Approvato dopo che è sufficientemente descritto e pronto per il team per stimare il livello di sforzo. Nella maggior parte dei casi, gli elementi nella parte superiore del Backlog prodotto si trovano nello stato Approvato, mentre gli elementi verso il centro e il basso sono in uno stato Nuovo
- Il team aggiorna lo stato di Commit quando decide di impegnarsi a usarlo durante lo sprint
- L'elemento viene spostato nello stato Fatto quando il team ha completato tutte le attività associate e il proprietario del prodotto accetta che sia stato implementato in base ai criteri di accettazione.
Aggiornare lo stato con Kanban o Taskboard
Teams può usare la bacheca Kanban per aggiornare lo stato dei PBI e lo sprint 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 Kanban per supportare più corsie o colonne da bagno. Per altre opzioni di personalizzazione, vedere Personalizzare l'esperienza di rilevamento del lavoro.
Eseguire il mapping dei pbi 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. A tale scopo, definire le funzionalità e mappare i pbi 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. È anche possibile usare 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.
I team possono prevedere il lavoro e definire le attività all'inizio di ogni sprint e ogni membro del team completa un subset di tali attività. Le attività possono includere sviluppo, test e altri tipi di lavoro. Ad esempio, uno sviluppatore può definire attività per implementare pbi e un tester può definire 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
Indicare il numero di ore o giorni di lavoro rimanenti per completare un'attività. Man mano che il lavoro procede, aggiornare questo campo. Viene usato per calcolare i grafici di capacità, il grafico burn-down sprint e il report Sprint Burndown (Scrum).
Se si divide un'attività in sottoattività, specificare Solo lavoro rimanente per le sottoattività. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team.
Selezionare il tipo di attività rappresentata da questa attività quando il team stima la capacità sprint per attività.
Tenere traccia dello stato di avanzamento dei test
Testare i pbi
Dal portale Web o da Gestione test è possibile creare test case che si collegano automaticamente a un PBI o a un bug. In alternativa, è possibile collegare un PBI o un bug a un test case dalla 
scheda (collegamenti).
Il test case contiene molti campi, molti dei quali sono 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 a tutti i PBI e i bug in un test case. Collegando pbi e bug ai test case, il team può tenere traccia dello stato di avanzamento eseguito durante il test di ogni elemento.
Tenere traccia dei difetti del codice
È possibile creare bug dal portale Web del portale Web, Visual Studio o durante il 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.
Tenere traccia degli ostacoli
Usare il tipo di elemento di lavoro Ostacoli per tenere traccia degli eventi che potrebbero bloccare lo stato di avanzamento o spedire un PBI. Usare il tipo di elemento di lavoro Bug esclusivamente per tenere traccia dei difetti del codice.
È possibile aggiungere un ostacolo 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.
Ordine elenco backlog
Il campo Priorità backlog viene usato per tenere traccia della classificazione relativa di PBI, bug, funzionalità o epiche. Per impostazione predefinita, tuttavia, 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.
Articoli correlati
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per