JIRA et l’Agilité : des dysfonctionnements chroniques

Etant amené à déployer des méthodes industrielles de test, et souvent dans un cadre agile, j’ai été confronté à devoir travailler avec JIRA, soit comme simple bugtracker, soit plus souvent pour implémenter une méthode agile, le cadre SCRUM. Ces situations réccurentes m’ont ainsi amené à réaliser des audits du processus d’ingénierie, agile ou pas, dans des sociétés pour des tailles très variables allant de la PME au grand compte.

1) JIRA est un ancien bugtracker mais …

Tout ticket historiquement est une « issue » ce qui en anglais signifie « problème ». Mais cet outil a évolué de sorte que désormais, un ticket est d’abord et avant tout une tâche à réaliser affectée à un utilisateur.

Le type « Bug » existe, mais représente-t-il réellement un défaut ? La réponse est non et il suffit de lire les champs qui le composent pour voir que le Bug standard est en réalité un correctif.

Car le ticket Bug ne contient pas les champs descriptifs du défaut d’un logiciel : pas de fréquence de survenance, pas d’échelle d’impact, pas de champ pour décrire le terminal de survenance du défaut … et surtout aucune distinction entre un incident de production et un défaut détecté en environnement de test – ce qui en termes d’impact est sans comparaison possible (techniquement, cela demande deux types de ticket différents et deux workflows).

2) Un défaut n’est pas un correctif

Un correctif peut regrouper plusieurs défauts à corriger. Et un même défaut peut, dans le temps, faire l’objet de plusieurs correctifs, soit sur plusieurs logiciels en parallèle, soit parce qu’un correctif aura besoin d’être complété car insuffisant (en cas d’une régression par exemple).

La relation entre défaut et correctif est donc N-N et non pas 1 pour 1.

Et dans le cas de l’agilité, un ticket ayant été traité ne saurait être rouvert pour revenir dans le backlog d’autant que la complexité devrait alors être révaluée (et écraser celle du sprint précédemment développé).

Ensuite, le workflow d’un rapport d’observation sert à qualifier s’il y a défaut ou pas : est-il sans objet ? Est-il un dysfonctionnement ? Un écart souhaitable ou non souhaité ? Quels sont les risques ? Le seul rôle ici des développeurs est d’indiquer s’ils reconnaissent pour défaut l’observation faite, s’ils ont réussi à la reproduire … bref, de fournir une analyse rapide et non consommatrice. En de rares cas l’analyse pourra être complexe et correspondre à une tâche consommatrice.

Alors que le correctif suit le workflow d’un développement et demande une charge de travail. A plus forte raison en agilité pour déterminer une complexité : le correctif est un item du backlog quand le défaut ou l’incident de production n’est qu’un document externe à celui-ci.

Attention de ne pas vouloir mettre tous les types de ticket dans le backlog : tout ticket n’est pas nécessairement un incrément.

3) Le workflow standard de JIRA … n’est pas un workflow

Un workflow est représentable par un graphe état-transition étiquetté (sur ses noeuds et sur ses transitions).

Mais pas dans l’installation de JIRA par défaut à moins qu’une customisation ait été définie auparavant ! En effet, les workflows ont des transitions « D’un état vers tous les autres ». Ce qui revient à dire qu’il n’existe pas de workflow puisqu’il n’y a pas de règle.

En outre, pour les tickets Task et Subtask, les états définis sont minimalistes : le responsable est « condamné » à terminer ses tâches et ne peut, par exemple, ni les abandonner ni les suspendre. Ces états/transitions n’existent pas.

4) Une Story n’est pas une User Story

Un type de ticket « Story » existe dans JIRA – de même que l’Epic. Mais ce type n’implémente pas l’Agilité, encore moins SCRUM. Hormis les champs Sprint et Story Point qui existent, l’essentiel des champs utiles en agilité sont manquants.

Il est aussi notable qu’un même ticket peut chronologiquement être associé à une infinité de sprint. Une définition qui amène une dérive souvent observée : les tickets se déplacent de sprint en sprint lorsque les développeurs n’ont pas le temps de tout développer.

Nous rappelons qu’à l’issue d’un sprint, la totalité du sprint backlog doit avoir été réalisée, le transfert de ticket devant être très occasionnel et non pas la règle.

Lorsque l’Agilité était implémentée à l’aide de post-its sur un mur cependant, ceux-ci étaient jetés à la poubelle une fois traités, ils étaient une microtâche développée par un seul membre de l’équipe et éventuellement validés par un autre.

Le PO comme le SCRUM Master n’allaient pas « faire les poubelles » pour remettre un post-it sur le mur. Cela est d’autant plus vrai que cela fausse le calcul de la vélocité. Alors que la conception de l’Agilité dans JIRA permet une dérive … d’autant qu’un même ticket peut être décomposé en sous-tâches, associées à plusieurs développeurs. Et aussi parce que JIRA automatise le transfert de tickets lors de la clôture des sprints.

Il est donc indispensable de customiser JIRA autant pour implémenter l’agilité, que les défauts, les incidents de production et les correctifs, puisque comme nous l’avons vus, seuls ces derniers ont une raison d’être dans le backlog avec les User Stories.

5) Une User Story n’est pas une fonctionnalité

Un biais souvent constaté est aussi cette confusion qu’une User Story décrirait une sous-partie du logiciel « d’un point de vue de l’utilisateur » donc qu’elle serait nécessairement une fonction du logiciel.

C’est pourtant faux – ou plutôt très occasionnellement vrai -. Si en effet vous avez uniquement des développeurs fullstack dans votre équipe, la totalité de l’US pourra être développée par elle ou lui. En revanche, si votre équipe est composée de développeurs spécialisés frontend ou backend, alors la fonctionnalité ne peut qu’être scindée au moins en deux US, une pour le frontend et l’autre pour le backend. JIRA peut donc fausser la vision Agile.

Une User Story est avant tout un incrément, que celui-ci soit strictement technique ou complet, ce périmètre dépendant du profil du développeur qui va travailler, et non intrinséquement une fonctionnalité comme le laisserait croire le mot « User » dans l’expression User Story. Il est d’ailleurs notable qu’historiquement, SCRUM utilise le terme « Item », l’expression User Story ou Story venant de l’Extreme Programming – une autre méthode Agile.

Le principe initial de l’agilité « avec un post-it sur un mur » est que l’US est censée être un incrément ATOMIQUE. Aussi, assimiler une US à une fonctionnalité est alors la cause d’une dérive de l’Agilité imposée par JIRA, outil trop permissif. Il est donc fondamental de customiser correctement l’outil en Agilité et ne pas se contenter des définitions par défaut.

6) Un correctif/un Fix n’est pas une Story ou une User Story

Par défaut, le type Fix n’existe pas dans JIRA (confondu avec le Bug improprement) si bien que le PO peut aussi bien détourner le ticket Story, Bug ou Task pour introduire les corrections du logiciel dans le flux des tâches de développement.

Sauf que, et le point précédent devient alors aggravant, un incrément de correction n’est pas une « Récit Utilisateur ». Il manque donc plusieurs types de ticket et champs dans JIRA pour réellement implémenter l’Agilité.

Il est préférable ici de créer le type Fix/Correctif pour les distinguer des US, puis de définir que seuls les correctifs et les US peuvent alimenter le backlog, laissant les défauts et incidents de production en dehors du flux.

Correctifs et US demandent alors une validation, contrairement aux incréments du backlog « Task » qui relèvent des activités complémentaires dans un sprint (comme mettre à jour une documentation par exemple).

7) La validation des incréments n’est pas implémentée dans JIRA

Par défaut, une Story dans JIRA peut aussi bien être une tâche débouchant sur un développement (et donc sa validation) qu’une activité de documentation par exemple, qui ne demande en rien un contrôle – d’autant plus si une équipe de testeurs dédiée est à l’oeuvre.

Dès lors, JIRA devrait être capable de différencier d’un côté les US et les Fix, et de l’autre toute l’activité sans contrôle qualité. Or ce n’est pas le cas sans customisation préalable car, en standard, JIRA ne sait pas faire la différence : tout passe dans le backlog, exceptées les Epics.

8) Une Story n’est pas testable mais validable

Conséquence du point n°5 pour l’équipe de test, la tendance à confondre la validation des US et la construction des tests de non régression !

Valider une US – si l’on comprend bien qu’elle n’est pas une fonctionnalité mais un incrément – demande donc des tests techniques de bas niveau, des tests de composants.

Côté backend par exemple, un testeur devra solliciter les API avec des outils comme SOAPUI ou Postman – activité très technique – alors que pour tester le frontend, en mode dégradé avec des fixtures, un testeur ne fera que des tests d’IHM « de surface ».

Un test fonctionnel complet ne peut donc pas être déroulé – à moins que l’US n’implémente à la fois frontend et backend et représente donc un tout assemblé, développé alors par un profil fullstack.

Dès lors, confondre la validation d’une US avec la rédaction d’un test Métier manuel – aussi bien qu’un script automatique est une erreur fondamentale.

Le concepteur de test en agilité a en effet deux casquettes simultanément : il valide le sprint en cours avec les développeurs, et il construit le référentiel des tests de non régression, ces deux tâches étant en vase communicant.

Là où les développeurs Agiles passent 90% sur le sprint en cours, et 10% à participer aux refinements, les testeurs agiles passent 40% sur le sprint en cours, et 60% à définir les tests des sprints à venir – voire davantage pour un automaticien.

Ma conclusion d’expert

Alors que je ne suis pas coach agile et que je dois déployer des méthodes de test chez mes clients, je suis contraint dans presque tous les cas de cadrer le processus agile/SCRUM : je suis ainsi devenu expert JIRA.

Avec toutes les difficultés relationnelles et humaines que cela représentent, les acteurs étant parfois convaincus de détenir une vérité en réalité imposée par un outil mal configuré et méconnu.

Ainsi, pour déployer une méthode de test, 75% de mon travail consiste désormais à convaincre des développeurs, SCRUM Masters et Product Owners que l’outil qu’ils utilisent au quotidien ne répond pas à leur besoin, qu’ils ne sont pas agiles – et pire, qu’ils introduisent des biais ou des dysfonctionnements.

A propos de l’auteur Emmanuel Michel Itié :

Consultant en informatique depuis plus de 25 ans, expert en test et accompagnement au changement, je mets en œuvre une méthodologie de test industrielle dans les DSI au travers de différents outils (Squash TM, ALM Quality Center, …), et dans le cas de l’Agilité, me trouve confronté à un outil incontournable : JIRA.

Je suis également chercheur bénévole dans les disciplines historiques et développeur fullstack.

Enfin, je suis auteur de plusieurs livres sur le test logiciel aux Editions ENI.