Bonnes pratiques pour créer et gérer vos workflows Jira

Il est relativement facile de mettre en place ses premiers workflows Jira Software en tant qu’administrateur, mais il y a de bonnes pratiques à respecter qui sont très utiles quand on dispose de nombreux workflows, et surtout indispensables pour maximiser les bénéfices de chacun de vos workflows en matière de collaboration, d’efficacité et de cohérence. Pour ne pas vous perdre sur la route de la conception et de la gestion des workflows Jira, découvrez avec cet article nos bonnes pratiques, agrégées pendant plusieurs années de projets pour nos clients en tant qu’Expert Atlassian.

Il est important de noter que les différentes versions de Jira n’offrent pas les mêmes options de configurations. Vous ne trouverez par exemple pas les mêmes conditions, validateurs, fonctions de publication disponibles dans la version Cloud ou dans la version Serveur, et de nombreux plugins (apps) viennent ajouter de nouvelles possibilités de configuration. Nous avons donc regroupé ici des recommandations suffisamment générales pour s’appliquer à tous les cas.

Les workflows Jira Software

Avant de commencer, rappelons brièvement ce qu’est un workflow et ses composantes pour partir sur des bases communes. Il s’agit d’une suite d’états, liés entre eux par des transitions. On parle aussi de “flux de travail” en français, mais nous utiliserons le mot “workflow “dans cet article, car c’est le terme le plus communément utilisé. Un workflow est associé à un type de demande, au sein d’un Système de workflow.

Le logiciel Jira Software offre 2 méthodes pour éditer les workflows :

• une interface textuelle,
• une interface visuelle sous forme de diagramme (disponible à partir de la version 6.1 de Jira), aussi appelée workflow designer.

Un workflow Jira est composé d’objets :

• Des étapes
  • États * (la liste d’état est globale à l’instance Jira)
  • Propriétés d’étape (ou “méta attributs” d’étape)
• Des transitions
  • Écran
  • Déclencheurs
  • Conditions
  • Validateurs
  • Fonctions de publication  ** (aka. Post-fonctions)
  • Propriétés de transition (ou “méta attributs” de transition)

* Une étape possède forcément un état
** Une transition possède au minimum 5 fonctions de publication (sauf pour la transition de création qui n’en contient que 3), la dernière étant le déclenchement d’un événement.

Bonnes pratiques générales pour vos workflows Jira

• Conserver de la simplicité : il est parfois tentant d’ajouter de multiples éléments de configuration dans votre workflow, mais veillez à ce que cela ne soit pas un frein à l’utilisation. Cela pourrait aussi rendre votre workflow Jira trop complexe à maintenir. Dans les deux cas, cela deviendrait contre-productif, pourrait mettre en péril l’adoption du workflow ou encore compliquer son évolutivité.
• Modéliser les processus avant de les implémenter dans Jira : s’ils ne correspondent pas à la réalité du travail quotidien des personnes impliquées dans le workflow, l’outil ne sera pas utilisé. Il est important de les valider avec les parties prenantes en amont.
• Documenter le workflow et donner accès à cette documentation aux utilisateurs : ce qui est évident pour ceux qui conçoivent le workflow, ne le sera peut-être plus dans quelques mois et ne l’est peut-être pas du tout pour les utilisateurs finaux.
• Réutiliser les workflows au maximum pour plusieurs types de demandes et dans plusieurs projets, afin d’éviter la multiplication et la complexité d’administration.
• Garder la possibilité de rouvrir les demandes, quitte à restreindre cette option à certains rôles projets spécifiques via des conditions. Ceci offrira de la flexibilité dans la gestion des demandes.
• Maîtriser la notion de résolution et éviter de multiplier les étapes terminales. Il est généralement recommandé de n’avoir qu’une étape terminale par workflow, la notion de résolution permettant de distinguer comment la demande a abouti.
• Ne jamais paramétrer de noms d’utilisateurs, ni de groupes dans un workflow (même si c’est techniquement possible) et favoriser à la place des rôles projet, configurables par les gestionnaires de projet de manière indépendante.

Bonnes pratiques de représentation graphique de votre workflow

Organiser graphiquement le workflow permet de le rendre aisément compréhensible d’un seul coup d’œil. Par exemple, si le processus s’y prête, une organisation en cascade peut simplifier la visualisation.

Dans l’éditeur graphique, voici quelques conseils pour vous aider à garantir la simplicité et la lisibilité de votre workflow :

• bannir les superpositions d’état,
• éviter au maximum que les flèches de transition ne se croisent,
• s’il est possible de faire des allers et retours entre deux états, ne pas hésiter à superposer les transitions.

Bonnes pratiques pour les transitions

• Pour le nom des transitions, il est important de privilégier des verbes d’action : par exemple “fermer”, “demander des informations”…
• Réutiliser les transitions vers le même état autant que possible (“Re-use transition”) : si plusieurs transitions vont vers le même état, il est conseillé d’utiliser l’option de réutilisation de transition, ainsi seule une transition devra être configurée.
• Utiliser l’option “autoriser toutes les transitions” : s’il est possible de passer de chacun des statuts vers un autre statut, activer “Tous”. A noter que cela constitue une transition configurable au même titre que n’importe quelle autre transition.
• Placer “opsbar-sequence” comme propriété des transitions pour organiser leur ordre et choisir initialement des valeurs multiples de 100 pour pouvoir, si nécessaire, intercaler de nouvelles valeurs par la suite.
• Pour les écrans de transition, établir une nomenclature permettant de les différencier des écrans d’opération (exemple : “Dev Bug WF Clore SCR” vs. “Dev Bug OP Create-Edit-View SCR”). Sur certains éléments de configuration, seul le nom apparaît et il est donc utile de pouvoir différencier ces éléments simplement avec le nom de l’écran (exemple : pour configurer un écran de transition).
• Ne pas hésiter à mettre un écran pour chaque transition, même simple, car cela permet de proposer une confirmation de validation de la transition (pour rappel : si l’utilisateur “annule” l’écran de transition, celle-ci ne sera pas exécutée).
• Si vous utilisez des écrans de transition, il est conseillé de limiter le nombre de champs présentés. Plus particulièrement, ne jamais utiliser les mêmes écrans que pour les opérations création/édition/vue.
• Limiter le nombre de transitions disponibles depuis chaque état à 4 pour un rôle utilisateur. Utiliser éventuellement des conditions, afin de définir quelles transitions les utilisateurs peuvent voir.
• Ne pas utiliser de conditions pour vérifier qu’une valeur est correcte, mais préférer des validateurs. Les validateurs permettent d’afficher un message d’erreur, alors que les conditions se contentent de cacher la transition tant qu’elles ne sont pas vérifiées.
• Penser à enlever automatiquement la valeur de résolution dans les transitions de réouverture.
• Les événements déclenchés lors des transitions doivent être cohérents. Pour plus de pertinence, il faut penser à aller modifier la dernière fonction de publication de la la transition (il s’agit de la dernière des 5 fonctions de publications par défaut) pour adapter l’évènement propagé.
• Autoriser l’abandon d’une demande, sans avoir à dérouler tout son cycle : créer une transition spécifique positionnant une résolution “abandonnée”.
• Autant que possible, ne pas utiliser de plugins (app) permettant d’envoyer des e-mails spécifiques depuis une transition et préférer l’utilisation du système de notification embarqué dans Jira.
• Autant que possible, ne pas utiliser de plugins (app) permettant de créer des conditions scriptées. Celles-ci étant calculées à l’affichage éventuel de la transition, cela peut causer des problèmes de performance.

Bonnes pratiques pour les étapes

• Pour le nom des statuts, privilégier des états, c’est à dire des verbes au participe passé.
• Éviter de créer plus de 10 étapes pour votre workflow. Au-delà, cela devient difficile à maintenir. Si vous pensez pourtant en avoir besoin, il est intéressant d’étudier la division du processus en sous-processus (par exemple : utilisation de sous-tâches avec un worfklow plus simple) ou de revoir son organisation.
• Bien comprendre la notion de Résolution, comme expliqué pour les transitions.
• Paramétrer une seule étape terminale (étape de sortie) et utiliser les résolutions pour différentier les cas dont vous avez besoin.
• Réutiliser le plus possible les états déjà créés dans les workflows existants. Cela permettra de créer des filtres qui seront utilisables sur plusieurs workflows différents (exemple de filtre : “status = CLOSED” vs. “status in (CLOSED, FERME, CANCELED, RESOLVED)” )
• Limiter l’édition de certains états à certains rôles (propriétés d’étape). Pour cela, placer  “Jira.issue.editable=false” comme propriété sur la ou les étapes finales afin que les valeurs des champs des demandes terminées ne soient plus modifiées (note : cela force la réouverture d’une demande pour pouvoir l’éditer)
• Garantir qu’une valeur de Résolution soit systématiquement placée sur les étapes finales : soit en plaçant une valeur de manière automatique, soit avec un écran + validateur.

Bonnes pratiques pour les plus avancés

• Si votre workflow est principalement utilisé dans un tableau Kanban, nous vous conseillons de privilégier les transitions “all” permettant une plus grande latitude d’utilisation.
• Avant de concevoir votre workflow, il est utile de se poser les questions suivantes : “Qui fait quoi ?”  ou plus précisément “À un instant T, qui est responsable de la demande ?”. Cela permet d’envisager les transitions et les étapes plus finement. En effet, le travail ne s’effectuant souvent pas directement dans Jira (à l’exception d’un projet Service Desk où Jira devient le principal outil de communication), il est important d’éviter qu’un utilisateur se retrouve contraint de passer successivement plusieurs transitions, simplement pour mettre la demande dans le bon état.
• Nous recommandons de mettre en place une nomenclature avec des numéros de version de workflow : “<Categorie> <Issue type(s)> WF v<x>“
  • “<Catégorie> <Issue type> WF” : permet d’identifier pour quelle catégorie de projet, pour quel type de demande le workflow est censé être utilisé.
  • Lors de la publication du workflow, garder une copie en ajoutant le numéro de version qui a été incrémenté.
  • Penser à effacer régulièrement dans les workflows inactifs les versions max(x)-2 et inférieures (i.e. : ne garder que les 2 ou 3 dernières versions).
• Nous recommandons de mettre en place une nomenclature avec des numéros de version également pour les systèmes de workflow : “<Categorie> WFS v<x>“
• Lors de la création d’un workflow, il est parfois aussi utile de créer un ou plusieurs tableaux de bord spécifiques (et leurs filtres JQL associés) pour suivre l’évolution des demandes : un tableau de bord général par manager pour suivre l’évolution globale et un tableau de bord spécifique par rôle ou étape d’avancement du workflow (parfois factorisable en un seul tableau de bord).

Vous pouvez donc maintenant optimiser la gestion de chacun de vos workflows existants et améliorer l’efficacité et l’intuitivité de ceux à venir.  Ces nombreuses recommandations sont issues d’entretiens avec nos consultants experts, alors n’hésitez pas à garder cet article en favori pour y revenir en cas de besoin. Si vous avez besoin d’un accompagnement de nos experts Jira certifiés par Atlassian, vous pouvez en bénéficier à travers une formation, un coaching personnalisé ou encore nos services de consulting et d’implémentation. N’hésitez pas à nous contacter pour discuter de vos besoins.