> Amélioration continue des processus > Cycle de développement logiciel > Jira Software > Modèle de données

Votre modèle de données pour le cycle de vie du développement logiciel

Jira Software

Attributs du cycle de vie du développement logiciel(21) Activités du cycle de vie du développement logiciel(14) Guides d’extraction(4)

Votre modèle de données pour le cycle de vie du développement logiciel

Ce modèle vous guide dans la collecte des données essentielles à l’analyse du cycle de vie du développement logiciel. Il présente les principaux champs à recueillir, les étapes du processus à suivre et des conseils pratiques pour extraire ces informations de Jira Software. Suivez ce guide pour préparer votre journal d’événements à l’analyse Process Mining.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils d’extraction pour Jira Software

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du cycle de vie du développement logiciel

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail le cycle de vie du développement logiciel.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité Activity	Nom d’un événement précis ou d’un changement de statut survenu au cours du cycle de développement d’un élément.
Description Cet attribut désigne une étape ou un jalon précis du processus de développement logiciel. Les activités sont déduites des changements du champ de statut de la demande Jira ou d’autres événements importants, comme les validations de code ou les revues. En Process Mining, la séquence de ces activités forme la carte du processus. Leur analyse permet de repérer le déroulement du processus, de mesurer la durée de certaines étapes et de détecter les écarts par rapport au flux de travail standard, comme les boucles de reprise ou les contrôles qualité omis. Pourquoi est-ce important ? Les activités définissent les étapes du processus. Leur séquence permet de visualiser son déroulement, de repérer les goulots d’étranglement et d’analyser les variations. Où trouver ces données Généralement déduit des transitions du champ « status » dans l’historique ou le journal des modifications de la demande Jira. Il est également possible d’enrichir cet attribut avec les données d’outils de développement connectés. Exemples Développement commencéRevue de code effectuéeTests d’assurance qualité terminésDéployé en production
	Élément de développement DevelopmentItem	Identifiant unique d’une unité de travail dans Jira Software, par exemple un récit utilisateur, une anomalie ou une tâche.
Description L’élément de développement sert d’identifiant principal du cas et représente une unité de travail distincte, comme une fonctionnalité, une correction d’anomalie ou une tâche. Il relie toutes les activités associées à cet élément, de sa conception et sa planification initiales jusqu’au développement, aux tests et au déploiement. Dans Jira, il correspond généralement à la clé de la demande, par exemple « PROJ-123 ». L’analyse de cet attribut permet de retracer le cycle de vie complet de chaque élément de travail. Il constitue la base de la création de cartes de processus, du calcul des temps de cycle et de l’identification des différences dans le parcours des divers éléments au fil du processus de développement. Pourquoi est-ce important ? Cette clé essentielle relie toutes les activités de développement associées et permet de suivre une unité de travail de son début à sa fin. Où trouver ces données Il s’agit du champ « key » standard d’une demande dans l’objet Issue de l’API Jira Software. Exemples PROJ-101CORE-5432API-789
	Heure de l’événement EventTime	Date et heure exactes auxquelles une activité ou un événement de développement précis s’est produit.
Description L’heure de l’événement est l’horodatage qui indique quand une activité a eu lieu. Elle constitue la base temporelle de toute analyse Process Mining et permet de remettre les événements de chaque cas dans l’ordre chronologique. Cet attribut est indispensable au calcul de toutes les métriques temporelles, notamment les temps de cycle, les durées de traitement et les temps d’attente entre les activités. Il permet d’analyser les performances du processus au fil du temps et de repérer les moments et les étapes où des retards surviennent dans le cycle de développement. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner correctement les événements et calculer toutes les métriques de durée, essentielles à la compréhension de l’efficacité du processus et à l’identification des retards. Où trouver ces données Correspond à l’horodatage « created » de chaque entrée du journal des modifications ou de l’historique d’une demande. Exemples 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données du processus depuis le système source.
Description Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis Jira Software. Il indique à quel point les données analysées sont récentes. Connaître la date de la dernière mise à jour permet de juger de l’actualité des analyses du processus. Les analystes et les utilisateurs métier peuvent ainsi vérifier qu’ils consultent des données à jour et connaître la date limite des événements inclus dans l’analyse. Pourquoi est-ce important ? Indique l’actualité des données, afin que les analyses et les Dashboards reflètent l’état le plus récent du processus. Où trouver ces données Cet horodatage est généré et enregistré à la fin du processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Système source SourceSystem	Système d’où proviennent les données extraites sur le cycle de développement.
Description Cet attribut indique l’origine des données. Pour ce processus, sa valeur sera toujours « Jira Software », mais il permet de distinguer les données lorsque plusieurs systèmes sources sont réunis dans une analyse plus large. Dans un environnement informatique plus vaste, préciser le système source assure la traçabilité des données et facilite la gestion de leur qualité ainsi que leur intégration entre différentes plateformes. Pourquoi est-ce important ? Assure la traçabilité de l’origine des données, un point important lors de leur intégration depuis plusieurs systèmes, ainsi que pour leur gouvernance et les audits. Où trouver ces données Il s’agit d’une valeur statique à ajouter lors de l’extraction et de la transformation des données. Exemples Jira Software
	Nom de l’équipe TeamName	Équipe de développement responsable de l’élément de travail.
Description Désigne l’équipe agile ou l’équipe produit chargée de l’élément de développement. Dans Jira, cette information est souvent enregistrée dans un champ personnalisé ou déduite d’autres éléments, comme le projet ou un composant précis. Cet attribut est essentiel à l’analyse des performances par équipe. Les Dashboards peuvent être filtrés pour afficher, par équipe, des métriques telles que le temps de cycle, le taux de reprises et le débit. Il est notamment utilisé dans les Dashboards « Inter-Phase Handoff Efficiency » et « Developer Workload & Item Progress ». Pourquoi est-ce important ? Permet de mesurer et de comparer les performances des équipes de développement, de repérer celles qui obtiennent de bons résultats et de partager leurs pratiques. Où trouver ces données Il s’agit souvent d’un champ personnalisé dans Jira. Demandez à votre administrateur Jira de vous indiquer son nom exact, qui peut être « Team », « Squad » ou un terme similaire. Exemples Équipe PhoenixServices centrauxLes Avengers de l’interface utilisateur et de l’expérience utilisateur
	Nom du projet ProjectName	Nom du projet Jira auquel appartient l’élément de développement.
Description Dans Jira, les éléments de travail sont organisés en projets. Le nom du projet fournit un contexte général et correspond souvent à un produit, une équipe ou une initiative. Cet attribut est une dimension utile pour filtrer et comparer les données. Il permet d’analyser et de comparer le processus de développement logiciel (SDLC) entre différents projets ou produits. Vous pouvez ainsi repérer les projets les plus efficaces, ceux qui nécessitent davantage de reprises et les différences de pratiques entre les équipes. Pourquoi est-ce important ? Permet de segmenter l’analyse du processus par projet, produit ou équipe, afin de comparer les performances et de repérer les bonnes pratiques. Où trouver ces données Il s’agit du champ « project » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Développement de l’application mobilePlateforme centraleScience des données
	Personne assignée Assignee	Utilisateur actuellement chargé de traiter l’élément de développement.
Description La personne assignée est responsable de l’élément de travail à l’étape où il se trouve. Dans Jira, il s’agit d’un champ standard qui change lorsque l’élément passe d’une personne ou d’une équipe à une autre. L’analyse de la personne assignée aide à comprendre l’affectation des ressources, la répartition de la charge de travail et les transferts entre intervenants. Elle permet de savoir quels développeurs ou équipes participent à certaines étapes, où se trouvent les goulots d’étranglement et comment le travail est réparti dans l’organisation. Pourquoi est-ce important ? Identifie l’utilisateur ou la ressource responsable d’une activité, ce qui permet d’analyser la charge de travail, de gérer les ressources et de comprendre les transferts entre personnes. Où trouver ces données Il s’agit du champ « assignee » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Alice SmithBob JohnsonNon attribué
	Priorité de l’élément ItemPriority	Niveau de priorité attribué à l’élément de développement, qui indique son degré d’urgence.
Description La priorité de l’élément indique son importance ou son degré d’urgence par rapport aux autres. Jira propose un champ standard « priority » avec des niveaux configurables, comme Highest, High, Medium et Low. L’analyse des priorités est essentielle pour vérifier la conformité et repérer les goulots d’étranglement qui touchent les éléments prioritaires. Par exemple, le Dashboard « Priority Item Conformance Check » s’appuie sur cet attribut pour vérifier si les éléments prioritaires sont traités plus rapidement, comme prévu, ou s’ils restent bloqués dans les mêmes files d’attente que les éléments moins prioritaires. Pourquoi est-ce important ? Permet de vérifier si les éléments prioritaires sont traités plus rapidement que les autres et suivent un parcours plus direct, afin de respecter les SLA. Où trouver ces données Il s’agit du champ « priority » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples La plus élevéeÉlevéeMoyenneFaible
	Statut de l’élément ItemStatus	Statut actuel de l’élément de développement dans son flux de travail.
Description Cet attribut indique l’étape précise à laquelle se trouve l’élément de développement à un moment donné, par exemple « In Progress », « In Review » ou « Done ». La séquence des changements de statut au fil du temps génère les activités analysées en Process Mining. L’attribut « Activity » représente l’événement de changement, tandis que « ItemStatus » indique l’état de l’élément. Il sert de dimension pour le filtrage et l’analyse : vous pouvez ainsi voir combien d’éléments se trouvent actuellement dans un état donné ou étudier les caractéristiques de ceux qui restent longtemps dans un même statut. Pourquoi est-ce important ? Donne un aperçu de l’étape du cycle de vie à laquelle se trouve un élément. Il est essentiel pour les analyses par statut et pour comprendre l’état actuel du travail en cours. Où trouver ces données Il s’agit du champ « status » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples À faireEn coursEn revueTerminé
	Type d’élément ItemType	Catégorie de l’élément de développement, par exemple anomalie, récit utilisateur, tâche ou epic.
Description Le type d’élément indique la nature du travail effectué. Jira utilise le champ standard « issuetype » pour distinguer les différentes catégories d’éléments de travail, qui suivent souvent des flux de travail différents. Cet attribut est essentiel pour les analyses comparatives. Il permet de filtrer le processus selon le type de travail, par exemple pour comparer le cycle de vie d’une anomalie à celui d’un récit utilisateur. Vous pouvez ainsi déterminer si certains types de travail sont davantage sujets aux retards, aux reprises ou aux écarts par rapport au processus standard. Pourquoi est-ce important ? Permet de segmenter l’analyse du processus pour comparer le traitement de différents types de travail, comme les anomalies et les nouvelles fonctionnalités, et repérer les différences entre leurs processus. Où trouver ces données Il s’agit du champ « issuetype » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Récit utilisateurAnomalieTâcheEpic
	Composant Component	Sous-section ou domaine fonctionnel d’un projet auquel appartient l’élément.
Description Dans Jira, les composants servent à répartir les demandes d’un projet en sous-ensembles plus faciles à gérer. Ils peuvent désigner un domaine fonctionnel, comme l’authentification des utilisateurs, une couche technique, comme l’API backend, ou un module, comme la génération de rapports. L’analyse par composant offre une vue plus détaillée du processus de développement. Elle permet de repérer les parties de l’application qui génèrent davantage d’anomalies, présentent des cycles de développement plus longs ou nécessitent plus de reprises, ce qui peut signaler une dette technique ou une complexité particulière. Pourquoi est-ce important ? Permet de segmenter le processus par domaine fonctionnel ou technique du produit et de repérer les composants à l’origine de retards ou de problèmes de qualité. Où trouver ces données Il s’agit du champ standard « components » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Interface utilisateurBase de donnéesPasserelle APIAuthentification
	Déclarant Reporter	Utilisateur qui a créé ou signalé l’élément de développement à l’origine.
Description Le déclarant est la personne qui a créé la demande dans Jira. Il peut s’agir d’un développeur, d’un testeur en assurance qualité, d’un responsable produit ou même d’un client, via une intégration avec un centre de services. L’analyse du déclarant permet de comprendre l’origine du travail. Vous pouvez, par exemple, comparer le cycle de vie des anomalies signalées par l’équipe d’assurance qualité à celui des anomalies signalées par les clients. Elle aide aussi à comprendre les modes de communication et la circulation de l’information au début du processus. Pourquoi est-ce important ? Indique l’origine de l’élément de travail et permet d’analyser les tendances selon les personnes qui créent les tâches ou signalent les anomalies. Où trouver ces données Il s’agit du champ « reporter » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Charles DarwinMarie CurieIsaac Newton
	Heure de fin de l’événement EventEndTime	Horodatage auquel une activité ou un statut a été achevé.
Description Cet attribut indique l’heure à laquelle une activité s’est achevée. Il correspond à l’horodatage de l’activité suivante dans la séquence d’un cas donné. Alors que « EventTime » (StartTime) marque le début d’une activité, EventEndTime en indique la fin. La différence entre ces deux horodatages correspond à la durée de traitement de l’activité. Cette donnée est essentielle au calcul du KPI « Average Stage Processing Time » et à la création de Dashboards qui analysent la durée des activités. Pourquoi est-ce important ? Indique la fin d’une activité et permet de calculer la durée de chaque étape du processus, ce qui est essentiel à l’analyse des goulots d’étranglement. Où trouver ces données Il s’agit d’un attribut dérivé. Pour un événement donné, l’heure de fin correspond à l’heure de début de l’événement suivant pour le même cas. Exemples 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	Nom du sprint SprintName	Nom du sprint agile auquel l’élément de développement est affecté.
Description Pour les équipes qui utilisent Scrum, le sprint est une période de durée définie pendant laquelle un ensemble de travaux est réalisé. Cet attribut indique le nom ou l’identifiant du sprint auquel appartient un élément. L’analyse par sprint est essentielle au Process Mining dans les équipes agiles. Elle permet d’évaluer les performances de chaque sprint, de comprendre les reports de travail et de suivre l’avancement par rapport aux objectifs du sprint. Elle fournit un contexte temporel plus précis que de simples plages de dates. Pourquoi est-ce important ? Fournit un contexte important aux équipes agiles et permet d’analyser l’efficacité du processus et le débit sprint par sprint. Où trouver ces données Cette information est généralement stockée dans un champ personnalisé « Sprint », géré par Jira Software (Agile). Elle est accessible via l’API Issue. Exemples Sprint 1 du projetSprint 3 du T4 2023Sprint 2 du PI de novembre
	Reprise IsRework	Indique si une activité fait partie d’une boucle de reprise.
Description Cet attribut booléen prend la valeur vraie lorsqu’une activité correspond à un retour en arrière dans le processus, par exemple lorsqu’un élément revient à l’étape « Développement démarré » après avoir échoué aux tests d’assurance qualité. Il est déterminé en analysant la séquence des activités d’un cas. Repérer les reprises est essentiel pour améliorer l’efficacité et la qualité des processus. Cet attribut alimente directement l’indicateur « Taux d’activités de reprise » et le Dashboard « Fréquence et parcours des boucles de reprise ». Il permet de quantifier les efforts perdus et de repérer les causes profondes des problèmes de qualité qui entraînent des reprises. Pourquoi est-ce important ? Signale explicitement les activités qui s’inscrivent dans des boucles de reprise inefficaces, afin de mesurer et d’analyser précisément le gaspillage et les problèmes de qualité dans le processus. Où trouver ces données Il s’agit d’un attribut calculé. Vous devez définir le flux de processus attendu, puis signaler toute activité qui s’en écarte en revenant à une étape antérieure. Exemples truefalse
	Résolution de l’élément ItemResolution	Issue finale ou motif de clôture d’un élément de développement.
Description La résolution explique pourquoi un élément a été placé dans un état de clôture. Le statut peut être « Closed », tandis que la résolution indique « Done », « Won’t Do », « Duplicate » ou « Cannot Reproduce ». Elle apporte un contexte important sur l’issue du travail. L’analyse de la résolution permet de distinguer le travail mené à bien des éléments annulés ou rejetés. Cette distinction est importante pour l’analyse de la qualité et pour comprendre le volume réel de travail utile, par opposition aux efforts consacrés à des éléments finalement abandonnés. Pourquoi est-ce important ? Distingue les éléments menés à bien de ceux clôturés pour d’autres raisons, ce qui est essentiel pour analyser avec précision la productivité et la qualité. Où trouver ces données Il s’agit du champ « resolution » dans l’objet « fields » de la réponse de l’API Jira Issue. Il est généralement renseigné uniquement lorsqu’une demande est clôturée. Exemples TerminéNe sera pas réaliséDoublonImpossible à reproduire
	Temps d’attente lors du transfert HandoffWaitTime	Temps d’inactivité entre deux activités consécutives.
Description Cette métrique mesure le temps d’attente ou de mise en file entre la fin d’une activité et le début de la suivante. Elle correspond au temps pendant lequel le travail reste en attente avant qu’une personne le prenne en charge. Cette métrique est essentielle pour l’indicateur « Temps d’attente moyen lors d’un transfert » et le Dashboard « Efficacité des transferts entre phases ». Des temps de transfert élevés signalent souvent des problèmes de coordination, des ressources insuffisantes ou une communication inefficace entre les équipes, par exemple entre le développement et l’assurance qualité. Réduire ces périodes d’inactivité est un levier important pour raccourcir le temps de cycle global. Pourquoi est-ce important ? Met en évidence les périodes d’inactivité ou d’attente dans le processus, révèle les inefficacités lors des transferts entre équipes ou personnes et permet de repérer les problèmes de coordination. Où trouver ces données Il s’agit d’une métrique calculée. Elle correspond à l’heure de début d’une activité moins l’heure de fin de l’activité précédente pour le même cas. Exemples 017280043200
	Temps de cycle total CycleTime	Durée totale de bout en bout d’un élément de développement.
Description Le temps de cycle mesure la durée totale écoulée entre la création d’un élément de développement et sa résolution définitive, par exemple son déploiement en production. Il est calculé au niveau du cas en soustrayant l’horodatage du premier événement de celui du dernier. Cet indicateur clé mesure la vitesse et l’efficacité globales du processus. L’indicateur « Temps de cycle moyen de bout en bout » et le Dashboard « Analyse du temps de cycle global du cycle de vie du développement logiciel » reposent directement sur ce calcul. Réduire le temps de cycle est souvent un objectif majeur des initiatives d’amélioration des processus. Pourquoi est-ce important ? Mesure la vitesse de bout en bout du processus de développement et fournit un indicateur clé de l’efficacité globale et du rythme de livraison. Où trouver ces données Cet attribut est calculé au niveau du cas. Il correspond à l’horodatage du dernier événement moins celui du premier événement pour un « DevelopmentItem » donné. Exemples 12096002592000604800
	Version de correction FixVersion	Version du logiciel dans laquelle l’élément de développement a effectivement été résolu et mis en production.
Description Dans Jira, le champ « Fix Version » indique la version qui contient le travail achevé pour un élément. Il marque le résultat concret du travail de développement. Cet attribut précise la version réellement livrée. Vous pouvez la comparer à « PlannedReleaseVersion » pour analyser les performances de livraison. Il permet également de regrouper tous les éléments livrés dans une version donnée et d’obtenir une vue d’ensemble du travail accompli. Pourquoi est-ce important ? Indique dans quelle version un travail a été inclus. Il fournit une référence fiable pour analyser les versions et suivre les fonctionnalités livrées. Où trouver ces données Correspond au champ « fixVersions » de la réponse de l’API Jira Issue. Exemples Correctif urgent v2.1.1Version majeure v3.0.0v2.2.0
	Version prévue PlannedReleaseVersion	Version ou mise en production cible dans laquelle l’élément doit être déployé.
Description Cet attribut, souvent associé au champ « Affects Version/s » dans Jira, indique la version prévue pour une fonctionnalité ou une correction. Il sert de date cible pour l’achèvement du travail. Cet attribut est essentiel au KPI « On-Time Release Delivery Rate ». En comparant la date réelle de déploiement à la date prévue pour cette version, vous pouvez mesurer le respect du calendrier et la prévisibilité du processus de mise en production. Pourquoi est-ce important ? Définit la date ou la version cible de livraison, ce qui permet de calculer le taux de livraison dans les délais et d’analyser le respect du calendrier. Où trouver ces données Correspond aux champs « versions » ou « fixVersions » de l’API Jira Issue. Le champ utilisé pour la planification peut varier. Exemples Version 2.1Version du T1 2024Lancement du projet Phoenix

Obligatoire Recommandé Facultatif

Activités du cycle de vie du développement logiciel

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de développement logiciel.

6 Recommandé 8 Facultatif

	Activité	Description
	Déployé en production	Cet événement marque le moment où les modifications de code associées à l’élément de développement sont mises en service dans l’environnement de production. Il peut être déduit du passage final au statut « Done » ou « Released », ou enregistré à partir d’un événement explicite transmis par un outil CI/CD intégré.
Pourquoi est-ce important ? Il s’agit du principal indicateur de réussite du processus. Il est essentiel pour calculer le temps de cycle total de bout en bout et mesurer la fréquence des déploiements ainsi que le débit. Où trouver ces données Peut être déduit du journal des modifications de l’élément Jira lorsque son statut passe à « Released » ou « Done ». Pour plus de précision, il peut être enregistré à partir des événements de déploiement transmis par des outils CI/CD comme Jenkins ou Bamboo, ou par la fonctionnalité Deployments de Jira. Données à recueillir Horodatage du passage au statut « Done » ou « Released ». Type d’événement inferred
	Développement commencé	Indique le moment où un développeur commence à travailler activement sur l’élément de développement. Cette étape est presque toujours déduite d’un changement de statut dans le flux de travail Jira, par exemple lorsque le ticket passe à « In Progress ».
Pourquoi est-ce important ? Cette étape est essentielle pour mesurer le temps de développement actif. Elle permet de distinguer le temps d’attente du travail qui apporte de la valeur, un indicateur important pour repérer les goulots d’étranglement. Où trouver ces données Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage du premier passage du champ « status » à « In Progress », « In Development » ou à un état actif similaire. Données à recueillir Horodatage du changement de statut vers « In Progress ». Type d’événement inferred
	Élément de développement créé	Cet événement marque le début du cycle de vie : un nouvel élément de développement, comme une user story, un bug ou une tâche, est enregistré dans Jira. Le système consigne explicitement la date et l’heure de création de chaque ticket.
Pourquoi est-ce important ? Cette activité marque le début du processus. Elle est indispensable pour calculer les temps de cycle de bout en bout et suivre le volume total de travail entrant. Où trouver ces données Cet événement fondamental concerne chaque ticket Jira. L’horodatage de création est enregistré dans le champ « created » de la fiche du ticket et est accessible via l’API Jira. Données à recueillir Le champ d’horodatage « created » de l’objet Jira Issue. Type d’événement explicit
	Tests d’assurance qualité commencés	Cet événement marque le début de la phase officielle de tests d’assurance qualité de l’élément de développement. Il est déduit d’un changement de statut Jira lorsque le ticket passe à un état comme « In QA », « In Testing » ou « Ready for Testing ».
Pourquoi est-ce important ? Cette étape marque le début du cycle de validation qualité. Mesurer le temps écoulé depuis « Development Completed » permet de repérer les retards de transfert entre les équipes de développement et d’assurance qualité. Où trouver ces données Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » passe à un état de test d’assurance qualité désigné, comme « In QA ». Données à recueillir Horodatage du changement de statut vers « In QA » ou « In Testing ». Type d’événement inferred
	Tests d’assurance qualité terminés	Indique que l’élément de développement a réussi tous les contrôles d’assurance qualité et qu’il est prêt pour l’étape suivante, comme les tests d’acceptation utilisateur ou la mise en production. Cette étape est déduite d’un changement de statut quittant l’état de test principal.
Pourquoi est-ce important ? Cette étape marque la fin d’un contrôle qualité important. L’analyse de la durée de la phase d’assurance qualité aide à optimiser les tests et la répartition des ressources. Où trouver ces données Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » passe de « In QA » à un état suivant, comme « Ready for UAT » ou « Ready for Release ». Données à recueillir Horodatage du changement de statut de « In QA » à « Ready for UAT ». Type d’événement inferred
	Tests UAT approuvés	Marque la fin réussie des tests d’acceptation utilisateur et indique que les parties prenantes approuvent la mise en production. Cette étape est déduite d’un changement de statut de « In UAT » à un état comme « Ready for Release » ou « Done ».
Pourquoi est-ce important ? Cette étape confirme l’acceptation par les équipes métier et autorise le déploiement de l’élément en production. Elle constitue un point de contrôle essentiel pour vérifier que le travail livré répond aux attentes des utilisateurs. Où trouver ces données Déduit du journal des modifications de l’élément Jira. Il s’agit de l’horodatage du passage du statut « In UAT » au statut suivant dans le flux de travail, qui marque l’approbation. Données à recueillir Horodatage du passage du statut « In UAT » à « Ready for Release ». Type d’événement inferred
	Développement terminé	Cette activité indique que le développeur a terminé le codage et que l’élément est prêt pour l’étape suivante, comme la revue de code ou les tests. Elle est déduite d’un changement de statut Jira, par exemple de « In Progress » à « In Review » ou « Ready for QA ».
Pourquoi est-ce important ? Cette étape marque la fin de la phase principale de développement. Elle permet d’analyser la durée du codage et l’efficacité des transferts vers l’équipe d’assurance qualité. Où trouver ces données Déduit du journal des modifications du ticket Jira, à partir de l’horodatage auquel le champ « status » passe d’un état de développement actif à un état suivant, comme « In Review » ou « Ready for QA ». Données à recueillir Horodatage du changement de statut de « In Progress » à « In Review » ou « Ready for QA ». Type d’événement inferred
	Échec des tests d’assurance qualité	Indique que l’équipe d’assurance qualité a détecté un défaut et renvoyé l’élément de développement aux développeurs pour reprise. Cette étape est déduite d’un retour à un statut antérieur, par exemple de « In QA » à « In Progress » ou « To Do ».
Pourquoi est-ce important ? Cette activité est essentielle pour repérer les boucles de reprise. Le suivi de sa fréquence permet de mesurer le coût d’une qualité insuffisante et de cibler les améliorations du développement ou des exigences. Où trouver ces données Déduit du journal des modifications du ticket Jira. L’événement est enregistré lorsque le champ « status » passe d’un état de test, par exemple « In QA », à un état de développement antérieur, comme « In Progress ». Données à recueillir Horodatage du changement de statut d’un état de test à un état de développement. Type d’événement inferred
	Élément de développement annulé	Marque l’arrêt d’un élément de développement avant son achèvement. Cette étape est déduite du passage à un statut final tel que « Canceled », « Rejected » ou « Won’t Do », souvent accompagné d’une résolution précise.
Pourquoi est-ce important ? Cette activité permet de suivre les issues du processus qui n’aboutissent pas. L’analyse des raisons d’annulation des éléments peut révéler des problèmes de planification, de priorisation ou de définition des exigences. Où trouver ces données Déduit du journal des modifications de l’élément Jira. Il s’agit de l’horodatage auquel le champ « status » passe à « Canceled » ou « Won’t Do » et où une résolution correspondante est définie. Données à recueillir Horodatage du passage au statut « Canceled », « Rejected » ou « Won’t Do ». Type d’événement inferred
	Élément de développement clôturé	Il s’agit de la dernière opération administrative, qui confirme qu’aucun autre travail n’est prévu sur l’élément. Elle est souvent déduite du passage au statut « Closed » et du renseignement du champ « Resolution ».
Pourquoi est-ce important ? Marque la fin définitive du parcours d’un élément. La comparaison avec « Deployed to Production » peut révéler un délai administratif ou une période de suivi après le déploiement. Où trouver ces données Déduit du journal des modifications de l’élément Jira. Il s’agit de l’horodatage auquel le champ « status » passe à « Closed » et une résolution est définie. Données à recueillir Horodatage du passage au statut « Closed ». Type d’événement inferred
	Élément prêt pour le développement	Indique qu’un élément de développement a été entièrement défini, examiné et priorisé. Un développeur peut alors commencer à travailler dessus. Cet état est généralement déduit d’un changement de statut dans le flux de travail, par exemple de « Backlog » à « To Do » ou « Ready for Dev ».
Pourquoi est-ce important ? Le suivi de cette étape permet de mesurer le niveau de préparation du backlog et le temps d’attente des éléments avant le début du développement. Il distingue le temps consacré à la planification et à l’affinage du temps de développement actif. Où trouver ces données Déduit du journal des modifications du ticket Jira. Recherchez l’horodatage auquel le champ « status » prend une valeur telle que « Ready for Dev », « To Do » ou « Selected for Development ». Données à recueillir Horodatage du changement de statut vers un état indiquant que l’élément est prêt pour le développement. Type d’événement inferred
	Préparé pour la mise en production	Indique que l’élément de développement a passé tous les contrôles et a été intégré à une version précise du logiciel, en attente de déploiement. Cette étape est souvent déduite du passage du statut de l’élément à « Ready for Release » ou du renseignement du champ « Fix Version ».
Pourquoi est-ce important ? Cette activité permet de suivre l’état de préparation d’une version et le temps d’attente des éléments avant leur déploiement, une fois les travaux de développement et de test terminés. Où trouver ces données Généralement déduit du journal des modifications de l’élément Jira, à partir du passage au statut « Ready for Release ». Il peut aussi être déduit de l’horodatage auquel le champ « Fix Version/s » est renseigné. Données à recueillir Horodatage du passage au statut « Ready for Release » ou du renseignement du champ « Fix Version ». Type d’événement inferred
	Revue de code effectuée	Indique qu’un pair ou un responsable a examiné le code pour en vérifier la qualité, la conformité aux normes et le fonctionnement. Cette étape peut être déduite d’un changement de statut, par exemple de « In Review » à « Ready for QA », ou enregistrée explicitement par des outils de développement intégrés.
Pourquoi est-ce important ? Cette activité constitue un contrôle qualité essentiel. L’analyse de sa durée et de ses résultats, notamment des reprises, contribue à améliorer la qualité du code et à réduire les bugs détectés plus tard dans le processus. Où trouver ces données Cette étape est généralement déduite du journal des modifications du ticket Jira lorsque le statut quitte l’état « Code Review ». Elle peut aussi être enregistrée explicitement si des outils de gestion de code, comme Bitbucket ou GitHub, sont intégrés. Données à recueillir Horodatage du changement de statut de « In Review » à l’état suivant. Type d’événement inferred
	Tests UAT commencés	Marque le début des tests d’acceptation utilisateur, au cours desquels les parties prenantes métier ou les utilisateurs finaux valident les nouvelles fonctionnalités. Cette étape est déduite d’un changement de statut Jira vers un état comme « In UAT » ou « User Acceptance Testing ».
Pourquoi est-ce important ? Cette activité marque le début de la dernière phase de validation avant la mise en production. L’analyse de sa durée est essentielle pour comprendre et réduire les retards liés à la disponibilité des parties prenantes ou aux boucles de retour. Où trouver ces données Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » est mis à jour avec la valeur « In UAT » ou un statut désigné similaire. Données à recueillir Horodatage du changement de statut vers « In UAT ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Jira Software

Étapes

Connectez-vous à votre instance Jira Software.
Dans la barre de navigation principale, sélectionnez Issues, puis cliquez sur Search for issues. Le navigateur de problèmes s’ouvre.
Sur la page de recherche, passez de la recherche De base à la recherche Avancé pour utiliser le langage de requête Jira (JQL).
Saisissez la requête JQL fournie dans la barre de recherche. Remplacez les valeurs fictives de la clé du projet et de la période par celles qui correspondent à vos besoins.
Exécutez la requête en cliquant sur l’icône de recherche ou en appuyant sur Entrée. La liste de tous les éléments de développement correspondant à vos critères s’affiche.
Dans le coin supérieur droit de la page des résultats de recherche, cliquez sur l’icône Export (elle peut ressembler à une icône de partage ou porter explicitement ce libellé), puis sélectionnez l’option XML. N’utilisez pas le format CSV : le format XML contient l’historique complet et structuré des modifications nécessaire à la création du journal d’événements.
Enregistrez le fichier XML téléchargé sur votre ordinateur. Il contient un enregistrement par problème Jira, avec toutes les modifications historiques imbriquées dans celui-ci.
Étape importante de transformation : le fichier XML exporté ne constitue pas un journal d’événements à plat. Vous devez utiliser un script externe ou un outil ETL pour analyser ce fichier. Le script doit parcourir chaque balise <item> (qui représente un problème Jira) du fichier XML.
Pour chaque problème, le script doit d’abord créer une ligne pour l’activité Élément de développement créé, à partir de l’horodatage du champ created.
Ensuite, le script doit analyser les données <changelog> de chaque problème. Pour chaque <changeitem> correspondant à une transition de statut, créez une nouvelle ligne dans le fichier de sortie. Associez la transition de statut Jira (par exemple, de « In Progress » à « In Review ») à l’activité métier correspondante (par exemple, « Développement terminé ») et utilisez l’horodatage de la transition pour EventTime.
Le script doit renseigner tous les attributs requis et recommandés pour chaque ligne en extrayant du fichier XML des informations telles que la clé du problème, son type, la personne à qui il est attribué et le projet.
Après avoir traité tous les problèmes et leur historique, enregistrez les données transformées dans un fichier CSV dont les en-têtes correspondent aux attributs indiqués. Le fichier est alors prêt à être importé dans l’outil de process mining.

Configuration

Filtres de requête JQL : la requête JQL est le principal outil de sélection des données. Parmi les filtres clés, project cible des projets de développement précis, issuetype inclut uniquement les éléments pertinents comme Story, Bug ou Task, et created définit la période d’analyse.
Période : pour une première analyse, il est recommandé d’extraire les données sur une période de 3 à 6 mois. Vous disposerez ainsi de suffisamment de données pour repérer des tendances, tout en limitant la taille du fichier exporté. Définissez la période dans votre requête JQL à l’aide de created >= 'YYYY-MM-DD' et created <= 'YYYY-MM-DD'.
Types de tickets : précisez les valeurs de issuetype. Vous souhaiterez souvent inclure Story, Bug, Task et Spike, mais exclure les tickets conteneurs comme Epic ou les tickets plus détaillés comme Sub-task s’ils ne représentent pas le cas principal.
Format d’exportation : sélectionnez obligatoirement le format XML. L’export CSV standard ne contient pas toujours les données structurées de l’historique des modifications nécessaires pour reconstituer la séquence des activités.
Autorisations utilisateur : la personne qui effectue l’exportation doit disposer de l’autorisation « Browse Projects » pour les projets Jira indiqués dans la requête JQL.

Exemple de requête config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Étapes

Établissez la connexion à la base de données : vérifiez que vous disposez d’identifiants en lecture seule et d’une connexion réseau à la base SQL utilisée par votre instance Jira. Cette méthode est réservée aux installations Jira hébergées par vos soins.
Connectez-vous avec un client SQL : utilisez un outil client de base de données tel que DBeaver, SQL Server Management Studio ou pgAdmin pour vous connecter à la base Jira avec les identifiants fournis.
Repérez les statuts du flux de travail : avant d’exécuter la requête, accédez aux paramètres du flux de travail de votre projet Jira (Project settings > Workflows). Notez précisément les noms des statuts correspondant à chaque activité à suivre, par exemple « Backlog », « In Progress », « In Review » et « Done ».
Personnalisez la requête SQL : copiez la requête SQL fournie dans votre client. Vous devez remplacer les valeurs fictives. Vérifiez en particulier les noms de statut dans les clauses WHERE de chaque bloc UNION ALL : ils doivent correspondre exactement au flux de travail de votre projet.
Définissez les paramètres de la requête : modifiez le filtre de période (WHERE ji.created >= '2023-01-01') selon la période à analyser. Il est également vivement recommandé de filtrer un ou plusieurs projets précis en décommentant et en renseignant le filtre de clé de projet (--AND p.pkey IN ('PROJ1', 'PROJ2')).
Configurez les champs personnalisés : repérez l’ID du champ personnalisé « Team Name » dans votre instance Jira. Vous le trouverez dans la page d’administration des champs personnalisés de Jira. Remplacez dans la requête la valeur fictive 'customfield_10100' par l’ID correspondant.
Exécutez la requête : lancez la requête SQL modifiée sur la base Jira.
Vérifiez le résultat : examinez rapidement les données renvoyées pour vous assurer que plusieurs activités sont représentées et que les colonnes sont renseignées comme prévu.
Exportez le journal d’événements : exportez l’ensemble des résultats de votre client SQL dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8.
Préparez l’importation : vérifiez que les en-têtes des colonnes du fichier CSV exporté correspondent aux noms d’attributs requis : DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName et TeamName.

Configuration

Identifiants de base de données : un compte utilisateur en lecture seule est nécessaire pour éviter toute modification accidentelle des données de la base Jira.
Noms des statuts du flux de travail : la requête repose principalement sur le filtrage par nom de statut, par exemple « In Progress » ou « Done ». Ces noms varient selon le flux de travail et le projet Jira. Remplacez les valeurs fictives de la requête par les noms exacts définis dans votre configuration.
Période : la requête comporte une clause WHERE ji.created >= '[YYYY-MM-DD]' qui limite le volume de données traité. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de maîtriser le volume et d’accélérer l’exécution de la requête.
Filtre de projet : pour cibler l’analyse, il est fortement conseillé de filtrer des clés de projet précises à l’aide de la condition p.pkey IN ('[YourProjectKey]'). Interroger tous les projets d’une grande instance Jira peut prendre beaucoup de temps.
Champ personnalisé de l’équipe : « Team Name » est considéré comme un champ personnalisé. La requête fournie utilise l’ID fictif customfield_10100, que vous devez remplacer par l’ID correct défini dans la configuration de votre instance Jira.
Performances : les requêtes directes sur la base de données peuvent mobiliser beaucoup de ressources. Effectuez cette extraction en dehors des heures de pointe ou, de préférence, sur une réplique en lecture de la base de production afin de ne pas nuire aux performances de Jira pour les utilisateurs.

Exemple de requête sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

Étapes

Prérequis : vérifiez que Python 3 est installé sur votre système. Installez les bibliothèques nécessaires, requests pour les appels API et pandas pour la manipulation des données, en exécutant la commande pip install requests pandas.
Générez un jeton API Jira : connectez-vous à votre instance Jira. Accédez aux paramètres de votre profil utilisateur, puis à la section Security et sélectionnez « Create and manage API tokens ». Créez un jeton et copiez-le dans un endroit sûr. Il remplacera votre mot de passe pour authentifier le script.
Configurez le script Python : copiez le script Python fourni dans un fichier, par exemple extract_jira_log.py. Ouvrez le fichier et mettez à jour la section de configuration en haut avec l’URL de votre site Jira, votre adresse e-mail et le jeton API que vous venez de générer.
Définissez la requête JQL : modifiez la variable JQL_QUERY dans le script. Cette requête détermine les tickets à extraire. Pour commencer, vous pouvez filtrer par projet, type de ticket et période, par exemple : project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d.
Personnalisez l’association des statuts : examinez le dictionnaire STATUS_MAPPING du script. Cette association est essentielle : elle convertit les statuts propres au flux de travail Jira de votre organisation en activités standard pour le Process Mining. Mettez à jour les clés, qui correspondent aux noms de statut Jira, pour qu’elles correspondent exactement à votre flux de travail.
Exécutez le script : lancez-le depuis votre terminal à l’aide de la commande python extract_jira_log.py. Le script se connectera à l’API Jira, récupérera les données des tickets et traitera leur historique de modifications.
Gérez la pagination de l’API : le script gère automatiquement la pagination en récupérant les tickets par lots de 50. Il poursuit les requêtes jusqu’à ce que tous les tickets correspondant à la requête JQL aient été récupérés.
Traitez l’historique des tickets : pour chaque ticket, le script récupère l’historique complet. Il repère l’événement de création, puis parcourt tous les changements de statut et ajoute au journal d’événements une ligne pour chaque transition pertinente selon votre STATUS_MAPPING.
Générez le fichier de journal d’événements : une fois tous les tickets traités, le script rassemble les événements dans un DataFrame pandas, ajoute les colonnes de métadonnées requises, comme SourceSystem et LastDataUpdate, puis enregistre le journal d’événements final dans un fichier CSV nommé jira_event_log.csv, dans le même répertoire.

Configuration

JIRA_URL : URL de base de votre instance Jira, par exemple https://your-company.atlassian.net.
JIRA_EMAIL : adresse e-mail du compte utilisateur utilisé pour l’authentification.
JIRA_API_TOKEN : jeton API généré dans les paramètres de sécurité de l’utilisateur Jira pour authentifier le script.
JQL_QUERY : requête en langage Jira qui filtre les tickets à extraire. Il est vivement recommandé de définir une période, par exemple les 6 à 12 derniers mois, afin de maîtriser le volume de données. Filtrez également par projet et par types de tickets pertinents pour analyser le bon processus, par exemple Story, Bug ou Task.
STATUS_MAPPING : dictionnaire Python qui associe les noms de statut propres au flux de travail Jira aux noms d’activité génériques requis. Ce paramètre est le plus important pour garantir l’exactitude du modèle de processus. Personnalisez-le en fonction du flux de travail de votre projet.
Prérequis : le script nécessite un compte utilisateur Jira disposant d’un accès en lecture aux projets et aux tickets à extraire, ainsi que des autorisations nécessaires pour utiliser l’API REST.

Exemple de requête python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

Étapes

Vérifiez que Jira Automation, les webhooks sortants et un récepteur HTTPS sont disponibles pour le projet Jira. Le récepteur doit accepter les requêtes POST et conserver l’intégralité de la charge utile JSON, y compris les métadonnées de l’événement et les champs du ticket.
Définissez le contrat d’événement avant de créer les règles. Utilisez Development Item comme identifiant de cas, Activity comme nom d’activité, EventTime comme horodatage de l’événement, SourceSystem comme système source Jira Software et LastDataUpdate comme horodatage d’ingestion ou d’actualisation. Configurez le récepteur pour conserver la clé du ticket Jira dans DevelopmentItem.
Créez des règles Jira Automation déclenchées par des événements de ticket. Configurez des règles pour la création d’un ticket, les transitions de statut du flux de travail, les changements de résolution, les changements de Fix Version, le cas échéant, ainsi que les événements de déploiement ou de revue intégrés disponibles dans votre configuration Jira. Jira ne propose pas de flux de travail universel : associez les noms de statut et les conditions de transition locales aux activités requises.
Configurez chaque règle pour envoyer un webhook à [Your webhook endpoint]. Utilisez POST et le format JSON. Incluez la clé du ticket, son type, la personne affectée, la priorité, le statut, le projet, le champ d’équipe s’il existe, l’horodatage de l’événement, les informations de transition, la résolution, les valeurs Fix Version et l’identifiant de l’événement Jira. Ne comptez pas sur ProcessMind pour déduire les activités à partir de l’historique des statuts.
Définissez des associations explicites entre les activités dans le récepteur de webhook ou la couche d’ingestion. Chaque webhook admissible doit produire une ligne dans le journal d’événements. Associez la création d’un ticket à Development Item Created, les transitions vers l’état prêt à Item Ready for Development, les transitions vers In Progress à Development Started, les transitions de fin de développement ou de revue à Development Completed, les transitions de revue ou les événements de revue intégrés à Code Review Performed, les transitions vers les tests à QA Testing Started, les retours en arrière pendant les tests d’assurance qualité à QA Testing Failed, les tests réussis à QA Testing Completed, les transitions UAT à UAT Started et UAT Approved, la préparation de la mise en production à Prepared For Release, le déploiement en production ou la fin de mise en production configurée à Deployed To Production, la clôture à Development Item Closed et l’annulation ou le rejet à Development Item Canceled.
Appliquez ces associations selon le flux de travail Jira et la configuration des événements approuvés par le responsable du processus. Par exemple, associez les statuts locaux tels que Backlog, To Do, Ready for Dev, In Progress, In Review, Ready for QA, In QA, In Testing, In UAT, Ready for Release, Done, Released, Closed, Canceled, Rejected ou Won’t Do uniquement s’ils correspondent bien à la signification métier prévue. Évitez de créer plusieurs lignes pour un même webhook, sauf si sa charge utile représente explicitement plusieurs événements admissibles.
Normalisez chaque événement selon le schéma requis. DevelopmentItem doit contenir la clé du ticket Jira, Activity doit contenir exactement l’un des 14 noms d’activité requis, EventTime doit indiquer l’horodatage de l’événement, SourceSystem doit contenir Jira Software et LastDataUpdate doit indiquer l’horodatage d’ingestion ou d’actualisation. Renseignez les attributs recommandés lorsqu’ils sont disponibles, notamment Assignee, ItemType, ItemPriority, ItemStatus, ProjectName et TeamName.
Éliminez les doublons de livraison de webhook à l’aide de l’identifiant de l’événement Jira, de la clé du ticket, de l’horodatage de l’événement, de l’identifiant de transition et de l’association d’activité. Une livraison de webhook pouvant être relancée, le récepteur doit traiter les requêtes de manière idempotente. Conservez l’horodatage d’origine de l’événement au lieu de le remplacer par celui de l’ingestion.
Validez le journal d’événements obtenu en vérifiant le schéma, les horodatages, les identifiants de cas, les noms d’activité, la gestion des doublons et la couverture de la période définie. Confirmez que les 14 valeurs d’activité peuvent apparaître dans les lignes et qu’aucune activité ne doit être déduite ultérieurement par ProcessMind.
Exportez le journal d’événements normalisé au format CSV ou dans un autre format de journal d’événements pris en charge par ProcessMind. Incluez une ligne par événement explicite et les colonnes DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName et TeamName. Importez le fichier ou connectez la sortie du récepteur selon la configuration d’ingestion de ProcessMind.

Configuration

Méthode et langage de requête : configurez des règles Jira Automation et un récepteur de webhook HTTPS. La valeur de requête est définie par la configuration, car l’extraction repose sur les règles et la normalisation des événements, et non sur une requête dans la base Jira.
Identifiant de cas : utilisez la clé du ticket Jira comme DevelopmentItem. Ne regroupez pas plusieurs tickets dans un même cas.
Activités requises : configurez des associations explicites pour Development Item Created, Item Ready for Development, Development Started, Development Completed, Code Review Performed, QA Testing Started, QA Testing Failed, QA Testing Completed, UAT Started, UAT Approved, Prepared For Release, Deployed To Production, Development Item Closed et Development Item Canceled.
Déclencheurs d’événement : activez les déclencheurs de création de ticket, de transition du flux de travail, de résolution, de Fix Version, d’intégration de revue et d’intégration de déploiement uniquement s’ils sont pris en charge et pertinents dans la configuration Jira.
Association des statuts : gérez une table d’association ou une configuration propre à chaque projet pour les statuts et transitions Jira locaux. Interprétez les statuts tels que In Progress, In QA, Done ou Closed selon la sémantique du flux de travail approuvé.
Période : pour une première validation, recueillez les événements sur une période de 3 à 6 mois. Pour une diffusion continue, démarrez le récepteur avant la période d’observation visée et prévoyez une stratégie de rejeu ou de rattrapage des événements générés pendant les interruptions.
Filtres : filtrez selon les projets Jira, les types de tickets, le périmètre du flux de travail et la période visés. Company Code et Document Type ne sont pas des notions standard de Jira Software : utilisez plutôt le projet, le type de ticket et les autres champs Jira configurés.
Champs de la charge utile : incluez la clé du ticket, son type, la personne affectée, la priorité, le statut, le projet, le champ d’équipe s’il existe, l’horodatage de l’événement, les détails de transition, la résolution, Fix Version et l’identifiant de l’événement.
Gestion des horodatages : conservez les informations de fuseau horaire lorsqu’elles sont disponibles. Utilisez l’horodatage de l’événement source pour EventTime et l’horodatage d’actualisation du récepteur pour LastDataUpdate.
Livraison et sécurité : utilisez HTTPS, l’authentification prise en charge par le récepteur, la validation des requêtes, la gestion des nouvelles tentatives et un traitement idempotent. N’inscrivez pas d’identifiants dans les lignes du journal d’événements.
Performances : utilisez l’ingestion asynchrone, le traitement par lots après réception si cette option est disponible, des clés de dédoublonnage indexées et un partitionnement par date d’événement pour les volumes importants. Évitez de conserver sans limite les charges utiles des webhooks dans le récepteur opérationnel.
Prérequis : autorisations Jira Automation, autorisation de configurer les règles du projet, autorisation de consulter les tickets et champs concernés, accès à un point de terminaison HTTPS et tout abonnement Jira ou toute capacité d’intégration nécessaire aux webhooks sortants et aux événements de déploiement.
Qualité des données : définissez la manière de traiter les tickets supprimés, les statuts renommés, les personnes affectées ou les champs d’équipe manquants, la conversion des fuseaux horaires, les livraisons en double et les événements reçus dans le désordre.

Exemple de requête config

{
  "method": "Real-time Event Streaming via Automation Webhooks",
  "approach": "Jira Automation rules send issue event JSON payloads to a configured HTTPS endpoint. The receiver normalizes each qualifying payload into one explicit event-log row.",
  "queryLanguage": "config",
  "confidence": "verified",
  "caseIdentifier": "DevelopmentItem",
  "sourceSystem": "Jira Software",
  "endpoint": "[Your webhook endpoint]",
  "dateFrom": "[Start date and time]",
  "dateTo": "[End date and time]",
  "filters": {
    "projects": "[Configure based on your Jira projects]",
    "issueTypes": "[Configure based on your Jira issue types]"
  },
  "outputColumns": [
    "DevelopmentItem",
    "Activity",
    "EventTime",
    "SourceSystem",
    "LastDataUpdate",
    "Assignee",
    "ItemType",
    "ItemPriority",
    "ItemStatus",
    "ProjectName",
    "TeamName"
  ],
  "activityMappings": [
    {
      "activity": "Development Item Created",
      "trigger": "Issue created",
      "condition": "The Jira issue creation event is received within the configured scope"
    },
    {
      "activity": "Item Ready for Development",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from a configured backlog or specification status to a configured ready-for-development status"
    },
    {
      "activity": "Development Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to the configured active development status, commonly In Progress"
    },
    {
      "activity": "Development Completed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from active development to a configured development-complete, review, or QA-ready status"
    },
    {
      "activity": "Code Review Performed",
      "trigger": "Workflow transition or configured review integration event",
      "condition": "A qualifying code review completion event is received, such as a transition from review to QA-ready"
    },
    {
      "activity": "QA Testing Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured QA or testing status"
    },
    {
      "activity": "QA Testing Failed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions backward from a configured QA or testing status to a development or rework status"
    },
    {
      "activity": "QA Testing Completed",
      "trigger": "Workflow transition",
      "condition": "The issue leaves the configured primary QA or testing status through a successful testing transition"
    },
    {
      "activity": "UAT Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured UAT or user acceptance testing status"
    },
    {
      "activity": "UAT Approved",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from UAT to a configured approval, release-ready, or completed status"
    },
    {
      "activity": "Prepared For Release",
      "trigger": "Workflow transition or Fix Version field change",
      "condition": "The issue reaches a configured release-ready status or receives a qualifying Fix Version value"
    },
    {
      "activity": "Deployed To Production",
      "trigger": "Configured deployment event or workflow transition",
      "condition": "A production deployment event is received, or the configured final release transition represents production deployment"
    },
    {
      "activity": "Development Item Closed",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches the configured Closed status and, where required, has a qualifying Resolution value"
    },
    {
      "activity": "Development Item Canceled",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches a configured canceled, rejected, or won't-do terminal state and, where required, has a qualifying Resolution value"
    }
  ],
  "normalization": {
    "oneRowPerEvent": true,
    "developmentItem": "payload.issue.key",
    "eventTime": "payload.event.timestamp or the source timestamp supplied by the Jira event",
    "sourceSystem": "Jira Software",
    "lastDataUpdate": "receiver ingestion timestamp",
    "assignee": "payload.issue.fields.assignee.displayName or account identifier when available",
    "itemType": "payload.issue.fields.issuetype.name",
    "itemPriority": "payload.issue.fields.priority.name",
    "itemStatus": "payload.issue.fields.status.name",
    "projectName": "payload.issue.fields.project.name",
    "teamName": "payload.issue.fields.team or the configured team field when available"
  },
  "deduplication": {
    "key": "payload.event.id, payload.issue.key, payload.event.timestamp, payload.transition.id, mapped activity",
    "behavior": "Ignore repeated deliveries with the same deduplication key while retaining the first valid event row"
  },
  "requiredConfiguration": [
    "Configure one or more Jira Automation rules for each qualifying event type",
    "Configure the webhook receiver at [Your webhook endpoint]",
    "Configure local Jira status and transition mappings",
    "Configure project and issue-type filters at [Configure based on your Jira projects] and [Configure based on your Jira issue types]",
    "Configure authentication and request validation according to the receiver implementation"
  ]
}

Prêt à commencer ?

Préparez vos données à l’aide de ce modèle et commencez dès aujourd’hui à optimiser le cycle de vie du développement logiciel. Repérez les pistes d’amélioration pour accélérer les livraisons et renforcer la qualité.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez le cycle de vie du développement logiciel dans Jira Software dès aujourd’hui !

Repérez les inefficacités et réduisez de 30 % le temps de cycle de votre processus de développement logiciel.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. Commencez l’optimisation en quelques minutes.

Votre modèle de données pour le cycle de vie du développement logiciel

Votre modèle de données pour le cycle de vie du développement logiciel

Attributs du cycle de vie du développement logiciel

Activités du cycle de vie du développement logiciel

Guides d’extraction

Requête JQL Jira avec export CSV ou XML intégré

Étapes

Configuration

Exemple de requête config

Requête directe dans la base Jira via SQL (hébergement autonome)

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST officielle de Jira

Étapes

Configuration

Exemple de requête python

Diffusion des événements en temps réel via des webhooks d’automatisation

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez le cycle de vie du développement logiciel dans Jira Software dès aujourd’hui !

Votre modèle de données pour le cycle de vie du développement logiciel

Votre modèle de données pour le cycle de vie du développement logiciel

Attributs du cycle de vie du développement logiciel

Activités du cycle de vie du développement logiciel

Guides d’extraction

Requête JQL Jira avec export CSV ou XML intégré

Étapes

Configuration

Exemple de requête config

Requête directe dans la base Jira via SQL (hébergement autonome)

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST officielle de Jira

Étapes

Configuration

Exemple de requête python

Diffusion des événements en temps réel via des webhooks d’automatisation

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez le cycle de vie du développement logiciel dans Jira Software dès aujourd’hui !

Prêt à commencer ?

Optimisez le cycle de vie du développement logiciel dans Jira Software dès aujourd’hui !