Tipi di elemento di lavoro e flusso di lavoro del modello di processo Scrum
Per pianificare un progetto software e tenere traccia dei difetti del software tramite Scrum, i team usano i tipi di elemento di lavoro noti come bug e PBI (Product Backlog Item, elemento del Backlog di Prodotto). Per ottenere informazioni su un insieme di funzionalità, scenari o esperienze utente, i proprietari del prodotto e i responsabili del programma possono mappare PBI e bug alle funzionalità. Quando i team lavorano in sprint, definiscono attività che si collegano automaticamente a elementi backlog di prodotto (PBI) e bug.
.png "Tipi di elementi di lavoro Scrum 3.0")
Usando Microsoft Test Manager e Team Web Access (TWA), i tester creano ed eseguono test case e creano bug per tenere traccia dei difetti del codice. Gli impedimenti tengono traccia dei problemi che potrebbero causare blocchi.
Definire il backlog usando i PBI e i bug
Quando si definisce un elemento del Backlog di Prodotto, è opportuno concentrarsi sul valore che i clienti ne riceveranno ed evitare descrizioni di come il team procederà allo sviluppo della funzionalità. Il proprietario del prodotto può classificare in ordine di priorità il backlog del prodotto in base al valore aziendale, all'impegno e alla dipendenza relativa di ciascun elemento da altri elementi di backlog. Il backlog del prodotto evolve di pari passo con i requisiti aziendali. In genere, i team specificano dettagli solo per gli elementi con priorità più elevata o per quegli elementi assegnati allo sprint corrente o a quello successivo.
È possibile creare PBI e bug dal pannello di aggiunta rapida nella pagina di backlog di prodotto.
.png "Aggiungere un elemento al backlog di prodotto")
Successivamente, è possibile aprire ogni PBI o bug per fornire altri dettagli ed effettuare una stima del lavoro richiesto. Classificando in ordine di priorità i PBI e i bug nella pagina di backlog (che viene acquisita nel campo Priorità del Backlog), i proprietari del prodotto possono anche indicare a quali elementi è necessario assegnare la priorità più alta.
.png "Modulo dell'elemento di lavoro per Elemento del Backlog di Prodotto")
Definendo il Lavoro richiesto per i PBI e i bug, i team possono usare la funzionalità di previsione e i grafici velocità per valutare il lavoro richiesto o gli sprint futuri. Definendo il Valore di business, i proprietari del prodotto possono specificare le priorità separatamente dalla classificazione stack dei backlog modificabili.
Usare le linee guida seguenti per questi campi fondamentali. Per informazioni dettagliate sulla creazione dei bug, vedere Tenere traccia dei difetti del codice più avanti in questo argomento.
Campo/scheda |
Utilizzo |
|---|---|
Stimare la quantità di lavoro necessaria per completare un PBI usando qualsiasi unità di misura preferita dal team, quali le misure delle magliette, i punti della storia o il tempo. I grafici velocità e gli strumenti di previsione Agile fanno riferimento ai valori in questo campo. Si tratta di un campo obbligatorio per generare i report Burn-down versione e Velocità. Per informazioni aggiuntive, vedere il white paper sull'esecuzione di una Stima. |
|
Specificare un numero tramite cui viene acquisito il valore relativo di un PBI rispetto ad altri PBI. Quanto più alto è il numero, maggiore è il valore di business. |
|
Descrizione (PBI) |
Fornire dettagli sufficienti per stimare la quantità di lavoro richiesta per implementare l'elemento. Concentrarsi sui destinatari della funzionalità, su cosa gli utenti vogliono ottenere e sul motivo. Non descrivere la modalità di sviluppo della funzionalità. Fornire dettagli sufficienti in modo che il team possa scrivere attività e test case per implementare l'elemento. |
Definire cosa significa "Operazione completata" descrivendo i criteri che il team deve usare per verificare se la correzione dei PBI o dei bug è stata implementata completamente. Prima di iniziare a lavorare su un PBI o su un bug, descrivere i criteri per l'accettazione del cliente nel modo più chiaro possibile. Le conversazioni che il team ha con i clienti per determinare i criteri di accettazione permettono di stabilire un'intesa comune a tutto il team, in modo da 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 più efficacemente se un elemento è stato completato in modo soddisfacente. |
Per altre informazioni sull'uso della pagina di backlog di prodotto, vedere qui.
Tenere traccia dello stato di avanzamento
I team possono usare la bacheca Kanban per tenere traccia dello stato di avanzamento di PBI e bug e la lavagna delle attività sprint per tenere traccia dello stato di avanzamento delle attività. Con il trascinamento degli elementi in una nuova colonna relativa allo stato vengono aggiornati i campi Stato e Motivo del flusso di lavoro.
.png "Spostare un elemento in una colonna diversa")
Di seguito viene descritta una progressione tipica del flusso di lavoro per un PBI:
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 una volta che è stato sufficientemente descritto ed è pronto per la valutazione, da parte del team, del livello di lavoro richiesto. Nella maggior parte dei casi, gli elementi nella parte superiore del Backlog di prodotto sono nello stato Approvato, mentre gli elementi verso il centro e il basso sono in un stato Nuovo.
Il team aggiorna lo stato su Eseguito quando si decide di completare il lavoro durante lo sprint.
Il team aggiorna lo stato dell'elemento impostandolo su Completato quando il team ha completato tutte le relative attività associate e il proprietario conferma che è stato implementato in base ai criteri di accettazione.
Aggiornando lo stato del flusso di lavoro, i team sanno quali elementi sono nuovi, in corso o completati. La maggior parte dei tipi di elemento di lavoro supporta la transizione in avanti e indietro da ogni stato del flusso di lavoro.
È possibile personalizzare la bacheca Kanban affinché supporti corsie o colonne aggiuntive. In alternativa, è possibile personalizzare il flusso di lavoro per il PBI e i tipi di elemento di lavoro attività, che modificheranno le intestazioni di colonna predefinite.
Per usare questi strumenti, vedere Utilizzare la bacheca Kanban e Lavorare in sprint.
Mapping dei PBI alle funzionalità
Quando si gestisce una famiglia di prodotti o esperienze utente, può essere opportuno visualizzare l'ambito e lo stato di avanzamento del lavoro per l'intera famiglia di prodotti. Questa operazione può essere eseguita definendo le funzionalità e mappando i PBI alle funzionalità.
Dalla pagina di backlog delle funzionalità, è possibile aggiungere rapidamente le funzionalità, nello stesso modo in cui sono stati aggiunti i PBI.
.png "Funzionalità di aggiunta rapida dal backlog Funzionalità")
L'elemento di lavoro della funzionalità contiene i campi analoghi a quelli forniti per i PBI. Oltre a Valore di business e Priorità è possibile specificare la Data di destinazione entro cui la funzionalità deve essere implementata.
.png "Form dell'elemento di lavoro della funzionalità")
Nella pagina di backlog con il mapping abilitato è possibile trascinare i PBI nella funzionalità che implementano.
.png "Eseguire il mapping di un PBI a una funzionalità")
Questo mapping crea collegamenti padre-figlio dalla funzionalità ai PBI, che vengono riportati nella scheda Implementazione.
Se si usano i backlog di portfolio è possibile eseguire il drill-down da un backlog all'altro per visualizzare il livello di dettaglio preferito. È anche possibile usare i backlog di portfolio per visualizzare un rollup del lavoro in corso in diversi team quando si configura una gerarchia di team.
Definire le attività necessarie per implementare i PBI e i bug
Quando il team gestisce il proprio lavoro in sprint, può usare la pagina di backlog sprint per suddividere il lavoro da portare a termine in attività distinte.
.png "Aggiungere un'attività a un elemento nel backlog sprint")
Assegnare un nome all'attività e valutare il lavoro che sarà accettato.
.png "Aggiungere un titolo e una stima delle ore")
Usando processi Scrum, i team prevedono il lavoro e definiscono le attività all'inizio di ogni sprint e ogni membro del team esegue un sottoinsieme di queste attività. Le attività possono includere sviluppo, test e altri tipi di lavoro. Uno sviluppatore ad esempio può definire alcune attività per l'implementazione dei 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 rimanente e Attività (facoltativo).
Campo |
Utilizzo |
|---|---|
Indicare il numero di ore o di giorni di lavoro rimanenti per il completamento di un'attività. Con l'avanzamento del lavoro, aggiornare il campo. Viene usato per calcolare i grafici di capacità, il grafico burn-down sprint e il report Burn-down sprint (Scrum). Se si divide un'attività in sottoattività, specificare il lavoro rimanente solo per queste ultime. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team. |
|
Selezionare il tipo di attività rappresentata da questa attività quando il team valuta la capacità dello sprint in base all'attività. Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione. |
Tenere traccia dello stato di avanzamento dei test
Testare gli elementi del backlog di prodotto
In Test Manager o TWA è possibile creare test case che si collegano automaticamente a un elemento del backlog di prodotto.
.png "Selezionare il gruppo di test e aggiungere un test case")
Il test case contiene numerosi campi, molti dei quali sono automatizzati e integrati con Test Manager e il processo di compilazione. Per la descrizione di ciascun campo, vedere Riferimento ai campi Integrare test e compilare.
.png "Form dell'elemento di lavoro per test case")
Nella scheda Elementi backlog testati sono elencati tutti i PBI e i bug presenti in un test case. Collegando i PBI e i bug ai test case, il team può tenere traccia dei progressi effettuati nel test di ogni elemento.
Tenere traccia dei difetti del codice usando i bug
È possibile creare bug da TWA o Visual Studio o durante l'esecuzione di test con Test Manager.
.png "Modulo del bug dell'elemento di lavoro per modello di processo Scrum")
Campo/scheda |
Utilizzo |
|---|---|
Acquisire informazioni sufficienti per consentire agli altri membri del team di comprendere l'impatto complessivo del problema e l'eventuale correzione del bug. Ciò include le azioni intraprese per trovare o riprodurre il bug e il comportamento previsto. Descrivere i criteri che il team deve usare per verificare se l'errore del codice è stato corretto. |
|
Valutazione soggettiva dell'impatto di un bug sul progetto. I valori consentiti sono:
Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione. |
|
Quando Test Manager crea bug, popola automaticamente Informazioni sistema e Rilevato in compilazione con le informazioni sull'ambiente software e sulla compilazione in cui si è verificato il bug. Per altre informazioni sulla definizione degli ambienti software, vedere Configurazione di computer di test per l'esecuzione di test o la raccolta di dati. Quando si risolve un bug, usare Integrato nella compilazione per indicare il nome della compilazione che incorpora il codice che corregge il bug. Per accedere a un menu a discesa con tutte le compilazioni che sono state eseguite, è possibile aggiornare le definizioni FIELD per Rilevato in compilazione e Integrato nella compilazione per fare riferimento a un elenco globale. L'elenco globale viene aggiornato automaticamente quando ognuna delle compilazioni viene eseguita. Per altre informazioni, vedere Campi che supportano l'integrazione con il test, la compilazione e il controllo della versione. Per altre informazioni sulla definizione dei nomi di compilazione, vedere Utilizzare i numeri di build per assegnare nomi significativi alle compilazioni completate. |
Definire i campi e le schede di elemento di lavoro comuni
I campi e le schede seguenti vengono visualizzati nella maggior parte dei form di elemento di lavoro. Ogni scheda viene usata per tenere traccia di informazioni specifiche, ad esempio Cronologia, Collegamenti o Allegati. Questi tre campi forniscono, rispettivamente una cronologia delle modifiche, la visualizzazione degli elementi di lavoro collegati e la possibilità di visualizzare e associare file.
L'unico campo obbligatorio è Titolo. Quando viene salvato, all'elemento di lavoro viene assegnato automaticamente un ID univoco.
Campo/scheda |
Utilizzo |
|---|---|
Titolo (obbligatorio) |
Immettere una descrizione con una lunghezza massima di 255 caratteri. È sempre possibile modificare in seguito il titolo. |
Assegnare l'elemento di lavoro al membro del team responsabile dell'esecuzione del lavoro. A seconda del contesto che si usa, nel menu a discesa verranno elencati solo i membri del team o i collaboratori del progetto team. |
|
Usare innanzitutto il valore predefinito. Con l'avanzamento del lavoro, aggiornarlo in modo tale che rifletta lo stato corrente. Per modificare l'elenco a discesa degli stati, vedere Modificare il flusso di lavoro per un tipo di elemento di lavoro. |
|
Usare prima il valore predefinito e aggiornarlo quando si modifica lo stato. Ogni stato è associato a un motivo predefinito. Per modificare l'elenco a discesa dei motivi, vedere Modificare il flusso di lavoro per un tipo di elemento di lavoro. |
|
Scegliere il percorso area associato al prodotto o al team oppure lasciare vuoto il campo fino a quando non viene assegnato un valore durante una riunione di pianificazione. Per modificare l'elenco a discesa delle aree, vedere Aggiungere e modificare percorsi di area e di iterazione. |
|
Scegliere lo sprint o l'iterazione in cui il lavoro deve essere completato oppure lasciare vuoto il campo e assegnare un valore in un secondo momento, durante una riunione di pianificazione. Per modificare l'elenco a discesa delle iterazioni, vedere Aggiungere e modificare percorsi di area e di iterazione. |
|
Usato per tenere traccia della classificazione dei PBI e dei bug. La sequenza di elementi nella pagina di backlog di prodotto viene determinata in base al punto in cui sono stati aggiunti gli elementi o a quello in cui sono stati spostati gli elementi nella pagina. Quando si trascinano elementi, un processo in background aggiorna questo campo, che è assegnato a type="Order" nel file ProcessConfiguration. |
|
Aggiungere tutti i tipi di collegamenti, quali collegamenti ipertestuali, insiemi di modifiche, file di origine e così via. In questa scheda vengono elencati inoltre tutti i collegamenti definiti per l'elemento di lavoro, anche quelli definiti in altre schede di controllo dei collegamenti. |
|
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. |
|
Rivedere l'itinerario di controllo acquisito dal sistema e acquisire informazioni aggiuntive. Ogni volta che l'elemento di lavoro viene aggiornato, le informazioni vengono aggiunte alla cronologia. Nella cronologia sono inclusi la data e l'autore della modifica e i campi modificati. Al campo della cronologia è anche possibile aggiungere testo formattato. |
Per trovare informazioni su altri campi, vedere Indice dei campi elemento di lavoro.
Iniziare a tenere traccia del lavoro
Prima di iniziare a tenere traccia del lavoro, è necessario avere creato un progetto team. Per crearne uno, vedere qui.
Per iniziare a tenere traccia del lavoro, eseguire una o più delle attività seguenti:
Per acquisire familiarità con attività elemento di lavoro comuni, vedere Introduzione all'utilizzo di elementi di lavoro.
Per creare un backlog, usare TWA. Vedere Creare il backlog.
Per creare una struttura di suddivisione del lavoro, usare Project o Excel.
Per informazioni sul client da usare, vedere Scegliere il client di Team Foundation per eseguire le attività.
Domande e risposte
D: Quali stati del flusso di lavoro sono supportati da Scrum?
R: Questi diagrammi mostrano gli stati di progressione e regressione principali di Funzionalità, Elemento del backlog di prodotto, Bug e Attività. Per personalizzare il flusso di lavoro, vedere questa pagina.
Funzionalità .png "Stati del flusso di lavoro funzionalità, modello di processo Scrum") |
Elemento del Backlog di Prodotto .png "Flusso di lavoro per Elemento del Backlog di Prodotto, processo Scrum") |
Bug .png "Stati del flusso di lavoro dei bug, modello di processo Scrum") |
Attività .png "Stati del flusso di lavoro delle attività, modello di processo Scrum") |
D: Come fare per risolvere un bug come duplicato?
R: Impostare lo stato su Rimosso e specificare Duplicato nel motivo.
D: Come fare per collegarsi a un bug esistente da Test Runner?
R: Vedere Aggiornare un bug esistente durante l'uso di Test Runner.