Work Items: Gestion et relations
Création d’un work item
La gestion des work item s’effectue dans la console Team Explorer de Visual Studio ou depuis le site portail de projet.
Pour cet exemple, nous allons effectuer la création d’une nouvelle tâche depuis la vue Team Explorer de Visual Studio.
Connectez-vous à votre projet dans Team Explorer puis dérouler les sous-éléments du projet. Vous devriez voir un élément Work Item
Cliquez sur Add Work Item > Task
Saisissez ensuite les informations nécessaires puis cliquez sur Save Work Item.
Afficher et valider les Work Item
Une fois le Work Item créé, dans Team Explorer déroulez Work Items puis cliquez sur Open Work Items afin d’afficher tous les work items ouverts et de vérifier qu’aucun problème n’est survenu lors de la création.
Sélectionnez la tâche afin d’en visualiser les informations. De là vous pouvez changer l’état de la tâche, et faire remonter des informations pour les autres membres de l’équipe en fonction de son état d’avancement.
Relations entre les Work Items
La gestion des liens entre les work items est une des nouvelles fonctionnalités de Team Foundation Serveur 2010.
Le principe est de pouvoir reporter dans le système les relations de dépendances entre les éléments de travail. Ces liens peuvent être de type :
- Enfant <=> Parent
- Prédécesseur <=> Successeur
- Testé par <=> Test
- Lié
- Etapes partagées
- Scenario de test manuel (test case)
Ces relations sont mises en place grâce à l’onglet Links de chaque Work Item.
Nous allons mettre en œuvre ce principe afin de voir de quelle façon cela va changer notre approche dans la gestion de projet.
Lier des work items
Pour cet exemple je pars du principe que nous avons déjà plusieurs work item créés. Ici il s’agit de quelques tâches de développement et de tests qu’il est importants de lier à ces derniers.
Pour cet exemple je me base sur 2 tâches d’ajout de fonctionnalité au programme et 3 scénarios de test qui devront valider le bon fonctionnement de ces fonctionnalités.
Configuration des liens
Dans le Team explorer, éditez la première tâche. Ouvrez l’onglet Other Links puis cliquez sur Add (Link).
Sélectionnez le type de lien Successeur, puis saississez l’ID de la seconde tâche ou cliquez sur Browse si vous ne connaissez pas son ID.
Vous pouvez saisir un commentaire pour votre équipe si vous le souhaitez.
Validez l’ajout en cliquant sur OK puis sauvegardez le work item.
La tâche dispose maintenant d’un lien vers sa tâche successeur. La seconde tâche dispose quand à elle d’un lien prédécesseur vers la première :
Affichage des relations
Afin de bien tester les options d’affichage des liens entre work item, j’ai ajouté les relations suivantes :
- La seconde tâche est successeur de la première
- La première tâche est testée par le premier test
- Le second test fait parti des tests de la seconde tâche
- Le troisième test est lié au second
Par défaut, l’affichage « plat » proposé par la requête Open Work Items ne permet pas d’identifier les relations entre work item du premier coup d’œil.
Cependant, Team Foudation Server 2010 propose deux nouveaux modes d’affichage beaucoup plus pratiques pour la gestion des work items.
Pour modifier l’affichage afficher la requête puis cliquez sur Edit Query :
Dans la liste Type of query, vous pouvez changer le type d’affichage :
L’affichage par défaut est une liste plate de work item : 1 ligne par work item. Vous pouvez donc changer de type d’affichage et sauvegarder la requête afin de valider la modification.
Mode Work Item et Liens Directs
Cet affichage permet de liste sous chaque work item de la liste les liens qui lui sont associés. Cela est être très utile lorsque l’on souhaite connaitre tous les liens d’un ou plusieurs work item.
Mode Arbre de Work Items
Ce mode offre une vue d’ensemble des dépendances de types Parent <=> Enfant et Prédécesseur <=> Successeur sous forme d’un arbre.
Attention : les tests liés à des tâches ne sont pas inclus sous forme de branches mais listés à part.






















A noter que en réalité,je ne dissocierai pas le test de la tâche, tout simplement parce que le dévelopement agile ne permet pas de dissocier un test d’une tâche. Une fonctionalitée n’est finie qu’une fois que qu’elle est prête a être mise en production, ce qui signifie que les tests sont implémentés. Ceci devient encore plus pertinent si on applique Test Driven Development, puisqu’on est alors pas autorisé à écrire de code sans avoir ecrit un test auparavant.
Cela dit, super série d’articles qui décrivent parfaitement et en détails comment implémenter efficacement les méthodes agiles à l’aide de TFS
This article was helpful in a paper I am writing for my thesis.
Thanks
Bernice Franklin
UGG Boots
UGG Purses
Classic Tall Chestnut
Merci pour cette information interessante