En installant JIRA, vous installez une instance. C’est à dire, une occurrence du logiciel JIRA. Une instance JIRA peut contenir zéro, un ou plusieurs projets, lesquels sont constitués de demandes, ou issues, qui, elles-mêmes, sont constituées de champs. Ces concepts sont détaillés ci-après.

Les Issues dans JIRA

L’« issue » est l’élément fondamental de JIRA. C’est la plus petite entité pouvant être traitée dans JIRA. Traiter une demande revient à la faire évoluer sur son workflow ou à modifier les champs qui s’y rapportent. D’autres concepts sont associés à la notion d’Issue au sein d’une instance JIRA. Notamment ceux d’Issue Types et de Workflow présentés ci-après.

Les issues types

Les demandes, au sein d’un projet JIRA, sont organisées par type. On parle de type de demande ou « Issue type », en anglais. La configuration par défaut, dite « Classic », de JIRA en propose 4 à ce jour :

•  Bug, pour gérer les remontées de bugs
•  Improvement, pour suivre les demandes d’amélioration
•  New Feature, pour les demandes d’implémentation de nouvelles fonctionnalités
•  Task, pour la gestion des tâches

Comme vous pouvez le constater, les issues types par défaut sont très liées à l’IT et au génie logiciel. Il est possible de les personnaliser en fonction des besoins de votre organisation. Et vous n’êtes pas obligé d’en avoir 4! Par exemple, il m’est arrivé d’implémenter JIRA pour un client dont le besoin se limitait à un seul type de demande : les demandes de travaux soumises à ses équipes de designers. Nous avons donc implémenté un seul type de demandes que nous avons appelé « Demande de travaux ». Rien à voir avec la configuration proposée par défaut… Les issues types peuvent être perçus comme un regroupement « qualitatif » de vos demandes à l’intérieur de votre projet JIRA. Un peu comme si vous aviez un panier rempli de plusieurs « types » de fruits et que vous décidiez de ranger: les pommes avec les pommes, les oranges avec les oranges, etc. JIRA vous permet de gérer plusieurs types d’issues, plusieurs types de demandes, au sein d’un même projet.

Les workflows

JIRA vous permet aussi de suivre, à tout moment, l’état d’avancement de vos issues. Cela est possible grâce à son moteur de workflow. Le workflow, ou flux de travail, en français, se défini comme  » la représentation d’une suite de tâches ou opérations effectuées par une personne, un groupe de personnes, un organisme, etc. Le terme flow (flux) renvoie au passage du produit, du document, de l’information, etc., d’une étape à l’autre ». Dixit Wikipedia. En pratique, je vous propose de retenir que le workflow d’une demande JIRA est l’ensemble des étapes par lesquelles elle peut passer pour que son traitement soit complet. Le workflow d’une demande JIRA inclut, à minima, une étape initiale, unique, et une étape finale, que les bonnes pratiques veulent aussi unique. L’étape initiale est toujours l’étape de création de la demande, généralement suivie de l’étape « Open », l’étape finale est généralement assimilée à l’état « Close ». En outre, le workflow JIRA est fortement personnalisable. Cela veut dire qu’il vous est tout à fait possible de l’adapter aux besoins de votre organisation. La configuration « Classic » suggérée par défaut dans JIRA propose néanmoins un workflow en 5 étapes :

• Open, c’est la première étape, la demande est enregistrée dans le système
• In Progress, un opérateur travaille activement sur la demande
• Resolve, l’opérateur estime avoir traitée la demande et, accessoirement, une validation du traitement est attendue
• Closed, le traitement de l’opérateur est validée, la demande est fermée
• Reopened, la demande est réouverte, pour une raison ou pour une autre, elle est de nouveau d’actualité et les traitements antérieurs sont invalidés

  Les workflows, dans JIRA, implémentent le cycle de vie d’une issue et vous pouvez avoir un workflow spécifique par Issue Type. Autrement dit, toutes les demandes d’un même type, au sein d’un même projet partagent le même workflow.

Les champs

Chaque issue dans JIRA est porteuse d’information. Cette information y est structurée à l’aide de champs. Les champs sont les porteurs de l’information élémentaire dans JIRA. Il en existe de plusieurs types : date, texte long, texte court, liste déroulante, etc. Il est par ailleurs possible de configurer leur caractère obligatoire ou facultatif ainsi que leur valeur par défaut. Les champs permettent de décrire et qualifier une issue. Nous reviendrons sur les champs au cours d’articles plus détaillés.

Projets JIRA et concepts associés

Les projets sont des regroupements de demande dans JIRA. En fonction de vos besoins, un projet JIRA peut servir au suivi de l’activité de n’importe quelle entité fonctionnelle au sein de votre organisation. Par exemple, un projet JIRA peut servir :

• Au suivi des campagnes commerciales réalisées par le département marketing
• Au suivi des demandes de support soumises aux équipes d’un Service Desk
• Au suivi des travaux réalisés par les équipes de développement logiciel
• Au suivi des candidatures traitées par le département des ressources humaines
• Au suivi des demandes d’amélioration ou de maintenance d’un site internet
• A implémenter le circuit de validation des demandes de congés par la hiérarchie et/ou les ressources humaines
• Au suivi des taches, travaux à réaliser par n’importe qu’elle autre entité au sein de votre organisation.

Un projet JIRA se caractérise, entre autre, par :

• Un nom
• Une clé servant de préfixe aux demandes
• Des demandes

La figure ci-après représente un projet JIRA et ses demandes. Le projet se nomme « Site Web », « Website Issues », en anglais. Il a pour clé « WEB » et pour demandes « WEB-101 », « WEB-102 », « WEB-103 », « WEB-104 », « WEB-105 ». Atlassian a beaucoup travaillé à la scalablilité de JIRA ces dernières années. Laquelle est, dans une certaine mesure, liée au nombre d’issues existantes dans votre instance. Vous trouverez les ressources liées à scalabilité de JIRA, mises en avant par Atlassian ici.

Les composants

Il est par ailleurs possible de structurer vos projets JIRA autour de « sous projets », en utilisant la notion de composants. Les composants sont des regroupement logiques des demandes à l’intérieur de vos projets JIRA. L’exemple le plus concret que j’ai trouvé pour illustrer cette notion est tiré de mon expérience d’intégrateur. J’ai déployé JIRA il y a quelques années pour une équipe en charge de la maintenance et de l’évolution d’une dizaine d’applications. Les utilisateurs finaux remontaient des incidents, des bugs, des demandes d’évolution ou des demandes d’assistance relatives à l’une ou l’autre des applications du périmètre. Chaque application était associée à un composant JIRA, ce qui permet d’extraire des statistiques précises sur les applications les plus sollicitées, les plus sujettes aux anomalies, etc. Les composants correspondent à un découpage structurelle de votre activité. Bien souvent, il sont associé à une notion de « sous périmètre » et de délégation de responsabilités.

Les versions

La notion de version prend tout son sens dans un contexte de développement logiciel. Il n’est généralement pas possible de traiter toutes les demandes en même temps. L’idée est de les regrouper par lots, ou versions. Lesquels feront, chacune pour sa part, l’objet d’une livraison spécifique. Les versions correspondent à un échelonnement dans le temps des échéances de livraison des issues. L’illustration ci-dessous présente le Road Map gadget utilisé pour visualiser les versions en cours sur un tableau de bord JIRA. On y retrouve :

• Le nom de la version (Angry Nerds 3.0, 2.0 et 2.1)
• La date de livraison prévue pour chaque version (17/Feb/13, 27/Mar/13, 27/Mar/13)
• Le nombre de demande traités vs restante pour chaque version

Rôles et groupes

Les rôles sont un moyen flexible d’associer des utilisateurs ou des groupes à un projet dans JIRA. C’est un des moyens dont vous disposer pour autoriser des utilisateurs JIRA à intervenir sur un projet donné. Rôles et groupes sont souvent confondus dans JIRA. Et pourtant, il faut bien comprendre que les rôles ont une portée locale, ils ont une consistance spécifique au projet. Un utilisateur ne « joue » un rôle que dans un projet donné. C’est ce qui permet aux utilisateurs d’avoir un rôle différent d’un projet à l’autre. Les groupes en revanche ont une portée globale. La consistance d’un groupe s’applique à toute l’instance. Si je suis membre du groupe « Administrateurs », je le suis pour tous les projets de l’instance. C’est ce qui permet aux administrateurs d’intervenir sur n’importe quel projet de l’instance. Une bonne pratique consiste à favoriser l’utilisation des rôles en matière de gestion des autorisations et des niveaux de sécurité. Procéder autrement peut rapidement se révéler fastidieux, au fur et à mesure que le nombre de vos projets JIRA et de leurs utilisateurs augmentent.   Voilà! Je vous ai tout dit! Vous possédez désormais les fondamentaux nécessaires à une prise en main réussi de JIRA. Et si vous faisiez un tour par la section Premiers pas pour mettre la main à la pâte 😉