Convention de nommage Jira/JSM : la méthode BleuLemon

Ce qu’il faut retenir en 5 points essentiels :

• Une convention de nommage partagée permet de gagner du temps lors des interventions sur Jira/JSM.

• Elle s’applique aussi bien sur des environnements DataCenter ou Cloud

• Elle favorise la cohérence et la maintenabilité des instances, même complexes.

• Chez BleuLemon, chaque Yuzu est formé à appliquer cette convention sur tous les projets clients.

• Les schémas Jira sont structurants : un nommage clair évite les erreurs et les doublons.

• Une convention n’est jamais figée : elle doit s’adapter à vos pratiques et évoluer avec vos besoins.

Nous allons vous livrer nos bonnes pratiques et surtout notre convention de nommage pour Jira et Jira Service Management (que vous retrouverez certainement sur votre instance) appliquée par tous nos consultants.

1. Qu’est-ce qu’une convention de nommage Jira/JSM et pourquoi c’est critique ?

Pourquoi cette question concerne tous les profils Jira ?

Que vous soyez Chef de projet, Consultant, Développeur, Administrateur de solution comme Jira ou Jira Service Management, vous avez tous déjà eu l’occasion de devoir passer sur le travail d’un collègue pour consulter, corriger ou faire évoluer ce qui a été fait. Vous savez combien il est difficile de reprendre un travail que nous n’avons pas initié, et comme il est possible de perdre un temps fou à se plonger dans la logique de quelqu’un d’autre et qui ne nous appartient pas ! Et je ne vous parle pas de la maintenabilité d’une instance …

Et si un tout petit changement pouvait vous permettre de gagner un temps précieux, seriez-vous prêts à le mettre en place ?

Ce que BleuLemon pratique

Chez BleuLemon, nous essayons d’uniformiser nos pratiques, notre façon de faire et surtout notre façon de paramétrer les outils de manière à permettre à chaque Yuzu de pouvoir reprendre rapidement le flambeau et apporter l’aide demandée par notre client pour corriger / faire évoluer les paramétrages d’une instance. Pour cela, nous avons établi une convention de nommage que l’ensemble des Yuzus applique à chaque intervention chez un client. Chaque nouveau Yuzu est sensibilisé et formé à cette convention de nommage, pour le plus grand plaisir de notre communauté citronnée

Les bénéfices/gains d’une convention de nommage claire et uniformisé

Cette convention de nommage nous permet de partager un langage commun et surtout de gagner un temps précieux lors d’une intervention chez un client, que ce soit une nouvelle intervention ou si l’on reprend le flambeau d’un collègue.

Une convention de nommage claire vous permet de :

• Partager une façon de faire commune, qu’il y ait 1 administrateur ou plusieurs.

• Faciliter la montée en compétences chez nos clients après notre intervention afin de développer de vrais automatismes.

• Anticiper les reprises d’instances par d'autres administrateurs : Pensez aux copains qui reprendraient le flambeau après vous : c’est leur éviter des heures de casse-tête !

• Maintenir les projets complexes sur le long terme : cela permet de garantir une certaine maintenabilité pour les administrateurs.

 Sans convention ou avec convention de nommage

Une convention réduit les erreurs, le temps d’audit et le bruit de reporting, tout en améliorant la maintenabilité et la gouvernance.

Vous trouverez ici schématiquement l’écart de performance et de risque entre une instance sans convention de nommage et une instance alignée sur la convention BleuLemon.

2. Schémas primaires et secondaires : la bonne logique Jira

Toute la structure de configuration des projets Jira ou JSM repose sur la logique de schémas qui sont rattachés à des éléments de configuration qui les composent.

Par exemple :

• Un schéma de types de tickets est composé de différents types de tickets.

Ces liens sont hyper importants car ils nous donnent des indications sur l’ordre de configuration à respecter pour permettre la mise en place de ces schémas, qui sont structurants pour les projets.

On identifie 2 types de schémas :

• Les schémas primaires,

• Les schémas secondaires.

Schémas primaires (ou Primary Scheme) : ITS, FCS, ITSS, WFS, PS

Les schémas primaires correspondent aux Schemes dont les configurations ont une forte adhérence pour le projet et que l’on retrouvera dans tous les cas:

• Issue Type Scheme : Ce schème est simple en termes de configuration mais il a un effet restrictif sur la configuration finale du projet. C’est notamment le cas pour les mises en place de Request Type sur les projets JSM puisque chaque Request Type dépend d’un issue Type dont découle toute la configuration qui suit

• Field Configuration Scheme : L'importance de ce scheme est sous-estimée et ce dernier est souvent mal utilisé. Dans la majorité des cas, il est utilisé pour spécifier :

  • le caractère obligatoire ou optionnel d'un champ;

  • des descriptions de champs divergentes à celle du champ initialement créé (permet de surcharger une description de champ pour l’adapter au contexte du projet);

  • dans quelques cas, sous DC, pour les plus techniques d'entre vous, un comportement altéré au travers de code Javascript injecté dans la description (donc utilisable en mode édition, sauf inline);

  • et rarement, pour cacher un champ (ex : Champ de calcul automatique masqué, etc..). En effet, la plupart d'entre vous préfère s'appuyer sur la présence ou non du champ dans un écran.

• Issue Type Screen Scheme : Ce scheme vous permet d'associer, selon les types de demandes, les écrans par opération (Create, View, Edit) avec leurs champs.

• Workflows Scheme : Ce scheme vous permet d'associer, toujours selon les types de demandes, le Workflow (Flux de travail) à utiliser. 

• Permission Scheme : Ce scheme est important et doit être configuré avec attention, car c’est lui qui va permettre à vos utilisateurs d’accéder ou non au projet. Il est important de le configurer le plus possible avec des rôles projet, de façon à pouvoir le réutiliser pour vos différents projets. C’est l’une des bonnes pratiques que nous recommandons à nos clients.

L'interdépendance de ces schemes peut être plus ou moins forte selon le niveau de complexité de vos Workflows au travers desquels vous pourrez :

• mettre en œuvre des contrôles de cohérence des données saisies => Nécessite des plug-ins en Cloud;

• conditionner les chemins secondaires de vos Workflows;

• et bien plus ...

Schémas secondaires : ISS, NS, IPS

Ils correspondent à des Schemes dont la configuration peut varier plus simplement d'un projet à l'autre sans remettre en cause les Schemes Primaires. Ils ne sont pas tous systématiquement utilisés dans les projets. On y retrouve donc :

• Issue Security Scheme : Très peu utilisé, ce scheme permet de mettre en place la confidentialité des tickets. Dans de très rares cas d'implémentation, il peut être requis de considérer ce scheme comme Primaire, dès lors que le besoin de confidentialité et de restriction d’affichage est présente.

• Notification Scheme : La configuration de ce scheme est tellement secondaire, qu'il peut souvent être retiré de la configuration de votre projet, dès lors que vos utilisateurs sont assez matures pour utiliser des Dashboards bien configurés couplés à d'éventuels abonnements à des filtres. En bref, cela s'adresse à ceux qui en ont marre d'être spammés par Jira. (Si si ça existe !)

• Priority Scheme : Il est considéré secondaire sur les projets Jira mais primaire sur les projets JSM puisque la notion de priorité est très souvent utilisée sur les projets de type “Support”.

Vous assimilez donc ici, que les Schemes Secondaires peuvent passer en Primaire selon vos cas d'usage et en fonction de l’outil.

3. Règles de nommage: codes, syntaxe, exemples

Chaque élément de configuration et chaque système, se doit de respecter une règle de nommage explicite, flexible et appréhendable rapidement.

De part notre expérience, nous respectons toujours quelques principes :

1. Privilégier les acronymes et abréviations des termes anglais pour les éléments de configuration de Jira. Pourquoi ?

   • Jira est développé en anglais et les termes sont quasi inchangés depuis les premières versions,

   • Les traductions françaises des versions successives ont souvent évolué du tout au tout, et cela peut se poursuivre,

   • La documentation de référence est en anglais ... Il n'est pas plus mal de s'y habituer 😉 

2. Essayer de nommer de façon distincte des notions différentes entre projets. Inspirez-vous des méthodes et/ou modèles de gestion de projets qui vous entourent (Scrum, Kanban, ITIL, CMMi ...). Exemple : dans la mesure du possible, un issueType (Type de ticket) doit avoir le même sens dans tous les projets.

3. Respecter une syntaxe de façon uniforme et généralisée du type CodeConfig (NomsConfig) où,

   • CodeConfig est un code (2 à 4 caractères) codifiant le type d'éléments de configurations concernés ...

   • NomsConfig correspondant à une liste non fermée de noms plus au moins discriminants, se rapportant à l'élément de configuration.

Les règles de nommage des concepts

Les règles de nommage des éléments de configurations

Scheme : Issue Type

Scheme : Field

Scheme : Screen

Scheme : Workflow

Scheme : Permission

Scheme : Security

Scheme : Notification

Scheme : Priority

4. Automatisations : conventions, recettes et gouvernance

Les automations peuvent être :

• Globales : partagées pour tous les projets de l’instance JSM et/ou JIRA

• Partagées à plusieurs projets : il suffit de préciser quels sont les projets concernés par l’automation

• Partagées à un type de projet : il suffit de sélectionner le type de projet concerné

• Unique : uniquement pour un seul projet, ce sont des règles locales, propres au projet.

Dans tous les cas, nous vous conseillons :

• De bien nommer votre automation;

• D’expliquer en description ce que permet l’automation et même son contexte d’application et d’utilisation;

• De toujours mettre l’acteur “Automation For Jira” pour l’exécution (pour éviter de mettre en échec les automations si vous utilisez un autre utilisateur qui peut être désactivé lors de son départ de la société).

Il existe aussi une convention de nommage pour les automations, que vous nous partageons ci-dessous :

Gouvernance minimale

• Owner obligatoire : indiquer le propriétaire de la règle (une personne car une équipe ne peut pas être propriétaire)

• Version : (ex: v2) en suffixe du nom si la logique évolue

• Changelog : 1 ligne en description à chaque modification importante (date, auteur, changement)

• Revue périodique : trimestrielle (tests, portée des projets, collisions potentielles)

• Acteur d’exécution : “Automation for Jira”

Au final …

• Convention à suivre telle quelle ou pas , le principal étant d’avoir une et partagée par tous.

• Ne pas hésiter à la remettre en cause dans le temps.

• Si vous utilisez des modèles standards (BluePrint de Jira), pensez à renommer les éléments selon la convention en place.

Foire Aux Questions (FAQ)

1. Avoir des Issues Type identiques : Pertinent ou aberrant ?

• Définition : Un Issue Type Scheme définit la liste des Issue Type, mais pas seulement.

• À faire :

  • En absence d'élément de configuration représentant la notion de Type de Projet, l’Issue Type Scheme est le meilleur candidat pour le formaliser, Donc on s’autorise à avoir 2 Issue Type Scheme ayant les mêmes Issue Type, car ils diffèrent par leur nom, qui est porteur d’information.

2. Comment nommer et structurer les écrans Create/Edit/View et les Transition Screens ?

• Définition :

  • Operation Screens (OS) portent les opérations Create/Edit/View;

  • Transition Screens (TS) concernent aux workflows.

• À faire :

  • Utiliser EN pour les opérations et “Any” si identiques (ex: OS (Tâche, Any));

  • Nommer TS avec des verbes (ex: TS (Démarrer), TS (Assigner)).

3. Quand créer un Workflow par type d’issue plutôt qu’un workflow unique ?

• Définition : un workflow dédié par type d’issue clarifie transitions/écrans et réduit l’ambiguïté.

• À faire : Retarder au maximum la mise en oeuvre des spécificités entre Issue Type (cloner le workflow quand on démarre la partie spécifique à un Issue Type )

4. Request Types vs Issue Types (JSM) : comment mapper correctement ?

• Définition : en JSM, Request Types ≠ Issue Types.

• À faire : Documenter explicitement la correspondance dans les schémas d’écrans (ITSS/SS) et respecter les conventions de nommage existantes. Éviter les ambiguïtés de libellés.

5. Cloud vs Data Center : quelles précautions sur validators, conditions et post‑functions ?

• Définition : la logique de nommage reste identique; les capacités diffèrent.

• À faire : garder les mêmes patrons (ITS, FCS, ITSS, WFS, PS…) et décrire dépendances/effets dans la description (notamment pour validators/conditions/post‑functions).

BleuLemon accompagne les DSI dans leur transformation avec fraîcheur et vivacité d’esprit. Nous aidons les organisations à libérer le potentiel collectif de leurs équipes, en ouvrant la voie à une organisation du travail plus solide et épanouissante.