TFS et Scrum - Configuration des meilleures pratiques pour les zones, les itérations, l'itération de backlog, l'itération de sprint

Question

Cet ensemble de questions tente d'obtenir une réponse aux meilleures pratiques sur la façon de configurer les zones et les itérations de TFS 2012 avec Scrum 2.

Contexte: Nous utilisons Team System depuis TFS 2005 et avions initialement créé un projet d'équipe pour chaque produit que nous avions, puis utilisé MSF 4.2 modèle de processus que nous avons finalement légèrement modifié (seulement quelques champs ont été ajoutés à certains types d'éléments de travail).

Passez à aujourd'hui et nous exécutons maintenant TFS 2012 et VS 2012. En tenant compte des expériences passées et des commentaires de la communauté, nous passerons à un seul projet d'équipe et Scrum 2.1, puis utiliserons les zones pour séparer les produits et les équipes. Les liens suivants permettent une bonne lecture de cette approche:

Une disposition typique que nous prévoyons d'appliquer pour les zones serait le long de ces lignes:

-> 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)

Sur le plan conceptuel, nous sommes assez satisfaits de ce qui précède, car il est logique pour notre environnement. Selon ce qui précède, nous aurions les équipes suivantes: * "Équipe client A" * "Équipe client B"

Question 1) Nous avons pensé que parce que nos équipes ne sont pas si grandes et pour rendre l'administration plus gérable, nous ne voulions pas définir d'équipes par produit car nous avons physiquement des équipes par client et ils supervisent tous les produits pour ce client. Est-ce une erreur ou est-ce OK?

Question 2) En supposant que la configuration de l'équipe ci-dessus est OK, est-il alors correct de "mapper" chacune des zones ci-dessus à chaque équipe, c'est-à-dire pour l'équipe " Client A Team "spécifiez la zone" Client A "(et toutes les sous-zones) comme zones appartenant à cette équipe. Qu'en est-il de la zone par défaut, est-il correct de définir la racine de la zone "Client A" comme valeur par défaut pour l'équipe?

En ce qui concerne la disposition des itérations, nous prévoyons quelque chose de similaire, comme ceci:

-> 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)

Question 3) Cela semble plus délicat pour obtenir les bonnes itérations, surtout quand il s'agit de TFS montrant le backlog. Plus précisément, pour la configuration de l'itération TFS Scrum 2, il semble que je ne devrais sélectionner (case à cocher) que les itérations de niveau feuille qui sont destinées à la planification et au développement ultérieur. Ainsi, en étendant l'exemple ci-dessus, nous pourrions avoir la possibilité que "l'équipe du client A" soit disponible pour commencer à travailler sur un nouveau produit B pendant les 4 prochaines semaines (en supposant des sprints de 2 semaines). Serions-nous alors seulement sélectionner (case à cocher) "Sprint 1" et "Sprint 2" dans la version 1? Est-ce que je le comprends/l'utilise correctement?

Question 4) Sélection de l'itération du backlog d'équipe - Cela peut être problématique en raison de notre concept d'avoir des équipes par client et non des équipes par produit, mais peut-être que je comprends simplement c'est faux. Dans la configuration des zones TFS, vous spécifiez quelle itération est "l'itération du backlog pour l'équipe". Mon problème est que nos PBI (articles de backlog de produit) seront spécifiques au produit et ne souhaitent pas les mélanger avec les PBI d'un autre produit. Donc, ce que je ne peux pas encore comprendre, c'est quel sera l'impact si nous sélectionnons la zone "Client A" comme "Itération de backlog pour l'équipe" au lieu peut-être de "Produit B". Je pense que je m'embrouille ici - quel serait un choix judicieux?

Les questions ci-dessus découlent de mon manque de compréhension de l'impact que ces sélections pour les itérations, les zones, les itérations d'arriéré d'équipe et les zones par défaut auront pour chaque équipe TFS 2012 définie. Certains problèmes que je rencontre avec cette configuration sont que TFS identifie correctement le backlog de produit et le backlog de sprint pour une équipe.

Je ne sais pas si avoir un projet d'équipe et plusieurs domaines pour les produits (comme cela est généralement recommandé) complique le problème.

Question 5) Site Web TFS Web Access - Pour une équipe donnée sous "WORK | work items | Shared Queries", il y a des requêtes prédéfinies sous un dossier appelé "Current" Sprint "(Tâches bloquées; Sprint Backlog; etc.), mais il semble que ces requêtes soient codées en dur contre" Root Project\Release 1\Sprint 1 "- ne devraient-elles pas découvrir automatiquement quel est le sprint actuel compte tenu des dates définies par rapport aux itérations? Sinon, quelle est la meilleure pratique pour gérer ces requêtes?

Connaissez-vous des formations/tutoriels spécifiques à TFS 2012 et Scrum 2 de qualité qui pourraient aider à répondre à ces questions, ou donner des conseils pour une configuration réussie de Scrum 2 TFS?

MrHinsh - Martin Hinshelwood · Accepted Answer

J'espère que vous avez trouvé l'utilisation de mon message, et je vous recommanderais également de consulter One Team Project pour les gouverner tous et TFS vNext: Configurer votre projet pour avoir un backlog principal et sous-équipes .

Voici mes meilleurs efforts pour répondre à vos questions:

Question 1) Nous avons pensé que parce que nos équipes ne sont pas si grandes et pour rendre l'administration plus gérable, nous ne voulions pas définir d'équipes par produit car nous avons physiquement des équipes par client et ils supervisent tous les produits pour ce client. Est-ce une erreur ou est-ce OK?

C'est très bien et cela vous permettra de grandir comme le font vos équipes. Si les membres de votre équipe travaillent sur plusieurs clients, vous pouvez rencontrer des problèmes de priorisation et de changement de contexte que vous pouvez minimiser en poussant votre équipe à un niveau supérieur, ou en ayant un seul carnet de commandes unifié et des sous-équipes distinctes, mais en se concentrant toujours sur le travail client et non sur le travail produit. Je recommanderais en effet cette approche pour la mise en page que vous avez.

Question 2) En supposant que la configuration de l'équipe ci-dessus est OK, est-il alors correct de "mapper" chacune des zones ci-dessus à chaque équipe, c'est-à-dire pour l'équipe "Client A Team", spécifiez la zone "Client A" (et toutes les sous-zones) comme les zones appartenant à cette équipe. Qu'en est-il de la zone par défaut, est-il correct de définir la racine de la zone "Client A" comme valeur par défaut pour l'équipe?

C'est en effet correct et devrait entraîner la création de tous vos éléments de travail lorsque cette équipe est sélectionnée avec ces valeurs par défaut. De nombreuses organisations créent également un backlog parent ou maître dans lequel divers éléments sont créés, commandés puis divisés dans le backlog d'équipe approprié, comme l'a expliqué Greg Boer, chef de produit pour les outils de planification agile TFS dans son article TFS vNext: Configuring votre projet pour avoir un backlog maître et des sous-équipes .

Votre mise en page pour les itérations semble en effet bonne tant que vos équipes ne franchissent pas la frontière entre les clients ou que vous commencerez à mapper difficilement les zones et les itérations aux équipes. Si vous pensez que vous devrez peut-être faire correspondre une seule équipe ou un seul groupe d'équipes à plusieurs clients, vous aurez peut-être besoin de quelque chose de plus comme:

-> 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)

Bien qu'il ne soit pas encore dynamique, cela permettrait ce scénario. Je conserverais cependant ma structure de contrôle de source $\TeamProject\Client A\ProductA et ne filtrerais pas cela. Il s'agit simplement d'une compartimentation du processus de planification et ne devrait pas nécessairement déborder dans les autres parties de votre solution ALM.

Question 3) Cela semble plus délicat pour obtenir les bonnes itérations, surtout quand il s'agit de TFS montrant l'arriéré. Plus précisément, pour la configuration d'itération de TFS Scrum 2, il semble que je ne devrais sélectionner (case à cocher) que les itérations de niveau feuille qui sont destinées à la planification et au développement ultérieur. Ainsi, en étendant l'exemple ci-dessus, nous pourrions avoir la possibilité que "l'équipe du client A" soit disponible pour commencer à travailler sur un nouveau produit B pendant les 4 prochaines semaines (en supposant des sprints de 2 semaines). Serions-nous alors seulement sélectionner (case à cocher) "Sprint 1" et "Sprint 2" de la version 1? Suis-je en train de le comprendre/de l'utiliser correctement?

Vous l'êtes, mais vous cherchez vraiment à avoir 3 Sprints pour avoir un backlog exploitable dans le cadre du processus Scrum. Je recommanderais de numéroter séquentiellement vos sprints consécutivement afin que dans l'interface utilisateur vous ne vous trompiez pas sur Sprint 2 lorsque vous cochez également Sprint 4 s'il s'appelle Sprint 1. Il est également agréable de garder un décompte du niveau d'expérience de l'équipe actuelle .

-> 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)

Mais vous êtes fondamentalement correct sur le processus technique impliqué et le résultat qu'il obtiendra.

Question 4) Sélection de l'itération du backlog d'équipe - Cela peut être problématique en raison de notre concept d'avoir des équipes par client et non des équipes par produit, mais peut-être que je comprends mal. Dans la configuration des zones TFS, vous spécifiez les itérations de l'itération "Backlog pour l'équipe". Mon problème est que nos PBI (articles de backlog de produit) seront spécifiques au produit et ne souhaitent pas les mélanger avec les PBI d'un autre produit. Donc, ce que je ne peux pas encore comprendre, c'est quel sera l'impact si nous sélectionnons la zone "Client A" comme "Itération de backlog pour l'équipe" au lieu peut-être de "Produit B". Je pense que je m'embrouille ici - quel serait un choix judicieux?

Vous ne vous embrouillez pas et la personne entrant quelque chose dans le carnet de commandes de l'équipe devra changer la valeur par défaut pour être l'itération/la zone du produit dans laquelle ils souhaitent le changement. Au moins par défaut, vous obtenez la bonne équipe et cela devrait être une chose facile pour la personne qui entre l'article, le propriétaire du produit ou un membre de l'équipe pour classer cela correctement.

Tout ce qui se trouve sous la zone que vous spécifiez comme équipe par défaut est par défaut inclus dans les éléments que vous voyez. Vous pouvez "cliquer avec le bouton droit" sur votre zone par défaut pour une équipe et désélectionner "Inclure les sous-zones" afin que vous ne voyiez que le niveau supérieur et c'est la technique utilisée pour le carnet de commandes principal de Greg. Je suggère toutefois que vous souhaitiez conserver un paramètre "Inclure les sous-zones" pour la visibilité et la transparence au sein de votre équipe.

Je ne sais pas si avoir un projet d'équipe et plusieurs domaines pour les produits (comme cela est généralement recommandé) complique le problème.

Ça peut. Certaines organisations préfèrent ajouter une liste déroulante pour "Équipe" à leurs éléments de travail (comme le modèle Conchango/EMC) et l'utiliser comme désignation d'équipe qui peut être configurée par défaut dans la configuration des outils de planification Agile. De cette façon, vous n'avez pas besoin d'une désignation d'équipe dans la zone ou l'itération si vous vous heurtez à cela. Je n'ai aucune recommandation de toute façon sans plus d'informations sur la configuration de votre organisation.

Question 5) Site Web TFS Web Access - Pour une équipe donnée sous "WORK | work items | Shared Queries" il y a des requêtes prédéfinies sous un dossier appelé "Current Sprint" (Tâches bloquées; Sprint Backlog; etc), mais il semble que ces requêtes sont codés en dur avec "Root Project\Release 1\Sprint 1" - ceux-ci ne devraient-ils pas découvrir automatiquement quel est le sprint actuel étant donné les dates définies par rapport aux itérations? Sinon, quelle est la meilleure pratique pour gérer ces requêtes?

Option 1: chaque sprint passe les 2 minutes nécessaires pour modifier les requêtes

Option 2: Créez un outil pour le faire pour vous

Option 3: avoir un nœud d'itération "actuel" supplémentaire dans votre version et déplacer l'itération actuellement active en dessous de ce nœud. Ensuite, définissez les requêtes pour pointer sur "Sous" que "Client A\Produit A\Version 1\Actuel". Il est ensuite plus rapide de modifier une fois l'itération imbriquée et toutes les requêtes fonctionnent. Il vous suffit alors de modifier le courant mais une fois par version.

Connaissez-vous des formations/tutoriels spécifiques à TFS 2012 et Scrum 2 de qualité qui pourraient aider à répondre à ces questions, ou donner des conseils pour une configuration réussie de Scrum 2 TFS?

Je recommanderais la formation de développeur professionnel Scrum de Scrum.org ou/et engager avec un consultant ALM.

Jaans · Answer

En rapport avec cette question et tout ce qui concerne la structure, les projets et les équipes TFS, @MrHinsh a le billet de blog suivant sur l'utilisation des équipes TFS sans les allouer à une zone . Mais ce n'est pas sans prudence.

Plus sur son blog: http://nakedalm.com/team-foundation-server-2012-teams-without-areas/