image

Créer un nouveau type de WorkItem dans TFS 2012

Je l’indiquais récemment il est parfois très utile de créer un nouveau type de work item dans TFS afin de gérer de nouveaux types d’informations non gérés par défaut par le process template que vous avez choisi lors de la création de votre Team Project.

Par exemple avec le modèle SCRUM vous disposez des types de work item suivants :

  • Product Backlog Item
  • Bug
  • Task
  • Impediment
  • Test Case

Comme vous avez pu l’apercevoir dans un précédent post, nous avons créé un type de Work Item spécifique pour gérer les migrations de données entre nos différents produits et des produits concurrents.

Je vais donc illustrer la création d’un nouveau type de work item en prenant cet exemple concret.

La plupart des éditeurs de logiciels connaissent très bien la problématique des migrations.

Que cela soit entre les différentes gammes de produits que peut proposer un éditeur ou même depuis des produits concurrents, les migrations de données peuvent être complexes et source récurrente de problèmes.

Afin d’être capable de mesurer l’activité suscitée par ces migrations, j’ai décidé de créer un nouveau type de work item qui nous permet d’avoir une bonne visibilité de l’impact de ces migrations sur l’activité du service développement.

Je trouve en effet très important d’arriver à avoir des indicateurs pertinents qui permettent d’avoir une vision précise de l’activité afin de pouvoir prendre des décisions avisées rapidement.

Dans le principe “Build-Mesure-Learn” mis en avant par les méthodes agiles, on a plutôt tendance à se focaliser sur le Build et non sur les deux étapes suivantes qui font pourtant du cycle vertueux permettant d’améliorer les choses en continu.

L’objectif étant de mieux travailler et non pas de travailler plus dur, plus vous arriverez à mesurer finement votre activité plus vous serez susceptibles de parvenir à améliorer les choses.

Les objectifs de ce type de work item Migration sont (entre autres) les suivants :

  • Mesurer le nombre de sollicitations (=interruptions) du service dév. pour chaque migration
  • Mesurer le temps passé sur ces sollicitations
  • Connaitre le nombre de corrections réalisées par migration

Ce qui nous permet sur une période donnée :

  • d’avoir le total de temps passé en assistance sur les migrations
  • de mesurer le nombre d’interruptions (et donc de perte de productivité) lié à cette activité
  • et de voir l’évolution du nombre de corrections effectuées afin d’apprécier la courbe de diminution de celles-ci

La création d’un nouveau type de Work Item correspond tout à fait à ce besoin puisqu’elle nous permet :

  • de stocker les informations souhaitées (nombres d’interruptions, etc.) très simplement
  • de faire des liens avec les work items liés (ex: les bugs)
  • d’utiliser les fonctionnalités de reporting, et d’export des WI vers Excel afin de pouvoir exploiter ces informations simplement

Je ne vais pas détailler la création d’un type de work item car la procédure est décrite dans la documentation :

Je vais plutôt vous montrer le résultat final :

Stockage des différentes informations souhaitées, et affichage des liens avec les autres Work Items :

image

 

Utilisation du champ History pour tracer tous les évènements lié à une migration :

    image

Il ne reste plus qu’à faire des belles statistiques à partir de cela afin d’avoir une vision précise de notre activité liée aux migrations !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *