Oltre alla tecnologia in se, l’introduzione della funzionalita’ di Agile Portfolio Management in Team Foundation Server e Service ha un grosso impatto sulla superficie che si va a coprire con il progetto.

Attenzione: in molti casi parlo di progetti medio-grandi. Introdurre concetti come questo in progetti piccoli potrebbe essere controproducente.

Fino ad oggi, il modo piu’ comune di approcciare l’agile backlog management e’ stato quelo di creare delle User Story e in seguito suddividerle in task unitari. Questo va benone e non sta cambiando, ma a volte ci si trova di fronte al seguente problema: la User Story e’ troppo grande per essere inclusa in uno sprint.

A volte capita, sfortunatamente. Per risolvere questo problema, ci viene in aiuto il concetto di Epic.

Un’ Epic e’ sostanzialmente una grande User Story, che e’ a sua volta divisa in diverse sottostorie il cui effort e’ compatibile con la durata dello sprint. Si puo’ rappresentare come un obiettivo funzionale. Una Epic contiene una o piu’ User Story tenute insieme da un tema comune. Non si terminera’ mai in uno sprint, solitamente un’Epic e’ una grossa feature (spesso una killer feature) del nostro prodotto. Si gestisce on top, perche’ potrebbe avere impatti anche su altri prodotti nell’organizzazione.

Il Theme e’ in coma a tutto quanto. Parlando in termini di progetto, potrebbe essere una major release. E’ una iniziativa, una pietra angolare del progetto stesso. I Theme guidano la strategia ed esprimono una direzione, per questo sono generalmente non specifici.

Al momento in Team Foundation Service (e presto in Team Foundation Server 2013) si avra’ il concetto di Epic out-of-the-box. Ma come Brian Harry ci ha detto nel suo post, e’ possibile effettuare delle customizzazioni con un basso effort per modificare l’esperienza d’uso e modellare in modo ancora piu’ fedele il processo.

Fino a ieri, volendo gestire qualcosa in piu’ di User Story e Task, Bug, etc. si doveva usare un certo livello di astrazione e l’uso di tool specifici come Project Server, spesso forzati ad un comportamento ai limiti del consentito.

Con le nuove feature rivelate ieri per l’Agile Portfolio Management possiamo evitare di scomodare Project Server per compiti nei quali sarebbe eccessivo, ma comunque potremo integrarlo con TFS 2013 se necessario.

Prendiamo questo esempio: vogliamo creare un sistema, e una delle sue feaure e’ il cestino dei rifiuti. Quindi creiamo la feature con il nuovo Work Item Type, e la vediamo nel backlog filtrando per feature:

Ovviamente questa feaure avra’ delle user story al suo interno. Diciamo che vogliamo mettere roba nel cestino e svuotare il cestino quando necessario.

Queste sono Product Backlog Item, o Requirement a seconda del  Process Template che si utilizza. Sto usando MSF for CMMI, quindi sono requisiti – ora posso nuovamente cambiare il filtro per visualizzarli:

Ovviamente questi Requirement saranno suddivisi in una serie di Task, non ci sono differenze rispetto al passato. Ecco cosa vedo cambiando ancora il filtro:

Questa vista e’ esattamente quello che vogliamo ottenere. Ed e’ molto piu’ semplice da capire e visualizzare. piuttosto che usare altri strumenti magari in modo improprio.

Allarghiamo questo concetto: puo’ essere utile se si hanno diversi team Scrum a lavorare sullo stesso backlog? E se si hanno backlog differenti (anche se non si dovrebbe…) perche’ non unire tutto nello stesso backlog in questo modo? Era dura spiegare ad alcuni manager come il progetto sta progredendo in termini di feature e copertura del mercato. Ora non lo e’ usando il Work Item Type Feature come una astrazione sul lavoro che stanno svolgendo i team. Ed e’ out-of-the-box, il che non e’ mai male.

Come Brian ha detto, e’ solo l’inizio…c’e’ sicuramente molto ancora da aggiungere qui.

Non sono solo uno strumento di chat all’interno del team, le appena annunciate Team Room sono un ottimo tool per arricchire la comunicazione all’interno del team.

Possiamo innanzitutto configurarle per fornire comunicazioni broadcast per specifici eventi, come una build particolare o una specifica modifica nel codice.

Ma il meglio arriva con i due tag specifici per la collaborazione: @ e #.

Il tag @ serve per taggare un utente:   che sara’ poi notificato a riguardo.

il tag # invece serve per menzionare uno specifico work item.

Dopo aver cliccato sull’ hyperlink si aprira’ una nuova tab con il work item linkato.

Potra’ sembrare stupido e semplicistico, ma e’ davvero un ausilio utile ed aggiunge valore anche a quelle discussioni ‘informali’ che si trascinano via email, oltre al fatto che essendo salvate su TFS rappresentano informazioni utili al team recuperabili a piacimento.