Les bonnes questions

Dans le précédent épisode, nous avons vu ensemble comment mettre en oeuvre un projet Jira et communiquer autour de son usage pour vous permettre, en tant qu’organe de gouvernance de votre intstance Jira, de mieux suivre les changements demandés.

Nous allons désormais passer au second volet, à savoir, la définition de types de demandes et de champs mieux adaptés au support !

Notre objectif aujourd’hui, tout mettre en oeuvre pour que vos collègues utilisateurs de Jira n’aient jamais cet air face à votre projet de Support Jira (SJ). Il s’agira de le guider au mieux dans la formulation de son besoin, tout en captant un maximum d’informations utiles.

Bien entendu, de nombreux autres champs pourront être envisagés, et j’aurais tendance à dire que seule votre imagination en sera la limite. Cela dit, la mesure à du bon aussi, personne n’aime remplir un formulaire de dix pages !

Nous adresserons donc dans l’ordre : 

  • Les types de demandes
  • Les écrans
  • Les champs personalisés

Types de demandes ou Issue types

A la création du projet SJ, Jira a instancié automatiquement quelques types de demandes, et les a associé au projet par l’intermédiaire d’un schéma de types de demandes. Ces demandes sont par défaut : 

  • Epic
  • Story
  • Bug
  • Task
  • Subtask

On pourrait vouloir des éléments plus parlants pour vos utilisateurs, et se rapprocher autant que possible de leurs besoins ou des problèmes qu’ils pourraient rencontrer, par exemple :

  • Accès
  • Formation

Pour créer des types de demandes, il vous faut aller dans (Jira Administration) > Issues > Issue Types > Add issue type

Nous recommandons de créer les types de demandes dans la langue de la plateforme choisie à l’installation, anglais la majorité du temps. Après avoir renseigné un Nom et une Description, il vous faudra choisir s’il s’agit d’un type de demande Standard ou d’une sous-tache. La seule différence est qu’une sous-tache ne peut exister sans être reliée à une demande parent.

Une fois le type de demande créée, il vous est possible de :

  • Cliquer “Edit” pour ajouter une icone de votre choix pour le type de demande
  • Cliquer “Translate” pour ajouter une traduction du nom du type de demande dans les différentes langues prises en charge dans votre plateforme.

Observez que les types de demandes que vous avez créés ne sont pas encore accessibles dans l’écran de création de demande pour le projet SJ. Il faut encore modifier le schéma de types de demandes qui permet l’association entre les types de demandes et le projet.

Pour ce faire, aller dans (Jira Administration) > Issues > Issue type schemes

Le schéma de type de demande par défaut contient tous les types de demandes existants, avec le temps, il devient de plus en plus impraticable. En revanche, lors de la création du projet, un schéma de type de demandes propre au projet SJ a été créé.

Après l’avoir retrouvé dans la liste, clickez sur edit afin de choisir par drag and drop les types de demandes qui seront valides pour ce schéma. Retirons ainsi les Epics et Stories, et ajoutons les types de demandes fraîchement crées.

Profitez en également pour définir un type de demande par défaut.

Si des demandes existaient déjà d’un type que vous venez de retirer, l’application vous proposera de les migrer vers un type toujours valide.

Vérifiez que les changements sont biens pris en compte en essayent de créer une nouvelle demande dans le projet SJ. La liste des types de demandes doit être mise à jour.

A l’avenir, sachez qu’il est possible d’associer un meme schéma de type de demande à plusieurs projets. Veillez aux indications du cartouche sous le nom du schéma pour éviter d’impacter des projets qui ne doivent pas l’être. Procédez à une copie du schéma au besoin en amont, puis associez la copie au(x) projet(s) concernés !

Ecrans ou Screens

Les écrans définissent quels sont les champs qui seront présentés à l’utilisateur dans deux contexte bien spécifiques : 

  • Lors d’une transition spécifique d’un état à un autre pour une demande. Nous verrons ce point un peu plus tard.
  • Lors d’une action sur une demande parmi : 
    • Création
    • Consultation
    • Edition

Ce sont ces derniers qui vont nous intéresser ici. Un écran pour chacun de ces actions sont regroupés dans un Screen Scheme ou Schéma d’écran pour les francophones. 

Ces Schémas d’écrans sont ensuite mis en correspondante à des types de demandes au sein d’Issue Type Screeen Schemes ou Schémas d’écrans de types de demandes

Maintenant, assez de théorie ! Si on aborde les relations pas forcément évidente entre l’écran et le projet, c’est avant tout parce que les champs proposés au sein du projet SJ sont pas franchement pertinents !

Que pourrait bien vouloir dire Fix Version pour une demande d’accès, ou encore que voudrait dire Composant ? 

Pour changer les champs proposés dans les écrans de notre projet de support, nous partirons de la configuration du projet lui-meme.

Clicker en bas à gauche de l’écran de consultation d’une demande du projet :  (Project Administration) > Screens

Observez que par défaut un système d’écran spécifique aux bugs et un second, associé à tous les autres types de demandes ont été créés.

N’hésitez pas à déployer les détails de chaque schéma avec le chevron devant leur nom.  Vous observez ainsi que  les trois actions (Création, Edition, Consultation) utilisent le même écran.

En cliquant sur le nom de ces écrans, il vous devient alors possible de choisir quels champs seront présents, ainsi que modifier leur ordre d’apparition.

Comme convenu, je vous laisse retirer : 

  • Component/s
  • Fix Version/s
  • Security Level
  • Epic Name
  • Epic Link

Ajoutons un champs supplémentaire, la date d’échéance par exemple, sur les écrans applicables à toutes les demandes à l’exception des Bugs. Pour ce faire, revenez à l’écran précédent, clicker sur le lien des écrans applicables aux types de demandes souhaitées, et ajoutez à la liste le champs Due Date. Pourquoi sur tous les types de demandes et pas les Bugs ? Car la réponse sera toujours “Pour hier !”.


Pour aller plus loin

Il est possible de proposer des champs différents pour chaque actions sur la demande.

La création d’écran spécifique à chaque action et leur ajout au système d’écran est laissé en exercice au lecteur.

https://confluence.atlassian.com/adminjiraserver073/associating-screen-and-issue-operation-mappings-with-an-issue-type-861253453.html


Champs personnalisés ou Custom Fields

Jira propose un ensemble de champs de base (dits system) tels que le résumé, la date d’échéance, ou encore le rapporteur. Il est possible d’étendre ces champs par des champs personnalisés aussi connus sous le nom de Custom Fields. Ceux-ci vous permettent de formaliser un peu plus le contenu des demandes, et guider vos utilisateurs pour la saisie de ces informations.

Pour l’exercice, nous allons créer : 

  • CC : Un champs “Multiple User Picker” qui servira à indiquer quels utilisateurs sont également concernés par une demande; l’équivalent du champs CC de nos emails.
  • Scope : Un champs “Project Picker” qui permettra d’indiquer quel projet est concerné par une demande.

Notez bien que de nombreux types de champs existent et qu’ils peuvent également être étendus par des plugins.

Pour ajouter un champs personnalisé, clicker sur (Jira Administration) > Issues > Custom fields > Add custom field.

Comme pour les types de demandes, tachez de les créer dans la langue d’installation puis d’utiliser l’option sur chacun d’eux  > Translate.

Lors de la création d’un champs personnalisé, Jira vous invite à l’ajouter à des écrans, faute de quoi ils ne seront pas visibles ni éditables. Il est en revanche ajouté à toutes les Field Configuration, le rendant permis et optionnel. Ce sont ces éléments qui permetent de définir quels champs sont requis ou non, valides ou non.

Une fois ces écrans créés et ajoutés aux écrans manipulés précédemment, vérifiez que tout s’affiche correctement.

Résumons les associations entre Schemes et les projets

Comme on dit souvent, une image vaut mieux que mille mots. Le diagramme ci-dessous représente l’articulation des différents objets que nous avons manipulés. Enfin, sauf pour les workflow, mais ca ne saurait tarder ! Vous en apprendrez plus sur les workflow et schémas de workflows dans nos prochains articles !

Gael Motte
Gael Motte

Consultant Avant Vente Solutions Atlassian

Recommandations