Votre template de données du cycle de développement logiciel

L’heure de début de l’événement indique la date et l’heure exactes auxquelles une activité a commencé. Elle établit l’ordre chronologique de tous les événements d’un même cas, ce qui est indispensable pour reconstituer précisément le flux du processus.

Les horodatages constituent le fondement de toutes les analyses de Process Mining fondées sur le temps. Ils servent à calculer des indicateurs clés de performance tels que les temps de cycle, les temps d’attente et les durées de traitement entre les activités. Leur analyse permet de localiser les goulots d’étranglement, de mesurer l’efficacité du processus et de comprendre la durée des différentes étapes du cycle de vie du développement. Par exemple, le délai entre « Code Submitted for Review » et « Code Review Completed » peut révéler des retards dans le processus de revue.

Cet horodatage est essentiel pour classer correctement les événements et calculer toutes les métriques temporelles, notamment le temps de cycle et les goulots d’étranglement.

Il est disponible dans les journaux d’événements, les pistes d’audit ou les tables d’historique qui enregistrent les changements apportés aux éléments de travail de développement.

L’identifiant de l’élément de développement est la clé primaire qui identifie de manière unique chaque instance de cas pendant tout le cycle de vie du développement logiciel. Chaque identifiant représente un travail distinct, comme une user story, une tâche ou une correction de bug, depuis sa création jusqu’à sa résolution finale ou son déploiement.

Dans une analyse de Process Mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque élément de travail. Il permet à l’outil de relier toutes les activités associées, telles que « Development Started », « Code Review Completed » et « Deployed to Production », au sein d’un flux de processus cohérent. L’analyse du cycle de vie des éléments de développement permet d’identifier les variations, les retards et les boucles de retouche associés à des travaux précis.

Il s’agit de l’identifiant de cas fondamental nécessaire pour suivre le cycle de vie complet de chaque élément de travail de développement, du début à la fin.

Il se trouve généralement dans les tables principales des éléments de travail ou du suivi des problèmes d’un système de gestion du développement logiciel.

Le nom de l’activité décrit une étape précise ou un changement d’état dans le processus de développement. Ces activités constituent les nœuds de la carte de processus et représentent des jalons importants, comme « Item Approved for Development », « Code Submitted for Review » ou « QA Testing Completed ».

Cet attribut est essentiel pour visualiser le flux du processus et comprendre la séquence des événements. En analysant les différentes activités, les équipes peuvent identifier les parcours les plus fréquents, repérer les écarts du processus et mesurer le temps passé aux différentes étapes. Il constitue la base de l’analyse des goulots d’étranglement, de la détection des reprises et de la vérification de la conformité par rapport à un modèle de processus cible.

Il définit les étapes du processus et permet de visualiser et d’analyser le flux de travail de développement.

Il est souvent dérivé des journaux de changements de statut, des flux d’événements ou des tables d’historique associées aux éléments de travail de développement.

L’attribut Dernière mise à jour des données enregistre la date et l’heure auxquelles les données ont été extraites ou mises à jour pour la dernière fois depuis le système source. Il fournit une indication claire de leur fraîcheur et de leur pertinence.

Cette information est essentielle pour garantir que les analyses et les Dashboards reposent sur des informations à jour. Les parties prenantes peuvent voir immédiatement dans quelle mesure la vue du processus est actualisée, ce qui renforce la confiance dans les analyses produites. Il s’agit également d’une métadonnée importante pour gérer les pipelines de données et planifier leur actualisation.

Il indique la fraîcheur des données et garantit que l’analyse est suffisamment actuelle et pertinente pour la prise de décision.

Cette valeur est généralement générée et stockée par le pipeline d’extraction, de transformation et de chargement des données (ETL).

L’attribut Système source identifie l’application ou la plateforme d’origine dans laquelle les données du cycle de vie du développement ont été enregistrées. Il est particulièrement utile dans les environnements où plusieurs outils de développement sont utilisés, par exemple Jira pour le suivi des problèmes et GitLab pour la gestion du code source.

Dans le cadre de l’analyse, la précision du système source facilite la validation des données et fournit un contexte pour les données du processus. Elle permet de comparer les processus gérés dans différents systèmes et garantit une interprétation correcte des données, car les noms de champs et les conventions de processus peuvent varier d’un système à l’autre. Elle peut également servir à filtrer l’analyse sur les données d’un outil donné.

Il fournit des informations sur l’origine des données, ce qui est essentiel pour leur validation et pour les analyses portant sur plusieurs systèmes intégrés.

Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données afin d’identifier l’origine des enregistrements.

Cet attribut identifie la personne ou le groupe responsable de l’exécution de l’étape en cours ou de l’ensemble de l’élément de travail. La personne affectée peut changer plusieurs fois au cours du cycle de vie, ce qui reflète les transmissions entre différents rôles, comme les développeurs, les testeurs d’assurance qualité et les réviseurs.

L’analyse de l’attribut Assigned To est essentielle pour comprendre la charge de travail des équipes, l’efficacité des transmissions et les modes de collaboration. Elle permet de filtrer la carte de processus afin d’examiner le travail d’une personne ou d’une équipe donnée et d’identifier les goulots d’étranglement liés aux ressources. Une analyse des réseaux sociaux fondée sur les transmissions entre personnes affectées peut révéler des lacunes de communication ou des structures de collaboration inutilement complexes.

Il permet d’analyser la charge des ressources, la fréquence des transferts et les modes de collaboration, afin d’améliorer l’efficacité de l’équipe.

Il se trouve dans l’enregistrement de l’élément de travail ou du problème, souvent dans l’historique ou le journal d’audit de l’élément.

L’heure de fin de l’événement marque la conclusion d’une activité. Alors que de nombreuses étapes du processus sont enregistrées comme des événements instantanés, avec des heures de début et de fin identiques, certaines activités ont une durée mesurable. Par exemple, une activité de revue de code peut avoir une heure de début et une heure de fin distinctes.

Cet attribut est essentiel pour calculer le temps de traitement actif de tâches précises et le distinguer du temps d’inactivité ou d’attente. En comparant la durée entre l’heure de début et l’heure de fin de l’événement, les analystes peuvent mesurer l’effort consacré aux activités créatrices de valeur. Cette approche permet une analyse plus fine de l’utilisation des ressources et aide à identifier les tâches qui consomment le plus de temps de travail actif.

Il permet de calculer le temps de traitement actif de chaque activité, de le distinguer du temps d’attente et d’obtenir une vision plus précise de l’effort fourni.

Il peut être présent dans les journaux d’événements ou être déduit de l’horodatage de l’activité suivante dans la séquence pour le même élément de travail.

Cet attribut identifie l’équipe, la squad ou le groupe chargé de livrer l’élément de développement. Dans les grandes organisations, le travail est souvent réparti entre plusieurs équipes spécialisées, comme « Frontend », « Backend », « Mobile » ou « Platform ».

L’analyse par nom d’équipe permet de comparer les performances et de partager les bonnes pratiques entre les équipes. Elle aide à répondre à des questions telles que « Quelle équipe affiche le temps de cycle le plus court ? » ou « Une équipe connaît-elle davantage de reprises que les autres ? ». Cette analyse peut révéler des différences de flux de travail, de compétences ou de disponibilité des ressources qui influencent les performances globales de livraison et font apparaître des possibilités d’amélioration ciblées.

Il permet de comparer les performances des différentes équipes, d’identifier les bonnes pratiques et de repérer les domaines à améliorer.

Il est souvent associé à l’utilisateur assigné ou enregistré directement dans le projet ou l’élément de travail.

Le nom du projet fournit un contexte en regroupant les éléments de travail associés à un produit, une initiative ou une base de code donnée. Les pratiques de développement et les temps de cycle peuvent varier considérablement d’un projet à l’autre, par exemple entre un système existant et une nouvelle application développée à partir de zéro.

Cet attribut permet d’agréger et de comparer les processus de développement à un niveau global dans les différentes parties de l’organisation. En filtrant l’analyse par projet, les responsables peuvent évaluer la santé et l’efficacité de chaque initiative de développement. Il est également essentiel pour comprendre le lien entre les performances du processus et le contexte ou l’environnement technique propre à un projet.

Il permet de segmenter l’analyse du processus par produit ou initiative et de révéler les écarts de performance liés au contexte du projet.

Il s’agit d’un champ standard de l’enregistrement de l’élément de travail ou du problème, ou du nom du dépôt dans des systèmes tels que Git.

L’attribut Priority indique le niveau d’urgence métier ou technique d’un élément de travail. Il prend généralement des valeurs telles que « High », « Medium » ou « Low » et aide les équipes à déterminer la prochaine tâche à traiter.

Dans le Process Mining, la priorité constitue une dimension d’analyse particulièrement utile. Elle permet de vérifier si les éléments hautement prioritaires sont effectivement traités plus rapidement que les éléments faiblement prioritaires. La comparaison des temps de cycle selon les niveaux de priorité peut révéler si le processus respecte les priorités métier. Si les éléments prioritaires sont souvent retardés, cela peut signaler des problèmes de planification, de répartition des ressources ou de conception du flux de travail.

Aide à vérifier si les travaux hautement prioritaires avancent plus rapidement dans le processus et à identifier les goulots d’étranglement qui touchent de manière disproportionnée les éléments importants.

Il s’agit d’un champ standard de l’enregistrement de l’élément de travail ou du problème dans la plupart des systèmes de gestion du développement.

Le statut de l’élément de développement représente l’état d’un élément de travail à un moment précis. Alors que le nom de l’activité capture l’événement de changement de statut, cet attribut capture l’état lui-même. Il peut être utile pour analyser l’état du travail au moment où un événement s’est produit.

Cet attribut sert souvent à créer le nom de l’activité, mais il fournit également un contexte supplémentaire. Par exemple, l’analyse du champ de statut permet de mesurer la durée pendant laquelle les éléments restent dans un état donné, tel que « Blocked » ou « Waiting for Review ». Comprendre le temps passé dans des états improductifs est essentiel pour identifier les retards systémiques et améliorer l’efficacité du flux.

Il permet d’analyser le temps passé dans les différents états et d’identifier les retards ainsi que le temps consacré à des statuts sans valeur ajoutée, comme « Blocked ».

Il est disponible comme champ principal de l’enregistrement de l’élément de travail ou du problème et figure dans son journal d’historique.

Cet attribut catégorise la nature du travail effectué. Les différents types d’éléments de travail suivent souvent des parcours distincts et répondent à des attentes différentes en matière de performance. Par exemple, un « Bug » peut nécessiter un processus de correctif urgent, tandis qu’une « Feature » suit un cycle standard de développement et de test.

Grâce à cet attribut, les analystes peuvent comparer les flux de processus et les performances selon les types de travaux. Ils peuvent ainsi répondre à des questions telles que « Le processus de correction des bugs est-il plus rapide que celui de développement des fonctionnalités ? » ou « Les éléments liés à la dette technique font-ils l’objet de davantage de retouches ? ». Il s’agit d’une dimension fondamentale pour segmenter les données et obtenir des analyses plus précises et exploitables.

Il permet de comparer les processus et les performances entre différentes catégories de travaux et de révéler les inefficacités propres à certains types de développement.

Il s’agit d’un champ standard de l’enregistrement de l’élément de travail ou du problème dans la plupart des systèmes de gestion du développement.

L’attribut Créateur identifie la personne à l’origine de l’élément de travail. Il peut s’agir d’un responsable produit créant une user story, d’un testeur QA enregistrant un bug ou d’un agent du service client signalant un problème rencontré par un client.

L’analyse du créateur des éléments de travail peut fournir des informations sur les sources de la demande. Par exemple, un volume élevé de bugs signalés par les utilisateurs finaux peut indiquer des problèmes de qualité dans les versions récentes. Cet attribut peut également servir à analyser la clarté et la qualité des exigences initiales en mettant en relation le créateur avec les retouches ou les retards ultérieurs.

Il aide à identifier les personnes à l’origine des travaux et à analyser les sources de la demande, des bugs ou des demandes de fonctionnalités.

Il s’agit d’un champ standard tel que « Reporter » ou « Author » dans l’enregistrement initial de création d’un élément de travail.

La gravité se distingue de la priorité : elle mesure l’impact technique d’un problème, tandis que la priorité mesure l’urgence de sa correction. Par exemple, une faute de frappe sur une page rarement consultée peut présenter une faible gravité et une faible priorité, alors qu’un problème critique de corruption des données aura une gravité et une priorité élevées.

Cet attribut est essentiel pour l’analyse de la qualité, notamment lors de l’étude des processus de correction des bugs. Il permet aux équipes d’évaluer si elles traitent efficacement les problèmes les plus graves en premier. En analysant le temps de cycle selon les niveaux de gravité, les organisations peuvent s’assurer que les problèmes critiques du système sont résolus rapidement afin de limiter leur impact sur les clients.

Il permet d’analyser l’efficacité avec laquelle l’équipe traite les problèmes selon leur impact technique et de s’assurer que les problèmes critiques sont résolus rapidement.

Il s’agit d’un champ standard, notamment pour les éléments de travail de type « Bug » ou « Incident », dans les systèmes de gestion du développement.

L’indicateur de retouche est un attribut booléen ou catégoriel dérivé qui signale les événements faisant partie d’un cycle de retouche. Cette situation est généralement identifiée lorsque le flux du processus revient en arrière, par exemple de « QA Testing » à « Development in Progress », ou lorsque des activités précises telles que « Rework Identified in QA » se produisent.

Cet attribut est particulièrement utile pour analyser la qualité et l’efficacité. Il permet de calculer directement les taux de retouche et de mettre en évidence les parties du processus qui génèrent le plus de retouches. En filtrant les activités de retouche, les équipes peuvent effectuer une analyse des causes profondes afin de comprendre pourquoi les problèmes de qualité ne sont pas détectés plus tôt. La réduction des retouches constitue un levier important pour améliorer à la fois la vitesse de développement et la qualité du produit.

Il quantifie directement les retouches et permet aux équipes d’en mesurer la fréquence, d’en analyser les causes et de suivre l’amélioration de la qualité au fil du temps.

Il est généralement dérivé lors de la transformation des données, en identifiant les boucles de retour en arrière dans le flux du processus ou les noms d’activités associés à des échecs précis.

L’attribut Version planifiée associe un élément de développement à un calendrier de livraison ou à une version précise. Il est souvent utilisé dans la planification des versions pour regrouper les fonctionnalités et les corrections en vue d’un déploiement coordonné.

L’analyse par version planifiée aide à évaluer la prévisibilité et la fiabilité du processus de publication. Elle permet de suivre les taux de livraison dans les délais en comparant la version planifiée à la date réelle de déploiement. Elle contribue également à la gestion du périmètre et à la compréhension du flux des travaux destinés à une version donnée, en mettant en évidence les risques ou les retards susceptibles d’affecter le calendrier de livraison.

Il relie les travaux de développement aux calendriers de livraison et permet d’analyser les taux de livraison dans les délais ainsi que la prévisibilité des versions.

Il s’agit d’un champ standard tel que « Fix Version », « Target Release » ou « Iteration Path » dans les outils de planification agile et de développement.