Questo guest post è stato scritto da Gian Maria Ricci : MVP Visual Studio ALM. Vi ricordo che potete scaricare la Beta di Visual Studio 11 e Team Foundation Server 11 a questo indirizzo.
Le novità di TFS 11: la nuova interfaccia web
Le nuove versioni di TFS11 e VS11 introducono molte novità nel mondo dell'ALM che impattano non solo gli sviluppatori ma tutto il team e gli stakeholder. In questo articolo verranno introdotte le novità più importanti sulla nuova interfaccia web di TFS, e verrete guidati nell'uso di alcune delle più importanti funzionalità introdotte con TFS11 per quanto riguarda la pianificazione dei requisiti.
Questo post si basa sulla macchina virtuale di test fornita da Brian Keller che potete scaricare qui e si riferisce ad un Team Project basato su un Process Template di tipo Scrum 2.0 Beta. I concetti e le funzionalità mostrate sono comunque applicabili a tutti gli altri Process Template.
TFS Web access : Primo impatto
In TFS11 è stata introdotta una interfaccia web completamente riscritta che garantisce una elevata interattività grazie alla strutturazione asincrona ed al supporto di funzionalità avanzate come Drag And Drop. Di fatto quindi l'interfaccia web costituisce in questa nuova versione il punto di accesso preferenziale alle funzionalità di TFS.
L'enorme lavoro fatto è immediatamente visibile semplicemente aprendo l'home page di un Team Project
Figura 1 Home page del progetto nel Web Access
Come si può vedere l'aspetto è completamente metro style e viene fornito un immediato colpo d'occhio sullo stato del progetto in modo chiaro e semplice. In alto abbiamo la possibilità di aggiungere molto velocemente un work item di tipo Product Backlog Item, Task o Bug, basta un click sull'icona corrispondente editare il work item e salvarlo in maniera asincrona. A seguire è possibile visualizzare l'occupazione del team (in questo caso abbiamo allocato 39 delle 42 ore dello sprint) ed il burndown che mostra l'andamento della sprint corrente. Due aspetti sono molto importanti: il primo è che ogni sprint ha ora associata una data di inizio e di fine (nell'esempio febbraio 06 : febbraio 14) che permette a TFS di conoscere automaticamente lo sprint corrente; il secondo è che il burndown è ora calcolato in tempo reale sui dati presenti nel database di TFS e non è più necessario attendere il consolidamento del cubo di Analysis Service per vedere cambiamenti nel burndown.
Le tile rappresentano invece i Project Favorites, ovvero gli elementi del progetto che rivestono particolare importanza e che sono quindi stati marcati come favoriti. In questo esempio le tile verdi rappresentano delle query di Work Item dove il numero rappresenta quanti Work Item soddisfano la query. La tile viola rappresenta invece i check-in recenti effettuati in un percorso del source control, la tile grigia infine rappresenta una build dove i piccoli istogrammi sono i risultati delle singole build.
Infine a destra abbiamo una serie di link che permettono di gestire le attività più importanti del team ed immediatamente sotto la lista dei membri del team con un link che porta alla pagina di amministrazione dei membri. Troviamo infine due link a due sezioni molto specifiche dell'amministrazione, di cui particolare importanza riveste la prima: Configure schedule and iterations che permette di aprire il menu visibile in Figura 2 dove vengono inserite le date che specificano la durata dei vari sprint.
Figura 2 Gestione delle iterazioni
Gestione del Backlog
In ogni progetto la parte sicuramente più importante è la corretta gestione dei requisiti che si traduce nell'avere un Backlog che contiene i requisiti e tutte le entità che sono pianificabili e che portano ad un valore per l'utente/cliente. Per un processo basato su scrum, nel backlog troveranno posto due tipologie di Work Item: i Product Backlog Item che costituiscono i requisiti ed i Bug che costituiscono anomalie che vanno corrette. Come si può vedere in Figura 3 le operazioni di gestione del backlog vengono ora svolte direttamente dall'interfaccia web
Figura 3 Gestione del backlog
Dato che ogni sprint ha associata data di inizio e fine, TFS riconosce correttamente che la sprint corrente è la Sprint 3. Per quanto riguarda invece la gestione dei PBI (Product Backlog Item), è immediatamente visibile in alto una semplicissima textbox per aggiungere velocemente un PBI digitando semplicemente il titolo e facendo click sul bottone Add, rendendo di fatto molto veloce l'aggiunta di PBI. Per aggiungere dettagli ad un elemento basta fare doppio click su di esso per aprire la finestra di editing del Work Item dove si può gestire qualsiasi campo. L'aspetto importante è che le operazioni di pianificazione, come il riordino dei PBI in base alla loro importanza e l'assegnazione ad una sprint vengono fatte mediante drag and drop e quindi in maniera molto intuitiva. Basta cliccare su un elemento e spostarlo nella lista per effettuare un riordino e basta trascinare un elemento su una delle sprint a sinistra per assegnare l'elemento a quella sprint.
Un altro aspetto importante è che il campo descrizione supporta ora rich text e potete anche aggiungere immagini direttamente nell'interfaccia web come visibile in Figura 4.
Figura 4 La descrizione è ora un campo rich text
In una pianificazione tipica i requisiti del backlog vengono riordinati mettendo in testa quelli più importanti, a questo punto si procede ad assegnare i PBI alla sprint corrente cercando di capire quanti requisiti si vogliono implementare in quest a sprint. Per ogni PBI si può notare un campo chiamato Effort, che in terminologia agile rappresenta una stima grezza della difficoltà di implementazione di quello specifico PBI. Sebbene questo valore sia empirico e spesso determinato da una semplice discussione tra i membri con l'ausilio di strumenti come il planning poker, iterazione dopo iterazione il quantitativo totale di Effort che viene realizzato dal team in un singolo sprint tende a diventare più o meno costante e viene chiamato Velocity, permettendo a TFS di "prevedere" il numero di PBI che verranno realizzati nelle prossime Sprint, come visibile in Figura 5.
Figura 5 Forecast in azione
Scomposizione del lavoro in task
Una volta che si sono assegnati i PBI allo sprint corrente, è tempo di scomporre ognuno di essi in task più orientati al Developer andando quindi ad effettuare le operazioni di design. Un PBI è infatti una descrizione macroscopica di una funzionalità (user story) o di un bug, per la realizzazione del quale è necessario completare una serie di compiti (task), che coinvolgono più persone del team. Cliccando il nome dello sprint corrente viene quindi aperta la schermata di design e scomposizione in task.
Figura 6 Pianificazione dello sprint
Anche in questo caso l'interfaccia web è molto semplice da usare, un grande tasto + è presente a sinistra di ogni PBI e permette di aggiungere un task con un semplice click. Ogni task a sua volta è un normale Work Item dove il campo Remaining Work rappresenta il numero di ore stimate per il suo effettivo completamento. A destra si può invece osservare la distribuzione di carico del team aggiornato in tempo reale. La prima barra mostra ad esempio il carico del team non categorizzato, ovvero la somma delle ore di tutti i Task rapportata al numero di ore disponibili per questo sprint. Il monte ore è determinato dalla configurazione della capacity, configurabile dall'apposito tab come visibile in Figura 7.
Figura 7 Configurazione della "capacity" del team
Sebbene per alcuni team questo possa essere sufficiente, per team più organizzati è comunque interessante visualizzare la distribuzione dei task tra le singole persone, per capire se qualche risorsa sarà sovraccaricata durante questo sprint. In questo caso in Figura 6 potete osservare la sezione Work By: Assigned To, che mostra una barra di occupazione per ogni membro del team e che viene aggiornata in tempo reale mano a mano che i vari task vengono assegnati alle varie risorse.
Una possibilità alternativa à ¨ quella di pianificare per tipologia di attività, partendo quindi dall'assegnare una tipologia differente di attività per ogni membro del team, come visibile in Figura 8. In questo caso i singoli task non verranno associati ad uno specifico membro, ma si specificherà semplicemente il tipo di attività associata a quel task. Sempre in Figura 8 a destra viene mostrato come la Work By Activity rappresenta la pianificazione basata per attività.
Figura 8 Assegnare la tipologia di attività svolta dalle risorse
Taskboard
Arrivati a questo punto abbiamo una lista di PBI scomposta in task da completare nello sprint corrente, il team può quindi iniziare a lavorare ed i work item passeranno dallo stato To Do, a In progress ed infine a Done. Per monitorare l'andamento dello sprint corrente TFS11 implementa una taskboard classica che permette la visualizzazione immediata dell'andamento dei lavori, rappresentata in Figura 9
Figura 9 Taskboard attiva, la suddivisione per PBI permette un immediato colpo d'occhio su llo stato del progetto
La taskboard supporta il Drag And Drop e può benissimo essere lasciata sempre visibile in uno schermo con supporto Touch Screen in modo che ogni membro del team sia in grado di interagire con essa. Come si può vedere, nelle colonne e nelle righe viene anche riportato il totale consolidato del numero di ore rimanenti, che permette di capire quali PBI sono in fase di completamento e quali invece sono ancora nelle fasi iniziali; In questo caso ad esempio si può subito capire che il secondo PBI ha ancora 12h di lavoro stimato mentre l'ultimo ha solo 4h.
Mano a mano che i vari Task vengono completati, gli sviluppatori spostano con il drag and drop i task da To-Do a In progress e per finire a Done, aggiornando in tempo reale il grafico di BurnDown, che mostra l'andamento dello sprint corrente.
Figura 10 Burndown chart
La taskboard è molto utile soprattutto se si pianifica per tipologia di attività o in generale quando i task non vengono assegnati a nessun membro del team in fase di pianificazione. In questo caso all'inizio dello sprint tutti i task saranno nella colonna ToDo e non saranno assegnati a nessuna risorsa specifica; ogni membro del team a questo punto non fa altro che aprire la taskboard, scegliere il task da cui iniziare a lavorare tra quelli disponibili, e trascinarlo nella colonna In Progress e facendo questo il task gli sarà automaticamente assegnato.
Altre sezioni interessanti della Web Interface
In questa nuova interfaccia web inoltre sono state aggiunte funzionalità che in precedenza erano proprie del rich client (Visual Studio Team Explorer) ad esempio la possibilità di gestire le build, visualizzandone i risultati, modificandone la qualità e garantendo la possibilità di accodare e gestire la coda per le nuove build.
Figura 11 Gestione delle build nell'interfaccia web
Anche il sorgente permette un certo livello di gestione via web come è possibile osservare in Figura 12. Si può navigare tra i sorgenti per visualizzare la history di un determinato percorso in modo da capire chi e quando ha lavorato a quella particolare porzione di codice. Naturalmente è anche possibile visualizzare il contenuto dei singoli file ed effettuare il diff tra le varie versioni direttamente via web. Quest'ultima funzionalità è utile ad esempio per visualizzare le differenze tra vari file di configurazione, oppure per avere un immediato colpo d'occhio sul codice modificato in checkin particolari, come ad esempio quelli relativi alla chiusura di un bug.
Figura 12 Gestione del source control
Nella sezione Work->Work Items si possono eseguire le query sui Work Item avendo a disposizione sia tutte le query preimpostate del progetto, ma anche l'editor per scriverne di nuove.
Nel pannello di amministrazione troviamo infine tutti i menu necessari all'amministrazione del progetto, in cui tra tutti spicca il tab Alert che permette di impostare con pochi click degli alert che verranno inviati via mail.
Come si può osservare in Figura 13 l'interfaccia è molto completa e presenta alcuni hyperlink che portano alla creazione di alert standard del tipo: quando una build fallisce, quando qualcuno mi assegna un work item, etc. Ad esempio sempre in Figura 13 possiamo vedere due alert impostati sulla base di queste due condizioni (build fallita ed assegnazione dei work item)
Figura 13 Pannello di controllo per gli alert
È ora possibile anche gestire tutta la security del Team Project direttamente dal pannello di controllo web, Aggiungere immagini alle persone del team per una più facile identificazione ed impostare le iterazioni e le date dei vari sprint.
Questo breve tour mostra come la nuova interfaccia web permetta una gestione ed amministrazione completa dei vostri Team Project tramite un normale browser, senza quindi richiedere strumenti specifici come Visual Studio o Office installati.
read full article
