Team Foundation Server: gestire al meglio i WorkItem

Di Lorenzo Barbieri – Microsoft MVP

Una delle funzionalità più interessanti di Team Foundation Server è la possibilità di creare, gestire, collegare e ottenere report sui WorkItem.

I WorkItem (o Elementi di Lavoro nella versione italiana) permettono di modellare e gestire una qualsiasi cosa (attività, bug, richiesta di modifica, requisito, allocazione, richiesta di intervento, etc…) che abbia uno stato, dato dal valore di alcuni campi, un flusso (workflow) e una storia, oltre alla possibilità di poter gestire dei collegamenti con altri WorkItem o con documentazione, risultati di test, elementi nel sistema di gestione del codice sorgente, etc…

La creazione e la gestione dei WorkItem richiede la presenza del Team Explorer (Figura 1), o di un’altra applicazione che permetta di interfacciarsi con i WorkItem stessi (ad esempio Team System Web Access, il plug-in gratuito per accedere a Team Foundation Server via Web, visibile in Figura 2), e una licenza CAL (client access license) di Team Foundation Server.

Figura 1

Figura 2

L’installazione del Team Explorer, oltre a configurare il plug-in all’interno di Visual Studio 2005, installa anche i plug-in per lavorare con i WorkItem con Microsoft Office Excel (2003 o 2007) e con Microsoft Office Project Professional (2003 o 2007).

Definizione dei WorkItem

Team Foundation Server basa la definizione dei WorkItem sul template utilizzato per creare un Team Project. Ogni Team Project di Team Foundation Server può avere un set diverso di WorkItem.

Assieme a Team Foundation Server sono inclusi due template di default: Microsoft Solutions Framework for Agile Software Development e Microsoft Solutions Framework for CMMI Process Improvement. Per maggiori informazioni sul Microsoft Solutions Framework (spesso abbreviato con “MSF”) e sulle differenze tra le due versioni si faccia riferimento all’articolo Introduzione a Microsoft Solutions Framework 4.0.

Esistono altri template che contengono diverse definizioni dei WorkItem, ad esempio Microsoft eScrum, VSTS Scrum Process Template, Cochango Scrum for Team System, XP for Team System, etc…

I WorkItem possono essere anche , ad esempio per inserire nuovi stati, nuovi campi, etc… Per editare un WorkItem esistente bisogna utilizzare i tool da riga di comando installati assieme al Team Explorer (witimport.exe e witexport.exe), e manipolare a mano i file XML corrispondenti alla definizione del singolo WorkItem, oppure si può utilizzare il Process Template Editor che fa parte dei Team Foundation Server Power Tools.

In questo Tip (Team Foundation Server: limitare i valori nel campo Assigned To dei Work Item con il Process Template Editor) si vede un esempio di modifica di un campo di un WorkItem tramite Process Template Editor.

Query sui WorkItem

Il template con cui è stato creato il Team Project oltre a definire i WorkItem, definisce anche una serie di Query sui WorkItem utilizzate per vedere i WorkItem presenti nel Team Project dall’interno del Team Explorer (Figura 3), dalla finestra che permette di associare i WorkItem ai CheckIn (Figura 4), oppure da Microsoft Office Excel, Microsoft Office Project Professional, etc...

Figura 3

Figura 4

Le Query sono di due tipi: “Team Queries” e “My Queries”. Le prime sono visibili a tutto il Team, le seconde sono visibili solo alla persona che le ha create.

Se si lancia una Query dall’interno del Team Explorer, si ottiene una lista dei WorkItem che soddisfano l’interrogazione (Figura 5), lista che può essere utilizzata per vedere il dettaglio di un singolo WorkItem, oppure che può essere “passata” a Excel o Project Professional semplicemente selezionando degli elementi e premendo le icone corrispondenti.

Figura 5

Selezionando l’icona “View Query” è possibile vedere e modificare la definizione della Query, come in Figura 6, dove è mostrata la definizione della Query “All Tasks” modificata per mostrare tutti i Task e non solo quelli non chiusi. La definizione delle Query è fatta in un linguaggio simile al linguaggio SQL chiamato WorkItem Query Language (WIQL). La definizione dettagliata del WIQL può essere trovata nel SDK di Visual Studio 2005, scaricabile da questo indirizzo: http://msdn.microsoft.com/vstudio/extend/.

Figura 6

Se si creano molte Query, può essere utile “raggrupparle” in sottocartelle. Purtroppo non è possibile creare sottocartelle all’interno della sezione WorkItems del Team Explorer. Le soluzioni possibili sono due: prefissare il nome della Query con il nome della “categoria”, oppure memorizzare le Query all’interno della sezione Documents del Team Explorer (ovvero nel portale creato all’interno di Windows Sharepoint Services durante la creazione del Team Project) come mostrato in questo blog (in inglese): http://blogs.msdn.com/noahc/archive/2007/01/19/managing-lots-of-work-item-queries.aspx

Creazione, modifica e salvataggio di WorkItem

E’ possibile creare un WorkItem nuovo direttamente dal Team Explorer, oppure passando da Excel o da Project Professional, come mostrato in Figura 7.

Figura 7

Se si sceglie di utilizzare il Team Explorer (selezionando quindi il tipo di WorkItem scelto tra quelli messi a disposizione dal Team Project) verrà mostrata la pagina di dettaglio del WorkItem, in cui si potrà creare il WorkItem, salvarlo o editarlo (Figura 8). La pagina di dettaglio è la stessa che viene aperta quando il WorkItem viene aperto dalla lista contenente il risultato delle Query viste in precedenza (Figura 5).

Figura 8

Come si vede se il WorkItem viola le regole contenute nella sua definizione (ad esempio le regole sui campi obbligatori) viene mostrato un errore, e il WorkItem non potrà essere salvato (con l’icona “Salva” a forma di dischetto di Visual Studio, come qualsiasi altro file).

Sui WorkItem si può vedere la storia , i WorkItem possono essere collegati fra di loro, o essere collegati ad altri documenti, possono contenere Attachments (ad esempio la schermata contenente il messaggio di errore a fronte di un Bug), etc…

Lo stato dei WorkItem è generalmente dato dal campo “State” e dal campo associato “Reason”, che spiega il motivo per cui un WorkItem è nello stato attuale. Un esempio dei possibili stati di un WorkItem è visibile in Figura 9, che mostra i possibili stati dello “Scenario”, ovvero il WorkItem che in MSF for Agile Software Development rappresenta un requisito funzionale.

Figura 9

Per vedere come lavorare in dettaglio sui WorkItem si parta da qui.

Reportistica

Sui WorkItem può essere necessario avere informazioni “aggregate” o in formato grafico, informazioni che non conviene estrarre direttamente dalle Query e dai dettagli.

Per questi casi è possibile utilizzare le funzionalità di reportistica di Team Foundation Server (basate su Sql Server 2005 Reporting Services) che permettono di ottenere tutta una serie di informazioni in maniera molto semplice.

I report di default vengono creati sulla base del template con cui è stato creato il Team Project, ad esempio se si utilizza MSF for Agile Software Development i report sono quelli mostrati in Figura 10.

Figura 10

I report possono mostrare informazioni prese dai WorkItem, dalla gestione del codice sorgente, dalle Team Build automatizzate, etc…

Un esempio di report con informazioni estratte dai WorkItem è il report “Remaining Work” (Figura 11), che mostra l’andamento nel tempo dello stato dei vari insiemi di WorkItem, mostrando in rosso quelli ancora in lavorazione, in giallo quelli “risolti”, ovvero terminati ma non ancora testati, ed in verde quelli chiusi.

Come si vede è possibile filtrare il report selezionando il tipo dei WorkItem (tutti, solo alcune categorie o solo una categoria ben definita, come mostrato in Figura 12), la data iniziale e finale del report, ma soprattutto Aree ed Iterazioni, che vedremo nel paragrafo seguente.

Figura 11

Figura 12

Aree ed Iterazioni

Team Foundation Server permette di suddividere un Team Project in Aree ed Iterazioni distinte.

Le Aree possono essere funzionali (ad esempio Reportistica, Immissione Dati, Elaborazione, etc…), sede in cui viene sviluppato il software (ad esempio Milano, Roma, Torino, etc…), sottoprogetti (ad esempio Word, Excel, Project, Outlook, etc…), o di qualsiasi altro tipo.

Le Aree possono anche essere una combinazione di varie componenti, in quanto non c’è limite alla profondità e all’annidamento dei nodi nell’albero (Figura 13).

Le Aree di solito non si usano per suddivisioni “temporali” dei progetti, in quanto questo compito è svolto dalle Iterazioni, che pur avendo lo stesso comportamento delle Aree, sono dotate di un’importanza maggiore , essendo quello delle Iterazioni un concetto presente in quasi tutte le metodologie di gestione dei progetti.

Figura 13

Le Aree e le Iterazioni vengono assegnate ai WorkItem nella sezione “Classificazione”. I WorkItem non possono appartenere contemporaneamente a più Aree o a più Iterazioni (Figura 14).

Figura 14

Le Aree e le Iterazioni sono comode per filtrare i WorkItem nelle Query, ma soprattutto sono comode perché quasi tutti i report prevedono Aree e Iterazioni come metodo di default per filtrare i WorkItem da mostrare. Aree ed Iterazioni all’interno dei report possono essere selezionate anche più di una volta, per vedere ad esempio tutti i WorkItem del sottoprogetto 1, assieme ad esempio a quelli della sede di Milano (Figura 15).

Figura 15

Aree ed Iterazioni possono essere modificate a piacere durante il progetto, selezionando l’apposito menù all’interno del Team Project (Figura 16).

Figura 16

Se si cancella un’Area o un’Iterazione, il sistema permette di riassociare i WorkItem ad un’altra Area o Iterazione, per non perdere la tracciabilità dei dati (Figura 17).

Figura 17

Utilizzo di Microsoft Office Excel come tool per la gestione “bulk” dei WorkItem

Utilizzando il Team Explorer non è facile effettuare compiti ripetitivi, ad esempio cambiare in un colpo solo l’utente al quale sono assegnati una serie di WorkItem, oppure cambiare in un colpo solo l’Iterazione in cui lavorare su una serie di WorkItem.

Per questi, e tanti altri, compiti ripetitivi lo strumento consigliato è Microsoft Office Excel (2003 o 2007) che, con il Team Explorer installato (e il supporto della programmabilità da .NET selezionato al momento del setup di Excel), permette di scaricare liste di WorkItem, modificarle e pubblicarle di nuovo sul server (Figura 18).

Figura 18

Una Query in Excel può essere aperta direttamente dal Team Explorer, oppure si può aprire un nuovo documento Excel e selezionare “New List” per collegarsi al Team Foundation Server.

Il tasto “Get Work Items” permette di inserire altri WorkItem nella lista corrente, il tasto “Publish” pubblica sul Team Foundation Server le modifiche effettuate, mentre il tasto “Refresh” aggiorna la lista corrente con le modifiche effettuate sul server. Il tasto “Configure List” permette di indicare come viene fatto il Refresh, ovvero se deve contenere solo i WorkItem attualmente presenti nella lista, oppure se deve rieseguire la Query e scaricare anche le modifiche (Figura 19).

Figura 19

Il tasto “Choose Columns” permette di scegliere quali colonne visualizzare nella lista in Excel, mentre il tasto Links ed Attachments sostituisce gli appositi tab presenti nella definizione dei WorkItem nel Team Explorer con la schermata mostrata in Figura 20, che permette di gestire completamente da Excel i collegamenti con altri WorkItem, con la documentazione, con i sorgenti, etc… e che permette di inserire gli Attachments senza lasciare Excel.

Figura 20

Se si desidera, ad esempio, chiudere in un colpo solo tutta una serie di WorkItem si può cambiare il valore dello stato per un WorkItem (Figura 21) e poi copiarlo su tutti quelli interessati (Figura 22).

Figura 21

Figura 22

Come si vede il plug-in per Excel contiene già tutti i valori possibili dei campi che nel Team Explorer erano inseriti come ComboBox, per impedire l’inserimento di valori non supportati (Figura 21 e 23).

Figura 23

Microsoft Office Excel è usato anche per lavorare con i WorkItem quando non si dispone del collegamento al Team Foundation Server. Non è un vero tool per lavorare offline (bisogna partire da una situazione iniziale creata quando si è collegati al server) ma permette di salvare una lista di WorkItem in locale, come documento Excel, per poi lavorarci anche senza il collegamento al server. Quando la connettività sarà ripristinata, ad esempio al rientro in ufficio, si potrà effettuare il Publish e sincronizzare le modifiche con quelle presenti sul server.

Se un WorkItem viene modificato sia da Excel, sia da un altro strumento, al momento del Publish su Excel viene mostrata una schermata che permette di gestire la situazione (Figura 24). Nella schermata vengono mostrati i campi che hanno valori che sono stati modificati sia in Excel, sia da un altro strumento, e si può decidere se mantenere il valore originale o quello modificato.

Figura 24

Utilizzo di Microsoft Office Project Professional per schedulare i WorkItem graficamente

Per poter schedulare graficamente i WorkItem in un diagramma di Gantt si utilizza Microsoft Office Project Professional, in versione 2003 o 2007 (Figura 25). La versione 2007 è supportata a partire dal Service Pack 1 di Visual Studio 2005 Team System. I diagrammi creati con il plug-in di Team Foundation Server abilitato in Project 2007 non saranno leggibili dalla versione 2003. A partire da Visual Studio 2008 invece sarà possibile generare diagrammi compatibili contemporaneamente con entrambe le versioni di Project.

L’utilizzo del plug-in per Project è praticamente identico a quello di Excel, con alcune piccole differenze:

  • Si può scegliere la modalità di sincronizzazione tra i Task di Project e i WorkItem di Team Foundation Server singolarmente per ogni elemento.

  • I Task di Project possono anche non essere sincronizzati con il TFS (utile per i Task di RollUp, etc…)

  • Il mapping dei campi di Project con i WorkItem è definito una volta per tutte a livello di Team Project.

  • Il collegamento tra Task di Project non implica un link tra i corrispondenti WorkItem, che va creato a parte.

Figura 25

Sicurezza

La gestione della sicurezza può essere definita a livello di tipologia di WorkItem (ad esempio, si può definire che tutti possono creare Bug, ma solo gli appartenenti al gruppo dei Tester li possono chiudere) e può essere ulteriormente rifinita a livello di Aree (ad esempio, si può definire che tutti possono vedere i WorkItem comuni, mentre i WorkItem dell’area di Milano possono essere visti solo dalle persone che appartengono al gruppo della sede di Milano, e così via per le altre Aree).

Maggiori informazioni sulla sicurezza dei WorkItem possono essere trovate a partire da qui.

Estensibilità

Come tutte le funzionalità di Team Foundation Server, anche la gestione dei WorkItem è completamente gestibile tramite i Web Service esposti dal server, o tramite il modello ad oggetti esposto dalle DLL installate con il Team Explorer.

E’ possibile crearsi dei Tool per automatizzare la gestione dei WorkItem, ed esistono già un gran numero di tool già pronti, gratuiti e a pagamento che possono essere trovati all’indirizzo www.teamsystemwidgets.com.

Ad esempio è possibile scaricare Tool per fare una fotografia allo schermo e creare un Bug con l’immagine allegata, oppure è possibile creare un WorkItem a partire da una pagina caricata in Internet Explorer, molto utile per testare applicazioni Web.

Conclusioni

La gestione dei WorkItem è completamente integrata con tutti gli altri strumenti presenti in Team Foundation Server (gestione del codice sorgente, documentazione, build automatiche e reportistica) ed è uno dei punti di forza di Team Foundation Server per poter gestire team di qualsiasi dimensione , dai più piccoli (con poche tipologie di WorkItem e con una gestione molto libera del loro ciclo di vita) ai più grandi (con molte tipologie di WorkItem e con regole ben precise per la gestione, l’auditing e la sicurezza).

In questo articolo si è cercato di spiegare come gestire i WorkItem di Team Foundation Server utilizzando gli strumenti forniti di default, ovvero il Team Explorer e i plug-in ad esso correlati. In un successivo articolo si vedrà come tracciare praticamente la definizione di un requisito, la sua implementazione, il test, la creazione di un bug collegato al requisito, e la sua risoluzione e chiusura.


Mostra: