Conseils pratiques – Videz à nouveau le champ de résolution

Jira Cloud : Flexibilité grâce à des workflows personnalisables

Chaque tâche a un cycle de vie. Un propriétaire de produit ou un chef de projet crée la tâche, l’employé A traite le processus et le transmet au collègue B pour l’assurance qualité, qui vérifie le travail et ferme le ticket. Ainsi, la tâche est créée, elle passe par quelques (ou plusieurs) étapes intermédiaires et, à un moment donné, elle est terminée.

Ces cycles de tâches sont cartographiés dans Jira sous la forme de workflows – et l’une des grandes forces de Jira réside dans les workflows. Chaque équipe ou projet peut mettre en place et utiliser ses processus uniques et spécifiques pour le traitement des tâches. Cela rend Jira très flexible et adapté à une grande variété de scénarios d’utilisation et de cas d’utilisation.

Résolution : Fin du cycle de vie de la tâche

Dans ce contexte, il est Champ de résolution dans Jira une fonctionnalité importante car elle spécifie la raison pour laquelle un problème a été fermé. Dans le même temps, il n’est pas nécessaire de gérer plusieurs champs indiquant pourquoi le dossier est fermé. Ainsi, la résolution capture les informations vitales de l’équipe tout en réduisant le temps passé à gérer les workflows.

Jira considère qu’un problème est hors de vie et terminé lorsque le champ Résolution a une valeur. Dans ce champ, Jira stocke la façon dont un problème a été résolu, par exemple si la tâche a été terminée ou annulée.

Résolution dans les projets gérés en équipe

Jira Cloud propose depuis un certain temps une fonctionnalité appelée “Projets gérés en équipe”. Ces projets sont conçus de sorte qu’au sein d’un projet spécifique, chaque membre de l’équipe ait la capacité de gérer le travail et les processus de l’équipe sans avoir à demander l’aide des administrateurs.

Cependant, Atlassian ne fonctionne plus avec le champ de résolution dans les projets gérés en équipe, mais utilise à la place les champs “Status Category”, qui correspond à peu près à la résolution, et “StatusCategoryChangedDate” (au lieu de “resolutiondate” ou “resolved”).

Mais que se passe-t-il si l’équipe de ces projets souhaite toujours travailler avec le domaine de la résolution ? Ensuite, une règle d’automatisation est requise pour définir la résolution lors de la transition vers un état spécifique. Jusqu’ici, tout va bien.

Problèmes rouverts et champ Résolution

Cependant, dans certains scénarios qui ne sont pas du tout farfelus, il arrive qu’une fois une résolution définie, il faille la remettre à zéro. Un processus atteint le statut final (par exemple “Terminé”) via une transition, et le champ Résolution reçoit ainsi une valeur spécifique en fonction du workflow. Mais ensuite, l’équipe se rend compte qu’il reste encore du travail à faire sur le processus. Ou, comme cela arrive souvent, le ticket a été accidentellement défini sur le statut final.

Dans la plupart des cas, le flux de travail doit permettre au processus d’être retransféré à un état antérieur. Cependant, le problème dans Jira Cloud est que la résolution définie n’est pas automatiquement définie sur zéro lors de cette opération. Par conséquent, le ticket est de nouveau en cours, mais la résolution a de la valeur, donc Jira suppose que le problème est résolu.

Cela peut avoir des implications étendues. Étant donné que la résolution contient une valeur, le ticket apparaît comme fermé dans les rapports et les évaluations, par exemple, bien qu’il soit (à nouveau) en cours de traitement.

Défi pour les administrateurs

Pour que la résolution soit automatiquement supprimée lorsque le statut final passe à un statut précédent, une modification manuelle importante du flux de travail existant est nécessaire – ou de nombreux flux de travail si vous souhaitez éviter que le problème décrit ne se produise dans les projets et dans le monde.

Dans ce cas, l’équipe d’administration devrait attribuer un soi-disant Poste Fonction pour que la résolution soit vidée lors de la réouverture d’un problème. Naturellement, les administrateurs aimeraient éviter un tel effort.

N’est-ce pas également possible via l’automatisation Jira ? L’automatisation peut être utilisée pour modifier la valeur de résolution (“Edit Issue Fields”), mais pas pour nettoyer à nouveau le champ. Ou?

Une solution de la communauté

Cependant, il existe un moyen simple comme l’a démontré un membre de la communauté Atlassian! Le problème peut en fait être corrigé avec une règle d’automatisation. La solution de contournement utilise l’action “Modifier le champ” puis les “Options avancées”.

Voici une capture d’écran de l’utilisateur Yaron montrant la solution élégante :

Cette solution de contournement permet aux administrateurs d’économiser beaucoup d’efforts pour personnaliser les flux de travail dans leurs instances cloud Jira et aide à tirer encore plus parti de l’automatisation Jira.

Et : L’exemple montre très bien la valeur d’une communauté d’utilisateurs active et experte comme la communauté Atlassian : même avec des défis administratifs exigeants, elle offre souvent des idées de solutions pratiques et des solutions de contournement qui aident immédiatement.

Vous souhaitez en savoir plus sur les possibilités d’automatisation de Jira ? Voulez-vous tirer le meilleur parti de votre système Jira et découvrir comment rendre l’administration plus efficace ?

Nos professionnels Atlassian expérimentés sont heureux de soutenir votre équipe avec un Forfait Conseil Plus. Aussi, nous offrons un service dédié Module de formation sur l’automatisation dans Jira qui vous aidera à utiliser Jira avec toutes ses possibilités – et même à réduire l’effort administratif.

Plus d’informations

SOS-IT ! Qu’est-ce que la gestion des incidents ? Et quels outils peuvent vous aider ?
ITSM, ITIL et DevOps : qu’est-ce que c’est ? Le jargon technique expliqué simplement pour les débutants en informatique
Inventaire 24h/24 et 7j/7 : Qu’est-ce que la gestion des actifs informatiques ?