Comment qualifier une anomalie pour faciliter sa correction ?

Dans nos missions d’accompagnement, nous constatons plusieurs problèmes dans la gestion des anomalies :

1. les équipes en charge de corriger des anomalies manquent d’information pour les traiter efficacement ;
2. les mails ou les tickets remplacent la communication orale, les équipes ne se comprennent pas, elles perdent du temps, le travail est individuel, des tensions se créent.

Si vous rencontrez ce type de problèmes dans votre organisation, il est possible de développer des compétences à plusieurs niveaux pour accélérer globalement le traitement des anomalies.

Même si ce n’est pas leur rôle a priori, les utilisateurs -ou leur représentants en interaction avec les développeurs- peuvent :

1. apporter certaines informations sur les anomalies pour faciliter le travail de priorisation et de développement ;
2. conserver une bonne dose de communication orale pour aider l’équipe à qualifier, tester, corriger les problèmes.

Cet article vous propose une liste non-exhaustive de pratiques qui peuvent aider une équipe en charge de corriger des anomalies.

Pour définir vos propres règles de communication avec les personnes avec qui vous interagissez, vous pouvez :

1. à l’instar de la Definition of Ready (DoR) pour les user stories, mener un atelier pour définir collectivement une DoR spécifique aux anomalies ;
2. mener des rétrospectives pour échanger sur les problèmes de communication et de priorisation.

Reco nº 1 : Aidez le développeur à reproduire l’anomalie

Le développeur a besoin de reproduire une anomalie pour pouvoir la corriger. Il doit donc avoir toutes les informations lui permettant de la reproduire rapidement, et lui fournir un exemple l’aide généralement dans ce travail.

 Reco nº 2 : Indiquez le comportement attendu et le comportement constaté

Séparez clairement le comportement attendu et le comportement constaté. Cela évite au développeur de chercher ou faire des hypothèses sur la fonctionnalité impactée.

Cela est particulièrement important pour les équipes travaillant sur des produits contenant beaucoup de fonctionnalités ou qui ont difficilement accès aux référents fonctionnels.

Reco nº 3 : Indiquez le caractère bloquant ou non de l’anomalie

Cela permet à l’équipe de prioriser la demande par rapport aux autres problèmes qui lui sont présentés, de décider si l’anomalie peut continuer d’exister ou non en Production. Sa responsabilité sera ensuite de maintenir le nombre d’anomalie jugée bloquante à 0, en les traitant en priorité sur les nouvelles fonctionnalités.

Discuter le caractère bloquant ou non d’une anomalie revient à répondre aux questions suivantes :

1. Les utilisateurs sont-ils bloqués dans leur travail ? Les clients bloqués dans leur parcours ?
2. En quoi les utilisateurs sont-ils bloqués ? Existe-t-il une solution de contournement ?
3. Quel est le coût du problème ? Sa fréquence ? Combien d’utilisateurs sont impactés ?

Reco nº 4 : Séparez les scénarios d’anomalie

Votre demande ne doit présenter qu’une seule anomalie, c’est-à-dire un seul scénario (si vous êtes en début de chaîne et remontez plusieurs problèmes à la fois, séparez clairement les différents scénarios qui posent problème).

Cela permet de traiter séparément chaque anomalie : priorisation à des moments différents en fonction de l’impact, prise en charge par différents développeurs, etc.

Reco nº 5 : Résumez votre demande en une phrase explicite

Résumez votre problème en une phrase explicite et discriminante permet :

1. d’identifier instantanément les utilisateurs et fonctionnalités impactés ;
2. dans l’outil de gestion des tickets, de se rappeler le détail de l’anomalie quand on repasse sur le résumé quelque temps après l’avoir lue une première fois en détail.

Idéalement, le résumé indique en quelques mots l’utilisateur, la fonctionnalité et le caractère bloquant ou non de l’anomalie.

 Autres informations intéressantes

Dans certains cas, ces informations sont utiles :

1. la date de détection de l’anomalie (la plus précise possible, cela permet de gagner du temps dans l’analyse des logs) ;
2. l’environnement concerné (exemple : recette, pré-prod, prod) ;
3. l’URL d’accès pour les sites web ;
4. les nom et version du navigateur et de l’OS, quand le problème concerne l’affichage ;
5. le caractère systématique ou aléatoire de l’anomalie ;
6. une copie d’écran pour illustrer ;
7. les coordonnées téléphoniques de la personne ayant détectée l’anomalie.