Dans un projet informatique, les tickets d'anomalie (bug ou incident) et d'évolution sont des moyens de communication entre les utilisateurs ou les clients, et l'équipe technique, mais font aussi office d'outil d'organisation, de documentation ou de support de réflexion.
Un ticket d'anomalie est généralement rédigé après avoir constaté un comportement inattendu d'un outil informatique. L'auteur cherche à transmettre à l'équipe technique les détails qui vont lui permettre de comprendre ce qu'il s'est passé, trouver les causes du problèmes, et enfin le résoudre.
Cela prend généralement la forme de cette suite d'actions : communiquer, diagnostiquer, enquêter, résoudre.
Les trois dernières étapes sont la responsabilité de l'équipe technique, mais la compréhension de l'évènement anormal se passe souvent dans le ticket d'anomalie. L'enjeu pour l'auteur de celui-ci est donc de décrire son expérience de manière à ce que l'équipe technique la comprenne, et puisse être efficace pour résoudre le problème. Tout le temps que l'équipe passer à lever les ambiguités ou demander des informations complémentaires repousse d'autant la résolution finale du problème.
Voici quelques pistes pour bien communiquer avec une équipe technique :
Comment rédiger un rapport d'anomalies
Le titre
Le titre d'un ticket devrait être le plus court possible en contenant les mots les plus signifiants. Il devrait à lui seul donner une idée du contenu du ticket. Il devrait être descriptif plutôt qu'interrogatif :
- Lorsqu'il s'agit d'une tâche programmée ou d'une évolution souhaitée, utilisez de préférence des verbes à l'infinitif. Par exemple « Traduire la page d'accueil », « Maquetter la page abonnement », « Importer le jeu de données des contours des communes françaises».
- Lorsqu'il s'agit d'une anomalie, utilisez plutôt des phrases nominales, c'est à dire sans verbe, qui décrivent factuellement l'anomalie observée. Par exemple « Message d'erreur lors de la validation du formulaire d'inscription », « Résultats de recherche incohérents pour les achats vieux d'un an», « Pas d'affichage des véhicules sur la carte après connexion ».
La description
Il est beaucoup plus efficace de ne décrire qu'un seul et unique problème à la fois. Ne décrivez pas tout ce qui est survenu lors d'une session d'utilisation/de test par exemple mais faites autant de tickets que nécessaires si vous avez constaté plusieurs anomalies. Ne cherchez pas non plus à faire des groupes de problèmes : si deux problèmes se révèlent en fait liés ou en doublon, c'est l'équipe technique qui les fusionnera, puisque le diagnostic du problème est de sa responsabilité. C'est toujours ça de moins à faire au moment d'écrire le rapport !
S'il existe un modèle de rapport d'anomalie, utilisez-le bien sûr. Celui-ci vous fera gagner du temps et vous guidera pour ne pas oublier d'information. Sinon rappelez-vous de ce que devrait contenir un rapport (et n'hésitez pas à suggérer à l'équipe technique de créer un modèle) :
1. ce que j'ai fait.
La première chose que va tenter de faire l'équipe technique, c'est de tenter de constater l'anomalie, et donc reproduire la situation qui vont a amenées à l'anomalie. C'est de votre responsabilité de transmettre les bonnes informations pour que les techniciens réussissent cette étape.
Donnez le contexte dans lequel l'anomalie est survenue, éventuellement énumérez la suite d'actions qui a emmené jusqu'au bug. Rappelez avec quel compte vous êtes connectés, donnez le lien de la page web concernée par le bug, et l'heure à laquelle il a survenu. Donnez ces informations à chaque fois, même si ça vous semble rébarbatif ou non pertinent. Ce sont des informations précieuses pour l'équipe technique. Un bug est peut être spécifique à ce contexte précis et difficilement reproductible en dehors. La date par exemple sert à retrouver les informations susceptibles d'aider à la compréhension dans les journaux d'erreurs techniques.
Exemple : « J'ai rencontré l'anomalie sur la plateforme de recette, jeudi 30 juin vers 14h30. J'étais connecté avec le compte Alice et après avoir ajouté un vélo dans son compte avec la position géographique (48° 52.6 S, 123° 23.6 O), j'ai cliqué sur l'icône carte qui amène sur http://monservice.example/carte. »
2. ce que j'ai constaté.
Expliquez le comportement non attendu qui a été observé, si possible illustré d'une capture d'écran ou d'une vidéo.
Exemple : « La carte s'affiche bien : on voit la rue dans laquelle habite Alice mais le point "vélo" n'apparait pas. »
3. ce que j'aurais du voir.
Parfois c'est évident, mais souvent ça ne l'est pas. Expliquez brièvement le comportement que vous espériez, et pourquoi ce que vous observez n'y correspond pas.
Exemple : « La carte devrait montrer l'endroit où est situé le vélo, puisque le vélo est situé en France métropolitaine. »
Enfin, un rapport d'anomalie ne devrait probablement PAS contenir :
un diagnostic : Astreignez-vous à ne décrire que les comportements observés, éventuellement les impacts réels ou anticipés sur votre usage ou celui des autres utilisateurs. Établir le diagnostic d'un problème fait partie du travail de l'équipe technique, ne perdez de temps sur cet aspect au risque de brouiller les pistes.
un brainstorming : N'ouvrez pas de nouvelles questions. Les tickets de bug ont pour fonction de décrire l'existant, les idées d'évolution et les brainstorming doivent avoir une place distincte ! Selon les méthodes de travail, cela peut être dans un autre outil ou bien dans un ticket avec une priorité dédiée à celà.
La priorité
Si vous faites partie de l'équipe produit et que c'est à vous de juger la priorité entre plusieurs tickets (via un indicateur sur le ticket par exemple), celle-ci doit être bien choisie.
La répartition des tickets doit avoir une forme de pyramide : peu de priorité très haute, un peu plus de priorité haute, encore un peu plus de priorité moyenne etc. Si tout est en priorité très haute alors les tickets sont probablement mal priorisés.
Considérez que les tickets les plus prioritaires seront dans la mesure du possible traités en premier. S'ils sont tous au même niveau, cela devient chronophage voire impossible pour l'équipe technique de déterminer l'ordre de réalisation le plus pertinent.
Pour organiser efficacement les tickets en fonction de leur priorité, pensez à ce à quoi vous êtes ou n'êtes pas prêts à renoncer, en cas de réduction des moyens de production. Si demain la capacité de développement était divisée par deux et que vous deviez vous séparer de la moitié des tickets, lesquels gardriez-vous ?
L'assignation
Même si l'outil utilisé le permet, n'assignez pas des tickets à des membres de l'équipe technique. C'est le rôle de l'équipe technique de se répartir les tickets. Par exemple même si vous utilisez simplement le mail, utilisez une adresse non nominative pour adresser le rapport.
Par contre, faites en sorte que les tickets d'anomalie et d'évolution parviennent de façon efficace à l'équipe technique : ne mélangez pas tickets non techniques et tickets techniques. Les sujets de communication ou de commerce devraient avoir leur propre listes de tickets. Utilisez par exemple une adresse mail spécifique dédiée dans le cas d'emails.