Configurer JIRA est la panacée des intégrateurs. C’est un peu mon fond de commerce. L’exercice peut sembler hasardeux mais en réalité, il s’articule autour de neuf grands axes qui correspondent à neuf éléments de configuration disponibles en natif dans JIRA :

1. Les rôles utilisateurs
2. Les types de demande
3. Les champs
4. Les écrans
5. Les notifications
6. Les niveaux de sécurité des demandes
7. Les autorisations de projet
8. Les workflows
9. Les catégories de projet

Examinons les de plus près. Les lignes qui suivent ne feront pas de vous un expert aguerri. Elles devraient néanmoins améliorer votre compréhension des leviers dont vous disposer nativement en matière de configuration JIRA.

1. Les rôles utilisateurs

Nous avons précédemment présenté la notion de rôle comme un des concepts fondamentaux de JIRA. C’est par là que tout commence car tout dans JIRA, ce que vous pouvez faire ou ne pas faire, et ce que vous pouvez voir ou ne pas voir, au sein d’un projet, est lié au rôle que vous y jouez.

2. Les types de demande

Les types de demande, « issue types » en anglais, sont tout aussi indispensables à la configuration de projet JIRA. Ils sont nécessaires pour configurer les champs, les écrans et les workflows. JIRA vous réclamera toujours au moins un type de demande par projet.

3. Les champs

[sociallocker id=”1552″]

Vous devrez définir, pour chaque type de demande que vous aurez configurées, les champs qui vont avec, ainsi que leur caractère obligatoire ou non et leur comportement. Bien entendu, qui peut le plus peut le moins: vous pouvez tout à fait disposer d’une seule et unique configuration de champs pour tous vos types de demandes si cela vous en dit.

4. Les écrans

Il existe deux catégories d’écran dans JIRA : les écrans d’opération et les écrans de transition. Les écrans d’opération sont au nombre de trois :

• L’écrans de création, qui sert à créer des demandes
• L’écran d’édition, qui sert à éditer des demandes
• L’écran de vue, qui sert à visualiser des demandes

Les écrans de transition sont des écrans que vous pouvez utiliser pour afficher ou mettre à jour des données sur une transition du workflow. Vous pouvez créer au maximum un écran par transition du workflow. La configuration d’écran consiste à définir l’ensemble des écrans qui seront utilisés par le projet JIRA et, pour chacun d’entre eux, les champs qu’ils contiendront.

5. Les notifications

Vos utilisateurs ne sont pas nécessairement connectés à JIRA en permanence. C’est pourquoi, l’outil peut leur envoyer des e-mails de notification pour leur signifier qu’une action est requise de leur part. Configurer les notifications d’un projet JIRA consiste à définir, en fonction des événements (Création, résolution, attribution des demandes, etc.) qui surviennent dans le cadre du projet, les populations d’utilisateurs qui seront notifiées. Par exemple : « Notifier l’auteur de la demande quand cette dernière est traitée » est une action qui devra être configurée à cette étape. La population, ici, est constituée par l’ »auteur » de la demande et l’événement en question est demande « traitée ». Nous reviendrons plus en détails sur la gestion des événements dans JIRA au cours d’articles dédiés.

6. Les autorisations

Pour des raisons de confort, de clarté, de lisibilité ou de confidentialité, on veut souvent cloisonner les taches et les responsabilités d’un projet JIRA à un autre ou d’une étape du workflow à une autre. Selon les cas, tout le monde n’a pas envie, n’a pas besoin ou n’a pas le droit de voir toutes les demandes de tous les projets; de créer des demandes dans tous les projets; de traiter toutes les demandes de tous les projets; etc. La configuration des autorisations permet d’implémenter ces contraintes. Elle permet d’attribuer des autorisations spécifiques à des populations spécifiques. Par exemple : « Seuls les membres du back office ont le droit de traiter des demandes » est une contrainte qui pourra être implémentée à cette étape. Nous reviendrons plus en détails sur les autorisations dans JIRA au cours d’articles dédiés

7. Les niveaux de sécurité

Il arrive que l’on veuille restreindre la visibilité de certaines demandes au sein d’un même projet. Par exemple, on peut imaginer que la teneur de certaines demandes soumises via JIRA ne doit être connue que du commanditaire et des exécutants. Ces demandes ne doivent donc en aucun cas être visible par des tiers. La configuration des niveaux de sécurité permet de prendre en compte cet aspect.

8. Les workflows

Le workflow est certainement l’épine dorsale de votre configuration car tout lui est relié : aussi bien les champs et les écrans qui sont dépendants du type de demande, que les notifications et les autorisations, voir les niveaux de sécurité, qui sont dépendants des rôles et des groupes d’utilisateurs. C’est lui qui implémente le cycle de vie de votre demandes, les étapes de traitement de votre issue, de son identification à sa résolution. Configurer un workflow c’est donc définir ces étapes en tenant compte des contraintes, des données et des traitements associées. Vous pouvez configurer au maximum un workflow par projet et par type de demande.

[/sociallocker]

9. Les catégories de projet

JIRA vous permet d’organiser vos projets en catégories. Chaque projet peut appartenir à une catégorie au maximum. Vous créez vous-même vos catégories et les affectez à vos projets. Cet aspect n’est pas aussi décisif que les précédents en matière de configuration mais permet de gagner en visibilité au fur et à mesure que les projets se multiplient au sein de votre instance.

C’est fait! Si vous m’avez suivi jusqu’au bout, vous connaissez désormais les tenants et les aboutissants d’une configuration JIRA ainsi que les fonctionnalités que vous fournit le socle standard en matière de personnalisation et d’adaptation à votre situation spécifique. Je recommande d’implémenter ces différents axes dans l’ordre précité car ils sont pour la plupart interdépendants. Par ailleurs, la configuration des axes 2 à 8 requiert de bien avoir assimilé la notion de « systèmes », « Schemes », en anglais, sur laquelle nous reviendrons au travers d’un article dédié. Enfin, si comme plusieurs des clients que j’ai eu l’occasion d’accompagner vous avez des besoins ultra spécifiques, sachez que le code de JIRA est ouvert. Vous pouvez toujours le personnaliser en développant un plugin. Je suis néanmoins convaincu que vous n’avez pas l’intention de réinventer la roue! Faites donc un tour par la Marketplace Atlassian. Sinon, j’ai recensé pour vous les plugins que j’utilise le plus souvent, peut-être y trouverez-vous votre bonheur.