Tipi di elemento di lavoro e flusso di lavoro del modello di processo Agile

Articolo
06/10/2015

I team usano tipi di elemento di lavoro (WIT) forniti con il modello di processo MSF for Agile Software Development 2013 (Agile) per pianificare e tenere traccia dello stato di avanzamento dei progetti software. I team definiscono le storie utente per gestire il backlog di lavoro, quindi, usando la bacheca Kanban, tengono traccia dello stato di avanzamento aggiornando lo stato delle storie utente.

Tipi di elemento di lavoro Agile 7.0

Per ottenere informazioni su un insieme di funzionalità, scenari o esperienze utente, i proprietari del prodotto e i responsabili del programma possono eseguire il mapping delle storie utente alle funzionalità. Quando i team lavorano in sprint, definiscono le attività che si collegano automaticamente alle storie utente.

Usando Microsoft Test Manager e Team Web Access (TWA), i tester creano ed eseguono test case. Bug e problemi sono usati per tenere traccia dei difetti del codice e dei problemi di blocco.

Definire le storie utente e stimare il lavoro richiesto usando i punti della storia

Le storie utente definiscono le applicazioni, i requisiti e gli elementi che i team devono creare. I proprietari del prodotto in genere definiscono le storie utente dell'ordine di priorità. Il team stima quindi il lavoro richiesto per distribuire gli elementi con la priorità più elevata.

Creare storie utente dal pannello di aggiunta rapida nella pagina di backlog di prodotto.

Pannello Aggiunta rapida, pagina del backlog delle storie

Successivamente, è possibile aprire ogni storia utente per fornire altri dettagli e stimare i punti della storia.

Form dell'elemento di lavoro per una storia utente

Definendo i Punti della storia, i team possono usare le funzionalità di previsione e i grafici velocità per valutare gli sprint futuri o il lavoro richiesto. Classificando in ordine di priorità le storie utente nella pagina di backlog (che viene acquisita nel campo Ordine di priorità), i proprietari del prodotto possono indicare a quali elementi è necessario assegnare la priorità più alta.

Usare le linee guida seguenti durante la compilazione del form. I campi obbligatori sono indicati in questo modo.

Campo/scheda	Utilizzo
Punti storia	Stimare la quantità di lavoro necessaria per completare una storia utente 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 velocità. Per ulteriori istruzioni, vedere il white paper Stima.
Rischio	Valutazione soggettiva dell'incertezza relativa rispetto al corretto completamento di una storia utente. I valori consentiti sono: 1 - Alto 2 - Medio 3 - Basso Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.
Dettagli (storie utente)	Per le storie utente, fornire dettagli sufficienti per stimare la quantità di lavoro richiesta per implementare la storia. 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. Passaggi da riprodurre (bug) Per i bug, 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. Si consiglia di includere cosa significa "Operazione completata" descrivendo i criteri che il team deve usare per verificare se la correzione della storia utente o dei bug è stata implementata completamente. Prima di iniziare a lavorare su una storia utente 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 che si soddisfino 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.

Punti storia

Stimare la quantità di lavoro necessaria per completare una storia utente 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 velocità.

Per ulteriori istruzioni, vedere il white paper Stima.

Rischio

Valutazione soggettiva dell'incertezza relativa rispetto al corretto completamento di una storia utente. I valori consentiti sono:

1 - Alto
2 - Medio
3 - Basso

Per modificare la selezione dei menu, vedere Personalizzare un elenco di selezione.

Dettagli (storie utente)

Per le storie utente, fornire dettagli sufficienti per stimare la quantità di lavoro richiesta per implementare la storia. 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.

Passaggi da riprodurre (bug)

Per i bug, 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.

Si consiglia di includere cosa significa "Operazione completata" descrivendo i criteri che il team deve usare per verificare se la correzione della storia utente o dei bug è stata implementata completamente.

Prima di iniziare a lavorare su una storia utente 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 che si soddisfino 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.

Tenere traccia dello stato di avanzamento

I team possono usare la bacheca Kanban per tenere traccia dello stato di avanzamento delle storie utente 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.

Bacheca Kanban con aggiornamento delle storie

È possibile personalizzare la bacheca Kanban affinché supporti corsie o colonne aggiuntive. In alternativa, è possibile personalizzare il flusso di lavoro per la storia utente e i tipi di elemento di lavoro attività, che modificheranno le intestazioni delle colonne predefinite.

Di seguito viene descritta una 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 su Attivo quando si decide di completare il lavoro durante lo sprint.
Una storia utente viene spostata in Risolto se il team ha completato tutte le attività associate e gli unit test per la storia sono stati superati.
Una storia utente viene spostata nello stato Chiuso quando il proprietario acconsente che la storia è stata implementata in base ai criteri di accettazione e i test di accettazione vengono superati.

Aggiornando il 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.

Eseguire il mapping di storie utente 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à ed eseguendo il mapping delle storie utente alle funzionalità.

Nella pagina di backlog delle funzionalità è possibile aggiungere rapidamente le funzionalità, nello stesso modo in cui sono state aggiunte le storie utente.

Pannello Aggiunta rapida, pagina del backlog di portfolio delle funzionalità

L'elemento di lavoro della funzionalità contiene campi analoghi forniti per le storie utente e include campi aggiuntivi, come descritto nella tabella seguente.

Form dell'elemento di lavoro della funzionalità per Agile

La scheda Implementazione acquisisce i collegamenti alle storie utente mappate.

Campo	Utilizzo
Priorità	Classificazione soggettiva della funzionalità in relazione all'azienda. I valori consentiti sono: 1: il prodotto non può essere rilasciato senza la funzionalità. 2: il prodotto non può essere rilasciato senza la funzionalità, ma non è necessario risolvere il problema immediatamente. 3: l'implementazione della funzione è facoltativa in base alle risorse, al tempo e al rischio. Per modificare la selezione dei menu, vedere Personalizzare un elenco di opzioni (menu a discesa) [reindirizzamento].
Valore di business	Specificare un numero tramite cui viene acquisito il valore relativo di una funzionalità rispetto ad altre funzionalità. Quanto più alto è il numero, maggiore è il valore di business.
Data di destinazione	Specificare la data entro cui la funzionalità deve essere implementata.

Priorità

Classificazione soggettiva della funzionalità in relazione all'azienda. I valori consentiti sono:

1: il prodotto non può essere rilasciato senza la funzionalità.
2: il prodotto non può essere rilasciato senza la funzionalità, ma non è necessario risolvere il problema immediatamente.
3: l'implementazione della funzione è facoltativa in base alle risorse, al tempo e al rischio.

Per modificare la selezione dei menu, vedere Personalizzare un elenco di opzioni (menu a discesa) [reindirizzamento].

Valore di business

Specificare un numero tramite cui viene acquisito il valore relativo di una funzionalità rispetto ad altre funzionalità. Quanto più alto è il numero, maggiore è il valore di business.

Data di destinazione

Specificare la data entro cui la funzionalità deve essere implementata.

Nella pagina di backlog con Mapping abilitato è possibile trascinare le storie utente nella funzionalità che implementano.

Eseguire il mapping di una storia utente a una funzionalità

Questo mapping crea collegamenti padre-figlio dalla funzionalità alle storie utente, 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 le storie utente e tenere traccia della capacità e del burn-down del team

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.

Collegamento Aggiungi attività in una pagina di backlog sprint

Assegnare un nome all'attività e valutare il lavoro che sarà accettato.

Form dell'elemento di lavoro per Attività

Se si usa processi Agile, i team prevedono il lavoro e definiscono le attività all'inizio di ogni sprint e ogni membro del team esegue un sottoset 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 delle storie utente e un tester può definire attività da 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/scheda	Utilizzo
Stima originale (vedere la nota 1)	Quantità stimata di lavoro richiesto per completare un'attività. In genere, questo campo non viene modificato dopo l'assegnazione.
Lavoro rimanente	Quantità di lavoro rimanente per completare un'attività. Con l'avanzamento del lavoro, aggiornare il campo. Usato per calcolare i grafici di capacità e burn-down sprint e i report seguenti: Burn-down e velocità, Lavoro rimanentee Stato di tutte le iterazioni. Se si divide un'attività in sottoattività, specificare le ore solo per le sottoattività. È possibile specificare il lavoro in qualsiasi unità di misura scelta dal team.
Lavoro completato	Quantità di lavoro eseguita per l'implementazione di un'attività.
Attività	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..
Implementazione	Questa scheda acquisisce i collegamenti padre-figlio creati tra storie utente e attività. Quando si aggiungono attività a una storia utente usando la lavagna delle attività sprint, vengono automaticamente creati i collegamenti alla storia. Mediante le attività, è possibile tenere traccia dello stato di avanzamento del lavoro che ha avuto luogo per il completamento della storia. Questa attività supporta inoltre diversi report, ad esempio Rapporto Stato di avanzamento requisiti (CMMI) e Rapporto Panoramica storie (Agile).

Note:

È possibile specificare il lavoro in ore o in giorni. Nessuna unità di tempo inerente è associata a questo campo.

Se si usa Microsoft Project per assegnare risorse e tenere traccia di una pianificazione, è possibile aggiornare questi campi usando Project.

Tenere traccia dello stato di avanzamento del test nelle storie utente e acquisire i difetti del codice

Storie utente testate

In Test Manager o in TWA, è possibile creare i test case che si collegano automaticamente a una storia utente oppure a un bug.

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.

Form dell'elemento di lavoro per test case

Nella scheda Storie utente testate sono elencati tutti i bug e le storie utente di un test case. Collegando le storie utente e i bug ai test case, il team può tenere traccia dei progressi effettuati nel test di ogni elemento. Definendo questi collegamenti, vengono supportate le informazioni visualizzate nel report Rapporto Panoramica storie (Agile).

Tenere traccia dei difetti del codice

È possibile creare bug da TWA o Visual Studio o durante l'esecuzione di test con Test Manager.

Modulo del bug dell'elemento di lavoro (modello di processo Agile)

Campo/scheda	Utilizzo
Passi da riprodurre	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.
Gravità	Valutazione soggettiva dell'impatto di un bug sul progetto. I valori consentiti sono: 1 - Critico 2 - Alto 3 - Medio 4 - Basso Per modificare la selezione dei menu, vedere Definire un elenco di selezione..
Info sistema Rilevato in compilazione Integrato nella compilazione	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.

Passi da riprodurre

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.

Gravità

Valutazione soggettiva dell'impatto di un bug sul progetto. I valori consentiti sono:

1 - Critico
2 - Alto
3 - Medio
4 - Basso

Per modificare la selezione dei menu, vedere Definire un elenco di selezione..

Info sistema

Rilevato in compilazione

Integrato nella compilazione

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 per tutti i tipi di elemento di lavoro è Titolo. Quando viene salvato, all'elemento di lavoro viene assegnato automaticamente un ID univoco. Altri campi obbligatori vengono evidenziati in giallo.

Campo/scheda	Utilizzo
Titolo [obbligatorio]	Immettere una descrizione con una lunghezza massima di 255 caratteri. È sempre possibile modificare in seguito il titolo.
Assegnato a	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.
Stato	Quando viene creato l'elemento di lavoro, per impostazione predefinita viene impostato il primo stato nel flusso di lavoro. 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.
Motivo	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.
Area	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.
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.
Tutti i collegamenti	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.
Allegati	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.
Cronologia	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.

Se è disponibile un progetto team, iniziare a tenere traccia del lavoro:

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 altre informazioni, vedere Scegliere il client di Team Foundation per eseguire le attività.

Domande e risposte

D: Come è possibile tenere traccia del valore di business?

R: È possibile usare il campo relativo alla priorità per distinguere il valore di varie storie. In alternativa, è possibile aggiungere un campo personalizzato al tipo di elemento di lavoro Storia utente che tenga traccia del valore relativo delle storie. Per informazioni a questo proposito, vedere Modificare o aggiungere un campo personalizzato.

D: Quali stati del flusso di lavoro sono supportati da Agile?

R: Questi diagrammi mostrano gli stati di progressione e regressione principali di Funzionalità, Storia utente, Bug e Attività. Per personalizzare il flusso di lavoro, vedere questa pagina.

Funzionalità