Nouvelles fonctionnalités des Work Items dans la CTP d’Octobre de Visual Studio 2010

 

Article écrit le 20 février 2009 par Loïc Baumann, Ingénieur Consultant pour Winwise

 

 

Visual Studio 2010 

 

 

 

Sommaire

 

NB : Cet article a été écrit à partir de la Community Technology Preview (CTP) d’Octobre 2008 de Visual Studio 2010.

1. Introduction

Cet article va vous faire découvrir les nouvelles fonctionnalités des Work Items (éléments de travail) de Visual Studio 2010 Team Foundation Server dans sa version CTP d’Octobre 2008.

Une CTP est une version non installable du produit disponible avant les bêtas. Elle permet d’évaluer les fonctionnalités et de donner un retour à l’équipe produit et d’anticiper les changements des prochaines versions.

Si la partie gestion de configuration est la première raison pour laquelle beaucoup d’entreprises font le saut vers Team Foundation Server, les Work Items constituent une sacrée cerise sur le gâteau de l’offre ALM de Microsoft.

Véritables éléments centraux au sein de la suite logicielle, les Work Items permettent aux équipes de partager les données relatives au bon développement de leurs projets.

Là où avant il était nécessaire de cumuler les logiciels et souvent dupliquer les données, les Work Items nous offrent enfin le luxe (pourtant nécessaire) de permettre aux différents protagonistes de l’équipe de travailler avec le même référentiel de données projets, simplifiant et fluidifiant la communication et intégrant une traçabilité à toute épreuve.

 

 

2. Utilisation des Work Item avec TFS 2008

De nos jours les projets hébergés avec TFS 2008 n’utilisent pas les Work Items pour stocker l’intégralité de leurs données. Ceci est généralement dû au fait que les Work Items sont limités techniquement pour pouvoir y parvenir ou que l’équipe a déjà une solution (partiellement) équivalente et ne souhaite pas évoluer vers du « tout Work Item ».

Pour ces raisons ils sont la plupart du temps utilisés pour une partie limitée du processus de développement, essayant de coexister avec des solutions déjà en place.

Avec TFS 2005 et 2008, j’ai personnellement toujours recommandé d’utiliser les Work Items lorsque les besoins suivants sont rencontrés :

  • Besoin d’un cycle de vie (« workflow »), impliquant potentiellement plusieurs personnes.
  • Besoin de traçabilité de l’information.
  • Besoin d’un lien avec le code qui est produit.

Concrètement, les scénarii les plus employés sont :

A)     Développement d’une tâche, avec une revue de code optionnelle.

B)     Gestion des défauts et du changement.

C)     Prise en considération des risques et de critères de qualité de service.

En fonction des équipes et des projets ces différents scénarii étaient utilisés et modifiés pour prendre en charge plus ou moins de choses.

Par exemple le type « Task » pouvait ou non prendre en charge le triage, la répartition du travail, la planification, le réalisé, etc.

Bien sûr, j’aurais aimé pouvoir utiliser les Work Items pour tout stocker, partant du principe que ça aurait pu être une bonne chose d’avoir une relation et une traçabilité complète entre Expression de Besoin, Spécification Technique, Conception, Développement, Revue de Code, Tests et bien sur le Code lui-même !

Par exemple, gérer les Exigences à l’aide de documents Word ne vous permettra pas d’avoir des matrices de traçabilité, une gestion fine de l’historique et l’information ne sera pas stockée dans un dépôt générique (les Work Items par exemple !). Les changements nécessitent des actions humaines pour mettre à jour les éléments adjacents, tout ceci est source d’erreur, prend du temps, bref ce n’est pas l’idéal !

Dans la suite de cet article nous allons voir si les nouvelles fonctionnalités liées aux Work Items résolvent certains problèmes que nous avions et poussent le concept plus loin encore.

 

 

3. Forces et faiblesses des Work Items

L’implémentation des Work Items dans les versions actuelles de Team System est déjà bonne, mais il y a toujours de place pour des améliorations.

Voici un bref récapitulatif des forces et faiblesses dans leur état actuel :

Forces

  • Intégré à l’environnement de développement et accessible à partir d’un client léger : développeurs, chefs de projet et parties prenantes ont tous un accès.
  • Peut être lié au code produit : le code n’est plus le seul référentiel ou point d’entrée pour initier un changement ou un correctif.
  • Hautement extensible et personnalisable : les Work Items s’adaptent à votre méthodologie et non l’inverse !
  • « User friendly » : c’est toujours un plus pour une meilleure adoption de la solution car la courbe d’apprentissage est très courte.
  • Traçabilité : tous les changements sont mis en version, idéal pour les adeptes de CMMI par exemple.
  • Workflow intégré : simple et efficace, mais Word ne propose pas ce genre de chose par exemple.

Faiblesses

  • Le system de liaisons entre Work Items est trop limité : on peut uniquement lier deux Work Items que de manière bidirectionnelle et sans gestion de version possible.
  • Pas d’intégration possible nativement avec MS Project Serveur.
  • L’édition est trop limitée pour y stocker des informations complexes.
  • Le système de requête est bon, mais c’est difficile d’avoir une bonne visibilité lorsque l’on a beaucoup de Work Items.

Ces faiblesses nous empêchent de gérer les Exigences de manière fine par exemple.

Le retour d’expérience que j’ai eu de la part des chefs de projet a souvent été positif concernant les Work Items lorsque l’on les considère unitairement, mais qu’il devenait difficile d’obtenir une vue globale de l’état du projet et enfin qu’il était coûteux de maintenir tout ceci synchronisé.

Concrètement : « un par un c’est super, mais dès que l’on doit en gérer plein ca devient bien plus difficile et on s’y perd rapidement ! ».

Les évolutions de 2010 vont-elles inverser la tendance ?

 

 

4. Le nouveau système de liaison

Enfin un système de liaison entre les Work Items digne de la suite logicielle, beaucoup de gens attendaient un système aussi riche depuis les débuts de Team System.

Comme il est évoqué dans la section des « faiblesses », la version courante de Team System propose un système de liaison limité, pour deux raisons :

1)     Il n’y a qu’un seul type de lien possible : unidirectionnel.

2)     Les liens ne sont pas mis en versions, il n’y a donc pas d’historique consultable concernant leur évolution.

A l’heure actuelle, si on lie un Work Item « 90 » à un autre, disons « 100 ». Un lien sera crée, il n’apparaitra pas dans l’historique du Work Item « 100 » et ensuite un lien dans l’autre sens sera automatiquement créé (ce qui provoque pas mal de problèmes).

La version 2010 a grandement évoluée sur ce point, nous avons maintenant un nombre infini de possibilités de création de liens à travers la fonctionnalité des liens typés.

Les liens typés nous permettent de créer un nouveau type de relation entre deux Work Items, il y a bien sur un jeu de type de liens prédéfinis :

Nom de référenceNom courtNom avantNom arrièreDescription
System.LinkTypes.RelatedRelatedRelatedRelatedLien bidirectionnel entre deux Work Items. Même comportement que les liens de TFS 2005/2008.
System.LinkTypes.HierarchyHierarchyChildParentCrée une hiérarchie entre deux Work Items à travers la relation Parent/Enfant.
Il est à noter que les enfants ne sont pas ordonnés.
System.LinkTypes.DependencyDependencySuccessorPredecessorCrée une dépendance entre deux Work Items à travers la relation Prédécesseur/Successeur.
Typiquement il faut accomplir le Work Item prédécesseur avant de pouvoir travailler sur le successeur.

 

Ce sont les trois types prédéfinis avec la version 2010. Cependant si on pousse un peu nos recherches, on trouvera dans les deux modèles Agile et CMMI un type de lien supplémentaire, définit dans un fichier XML :

<LinkTypes>
      <LinkType ReferenceName="Microsoft.VSTS.Common.TestedBy" ForwardName="Tested By" ReverseName="Tests" Topology="Dependency" />
</LinkTypes>

Nul besoin de décrire l’élément XML…

 

 

5. Des liens mis en version

L’impossibilité de mettre en version les liens dans les Work Items est une grosse limitation des versions existantes de Team System.

Créer un réseau de Work Items est important ainsi que de pouvoir le faire évoluer dans le temps tout en gardant de la traçabilité. Le meilleur exemple de ce besoin serait la prise en charge des exigences et spécifications.

Il suffit de lier deux Work Items et d’aller consulter l’historique pour se rendre compte que le problème a été adressé par Microsoft :

History

Une nouvelle section spécifique aux liens est maintenant présente dans l’historique, nous offrant la possibilité de découvrir tout le passé les concernant.

 

 

6. Le nouveau contrôle graphique des liens

Maintenant que nous avons plusieurs types de liens, il nous faut un nouveau contrôle dans notre formulaire de Work Items pour les créer et les afficher. Ce nouveau contrôle se nomme « LinksControl »

Links

Parmi ses particularités :

  • Il est possible d’avoir plusieurs instances de ce contrôle dans un formulaire de Work Item. Cette fonctionnalité est très importante, surtout lorsqu’on la conjugue avec la suivante.
  • Le contrôle affichera les liens en fonction d’un filtre prédéfini (déclaré dans la définition du type de Work Item).
  • Il est possible de créer une requête WIQL (Work Item Query Language) à partir du contenu du contrôle. Cette fonctionnalité peut paraître peu utile à première vue, mais nous verrons plus loin qu’elle permet de résoudre une limitation du contrôle qui ne prend en charge l’affichage que des liens directs. Il est en effet impossible de visualiser par exemple toute la hiérarchie en dessous du Work Item.

Un nouveau dialogue est disponible pour la création d’un lien :

Child

Vous pouvez constater qu’il y a maintenant un large de choix de types de liens à créer. Ces types devraient contenter la plupart des utilisateurs !

 

 

7. Utilisation de la hiérarchie

Testons maintenant la fonctionnalité tant attendue. Je vais créer trois Work Items : un «  Requirement », un « Change Request » et enfin un « Task », liés tous ensemble :

Requirement_Change Request_Task

En regardant le contrôle des liens du Work Item de type « Requirement », nous constatons qu’il n’est affiché que le « Change Request », comme il a été dit précédemment seuls les enfants directs sont affichés.

Description

Comment faire si nous voulons afficher la hiérarchie dans son intégralité ? Apparemment le seul moyen est de passer par les requêtes.

D’abord nous créons la requête à partir du Work Item en cliquant sur l’icône « View as Query » à partir de la barre d’outils :

Description

En exécutant la requête le résultat n’est pas celui que nous attendions :

Query Results

La requête nous montre toujours que les enfants directs sans aller plus loin.

Editions celle-ci afin en cliquant sur le bouton « Edit Query » dans la barre d’outil, nous allons certainement pouvoir trouver un moyen d’améliorer le résultat.

Voici le haut de la fenêtre d’édition de requête :

Work Items and Direct Links

On dirait bien que le choix « Work Items and Direct Links » de la combo box « Type of Query » est la raison de cet affichage limité.

Les autres choix disponibles sont les suivants :

Type of Query

Le dernier choix a l’air d’être le bon, changeons donc de type et exécutons la requête à nouveau :

CurrentTimeQuery

Enfin nous avons le résultat affiché sous forme de hiérarchie !

Maintenant regardons de plus près les quatre petits boutons (encadré en rouge ci-dessus), le premier va nous changer la disposition des fenêtres afin d’obtenir une représentation plus proche d’un explorateur :

CurrentTimeQuery

Le résultat est à la hauteur de nos attentes, la hiérarchie peut être parcourue facilement, et on peut consulter les Work Items sans problème.

 

 

8. Conclusion

L’introduction de la hiérarchie dans la version 2010 est un succès, les possibilités fonctionnelles ainsi que la nouvelle interface graphique permettront son utilisation dans le cadre de projets de grande envergure.

Le fait de pouvoir créer ses propres types de liens et que ceux-ci soient « versionable » va certainement ouvrir la porte à de nombreuses extensions très prometteuses.