Créer un workflow Jira est un exercice qui parait au premier abord simple et qui est en réalité beaucoup plus complexe qu’il n’y parait. 

En effet, on a tendance à vouloir découper le travail au maximum, représenter tout un processus dans les moindres détails, ajouter des règles, des transitions, des champs personnalisés qui complexifient et s’avèrent avec le temps une source d’erreurs et de non-adhérence des équipes. 

Si la bonne pratique reste de laisser la conception de workflow à un expert qui saura vous orienter et traduire votre processus de travail en workflow Jira, dans certains cas, vous n’aurez d’autre choix que de le faire par vous-même. Voyons ensemble comment construire un workflow efficace, en évitant les pièges parmi les dizaines de possibilités offertes par Jira ! 

Définir une Definiton of Done

Avant de se lancer dans la conception d’un workflow, la première étape est de se mettre d’accord au sein de l’équipe de projet sur la signification du « Done » c’est à dire de l’état sortant du workflow. C’est ce qu’on appelle la Définition of Done (ou DOD) ; Cette étape est importante car elle permet de définir qu’est-ce que l’équipe considère comme la dernière étape clôturant le workflow de travail : Est-ce qu’un ticket testé sur un environnement spécifique est un ticket « Done » ? Est-ce qu’un ticket développé est un ticket « Done ». 

Voir notre article  » Définition of Done » pour plus de détails sur le sujet.

Un point d’entrée, un point de sortie, ni plus, ni moins

Vous pourriez être tenté de mettre en place un workflow avec plusieurs points de sortie. Un statut « CANCEL » pour les tickets que l’on annule en cours de route, un statut « DONE » pour ceux ce qui arrivent jusqu’au bout et peut être d’autres statuts propres à votre façon de travailler ; puisque Jira le permet, pourquoi s’en priver !

Même si le besoin de tracer le taux de tickets annulés, le taux de tickets terminés est légitime, la multiplication d’étapes de workflow risque de rapidement surcharger et complexifier votre outil de travail quotidien. La bonne approche est toujours la plus simple, adopter un point d’entrée unique et un point de sortie. Et votre problématique de suivi des causes de fermeture pourra être géré avec un autre concept dans Jira (ndlr : la résolution).

Une nomenclature claire, concise et réutilisable

Il faut accorder beaucoup d’importance à la nomenclature des états (statuts), mais également des transitions. En effet il est important que votre workflow soit clair, concis et compréhensible de tous, particulièrement de l’équipe qui va l’utiliser, mais également des futurs nouveaux arrivants (ne pas sous-estimer le turn-over et l’onboarding). La meilleure expérience utilisateur est toujours celle que l’on n’explique pas ! Le workflow doit donc être simple, intuitif et chaque libellé choisi doit être évident sur l’action ou l’état qu’il induit. N’hésitez-pas à faire tester votre workflow par quelqu’un extérieur à votre équipe. 

Ex : « In Progress » / « To Test »

1/ Soyez clair & concis :

Choisissez un libellé simple : un ou deux mots idéalement, le plus court possible car il faut penser à la place qu’il va occuper dans toute l’interface et potentiellement pour les utilisateurs ayant de petits écrans. En revanche la concision ne doit pas desservir la compréhension : il faut donc éviter les abréviations et termes internes à l’activité de l’entreprise.

2/ Autant que possible, restez générique et non spécifique :

Lors de la création d’un workflow on a une envie naturelle de personnalisation, on a donc tendance à utiliser des termes précis, alors que dans le fond, quand on prend du recul sur différents types d’activité, il y a une phase de préparation, une phase de validation, de réalisation, de test… que ce soit pour le développement d’un logiciel informatique, d’une campagne marketing ou l’usinage d’une pièce automobile. Dès lors il convient de pouvoir réconcilier les services d’une même organisation autour de termes génériques en permettant ainsi d’avoir à l’échelle d’un groupe une vision consolidée des projets, des sujets et de leur avancement macro, comme micro puisque c’est toute la force de Jira.

3/ Créer les états et transitions en anglais :

On pourrait être tenté de créer un Jira franco-français et ignorer l’anglais, mais ce serait oublier que la version native est anglaise, que Jira intègre un système de traduction qu’il est préférable d’utiliser. De plus, si votre activité grossie et que vous devez un jour travailler en anglais, alors il faudra tout revoir. Autant commencer proprement dès le début. Il est donc préférable de créer vos statuts et transition en anglais et d’ajouter une traduction en français sur ces statuts depuis l’interface d’administration.

4/ Un état = un acteur + une action

Pour définir votre workflow, il convient de partir de votre processus de travail et de définir un état de worflow à chaque fois que la tâche à accomplir change d’acteur ; un acteur représentant un rôle spécifique au sein de votre organisation réalisant une ou plusieurs tâches dans votre processus de travail (Ex : Tech Lead, Dev, QA, Business Analyst, Product Owner…)

En effet cela permet de rendre le workflow plus léger, moins chronophage à mettre à jour par les équipes et parfois même plus facilement automatisable. N’oubliez jamais qu’il vaut mieux un workflow très simple mais bien maitrisé et toujours à jour qu’un workflow complexe qu’une personne doit sans cesse maintenir à jour.

Exemple : pour un workflow de développement logiciel d’une petite équipe, on serait tenté de séparer en différentes étapes les tâches que réalise un développeur : le développement, les tests de la fonctionnalité et la Pull Request. Néanmoins ces 3 tâches incombent au rôle « Développeur », donc un seul état « In Progress » (En cours) sera amplement suffisant.

En revanche si dans le processus, les Pull Request (ou Merge Request) sont toutes vérifiées par un Tech Lead qui donne son approbation, cela peut avoir du sens de créer un statut dédié à cette tâche spécifique qui revient au rôle « Tech Lead ».

5/ Ne multipliez pas les états synonymes

Avec le temps, un terme parlera plus à un utilisateur qu’un autre et des initiatives de créer de nouveaux workflow avec des états similaires à ceux déjà existant apparaîtront (« En développement », « En réalisation », « En cours », « In Progress »…). C’est à ce moment qu’il faut être vigilant pour éviter au maximum la prolifération d’états synonymes mais plutôt de discuter pour arriver a faire converger les équipes vers un terme qui parlera à tous. Le meilleur exemple reste le statut de clôture du workflow qui selon les équipes sera « Fini« , « Terminé, « Clos » ou encore « Done » (pour ceux qui les auront bien créé leurs statuts en anglais). A première vue cette initiative parait anodine, chacun ayant sa propre signification du « Fini » mais lorsque les projets Jira se multiplient, trouver tous les tickets clôturés le mois passé devient très compliqué car il faut an agréger une quantité importante de statuts au sein de l’instance Jira. Par ailleurs cette multiplication de statuts, cumulée à d’autres (mauvaises) pratiques aura tendance à ralentir votre instance Jira avec le temps.

A contrario, si la mutualisation de certains états que l’on pourrait qualifier de « génériques » (« To Do », « In Progress », « Test », « Done ») est une bonne pratique générale, elle n’est pas à appliquer à tous les statuts de workflow. En effet, certaines étapes spécifiques à un processus de travail ne sont pas mutualisables et il ne convient pas de les adapter. Attention cependant, car en cas de réutilisation d’état(s) déjà existant, leur(s) modification (renommage par exemple) aura une incidence sur TOUS les workflow utilisant cet état.

ATTENTION : Si vous utilisez plusieurs produits Atlassian, comme JSM (Jira Service Management) et Jira ; par défaut Jira propose des statuts différents entre les deux produits pour traduire les états d’ouverture et de fermeture du workflow. Il est important de conserver cette distinction et de ne pas converger vers une simplification trop extrême de vos statuts de workflow. Il est important de séparer le fonctionnement des deux produits qui n’ont pas la même utilisation et ne sont pas destiné aux mêmes utilisateurs.

Conception du workflow

Etape 1 : placer sur votre page de conception vos différentes étapes de workflow (Statuts). En prenant en considération toutes les recommandations exposées précédemment, vous devriez arriver à 6 à 8 statuts dans la plupart des cas.

NB : pour chaque statut entre le statut d’ouverture et de fermeture du workflow, on pourra imaginer des points d’attache pour les transitions pour matérialiser les transitions à venir : en vert, les transitions sortantes permettant de faire avancer ou reculer le ticket Jira vers un autre statut ; en bleu les transitions entrantes.

Etape 2 : placer les différents statuts dans leur ordre de déroulement sous forme d’escalier et commencer à dessiner les différentes transitions entre chaque

Etape 4 : attacher des écrans à certaines transition pour récupérer certaines informations souhaitées ; on pourra par exemple mettre en place un « Résolution Screen » qui permettra de collecter les informations de résolution, de version de correction, ou de temps passé sur le ticket. 

Etapes 5 :  ajouter des règles sur vos transitions pour sécuriser, fiabiliser et/ou automatiser votre workflow. C’est toute la puissance et l’intérêt de Jira et on aurait tort de s’en priver, même si ces options sont à expérimenter, à tester et à ne pas faire pendant un Sprint de développement pour ne pas perturber une équipe. Ces règles peuvent permettre à certaines étapes du workflow de :

• Forcer à ce que certaines informations soient complétés pour garantir qu’elles soient complétées
• Empêcher que certaines actions puissent être faites par certains rôles
• Automatiser le renseignement de certains champs en fonction de l’utilisateur qui fait l’action
• Déclencher des actions en fonction d’une action précédemment faite
• Et beaucoup d’autres choses encore…

Attention cependant à ne pas trop complexifier : on ne recommandera jamais assez de commencer simple, de voir comment une équipe apprivoise le workflow, puis de faire des ajustements par itération en fonction des difficultés rencontrés.

Par ailleurs verrouiller un workflow peut également devenir complexe à appréhender par les équipes et une véritable source de problème en cas d’absence, de maladie d’un membre (rôle) clé du worflow. Il faut donc prendre en compte ces possibilités lors de la conception du workflow.

En conclusion, faites simple !

Concevoir un workflow Jira est un exercice qui demande à la fois une certaine maturité, une prise de recul et une maitrise de Jira et de certains concepts. On a souvent tendance à croire que la personne la mieux placée pour construire un workflow se trouve au de l’équipe qui va utiliser le workflow mais en réalité, il est bien souvent plus efficace de faire auditer son fonctionnement par une personne tiers, si possible experte dans les solutions Atlassian qui pourra vous aider à traduire votre métier et votre façon de travailler en un workflow efficace.

Dans tous les autres cas, si vous êtes amené à faire par vous même, faites simple, commencez petit et enrichissez au fur et à mesure