Precedenti post della serie

Organizzare I Team Project del proprio TFS
Configurazione di Un Team Project per piu Teams con Backlog Multipli.

In questo post verrà mostrato come configurare un Team Project per avere più team multipli che lavorano su uno stesso Backlog, situazione molto comune nei team agili. In questo caso bisogna utilizzare un semplice “trucco” affinché TFS possa gestire Sprint Backlog distinti. La configurazione è molto simile a quella mostrata precedentemente per la configurazione di un Team Project con Backlog Distinti. Vediamo quindi come si configura il tutto.

La prima differenza è nella gestione delle aree, di base quello che viene fatto è creare un’area di base (in questo esempio chiamata Common) e procedere poi alla creazione dei due Team specificando però di non creare automaticamente un’area associata. Una volta creati si procederà alla creazione manuale di un’area distinta per ogni come sottoarea della Common. Per entrambi i team l’area base verrà configurata come sorgente del Backlog.

In questo modo entrambi i team vedranno nel backlog tutti gli elementi facenti parte dell’area Common e delle sue aree figlie, ottenendo quindi il risultato voluto: Avere un unico Backlog per più team distinti.

Quando si tratta invece di andare a configurare le iterazioni la situazione è leggermente differente. Durante uno sprint planning o in generale durante la pianificazione della prossima iterazione, si deve decidere quali elementi del Backlog faranno parte dell’iterazione, ma molto spesso si vuole anche assegnare questi PBI ad un team oppure ad un altro. In generale possiamo avere due casi

Caso 1: Lo sprint Backlog è comune tra i due team. Questo significa che quando si è raggiunto un accordo sui PBI da risolvere nella successiva iterazione, entrambi i team iniziano a lavorare sullo stesso set di PBI. Questo caso è piuttosto anomalo, perché di fatto è come lavorare con un unico Team. In questo caso si può tranquillamente creare l’albero delle iterazioni con gli sprint e usare la stessa configurazione per entrambi i team.

Caso 2: Ogni team ha il suo Sprint Backlog. Questa è la soluzione più standard, in questo modo ogni team ha il suo insieme di PBI su cui lavorare nella prossima iterazione. In questo caso è necessario in TFS procedere alla creazione di un albero distinto di iterazioni per ogni team, come mostrato in figura.

Qui viene rappresentata la configurazione per i TeamA, ma si può notare come è presente anche un albero di iterazioni chiamato CommonB i cui figli sono sprint con lo stesso nome e le stesse date, per il TeamB. Il Team B avrà chiaramente flaggati gli sprint figli di CommonB.

In questo modo, quando si effettua la pianificazione, si può aprire in due pagine distinte del browser la gestione del Backlog di entrambi i team.

Le due visioni sono sovrapposte nella figura sopra e si può facilmente notare come entrambi i team vedono esattamente lo stesso Backlog. Ora supponiamo che il TeamA si prenda carico della UserStory 1 ed il TeamB si prenda carico della User Story 2. Per fare questo ogni team trascina la User Story che vuole assegnarsi nello sprint corrente (Sprint 3) con il classico Drag And Drop.

Sebbene visivamente l’operazione per entrambi i team sia identica, il link Sprint 3 che è rappresentato nelle due visualizzazioni non è lo stesso. Per il Team A è CommonA/Sprint3 mentre per il TeamB è CommonB/Sprint3. In questo modo cliccando sul link ed andando a visualizzare il proprio Sprint Backlog ogni team vede solamente i PBI di cui si è fatto carico.

Come si può vedere dalla figura sopra, ogni Team vede le proprie User Story nel proprio Sprint Backlog.

Gian Maria