Les nouveaux domaines d’application de JIRA


Publié par
François DUSSURGET

21 août 2009

A l’origine conçu pour couvrir les besoins de Bug Tracking, JIRA s’est rapidement imposé comme un Issue Trackers auprès des équipes de développement de logiciels. Ses qualités ergonomiques et sa puissance de paramétrage ont permis d’étendre rapidement son domaine d’application à la gestion des demandes métiers, des exigences, des risques voir la gestion de portefeuille projet. De grands groupes ont d’ailleurs aujourd’hui basé l’industrialisation de leur processus CMMI Niv3 sur la solution JIRA.

En parallèle, chez ces mêmes clients,  le succès du déploiement de JIRA a fait des émules au sein des services en charge du support applicatif, on retrouve ainsi assez fréquemment cette solution comme socle technique pour la gestion des tickets et l’industrialisation d’un certain nombre de processus ITIL. Bien évidemment, il n’est pas question de concurrencer directement les acteurs majeurs de ce secteur mais à l’heure ou l’on recherche activement à optimiser les investissements, JIRA  est une solution « light tools » qui prend de plus en plus de sens sur le marché.

Plus étonnant, dans certaines structures , JIRA se révèle être une brique importante du système d’information avec à sa charge l’industrialisation  de certains processus business…

  • Ludovic Lambert

    En fait la multiplication des instances JIRA n’est pas un véritable problème sous réserve d’isoler les instances *par processus* et non pas par entité métier ou pays.

    Recommandé: avoir une instance JIRA pour gérer les tickets de développement, une autre pour gérer les tickets de support et une 3ème pour gérer les demandes d’achat.

    A éviter : créer plusieurs instances de JIRA couvrant le même périmètre processus pour différentes entités.

    Dans le 1er cas, les intégrations, la configuration, les utilisateurs sont homogènes par environnement, le caractère collaboratif et l’administration sont saufs.

    Dans le 2nd cas, les interactions sont difficiles, la configuration est multipliée (et généralement en doublons), l’administration rendue plus que laborieuse.

    Quelle que soit l’architecture retenue, Crowd devient impératif afin d’avoir une gestion des identités cohérente entre les environnements, ainsi que le SSO pour les utilisateurs amenés à travailler sur plusieurs instances.

  • Stephane Oberlechner

    Dans notre groupe (15000 personnes), JIRA était initialement prévu pour la DSI, soit 200 collaborateurs. Trés vite, les différentes directions métiers y ont adhéré par capillarité. Aujourd’hui, ces dernières nous demandent leur propre instance JIRA afin d’étendre son utilisation et de ne pas limiter l’usage aux seules demandes de changement. Par contre, démultiplier le nombre d’instances JIRA risque de réduire fortement le caractère collaboratif de l’outil. Il semble y avoir assez peu de témoignage client sur ce type de demandes.

  • Romain DEGUIL

    En effet, l expérience montre que JIRA prend vite une place « centrale » dans le SI. Ceci est sans doute du à sa simplicité d’utilisation et d’adminstration : les utilisateurs ont vite tendance à faire exploser le périmètre initialement prévu lors du premier déploiement de l’outil !