Scrum, XP et TFS 2010

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.

Les Work Item sont les éléments de bases du travail en équipe sur Team Foundation server.

Ce sont des éléments de travail que l’on utilisera afin de guider le travail des membres de l’équipe en leur attribuant des tâches et en effectuant un suivi précis de celles-ci.

Les Différents Types de Work Items

Bug

Utilisé lorsqu’un bug est identifié, la tâche décris la manière de reproduire le bug, le comportement actuel ainsi que le résultat attendu.

Exemple : Le bouton de validation reste inactif même si tous les champs sont remplis.

Issue

Utilisé pour demander une modification d’un élément déjà existant exemple

Exemple : Changer le lien hypertexte vers l’aide par un bouton

Shared Steps

Les étapes partagées sont des tâches récurrentes des tests manuel qui seront donc réutilisées à chaque fois que l’on en a besoin afin d’éviter de recréer un nouvel item à chaque fois.

1. saisir le login
2. saisir le mot de passe
3. cliquer sur « connecter »

Task

Une tâche est typiquement une nouvelle fonctionnalité à implémenter

Exemple : Ajouter un champ pour une adresse e-mail de secours

Test Case

Les tests cases sont des scénarios de test manuel c’est à dire qui ne seront pas effectuer grâce à du code mais par un testeur qui effectuera les opérations demandées manuellement et effectuera un retour sur le résultat obtenu.

Exemple :

1. se connecter
2. aller sur « mon profil »
3. cliquer sur « parrainage »
4. entrez une adresse email de test
5. cliquez sur envoyer l’invitation

User Story

Les user story sont également des scenarios de tests manuels mais beaucoup moins détaillés que les tests cases. Il s’agit uniquement de décrire en language usuel la fonctionnalité que l’on souhaite tester et le résultat attendu et ceci en une à deux phrases maximum. Il s’agit d’un concept phare de la méthode agile extreme programming. On peut lier des tests cases à une user story afin de détailler les étapes.

Exemple : les clients peuvent inviter un ami par mail.

Les paramètres des Work Items

Tableau récapitulatif

Détail des paramètres

Status

• Title : titre du work item
• Assigned to : utilisateur qui devra réaliser la tâche
• State : état de réalisation de la tâche
• Area : partie du projet concernée par la tâche
• Iteration : iteration à laquelle la tâche doit être réalisée
• Reason : raison(s) de l’existence de cette tâche
• Activity :
• Automation Status : automatiser l’exécution

Planning

• Stack Rank : rang dans l’ordre de realisation des tâches
• Priority : degré d’urgence de la réalisation
• Story points : Nombre d’étapes dans le scenario de test
• Risk : degré de risqué d’échec estimé
• Severity : degré d’importance de la tâche
• Due Date : date de realisation prévue

Effort

• Original Estimate : estimation du temps nécessaire
• Remaining : estimation du temps restant avant réalisation
• Completed : temps de travail déjà effectué

Autres

• Description : description du work item
• History : raisons pour laquelle le work item à été créé
• Steps to Reproduce : étapes à reproduire dans le work item
• Links : lier des éléments au work item (work item, lien…)
• File Attachement : lier  des fichiers (image, fichier texte…)
• System Infos : état du system au moment du test
• Test Cases : tests manuels pour tester la correction du bug
• Steps : étapes de la tâche partagée
• Implementation : lier des tâches parentes et enfants
• Tested Work Item : lier des tests préalables
• Associated Automation : associer un test automatisé