TFS e Scrum - migliore configurazione pratica per Areas, iterazioni, backlog di iterazione, sprint iterazione

Question

Questa serie di domande cerca di suscitare una risposta migliore pratica su come configurare TFS 2012 Aree e iterazioni con Scrum 2.

Contesto: Stiamo usando team System dal TFS 2005 e aveva inizialmente creato un progetto di squadra per ogni prodotto che abbiamo e poi utilizzato MSF 4.2 template processo che alla fine abbiamo ottimizzato un po '(solo aggiunto alcuni campi ad alcuni tipi di elementi di lavoro).

Passare al giorno presente e ora eseguiamo TFS 2012 e VS 2012. Tenendo conto delle esperienze passate e del feedback della community, passeremo a un singolo progetto di team e Scrum 2.1 e quindi utilizzeremo le aree per separare prodotti e team. I seguenti link fanno buona lettura per questo approccio:

• http://blog.hinshelwood.com/when-should-i-use-areas-in-tfs-instead-of-team-projects-in-team-foundation-server-2010/
• TFS Areas, Optimal Definition and Configuration
• Team Foundation Server - Area/Iteration

Un layout tipico abbiamo intenzione di applicare per le aree sarebbe in questo senso:

-> Team Project (Area root) 
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) 
    |---> Product A 
    | |---> Feature Area 1 
    | |---> Feature Area 2 
    | |---> Feature Area 3 
    | 
    |---> Product B 
    | |---> Feature Area 1 
    | |---> Feature Area 2 
    | 
    | (ETC) 

|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) 
    |---> Product C 
    | |---> Feature Area 1 
    | |---> Feature Area 2 
    | 
    | (ETC) 

Concettualmente siamo abbastanza contenti sopra come è logico per il nostro ambiente. Secondo quanto sopra avremmo squadre come segue: * "Client A Team" * "B della squadra Client"

Domanda 1) Abbiamo pensato che, poiché le nostre squadre non sono così grandi e per rendere l'amministrazione più gestibile, che non volevamo definire team per prodotto poiché fisicamente abbiamo team per cliente e controllano tutti i prodotti per quel cliente. È un errore o è OK?

Domanda 2) Supponendo che la suddetta configurazione del team sia OK, abbiamo quindi corretto "mappare" ciascuna delle aree sopra ad ogni squadra, ad es. Per il team "Cliente A" specificare l'area "Cliente A" (e tutte le sottozone) come le aree di proprietà di quella squadra. Per quanto riguarda l'area predefinita, è possibile impostare la radice dell'area "Cliente A" come predefinita per il team?

Per quanto riguarda il layout di iterazioni abbiamo in programma per qualcosa di simile, come questo:

-> Team Project (iteration root) 
|--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) 
    |---> Product A 
    | |---> Release 1 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | | |---> Sprint 3 
    | | 
    | |---> Release 2 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | | |---> Sprint 3 
    | | 
    | |---> Release 3 
    | 
    |---> Product B 
    | |---> Release 1 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | | 
    | |---> Release 2 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | 
    | (ETC) 

|--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) 
    |---> Product C 
    | |---> Release 1 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | | 
    | |---> Release 2 
    | | |---> Sprint 1 
    | | |---> Sprint 2 
    | 
    | (ETC) 

Domanda 3) Questo sembra essere più complicato per ottenere le iterazioni diritto, soprattutto quando si tratta di TFS che mostra l'arretrato . In particolare, per l'installazione di Iterazione di TFS Scrum 2, sembra che dovrei selezionare (casella di controllo) solo le iterazioni a livello foglia che sono per la pianificazione e lo sviluppo successivo. Quindi, estendendo l'esempio precedente, potremmo avere la "Client A Team" che sarà disponibile per iniziare a lavorare su un nuovo prodotto B per le prossime 4 settimane (ipotizziamo uno sprint di 2 settimane). Sarebbe quindi solo selezionare (casella di controllo) "Sprint 1" e "Sprint 2" dalla versione 1? Sto capendo/usandolo correttamente?

Domanda 4) squadra Backlog Iterazione selezione - Questo potrebbe essere problematico a causa della nostra idea di squadre per cliente e non le squadre per prodotto, ma forse ho solo capire sbagliato. Nella configurazione delle aree TFS, si specifica quale iterazione è "l'iterazione del backlog per il team".Il mio problema è che il nostro PBI (Product Backlog Items) sarà specifico del prodotto e non si desidera mescolarli con PBI di un altro prodotto. Quindi quello che non riesco ancora a capire è quale sarà l'impatto se selezioniamo l'area "Client A" come "L'iterazione del backlog per il team" anziché "Prodotto B". Penso che mi sto confondendo qui - quale sarebbe una scelta sensata?

Le domande di cui sopra sono la mia mancanza di comprensione dell'impatto che queste selezioni per iterazioni, aree, iterazioni del backlog del team e aree predefinite avranno per ogni team TFS 2012 definito. Alcuni problemi che ho riscontrato con questa configurazione sono per TFS per identificare correttamente il backlog del prodotto e il backlog dello sprint per un team.

Non so se un progetto di team e più aree per prodotti (come generalmente consigliato) complicano il problema.

Domanda 5) sito TFS Web Access - Per ogni squadra sotto "Lavoro | elementi di lavoro | Shared query" non c'è query predefinite in una cartella chiamata "Sprint corrente" (bloccati compiti; Sprint Backlog, ecc), ma sembra che queste query siano codificate su "Root Project \ Release 1 \ Sprint 1" - non dovrebbero scoprire automaticamente qual è lo sprint corrente date le date definite rispetto alle iterazioni? In caso contrario, qual è la migliore pratica per mantenere queste domande?

Conoscete alcuni corsi/esercitazioni specifici di qualità TFS 2012 e Scrum 2 che potrebbero aiutare a rispondere a queste domande o fornire indicazioni per una corretta installazione di TFS Scrum 2?

Answer 1

Spero che tu abbia trovato utile il mio post e ti consiglierei anche di dare un'occhiata a One Team Project to rule them all e TFS vNext: Configuring your project to have a master backlog and sub-teams.

Ecco il mio meglio per rispondere alle vostre domande:

Domanda 1) Abbiamo pensato che, poiché le nostre squadre non sono così grandi e per rendere l'amministrazione più gestibile, che non volevamo definire team per prodotto poiché fisicamente disponiamo di team per cliente e controllano tutti i prodotti per quel cliente. È un errore o è OK?

Questo è proprio bene e vi permetterà di crescere come le tue squadre fanno. Se i membri del tuo team lavorano su più client, potresti individuare problemi di priorità e di cambio di contesto che puoi ridurre spingendo il tuo team di un livello, o un unico backlog unificato e gruppi secondari separati ma concentrandoti sul lavoro del cliente e non sul lavoro del prodotto. Consiglierei davvero questo approccio per il layout che hai.

Domanda 2) Partendo dal presupposto che la configurazione di squadra di cui sopra è OK, siamo quindi corretto "mappa" ciascuna delle aree di cui sopra per ciascun cioè team In squadra "Client A Team" specificare zona "Client A" (e tutte le sotto-aree) come le aree di proprietà di quella squadra. Per quanto riguarda l'area predefinita, è possibile impostare la radice dell'area "Cliente A" come predefinita per il team?

Questo è davvero corretto e dovrebbe portare a tutti i tuoi elementi di lavoro in fase di creazione, quando quella squadra viene selezionato con i valori di default. Molte organizzazioni creano anche un backlog principale o principale in cui gli articoli misc vengono creati, ordinati e quindi suddivisi nel backlog del team appropriato come Greg Boer, proprietario del prodotto per gli strumenti di pianificazione Agile TFS scritti nel suo post TFS vNext: Configuring your project to have a master backlog and sub-teams.

Il layout per le iterazioni è davvero bello fino a quando i team non superano il confine tra i clienti o inizieranno a entrare in aree di mappatura difficili e iterazioni ai team. Se si pensa che potrebbe essere necessario avere un unico team o di un gruppo di squadre mappare a più di un cliente, allora potrebbe essere necessario qualcosa di più simile a:

-> Team Project (Iteration root) 
|—> Team Boundary (This could be one or more teams) 
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) 
     |---> Product A 
     | |---> Release 1 
     | |---> Release 2 
     | |---> Release 3 
     | 
     |---> Product B 
     | |---> Release 1 
     | |---> Release 2 
     | 
     | (ETC) 

    |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B) 
     |---> Product C 
     | |---> Release 1 
     | |---> Release 2 
     | 
     | (ETC) 

Mentre ancora non dinamica ciò consentirebbe tale scenario. Tuttavia conserverei comunque la mia struttura di controllo del codice $ \ TeamProject \ Client A \ ProductA e non la filtrerò. È semplicemente una compartimentazione del processo di pianificazione e non dovrebbe necessariamente riversarsi nelle altre parti della soluzione ALM.

Domanda 3) Questo sembra essere più complicato per ottenere le iterazioni diritto, soprattutto quando si tratta di TFS che mostra l'arretrato. In particolare, per l'installazione di Iterazione di TFS Scrum 2, sembra che dovrei selezionare (casella di controllo) solo le iterazioni a livello foglia che sono per la pianificazione e lo sviluppo successivo. Quindi, estendendo l'esempio precedente, potremmo avere la "Client A Team" che sarà disponibile per iniziare a lavorare su un nuovo prodotto B per le prossime 4 settimane (ipotizziamo uno sprint di 2 settimane). Dovremmo quindi selezionare solo (casella di controllo) "Sprint 1" e "Sprint 2" dalla versione 1? Sto capendo/usandolo correttamente?

Tu sei, ma che cercate a 3 Sprint fuori per avere un portafoglio perseguibile come parte del processo di Scrum. Ti consiglio di numerare sequenzialmente i tuoi sprint consecutivamente in modo che nell'interfaccia utente non ti confonderai su Sprint 2 quando spunti anche lo Sprint 4 se è chiamato Sprint 1. È anche bello tenere un conto del livello di esperienza del team attuale .

-> Team Project (Iteration root) 
|—> Team Boundary (This could be one or more teams) 
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A) 
     |---> Product A 
     | |---> Release 1 
     | | |---> Sprint 1 
     | | |---> Sprint 2 
     | | |---> Sprint 3 
     | |---> Release 2 
     | | |---> Sprint 4 
     | | |---> Sprint 5 
     | | |---> Sprint 6 
     | |---> Release 3 
     | | |---> Sprint 7 
     | | |---> Sprint 8 
     | | |---> Sprint 9 
     | 
     | (ETC) 

Ma si sono fondamentalmente corretta sul processo tecnico coinvolta e il risultato si raggiungerà.

Domanda 4) della squadra Backlog Iterazione selezione - Questo potrebbe essere problematico a causa della nostra idea di squadre per cliente e non le squadre per prodotto, ma forse ho solo capire sbagliato. Nell'installazione di TFS Areas, si specifica quale iterazione "l'iterazione del backlog per il team". Il mio problema è che il nostro PBI (Product Backlog Items) sarà specifico del prodotto e non si desidera mescolarli con PBI di un altro prodotto. Quindi quello che non riesco ancora a capire è quale sarà l'impatto se selezioniamo l'area "Client A" come "L'iterazione del backlog per il team" anziché "Prodotto B". Penso che mi sto confondendo qui - quale sarebbe una scelta sensata?

Non stai confondendo se stessi e la persona che entra qualcosa in arretrato della squadra sarà necessario modificare il valore predefinito di essere l'iterazione/area del prodotto che vogliono il cambiamento. Almeno per default stai ottenendo la squadra corretta e questa dovrebbe essere una cosa facile per la persona che entra nell'oggetto, il proprietario del prodotto o un membro del team per classificarlo correttamente.

Tutto ciò che si trova sotto l'area specificata come Team Default è di default incluso negli articoli che vedi. Puoi "fare clic con il pulsante destro" sull'area predefinita per un team e deselezionare "Includi aree secondarie" in modo da visualizzare solo il livello superiore e questa è la tecnica utilizzata per il Backlog del padrone di Greg. Ti suggerirei comunque di voler mantenere un'impostazione di "Includi aree secondarie" per visibilità e trasparenza all'interno del tuo team.

Non so se abbia un singolo progetto di squadra e più aree per i prodotti (come è generalmente consigliato) complica la questione.

Può. Alcune organizzazioni preferiscono aggiungere un elenco a discesa per "Team" ai propri elementi di lavoro (come il modello Conchango/EMC) e utilizzarlo come designazione del team che può essere configurata come predefinita nella configurazione di Agile Planning Tools. In questo modo non hai bisogno di una designazione Team in Area o Iteration se ti stai battendo contro. Non ho alcuna raccomandazione in entrambi i casi senza ulteriori informazioni su come è configurata la tua organizzazione.

Domanda 5) TFS Web Access sito - Per ogni squadra sotto "Lavoro | elementi di lavoro | Shared query" non c'è query predefinite in una cartella chiamata "Sprint corrente" (Blocked compiti; Sprint Backlog; ecc), ma sembra che queste query siano codificate su "Root Project \ Release 1 \ Sprint 1" - non dovrebbero scoprire automaticamente qual è lo sprint corrente date le date definite rispetto alle iterazioni? In caso contrario, qual è la migliore pratica per mantenere queste domande?

Opzione 1: ogni sprint spendere i 2 minuti che ci vuole per cambiare le query

Opzione 2: Creare uno strumento per farlo per voi

Opzione 3: hanno un ulteriore corrente” "Nodo di iterazione all'interno della Release e sposta l'iterazione attualmente attiva al di sotto di quel nodo. Quindi imposta le query in modo che puntino su "Sotto" che "Cliente A \ Prodotto A \ Versione 1 \ Attuale". Quindi è più veloce cambiare l'iterazione annidata una volta e tutte le query funzionano. Devi solo cambiare la corrente, ma una volta per versione.

Sai di qualche TFS qualità 2012 e Scrum 2 specifici di formazione/tutorial che potrebbero aiutare a rispondere a queste domande, o dare alcune linee guida per una corretta messa a punto Scrum 2 TFS?

mi sento di raccomandare la formazione Professional Developer Scrum da Scrum.org o/e coinvolgente con un consulente ALM.

Answer 2

correlati a questa domanda e tutte le cose per quanto riguarda TFS strutturazione, i progetti e le squadre, @MrHinsh ha il seguente post sul blog utilizzando TFS Squadre senza loro assegnazione a una zona. Non è senza cautela però.

Più sopra al suo blog: http://nakedalm.com/team-foundation-server-2012-teams-without-areas/