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

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

Jira Software

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

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

Ce modèle fournit une feuille de route claire pour recueillir les données essentielles à l’analyse de votre cycle de développement logiciel. Il précise les principaux champs de données à collecter, les étapes importantes du processus à suivre et les indications pratiques pour extraire ces informations de Jira Software. Utilisez ce guide pour préparer votre journal d’événements au Process Mining.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction pour Jira Software

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du cycle de développement logiciel

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

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité Activity	Le 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 représente une étape ou un jalon distinct du processus de développement logiciel. Ces activités sont déduites des changements apportés au champ de statut du ticket Jira ou d’autres événements importants, tels que des validations de code ou des revues. Dans le Process Mining, la séquence de ces activités forme la carte du processus. L’analyse des activités aide à comprendre le déroulement du processus, à mesurer la durée de certaines étapes et à détecter les écarts par rapport au flux de travail standard, comme les boucles de reprise ou les contrôles qualité ignorés. Pourquoi c’est important Les activités définissent les étapes du processus et leur séquence est essentielle pour visualiser son déroulement, repérer les goulots d’étranglement et analyser les variations du processus. Où les obtenir Généralement déduite des transitions du champ « status » dans l’historique ou le journal des modifications du ticket Jira. Elle peut également être enrichie avec les données d’outils de développement connectés. Exemples Développement commencéRevue de code effectuéeTests QA terminésDéployé en production
	Élément de développement DevelopmentItem	L’identifiant unique d’une unité de travail, comme une story, un bug ou une tâche, dans Jira Software.
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 de bug ou une tâche. Il relie toutes les activités, depuis la conception et la planification initiales jusqu’au développement, aux tests et au déploiement de cet élément. Dans Jira, il correspond généralement à la clé du ticket, 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 construction des cartes de processus, du calcul des délais de cycle et de l’identification des variations dans le parcours des différents éléments au sein du processus de développement. Pourquoi c’est important Il s’agit de la clé essentielle qui relie toutes les activités de développement associées et permet de retracer le parcours d’un même élément de travail du début à la fin. Où les obtenir Il s’agit du champ « key » standard d’un ticket dans l’objet Jira Software Issue de l’API. Exemples PROJ-101CORE-5432API-789
	Heure de l’événement EventTime	La date et l’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 le moment où une activité a eu lieu. Elle constitue la base temporelle de toutes les analyses de Process Mining et fournit l’ordre chronologique des événements pour chaque cas. Cet attribut est essentiel pour calculer tous les indicateurs temporels, notamment les délais de cycle, les temps de traitement et les temps d’attente entre les activités. Il permet d’analyser la performance du processus au fil du temps et d’identifier quand et où surviennent les retards dans le cycle de développement. Pourquoi c’est important Cet horodatage est fondamental pour ordonner correctement les événements et calculer tous les indicateurs fondés sur la durée, essentiels pour comprendre l’efficacité du processus et identifier les retards. Où les obtenir Cela correspond à l’horodatage « created » de chaque entrée de l’historique ou du journal des modifications d’un ticket. Exemples 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Dernière mise à jour des données LastDataUpdate	L’horodatage indiquant la dernière actualisation des données de ce processus depuis le système source.
Description Cet attribut enregistre la date et l’heure de l’extraction la plus récente des données depuis Jira Software. Il fournit un contexte sur l’actualité des données analysées. La connaissance de la date de dernière mise à jour est importante pour évaluer l’actualité des analyses du processus. Elle aide les analystes et les utilisateurs métier à vérifier qu’ils consultent des données à jour et indique le point de coupure des événements inclus dans l’analyse. Pourquoi c’est important Indique l’actualité des données, essentielle pour garantir que les analyses et les Dashboards reflètent l’état le plus récent du processus. Où les obtenir 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	Le système depuis lequel les données du cycle de développement ont été extraites.
Description Cet attribut identifie l’origine des données. Pour ce processus, sa valeur sera toujours « Jira Software », mais il est utile pour distinguer les données lorsque plusieurs systèmes sources sont réunis dans une analyse plus large. Dans un environnement informatique étendu, la précision du système source garantit la traçabilité des données et facilite la gestion de leur qualité ainsi que les travaux d’intégration entre différentes plateformes. Pourquoi c’est important Fournit une traçabilité claire des données, essentielle lors de l’intégration de données provenant de plusieurs systèmes ou dans le cadre de la gouvernance et de l’audit des données. Où les obtenir Il s’agit d’une valeur statique qui doit être ajoutée lors du processus d’extraction et de transformation des données. Exemples Jira Software
	Nom de l’équipe TeamName	L’équipe de développement responsable de l’élément de travail.
Description Représente l’équipe agile ou l’équipe de fonctionnalités chargée de l’élément de développement. Dans Jira, cet attribut est souvent implémenté sous la forme d’un champ personnalisé, ou peut être déduit d’autres informations, telles que le projet ou un composant spécifique. Cet attribut est essentiel pour analyser les performances au niveau de l’équipe. Il permet de filtrer les Dashboards afin d’afficher des indicateurs tels que le temps de cycle, le taux de reprise et le débit pour chaque équipe. Il est indispensable aux Dashboards « Efficacité des transferts interphases » et « Charge de travail des développeurs et progression des éléments ». Pourquoi c’est important Permet de mesurer et de comparer les performances de différentes équipes de développement, afin d’identifier les équipes les plus performantes et de partager les bonnes pratiques. Où les obtenir Il s’agit souvent d’un champ personnalisé dans Jira. Consultez votre administrateur Jira pour identifier le nom exact du champ, qui peut être « Team », « Squad » ou un intitulé similaire. Exemples Équipe PhoenixServices centrauxAvengers UI/UX
	Nom du projet ProjectName	Le nom du projet Jira auquel appartient l’élément de développement.
Description Dans Jira, tous les éléments de travail sont organisés en projets. Le nom du projet fournit un contexte de haut niveau et correspond souvent à un produit, une équipe ou une initiative précise. Cet attribut constitue une dimension puissante pour le filtrage et la comparaison. Il permet d’analyser et de comparer les performances du processus de cycle de vie du développement logiciel entre différents projets ou produits. Vous pouvez ainsi déterminer quels projets sont les plus efficaces, lesquels génèrent le plus de reprises et si les équipes suivent des variantes de processus différentes. Pourquoi c’est important Permet de segmenter l’analyse du processus par projet, produit ou équipe, afin de comparer les performances et d’identifier les bonnes pratiques. Où les obtenir Il s’agit du champ « project » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Développement d’applications mobilesPlateforme centraleScience des données
	Priorité de l’élément ItemPriority	Le niveau de priorité attribué à l’élément de développement, qui indique son degré d’urgence.
Description La priorité de l’élément définit son importance ou son urgence relative. Jira propose un champ standard « priority » avec des niveaux configurables tels que Highest, High, Medium et Low. L’analyse de la priorité est essentielle pour vérifier la conformité et repérer les goulots d’étranglement qui concernent les éléments critiques. Par exemple, le Dashboard « Contrôle de conformité des éléments prioritaires » s’appuie sur cet attribut pour vérifier que les éléments à haute priorité sont traités plus rapidement, comme prévu, ou qu’ils ne restent pas bloqués dans les mêmes files d’attente que les éléments à faible priorité. Pourquoi c’est important Aide à déterminer si les éléments hautement prioritaires sont traités plus rapidement que les éléments peu prioritaires et s’ils suivent un parcours plus direct, afin de respecter les SLA. Où les obtenir 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
	Responsable Assignee	L’utilisateur actuellement chargé de traiter l’élément de développement.
Description La personne affecté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 évolue lorsque l’élément passe d’une personne ou d’une équipe à une autre. L’analyse de la personne affectée est essentielle pour comprendre la répartition des ressources, la distribution de la charge de travail et les points de transfert. Elle permet de déterminer quels développeurs ou quelles équipes interviennent à certaines étapes, qui constitue un goulot d’étranglement et comment le travail est réparti dans l’organisation. Pourquoi c’est 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 les personnes. Où les obtenir Il s’agit du champ « assignee » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Alice SmithBob JohnsonNon attribué
	Statut de l’élément ItemStatus	Le 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é, comme « In Progress », « In Review » ou « Done ». La séquence des changements de statut au fil du temps génère les activités utilisées par le Process Mining. Alors que l’attribut « Activity » représente l’événement de changement, « ItemStatus » indique l’état de l’élément. Il sert de dimension de filtrage et d’analyse, par exemple pour connaître le nombre d’éléments actuellement dans un état donné ou étudier les caractéristiques des éléments qui restent longtemps dans un statut particulier. Pourquoi c’est important Fournit une vue instantanée de la position d’un élément dans son cycle de vie, essentielle pour les analyses fondées sur le statut et la compréhension de l’état actuel du travail en cours. Où les obtenir 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	La classification de l’élément de développement, par exemple Bug, Story, Task ou Epic.
Description Le type d’élément catégorise la nature du travail effectué. Jira utilise le champ standard « issuetype » pour distinguer différents types d’éléments de travail, qui disposent souvent de flux de travail spécifiques. Cet attribut est essentiel pour les analyses comparatives. Il permet de filtrer le processus selon certains types de travail, par exemple pour comparer le cycle de vie d’un « Bug » à celui d’une « Story ». Vous pouvez ainsi déterminer si certains types de travail sont davantage exposés aux retards, aux reprises ou aux écarts par rapport au processus standard. Pourquoi c’est important Permet de segmenter l’analyse du processus afin de comparer le traitement de différents types de travail, comme les bugs et les nouvelles fonctionnalités, et de repérer les différences entre leurs processus. Où les obtenir Il s’agit du champ « issuetype » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples StoryBugTaskEpic
	Composant Component	Une sous-section ou un domaine fonctionnel d’un projet auquel l’élément appartient.
Description Dans Jira, les composants servent à regrouper les tickets d’un projet en sous-ensembles plus petits et plus faciles à gérer. Il peut s’agir d’un domaine fonctionnel tel que « Authentification des utilisateurs », d’une couche technique comme « API Backend » ou d’un module comme « Reporting ». L’analyse par composant offre une vue plus détaillée du processus de développement. Elle peut aider à déterminer si certaines parties de l’application génèrent davantage de bugs, présentent des cycles de développement plus longs ou nécessitent davantage de reprises, ce qui peut révéler des zones de dette technique ou de complexité. Pourquoi c’est important Permet de segmenter le processus selon les domaines fonctionnels ou techniques du produit, afin d’identifier les composants à l’origine des retards ou des problèmes de qualité. Où les obtenir Il s’agit du champ standard « components » dans l’objet « fields » de la réponse de l’Issue API Jira. Exemples Interface utilisateurBase de donnéesPasserelle APIAuthentification
	Est une reprise IsRework	Un indicateur signalant qu’une activité fait partie d’une boucle de reprise.
Description Cet attribut booléen vaut true lorsqu’une activité représente un retour en arrière dans le processus, par exemple lorsqu’un élément revient à « Development Started » après avoir échoué aux tests d’assurance qualité. Sa valeur est déterminée en analysant la séquence des activités d’un cas. L’identification des reprises est fondamentale pour améliorer l’efficacité et la qualité des processus. Cet attribut contribue directement au KPI « Taux d’activités de reprise » et au Dashboard « Fréquence et chemins des boucles de reprise ». Il permet de quantifier le travail gaspillé et d’identifier les causes profondes des problèmes de qualité qui entraînent des reprises. Pourquoi c’est important Signale explicitement les activités qui font partie de boucles de reprise inefficaces, afin de mesurer et d’analyser précisément les pertes de processus et les problèmes de qualité. Où les obtenir Il s’agit d’un attribut calculé. Il faut définir le flux de processus attendu, puis signaler toute activité qui s’en écarte en revenant à une étape antérieure. Exemples truefalse
	Heure de fin de l’événement EventEndTime	L’horodatage auquel une activité ou un statut a été terminé.
Description Cet attribut indique l’heure d’achèvement d’une activité. 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 marque la fin. La différence entre ces deux horodatages correspond au temps de traitement de l’activité. Cet élément est essentiel pour calculer le KPI « Temps moyen de traitement d’une étape » et créer des Dashboards qui analysent la durée des activités. Pourquoi c’est important Définit le point de fin d’une activité et permet ainsi de calculer la durée de chaque étape du processus, ce qui est essentiel pour analyser les goulots d’étranglement. Où les obtenir Il s’agit d’un attribut dérivé. Pour un événement donné, son 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	Le 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 limitée dans le temps au cours de laquelle un ensemble de tâches est réalisé. Cet attribut contient le nom ou l’identifiant du Sprint auquel appartient un élément. L’analyse par Sprint est fondamentale pour le Process Mining appliqué aux méthodes agiles. Elle permet d’évaluer les performances de chaque Sprint, de comprendre le travail reporté 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 c’est important Fournit un contexte essentiel aux équipes agiles et permet d’analyser l’efficacité des processus et le débit Sprint par Sprint. Où les obtenir Ces informations sont généralement stockées dans un champ personnalisé « Sprint », géré par Jira Software (Agile). Les données sont accessibles via l’Issue API. Exemples Sprint 1 de PROJSprint 3 du T4 2023Sprint 2 PI de novembre
	Rapporteur Reporter	L’utilisateur qui a créé ou signalé initialement l’élément de développement.
Description Le rapporteur est la personne qui a créé le ticket dans Jira. Il peut s’agir d’un développeur, d’un testeur QA, d’un responsable produit ou même d’un client via une intégration avec un service desk. L’analyse du rapporteur peut fournir des informations sur l’origine du travail. Vous pouvez par exemple comparer le cycle de vie des bugs signalés par l’équipe QA à celui des bugs signalés par les clients. Elle peut également aider à comprendre les modes de communication et la circulation des informations au début du processus. Pourquoi c’est important Identifie 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 bugs. Où les obtenir Il s’agit du champ « reporter » dans l’objet « fields » de la réponse de l’API Jira Issue. Exemples Charles DarwinMarie CurieIsaac Newton
	Résolution de l’élément ItemResolution	Le résultat final ou le 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 clôturé. Même si le statut est « Closed », la résolution peut être « Done », « Won’t Do », « Duplicate » ou « Cannot Reproduce ». Elle fournit un contexte essentiel sur le résultat du travail. L’analyse de la résolution permet de distinguer les travaux terminés avec succès des éléments annulés ou refusés. Cette distinction est importante pour analyser la qualité et comprendre le véritable débit de travail utile, par opposition aux efforts consacrés à des éléments finalement écartés. Pourquoi c’est important Distingue les éléments terminés avec succès de ceux clôturés pour d’autres raisons, ce qui est essentiel pour analyser précisément la productivité et la qualité. Où les obtenir 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’un ticket est clôturé. Exemples TerminéNe sera pas réaliséDoublonImpossible à reproduire
	Temps d’attente lors d’un transfert HandoffWaitTime	Le temps d’inactivité entre deux activités consécutives.
Description Cette métrique calcule le temps d’attente ou de mise en file entre la fin d’une activité et le début de la suivante. Elle représente la durée pendant laquelle le travail reste en attente avant d’être pris en charge. Il s’agit d’une métrique essentielle pour le KPI « Temps d’attente moyen lors d’un transfert » et le Dashboard « Efficacité des transferts interphases ». Des temps de transfert élevés signalent souvent des problèmes de coordination, des contraintes de ressources ou une communication inefficace entre les équipes, par exemple entre le développement et l’assurance qualité. La réduction de ce temps d’inactivité constitue un levier important pour diminuer le temps de cycle global. Pourquoi c’est important Met en évidence le temps d’inactivité ou de mise en file dans le processus, révèle les inefficacités lors des transferts entre équipes ou collaborateurs et fait ressortir les problèmes de coordination. Où les obtenir 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	La 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 finale, par exemple son déploiement en production. Il est calculé au niveau du cas, comme la différence entre l’horodatage du tout premier événement et celui du tout dernier événement. Il s’agit d’un KPI principal pour mesurer la vitesse et l’efficacité globales du processus. Le KPI « Temps de cycle moyen de bout en bout » et le Dashboard « Analyse globale du temps de cycle SDLC » reposent directement sur ce calcul. La réduction du temps de cycle constitue souvent un objectif majeur des initiatives d’amélioration des processus. Pourquoi c’est important Mesure la vitesse de bout en bout du processus de développement et fournit un indicateur clé de l’efficacité globale et de la vitesse de livraison. Où les obtenir Il s’agit d’un attribut 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	La version logicielle dans laquelle l’élément de développement a effectivement été résolu et livré.
Description Dans Jira, « Fix Version » indique la release qui contient le travail terminé pour un élément. Elle matérialise le résultat concret de l’effort de développement. Cet attribut fournit le contexte réel de la release, qui peut être comparé à « PlannedReleaseVersion » pour analyser les performances de livraison. Il permet également de regrouper tous les éléments livrés dans une release donnée afin d’obtenir une vue consolidée du travail réalisé. Pourquoi c’est important Confirme la release dans laquelle un élément de travail a été inclus et fournit la référence de référence pour analyser les releases et suivre les fonctionnalités livrées. Où les obtenir Correspond au champ « fixVersions » de la réponse de l’Issue API Jira. Exemples Hotfix v2.1.1Release majeure v3.0.0v2.2.0
	Version prévue pour la mise en production PlannedReleaseVersion	La version logicielle cible ou la release dans laquelle l’élément doit être déployé.
Description Cet attribut, qui correspond souvent au champ « Affects Version/s » dans Jira, indique la release prévue pour une fonctionnalité ou une correction. Il sert de date cible pour l’achèvement du travail. Cet attribut est essentiel pour le KPI « Taux de livraison des releases dans les délais ». En comparant la date réelle de déploiement à la date de release prévue associée à cette version, vous pouvez mesurer le respect du calendrier et la prévisibilité de votre processus de release. Pourquoi c’est important Définit la date ou la release cible, ce qui permet de calculer les taux de livraison dans les délais et d’analyser le respect du calendrier. Où les obtenir Correspond aux champs « versions » ou « fixVersions » de l’Issue API Jira. Le champ utilisé pour la planification peut varier. Exemples Version 2.1Release du T1 2024Lancement du projet Phoenix

Obligatoire Recommandé Facultatif

Activités du cycle de développement logiciel

Voici les principales étapes et jalons du processus à enregistrer dans votre journal d’événements pour découvrir précisément le cycle 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 disponibles dans l’environnement de production. Il peut être déduit d’un changement de statut final vers « Done » ou « Released », ou enregistré comme événement explicite par un outil CI/CD intégré.
Pourquoi c’est important Il s’agit du point d’aboutissement principal du processus. Il est essentiel pour calculer le délai total de cycle de bout en bout et mesurer la fréquence des déploiements ainsi que le débit. Où les obtenir Cette étape peut être déduite du journal des modifications du ticket Jira lorsque le statut passe à « Released » ou « Done ». Pour davantage de précision, elle peut être enregistrée à partir des événements de déploiement transmis par des outils CI/CD comme Jenkins ou Bamboo, ou via la fonctionnalité Deployments de Jira. Collecte Horodatage du changement de statut vers « Done » ou « Released ». Type d’événement inferred
	Développement commencé	Représente le moment où un développeur commence activement à travailler 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 statut du ticket passe à « En cours ».
Pourquoi c’est important Il s’agit d’une étape essentielle pour mesurer le temps consacré au développement actif. Elle permet de distinguer le temps d’attente du travail créateur de valeur, une métrique importante pour repérer les goulots d’étranglement. Où les obtenir Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » passe pour la première fois à « In Progress », « In Development » ou à un état actif similaire. Collecte Horodatage du changement de statut vers « In Progress ». Type d’événement inferred
	Élément de développement créé	Cette étape marque le début du cycle de vie, lorsqu’un nouvel élément de développement, comme une story, un bug ou une tâche, est officiellement enregistré dans Jira. Le système capture explicitement cet événement avec un horodatage de création pour chaque ticket.
Pourquoi c’est important Cette activité constitue le début de référence du processus. Elle est essentielle pour calculer les délais de cycle de bout en bout et suivre le volume total du travail entrant. Où les obtenir Il s’agit d’un événement fondamental pour chaque ticket Jira. L’horodatage de création est enregistré dans le champ « created » de l’enregistrement du ticket, accessible via l’API Jira. Collecte Le champ d’horodatage « created » de l’objet Jira Issue. Type d’événement explicit
	Tests QA 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 tel que « In QA », « In Testing » ou « Ready for Testing ».
Pourquoi c’est important Il s’agit d’un jalon important qui ouvre le cycle de validation qualité. Mesurer le délai entre « Development Completed » et cette étape permet de mettre en évidence les retards de transfert entre les équipes de développement et de QA. Où les obtenir Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » passe à un état de test QA défini, comme « In QA ». Collecte Horodatage du changement de statut vers « In QA » ou « In Testing ». Type d’événement inferred
	Tests QA terminés	Indique que l’élément de développement a passé avec succès 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 c’est important Cette étape marque la fin d’une quality gate importante. L’analyse de la durée de la phase QA aide à optimiser les processus de test et l’affectation des ressources. Où les obtenir 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 ultérieur tel que « Ready for UAT » ou « Ready for Release ». Collecte Horodatage du changement de statut de « In QA » à « Ready for UAT ». Type d’événement inferred
	UAT approuvé	Représente la réussite 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 » vers un état tel que « Ready for Release » ou « Done ».
Pourquoi c’est important Ce jalon confirme l’acceptation métier et autorise le déploiement de l’élément en production. Il constitue une quality gate essentielle pour vérifier que le travail livré répond aux attentes des utilisateurs. Où les obtenir Cette information est déduite du journal des modifications du ticket Jira. Il s’agit de l’horodatage du changement de statut de « En UAT » vers l’état suivant du flux de travail, ce qui indique une approbation. Collecte Horodatage du changement de statut de « 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 lors du passage de « In Progress » à « In Review » ou « Ready for QA ».
Pourquoi c’est important Cette étape marque la fin de la phase centrale de développement. Elle permet d’analyser la durée du codage et l’efficacité des transferts vers l’équipe d’assurance qualité. Où les obtenir Déduit du journal des modifications du ticket Jira, en enregistrant l’horodatage auquel le champ « status » passe d’un état de développement actif à un état ultérieur tel que « In Review » ou « Ready for QA ». Collecte Horodatage du changement de statut de « In Progress » à « In Review » ou « Ready for QA ». Type d’événement inferred
	Élément de développement annulé	Représente l’arrêt d’un élément de développement avant son achèvement. Cette étape est déduite d’un changement de statut vers un état terminal tel que « Canceled », « Rejected » ou « Won’t Do », souvent accompagné d’une résolution spécifique.
Pourquoi c’est important Cette activité suit les résultats non concluants du processus. L’analyse des raisons pour lesquelles des éléments sont annulés peut révéler des problèmes de planification, de priorisation ou de définition des exigences. Où les obtenir Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le statut du ticket passe à « Canceled » ou « Won’t Do » et une résolution correspondante est définie. Collecte Horodatage du changement de statut vers « 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 action administrative, qui confirme qu’aucun travail supplémentaire n’est prévu sur l’élément. Elle est souvent déduite d’un changement de statut vers « Closed » et du renseignement d’une valeur dans le champ « Resolution ».
Pourquoi c’est important Cette étape représente la fin absolue du parcours d’un élément. La comparaison avec « Deployed to Production » peut révéler un décalage administratif ou une période de surveillance après le déploiement. Où les obtenir Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » passe à « Closed » et une résolution est définie. Collecte Horodatage du changement de statut vers « 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 spécifié, examiné et priorisé, et qu’il est prêt à être pris en charge par un développeur. Cela est généralement déduit d’un changement de statut dans le flux de travail, par exemple lors du passage de « Backlog » à « À faire » ou « Prêt pour le développement ».
Pourquoi c’est important Son suivi 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 au perfectionnement du temps de développement actif. Où les obtenir 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 ». Collecte Horodatage du changement de statut vers un état indiquant que l’élément est prêt avant 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, dans l’attente de son déploiement. Cette étape est souvent déduite lorsque le statut du ticket passe à « Ready for Release » ou lorsque le champ « Fix Version » est renseigné.
Pourquoi c’est important Cette activité permet de suivre la préparation des mises en production et le temps pendant lequel les éléments attendent une fenêtre de déploiement une fois les travaux de développement et de test terminés. Où les obtenir Généralement déduite du journal des modifications du ticket Jira sous la forme d’un changement de statut vers « Ready for Release ». Elle peut également être déduite de l’horodatage auquel le champ « Fix Version/s » est renseigné. Collecte Horodatage du changement de statut vers « 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 vérifié le code sous l’angle de la qualité, des normes et du fonctionnement attendu. Cette étape peut être déduite d’un changement de statut, par exemple lors du passage de « In Review » à « Ready for QA », ou provenir directement des outils de développement intégrés.
Pourquoi c’est important Cette activité constitue une quality gate essentielle. L’analyse de sa durée et de ses résultats, notamment les reprises nécessaires, contribue à améliorer la qualité du code et à réduire les bugs détectés plus tard dans le processus. Où les obtenir Cette étape est généralement déduite du journal des modifications du ticket Jira lorsque le statut quitte un état « Code Review ». Elle peut également être enregistrée comme événement explicite si des outils de gestion du code, comme Bitbucket ou GitHub, sont intégrés. Collecte Horodatage du changement de statut de « In Review » vers l’état suivant. Type d’événement inferred
	Tests QA échoués	Indique que l’équipe QA a détecté un défaut, ce qui entraîne le renvoi de l’élément de développement aux développeurs pour reprise. Cette étape est déduite d’une transition de statut vers un état antérieur, par exemple de « In QA » à « In Progress » ou « To Do ».
Pourquoi c’est important Cette activité est essentielle pour identifier les boucles de reprise. Le suivi de sa fréquence permet de quantifier le coût de la non-qualité et de repérer les domaines à améliorer dans le développement ou la définition des exigences. Où les obtenir 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 ». Collecte Horodatage du changement de statut d’un état de test vers un état de développement. Type d’événement inferred
	UAT commencé	Marque le début des tests d’acceptation utilisateur, au cours desquels les parties prenantes métier ou les utilisateurs finaux valident la nouvelle fonctionnalité. Cette étape est déduite d’un changement de statut Jira vers un état tel que « In UAT » ou « User Acceptance Testing ».
Pourquoi c’est important Cette activité suit 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 cycles de retour. Où les obtenir Déduit du journal des modifications du ticket Jira. Il s’agit de l’horodatage auquel le champ « status » est mis à jour avec « In UAT » ou un statut défini similaire. Collecte Horodatage du changement de statut vers « In UAT ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Jira Software

Étapes

Connectez-vous à votre instance Jira Software.
Dans la barre de navigation principale, sélectionnez Tickets, puis cliquez sur Rechercher des tickets. Le navigateur de tickets s’ouvre.
Sur la page de recherche, remplacez la recherche De base par la recherche Avancée afin d’activer l’utilisation du langage de requête Jira (JQL).
Dans la barre de requête JQL, saisissez la requête JQL fournie. Remplacez les valeurs d’exemple correspondant à la clé du projet et à la période afin de les adapter à 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 l’angle supérieur droit de la page des résultats, cliquez sur l’icône Exporter (elle peut ressembler à une icône de partage ou être accompagnée d’un libellé explicite), puis sélectionnez l’option XML. N’utilisez pas le format CSV, car le format XML contient l’historique complet et structuré du journal des modifications nécessaire à la création du journal d’événements.
Enregistrez le fichier XML téléchargé sur votre ordinateur. Ce fichier contient un enregistrement pour chaque ticket Jira, ainsi que toutes les modifications historiques imbriquées dans cet enregistrement.
Étape importante de transformation : le fichier XML exporté n’est pas un journal d’événements à plat. Vous devez utiliser un script externe ou un outil ETL pour l’analyser. Le script doit parcourir chaque balise <item> (qui représente un ticket Jira) dans le fichier XML.
Pour chaque ticket, le script doit d’abord générer une ligne pour l’activité Élément de développement créé, en utilisant l’horodatage du champ created.
Ensuite, le script doit analyser les données <changelog> de chaque ticket. Pour chaque <changeitem> représentant une transition de statut, générez une nouvelle ligne dans le fichier de sortie. Associez la transition de statut Jira, par exemple de « En cours » à « En revue », à l’activité métier correspondante, par exemple « Développement terminé », puis utilisez l’horodatage de la transition pour renseigner EventTime.
Le script doit renseigner tous les attributs obligatoires et recommandés pour chaque ligne, en extrayant de la structure XML des informations telles que la clé du ticket, son type, la personne affectée et le projet.
Après avoir traité tous les tickets et leur historique, enregistrez les données transformées dans un fichier CSV dont les en-têtes correspondent aux attributs spécifiés. Le fichier sera prêt à être importé dans l’outil de Process Mining.

Configuration

Filtres de requête JQL : la requête JQL est l’outil principal de sélection des données. Les filtres essentiels comprennent project pour cibler certains projets de développement, issuetype pour inclure uniquement les éléments pertinents tels que Story, Bug ou Task, et created pour définir la période d’analyse.
Plage de dates : 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 faire ressortir des tendances pertinentes, tout en conservant une taille de fichier raisonnable. Définissez la période à l’aide de created >= 'YYYY-MM-DD' et created <= 'YYYY-MM-DD' dans votre requête JQL.
Types de tickets : soyez précis dans les valeurs de issuetype. Vous souhaiterez souvent inclure Story, Bug, Task et Spike, mais exclure les tickets conteneurs tels que Epic ou les tickets trop granulaires comme Sub-task, s’ils ne représentent pas le cas principal.
Format d’export : vous devez sélectionner XML comme format d’export. L’export CSV standard ne contient pas toujours de manière fiable les données structurées du journal des modifications nécessaires pour reconstituer la séquence des activités.
Autorisations utilisateur : l’utilisateur qui effectue l’export doit disposer de l’autorisation « Browse Projects » pour les projets Jira indiqués dans la requête JQL.

a 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

Établir la connexion à la base de données : vérifiez que vous disposez d’identifiants avec accès en lecture seule et d’une connectivité réseau vers la base de données SQL principale de l’instance Jira. Cette méthode s’applique uniquement aux installations Jira auto-hébergées.
Se connecter 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 de données Jira à l’aide des identifiants fournis.
Identifier 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 (Paramètres du projet > Flux de travail). Notez précisément les noms des statuts correspondant à chaque activité que vous souhaitez suivre, par exemple « Backlog », « En cours », « En révision » et « Terminé ».
Personnaliser la requête SQL : copiez la requête SQL fournie dans votre client. Vous devez personnaliser les valeurs des espaces réservés. Portez une attention particulière aux noms des statuts dans les clauses WHERE de chaque bloc UNION ALL, car ils doivent correspondre exactement au flux de travail de votre projet.
Définir les paramètres de la requête : modifiez le filtre de période (WHERE ji.created >= '2023-01-01') afin de définir 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')).
Configurer les champs personnalisés : identifiez l’identifiant du champ personnalisé « Team Name » dans votre instance Jira. Vous pouvez le trouver en accédant à la page d’administration des champs personnalisés de Jira. Remplacez l’espace réservé 'customfield_10100' dans la requête par l’identifiant réel.
Exécuter la requête : exécutez la requête SQL modifiée sur la base de données Jira.
Vérifier le résultat : examinez brièvement les données renvoyées afin de vous assurer qu’elles contiennent des lignes correspondant à différentes activités et que les colonnes sont renseignées comme prévu.
Exporter le journal d’événements : exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que l’encodage du fichier est UTF-8.
Préparer l’importation : vérifiez que les en-têtes de colonnes du fichier CSV exporté correspondent aux noms d’attributs requis : DevelopmentItem, Activité, 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 la base Jira afin d’éviter toute modification accidentelle des données.
Noms des statuts du flux de travail : la requête repose principalement sur un filtrage par nom de statut, par exemple « En cours » ou « Terminé ». Ces noms dépendent de chaque flux de travail et de chaque projet Jira. Vous devez remplacer les valeurs d’exemple dans la requête par les noms exacts de votre configuration.
Période : la requête contient une clause WHERE ji.created >= '[YYYY-MM-DD]' pour limiter le volume de données traité. Pour une première analyse, il est recommandé d’utiliser une période de trois à six mois afin de conserver un volume gérable et d’accélérer l’exécution de la requête.
Filtre de projet : pour cibler l’analyse, il est vivement 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 être très lent.
Champ personnalisé de l’équipe : « Nom de l’équipe » est supposé être un champ personnalisé. La requête fournie utilise l’identifiant d’exemple customfield_10100, qui doit être remplacé par l’identifiant correspondant à la configuration de votre instance Jira.
Performances : les requêtes directes sur la base de données peuvent mobiliser beaucoup de ressources. Exécutez 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 dégrader les performances de Jira pour les utilisateurs.

a 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 effectuer les appels d’API et pandas pour manipuler les données, en exécutant la commande : pip install requests pandas.
Générez un jeton d’API Jira : connectez-vous à votre instance Jira. Accédez aux paramètres de votre profil utilisateur, puis à Sécurité et sélectionnez « Créer et gérer les jetons d’API ». Créez un nouveau jeton et copiez-le dans un emplacement sécurisé. Ce jeton remplacera le mot de passe pour l’authentification du 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 située en haut avec l’URL de votre site Jira, votre adresse e-mail et le jeton d’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éfinit le périmètre des tickets à extraire. Pour commencer, vous pouvez filtrer par projet, type de ticket et période précise, 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, car elle convertit les statuts propres au flux de travail Jira de votre organisation en activités standardisées pour le Process Mining. Vous devez mettre à jour les clés, qui correspondent aux noms des statuts Jira, afin qu’elles correspondent exactement à votre flux de travail.
Exécutez le script : lancez le script depuis votre terminal à l’aide de la commande python extract_jira_log.py. Le script se connecte à l’API Jira, récupère les données des tickets et traite les journaux des 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 continue d’envoyer des requêtes jusqu’à la récupération de tous les tickets correspondant à la requête JQL.
Traitez les journaux des modifications des tickets : pour chaque ticket, le script récupère l’historique complet. Il identifie l’événement de création, puis parcourt tous les changements de statut afin de créer une nouvelle ligne dans le journal d’événements pour chaque transition pertinente, selon votre STATUS_MAPPING.
Générez le fichier du 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 telles que 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 : l’URL de base de votre instance Jira, par exemple https://your-company.atlassian.net.
JIRA_EMAIL : l’adresse e-mail du compte utilisateur utilisé pour l’authentification.
JIRA_API_TOKEN : le jeton d’API généré dans les paramètres de sécurité de l’utilisateur Jira pour l’authentification du script.
JQL_QUERY : la chaîne du langage de requête Jira qui filtre les tickets à extraire. Il est vivement recommandé de définir une période, par exemple les six à douze derniers mois, afin de maîtriser le volume de données. Vous devriez également filtrer par projet et par types de tickets pertinents, par exemple Story, Bug et Task, pour garantir que vous analysez le bon processus.
STATUS_MAPPING : un dictionnaire Python qui associe les noms de statut propres à votre flux de travail Jira aux noms d’activités génériques requis. Il s’agit du paramètre le plus important pour garantir l’exactitude du modèle de processus. Vous devez le personnaliser 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. L’utilisateur doit également être autorisé à utiliser l’API REST.

a 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 la charge utile JSON complète, 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 du cas, Activity comme nom de l’activité, EventTime comme horodatage de l’événement, SourceSystem comme 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 avec des déclencheurs liés aux événements des tickets. Configurez des règles pour la création des tickets, les transitions de statut du flux de travail, les changements de résolution, les changements de Fix Version lorsque cela s’applique, ainsi que les événements de déploiement ou de revue intégrés disponibles dans votre configuration Jira. Jira ne fournit pas un flux de travail universel. Associez donc les noms de statut et les conditions de transition locaux aux activités requises.
Configurez chaque règle pour envoyer un webhook à [Your webhook endpoint]. Utilisez POST et un contenu JSON. Incluez la clé du ticket, son type, la personne affectée, la priorité, le statut, le projet, le champ d’équipe s’il est disponible, l’horodatage de l’événement, les informations de transition, la résolution, les valeurs de Fix Version et l’identifiant de l’événement Jira. Ne demandez pas à ProcessMind de déduire les activités à partir de l’historique des statuts.
Créez des associations explicites entre les activités dans le récepteur du webhook ou la couche d’ingestion. Chaque webhook admissible doit devenir une ligne du 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 revue ou de fin du développement à Development Completed, les transitions de revue ou les événements de revue intégrés à Code Review Performed, les transitions de test à QA Testing Started, les retours en arrière pendant l’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 cette association en vous fondant sur 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 lorsque ces valeurs correspondent à la signification métier attendue. Évitez de créer plusieurs lignes pour un même webhook, sauf si la 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 contenir l’horodatage de l’événement, SourceSystem doit contenir Jira Software et LastDataUpdate doit contenir l’horodatage d’actualisation de l’ingestion. Renseignez les attributs recommandés lorsqu’ils sont disponibles, notamment Assignee, ItemType, ItemPriority, ItemStatus, ProjectName et TeamName.
Dédupliquez les livraisons de webhooks à 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 peut être réessayée. Le récepteur doit donc être idempotent. 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 configurée. Confirmez que les 14 valeurs d’activité peuvent apparaître comme 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 config, car l’extraction repose sur la configuration des règles et la normalisation des événements, et non sur une requête de base de données Jira.
Identifiant du 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énements : 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 lorsqu’ils sont pris en charge et pertinents dans la configuration Jira.
Association des statuts : tenez à jour une table d’association ou une configuration propre au projet pour les statuts et les transitions Jira locaux. Les noms de statut tels que In Progress, In QA, Done ou Closed doivent être interprétés selon la sémantique approuvée du flux de travail.
Période : pour la validation initiale, collectez trois à six mois d’événements. Pour une diffusion continue, démarrez le récepteur avant la période d’observation cible et prévoyez une stratégie de rejeu ou de rattrapage pour les é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 des événements concernés. Company Code et Document Type ne sont pas des concepts 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 est disponible, l’horodatage de l’événement, les informations 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, le mécanisme d’authentification pris en charge par le récepteur, la validation des requêtes, la gestion des nouvelles tentatives et un traitement idempotent. Ne placez pas les identifiants directement dans les lignes du journal d’événements.
Performances : utilisez une ingestion asynchrone, un traitement par lots après réception lorsqu’il est pris en charge, des clés de déduplication 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, point de terminaison HTTPS accessible et éventuelles fonctionnalités de forfait Jira ou d’intégration nécessaires aux webhooks sortants et aux événements de déploiement.
Qualité des données : définissez le comportement à adopter pour les tickets supprimés, les statuts renommés, les personnes affectées manquantes, les champs d’équipe manquants, la conversion des fuseaux horaires, les livraisons en double et les événements reçus dans le désordre.

a 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 ?

Commencez dès aujourd’hui à optimiser votre cycle de développement logiciel en préparant vos données avec ce modèle. Obtenez les analyses nécessaires pour accélérer la livraison et améliorer la qualité.

Retour au guide d’amélioration Télécharger le modèle

Optimisez votre SDLC dans Jira Software dès aujourd’hui !

Identifiez les inefficacités et réduisez de 30 % le temps de cycle de votre SDLC.

Démarrer l’essai gratuit

Aucune carte bancaire requise, commencez l’optimisation en quelques minutes.

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

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

Attributs du cycle de développement logiciel

Activités du cycle de développement logiciel

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête config

Requête directe de la base Jira via SQL, en environnement auto-hébergé

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST officielle de Jira

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez votre SDLC dans Jira Software dès aujourd’hui !

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

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

Attributs du cycle de développement logiciel

Activités du cycle de développement logiciel

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête config

Requête directe de la base Jira via SQL, en environnement auto-hébergé

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST officielle de Jira

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez votre SDLC dans Jira Software dès aujourd’hui !

Nous attachons de l’importance à votre confidentialité