Gestire i tipi di elemento di lavoro e il flusso di lavoro del processo Scrum

servizi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

Usare Scrum in Azure Boards per pianificare e classificare in ordine di priorità la distribuzione del software e tenere traccia dei difetti. I team registrano il lavoro come elementi del backlog del prodotto (PBI) e bug, associano tali elementi alle funzionalità per garantire visibilità a livello di portfolio e suddividono il lavoro dello sprint in attività collegate a PBI e bug.

Immagine concettuale che mostra i tipi di elemento di lavoro del processo Scrum usati per pianificare e tenere traccia.

Note

Se non si ha familiarità con il processo Scrum, vedere Informazioni su Sprint, Scrum e gestione dei progetti.

Questo articolo consente di:

Prerequisites

Area Requisito Perché è importante
Appartenenza al progetto È necessario essere membri del progetto con l'autorizzazione per visualizzare e modificare gli elementi di lavoro in Azure Boards. Obbligatorio per creare, aggiornare e spostare gli elementi di lavoro tramite gli stati del flusso di lavoro Scrum.
Livello di accesso Per creare e aggiornare gli elementi di lavoro, è necessario almeno l'accesso di base . Obbligatorio per le principali azioni di backlog, bacheca e tracciamento delle attività.
Backlog e accesso alla bacheca È necessario accedere ai backlog e alle bacheche del team. Necessario per assegnare la priorità ai PBI, pianificare gli sprint e aggiornare lo stato nelle bacheche e nei taskboard.
Autorizzazioni di configurazione del team Per definire le impostazioni del team, i livelli del backlog o la configurazione della bacheca, è necessario essere membri di Project Administrators o disporre di autorizzazioni delegate equivalenti. Obbligatorio per la configurazione e la personalizzazione a livello di team.
Accesso alla gestione dei test Per creare ed eseguire test case, è necessario accedere a Azure Test Plans (o strumenti di test equivalenti per la distribuzione). Obbligatorio per collegare i test case ai pbi e tenere traccia dei risultati dei test.

Per altre informazioni, vedere Impostare le autorizzazioni e l'accesso per il monitoraggio delle attività lavorative.

Definire PBIs e bug

Definire prima i PBI e i bug per rappresentare innanzitutto il valore per il cliente, e poi i dettagli di implementazione man mano che il lavoro si avvicina all'esecuzione.

Usare questo modello:

Quando cambiano le priorità, aggiorna l'ordine del backlog. La pagina del backlog tiene traccia di questo ordine tramite Priorità backlog.

Screenshot che mostra il modulo dell'elemento del backlog di prodotto.

Impostare Sforzo in modo che i grafici di previsione e velocità possano proiettare la capacità sprint futura. Impostare Valore business per esprimere la priorità in modo indipendente dalla classificazione dello stack.

Usare i campi seguenti per completare ogni elemento in modo coerente prima della pianificazione dello sprint. Per informazioni dettagliate sui bug, vedere Gestire i bug.

Campo Come usarlo
Effort Stimare il lavoro necessario per completare il PBI utilizzando l'unità di misura numerica del team, ad esempio gli story point o il tempo. A seconda della personalizzazione del processo, questo campo può essere facoltativo o obbligatorio. I grafici di velocità e le previsioni usano questo valore.
Valore aziendale Immettere un numero che indica il valore aziendale relativo rispetto ad altri PBI. I numeri più alti indicano un valore superiore.
Description Descrivere chi serve la funzionalità, cosa deve eseguire l'utente e perché è importante. Includere un contesto sufficiente per la suddivisione delle attività e la progettazione dei test.
Criteri di accettazione Definire le condizioni per l'esecuzione prima dell'avvio dell'implementazione. I criteri chiari allineano le aspettative dei team e degli stakeholder e supportano i test di accettazione.

Raccogliere commenti nella sezione Discussione

Usare la sezione Discussione per collaborare agli elementi di lavoro aggiungendo ed esaminando i commenti.

Screenshot della sezione Discussione all'interno di un formulario di un elemento di lavoro.

Quando si posiziona il cursore in una casella di testo che supporta la formattazione, viene visualizzata la barra degli strumenti dell'editor rtf.

Screenshot della sezione Discussione, barra degli strumenti dell'Editor di Testo Formattato.

Note

Un campo Discussione dell'elemento di lavoro 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 !.

Screenshot della sezione Discussione, menu a discesa selettore di persone.

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:

Screenshot della sezione Discussione in cui è possibile scegliere Modifica o Elimina azioni.

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.

Screenshot della sezione Discussione, aggiungi una reazione a 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 Percorso area e dal permesso modificare i 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.

Screenshot della sezione Discussione, commento salvato.

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 si sposta in avanti, aggiornare State per riflettere lo stato corrente e impostare Reason quando necessario. Entrambi i campi vengono visualizzati nell'intestazione dell'elemento di lavoro.

Usare gli aggiornamenti dello stato in modo coerente per mantenere allineate le visualizzazioni backlog, bacheca e report.

Flusso rapido:

  • Definire e classificare in ordine di priorità i pbi e i bug.
  • Spostare gli elementi tra gli stati del flusso di lavoro durante l'avanzamento del lavoro.
  • Rivedi dashboard e report per verificare che lo stato sia allineato.

Schermata che mostra l'intestazione del modulo dell'elemento di lavoro di un bug.

Stati del flusso di lavoro scrum

Aggiorna stato per indicare se un elemento è nuovo, in corso, completato o rimosso dall'ambito. La maggior parte dei WIT supporta sia le transizioni in avanti che all'indietro.

I diagrammi seguenti mostrano i principali stati di avanzamento e regressione per i tipi di elemento di lavoro PBI, Bug e Task.

Elemento del backlog di prodotto Bug Task
Immagine concettuale che mostra gli stati del flusso di lavoro Product Backlog Item, processo Scrum. Immagine concettuale che mostra gli stati del flusso di lavoro dei bug, il processo Scrum. Immagine concettuale che mostra gli stati del flusso di lavoro delle attività, il processo Scrum.

Tipico ciclo di vita di PBI e bug:

  • Nuovo: un proprietario del prodotto o un tester crea l'elemento. Il motivo predefinito varia in base al tipo di elemento di lavoro e alla configurazione del processo, ad esempio Nuovo elemento backlog.
  • Approvato: l'elemento è sufficientemente definito per il team per stimare e preparare la pianificazione dello sprint. Gli elementi con priorità più alta in genere passano prima a questo stato.
  • Impegnato: il team concorda di consegnare l'elemento nello sprint.
  • Operazione completata: tutte le attività correlate vengono completate e il proprietario del prodotto conferma che l'elemento soddisfa i criteri di accettazione.

Utilizzare Rimosso per gli elementi esclusi intenzionalmente dall'ambito e non previsti per la consegna. Mantenere questi elementi al di fuori di Done consente di mantenere l'accuratezza dei report.

Aggiorna lo stato dalle bacheche e dai taskboard

Usa le bacheche per mantenere aggiornato lo stato man mano che il lavoro procede nello sprint:

  • Usa la board per aggiornare lo stato di PBI e bug.
  • Usare lo sprint Taskboard per aggiornare lo stato dell'attività.
  • Trascinare un elemento in una nuova colonna per aggiornare sia State che Reason.

Screenshot che mostra lo stato di avanzamento della bacheca nel portale Web.

È possibile personalizzare la tavola con corsie e colonneda bagno. Per ulteriori opzioni, vedi Personalizzare l'esperienza di monitoraggio del lavoro.

Mappare i PBI con le funzionalità

Mappa i PBI alle funzionalità per tenere traccia dell'ambito e dell'avanzamento in diversi prodotti, scenari o team.

Usare questo approccio:

Controllo di convalida: verificare che ogni funzionalità mostri i PBI figlio collegati e che i valori di rollup corrispondano allo stato dell'elemento figlio.

Definire le attività

Quando il team lavora in sprint, suddivide i PBI e i bug in attività nella pagina del backlog dello sprint.

Screenshot che mostra il backlog Sprint e l'esperienza di aggiunta di un'attività.

Assegnare a ogni attività il nome e stimare lo sforzo.

Screenshot che mostra il modulo dell'item di lavoro Scrum Task.

I team definiscono in genere le attività all'inizio di ogni sprint. I membri del team completano sottoinsiemi di lavoro, ad esempio sviluppo, test o documentazione.

Usare questo modello:

  • Creare attività per ogni fase della consegna necessaria a completare il PBI o il bug.
  • Assegna attività ai membri del team in base alla responsabilità.
  • Aggiorna i valori delle attività ogni giorno in modo che la capacità e il burndown siano accurati.

Quando il team effettua le stime in ore o giorni, usa Lavoro rimanente e, facoltativamente, Attività.

Campo Come usarlo
Lavoro rimanente Immettere il numero di ore o giorni rimanenti e aggiornare il valore man mano che il lavoro procede. Questo campo alimenta i grafici di capacità, il burndown dello sprint e i report correlati. Se si suddivide il lavoro in sottoattività, tenere traccia solo del lavoro rimanente nelle sottoattività.
Activity Selezionare la categoria di attività che descrive meglio l'attività in modo che il team possa stimare ed esaminare la capacità dello sprint in base al tipo di attività.

Tenere traccia dello stato di avanzamento dei test

Usare le indicazioni seguenti per connettere la copertura dei test e il rilevamento dei difetti agli elementi del backlog sprint.

Usare questo modello per connettere il lavoro di test agli elementi di backlog:

  • Crea casi di test dal portale web in modo che siano collegati a un PBI o a un bug.
  • Se necessario, aprire la scheda Collegamenti e aggiungere manualmente la relazione.

Per Azure DevOps Server 2022, è anche possibile usare Microsoft Test Manager 2017.

Screenshot che mostra la selezione del gruppo di test e l'aggiunta di un test case.

I test case includono campi che si integrano con flussi di lavoro di compilazione e test. Per ulteriori dettagli, vedere Query basata sui campi di integrazione di build e test.

Schermata che mostra il modulo dell'elemento di lavoro per il caso di test Scrum.

Nella scheda Collegamenti sono elencati i bug e i pbi collegati a ogni test case.

Controllo di convalida: confermare che ogni caso di test mostri il PBI o il bug collegato nella scheda Collegamenti.

Tenere traccia dei difetti del codice

Crea bug dal portale web o da Visual Studio. Per informazioni dettagliate, vedere Gestire i bug.

Per Azure DevOps Server 2022, è anche possibile creare bug tramite Microsoft Test Manager 2017.

Definizioni per i campi comuni di monitoraggio 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.

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.

Tenere traccia degli ostacoli

Usa il tipo di elemento di lavoro Impediment per tenere traccia degli impedimenti. Usare Bug solo per i difetti del codice.

È possibile aggiungere un ostacolo da:

Screenshot che mostra l'aggiunta di un elemento di lavoro da un widget Nuovo elemento di lavoro.

Gli elementi di lavoro che aggiungi dal widget vengono automaticamente assegnati all'area predefinita e ai percorsi di iterazione del tuo team. Per usare un contesto del team diverso, consulta Cambiare contesto del team.

Ordine della lista backlog

Usa Priorità del backlog per gestire l'ordinamento relativo di PBI, bug, funzionalità ed epic.

Usare questo modello:

  • Riordinare gli elementi direttamente nella pagina backlog (vedere Creare il backlog).
  • Trascinare gli elementi per riflettere la priorità aziendale corrente.
  • Lascia che Azure DevOps aggiorni Priorità del backlog in background.

Controllo di convalida: confermare che l'ordine di backlog corrisponda alla priorità aziendale dopo il riordinamento.

Risolvere i problemi comuni

Issue Cause Resolution
Non è possibile spostare un elemento di lavoro nello stato previsto Le regole del flusso di lavoro o la personalizzazione del processo limitano le transizioni Esaminare la personalizzazione del processo e le transizioni consentite. Vedere Personalizzare un processo di ereditarietà.
Il campo obbligatorio blocca il salvataggio di un elemento di lavoro Le regole personalizzate specifiche del progetto richiedono campi aggiuntivi Controllare il messaggio di convalida e completare i campi obbligatori per il processo. Vedere Impostare regole per gli elementi di lavoro.
Non è possibile creare o modificare test case Autorizzazioni di test mancanti o livello di accesso Verificare l'accesso e le autorizzazioni per gli artefatti di test. Vedere Impostare le autorizzazioni e l'accesso per il monitoraggio del lavoro.
Il test case collegato non viene visualizzato in un elemento del backlog Il collegamento non è stato creato come collegamento all'elemento di lavoro o è stato aggiunto a un elemento diverso Aprire il test case e l'elemento backlog, quindi verificare i collegamenti nella scheda Collegamenti per entrambi gli elementi.
Non è possibile risolvere il problema dopo l'applicazione di queste correzioni I criteri o le autorizzazioni a livello di organizzazione bloccano comunque l'azione Per prima cosa, contatti l'amministratore del progetto. Se il problema riguarda l'intera organizzazione, contatta l'amministratore Project Collection o l'amministratore di Azure DevOps.

Contenuti correlati

  • Last updated on