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

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

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

Ce template fournit un guide complet pour collecter et préparer les données de votre cycle de développement logiciel à partir de GitHub. Vous y trouverez les attributs recommandés, les activités essentielles à suivre et des conseils pratiques pour extraire les données. Utilisez cette ressource pour constituer un journal d'événements fiable, adapté à l'analyse et à l'optimisation de vos processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction
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.

Attributs du cycle de vie du développement logiciel

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le cycle de vie du développement logiciel et découvrir précisément le processus.
3 Obligatoire 5 Recommandé 15 Facultatif
Nom Description
Activité
ActivityName
Nom d’un événement ou d’une tâche précis survenu au cours du cycle de vie du développement logiciel.
Description

Le nom de l’activité décrit une étape unique du processus de développement, comme « Issue Created », « Code Pushed to PR », « Pull Request Approved » ou « Deployment Succeeded ». Ces événements forment la séquence d’étapes qui constitue le processus de bout en bout d’un élément de développement.

Cet attribut est fondamental pour le Process Mining, car il sert à construire la carte de processus. L’analyse de la séquence, de la fréquence et de la durée de ces activités révèle le flux réel du processus, identifie les parcours courants, met en évidence les écarts et localise les goulots d’étranglement.

Pourquoi c’est important

Cet Attribut constitue la structure de base de la carte du processus et permet de visualiser et d’analyser la séquence des événements du cycle de vie du développement.

Où les obtenir

Dérivé du champ « action » des charges utiles d’événements webhook, par exemple « opened » ou « closed » pour un problème, ou du type d’événement lui-même, comme « PushEvent » ou « PullRequestReviewEvent ».

Exemples
Problème crééPull request ouverteCode poussé vers la PRRevue demandéePull request fusionnée
Élément de développement
DevelopmentItemId
Identifiant unique d’une unité de travail de développement, comme une fonctionnalité, un correctif de bug ou une tâche. Il sert d’identifiant de cas principal.
Description

L’identifiant de l’élément de développement suit un élément de travail depuis sa création jusqu’à son déploiement final. Il relie toutes les activités associées, comme la création d’une branche, les commits, les pull requests, les revues et les déploiements, au sein d’une même instance de processus cohérente.

Dans les analyses, cet identifiant sert à calculer le temps de cycle de bout en bout d’une tâche de développement. Il permet de reconstituer l’intégralité du parcours d’une fonctionnalité ou d’un correctif, puis d’analyser en détail les goulots d’étranglement, les boucles de reprise et les variations du processus pour chaque élément de travail.

Pourquoi c’est important

Il s’agit de la clé essentielle du Process Mining, qui relie tous les événements de développement associés au sein d’un même cas afin de visualiser et d’analyser précisément le cycle de vie du développement logiciel de bout en bout.

Où les obtenir

Il s’agit généralement du numéro du problème ou de la pull request dans GitHub. Il peut être extrait du champ « number » de la charge utile des événements webhook ou des réponses d’API associés aux problèmes ou aux pull requests.

Exemples
101PR-2345TASK-812
Heure de début
EventTimestamp
Date et heure exactes auxquelles une activité ou un événement de développement précis s’est produit.
Description

Cet horodatage marque le début d’une activité. Il est essentiel pour classer les événements par ordre chronologique et reconstituer le flux du processus pour chaque élément de développement. La séquence et l’écart de temps entre ces horodatages servent à analyser la performance du processus.

Dans le cadre de l’analyse, cet attribut est indispensable au calcul de toutes les métriques temporelles, notamment les temps de cycle, les durées de traitement et les temps d’attente. Il permet d’identifier les délais entre les étapes et fournit les données nécessaires à l’analyse des goulots d’étranglement et au suivi de la performance dans les Dashboards.

Pourquoi c’est important

Cet horodatage est essentiel pour classer correctement les événements et calculer toutes les métriques de performance, notamment les temps de cycle et la durée des goulots d’étranglement.

Où les obtenir

Se trouve généralement dans les champs « created_at » ou « updated_at » des charges utiles JSON provenant des API et des webhooks GitHub pour différents objets, comme les problèmes, les pull requests et les commits.

Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Dépôt
RepositoryName
Nom du dépôt de code dans lequel l’activité de développement est réalisée.
Description

Le dépôt sert d’identifiant de projet ou de produit. Il contient l’ensemble du code, des problèmes et des pull requests d’une application ou d’un composant donné. Il permet de segmenter et de comparer les processus de développement entre différents produits ou équipes.

Dans l’analyse, cet Attribut permet de filtrer et de comparer la performance des processus entre différents projets. Il aide à répondre à des questions telles que « Quel projet présente le temps de cycle le plus long ? » ou « Comment le processus de correction des bugs du projet A se compare-t-il à celui du projet B ? ». Il est essentiel au Dashboard « Throughput by Project and Type ».

Pourquoi c’est important

Permet de segmenter et de comparer les processus de développement entre différents projets, produits ou équipes, pour une analyse plus ciblée.

Où les obtenir

Disponible dans l’objet « repository » de presque toutes les charges utiles de webhooks et d’API GitHub. Le champ utilisé est généralement « repository.full_name » ou « repository.name ».

Exemples
my-org/web-appmy-org/api-servicemy-org/data-pipeline
Heure de fin
EndTimestamp
Date et heure exactes auxquelles une activité ou un événement de développement précis a été terminé.
Description

L’horodatage de fin marque l’achèvement d’une activité. Si de nombreux événements GitHub sont instantanés, comme « Issue Created », certaines activités ont une durée mesurable, comme l’exécution d’un contrôle CI. La différence entre l’heure de fin et l’heure de début donne le temps de traitement d’une activité.

Cet Attribut sert à calculer la métrique « ProcessingTime », essentielle pour comprendre la part d’effort actif consacrée à différentes tâches, comme les revues de code ou les contrôles automatisés. L’analyse des temps de traitement aide à identifier les activités inefficaces qui consomment trop de temps.

Pourquoi c’est important

Permet de calculer précisément les temps de traitement des activités et de distinguer le temps de travail actif du temps d’attente.

Où les obtenir

Peut être trouvé dans le champ « completed_at » des objets d’exécution de contrôles ou être déduit de l’horodatage d’un événement ultérieur qui clôt logiquement l’activité.

Exemples
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorité
Priority
Niveau de priorité attribué à un élément de développement, par exemple « High », « Medium » ou « Low ».
Description

La priorité indique le degré d’urgence ou l’importance métier d’un élément de travail. Dans GitHub, la priorité n’est pas un champ natif et est généralement gérée à l’aide de labels, par exemple « P1-High » et « P2-Medium ». Une convention de nommage cohérente est nécessaire pour extraire ces informations de manière fiable.

Cet attribut est essentiel pour la « Priority-Based Flow Analysis ». Il permet aux analystes de vérifier si les éléments prioritaires sont effectivement traités plus rapidement que les éléments moins prioritaires et de mesurer la variation du temps de cycle selon la priorité. Il contribue à évaluer l’efficacité du processus de priorisation.

Pourquoi c’est important

Permet d’analyser si les éléments prioritaires sont traités plus rapidement que les autres et de vérifier ainsi l’efficacité de la stratégie de priorisation.

Où les obtenir

Dérivé des labels GitHub appliqués aux issues ou aux pull requests. Nécessite une convention standardisée pour les labels de priorité.

Exemples
ÉlevéeMoyenneFaibleCritique
Type d’élément de développement
DevelopmentItemType
Classification de l’élément de travail de développement, comme une fonctionnalité, un bug, une tâche ou une epic.
Description

Cet attribut catégorise la nature du travail effectué. Ces informations sont généralement gérées au moyen de libellés ou de modèles d’issues spécifiques dans GitHub. Comprendre le type de travail est essentiel pour définir des attentes de performance adaptées, car une correction de bug peut avoir un temps de cycle attendu bien plus court qu’une nouvelle fonctionnalité.

Cet attribut permet de comparer différents types de travail. Il aide à déterminer si les corrections de bugs sont traitées plus rapidement que les nouvelles fonctionnalités et à comprendre la répartition des ressources entre la dette technique et les nouveaux développements. Il constitue une dimension essentielle du Dashboard « Débit par projet et par type ».

Pourquoi c’est important

Catégorise les éléments de travail afin de comparer les performances et d’analyser la manière dont les différents types de travaux, par exemple les bugs et les fonctionnalités, suivent le processus.

Où les obtenir

Généralement dérivé des labels GitHub appliqués aux issues ou aux pull requests. Nécessite une convention de nommage cohérente, par exemple « type:bug » et « type:feature ».

Exemples
BugFonctionnalitéTâcheDette technique
Utilisateur assigné
Assignee
Utilisateur ou développeur chargé de traiter l’élément de développement ou une tâche précise, comme la revue d’une pull request.
Description

Cet attribut identifie la personne responsable du travail à une étape donnée. Il peut s’agir de la personne à qui une issue est attribuée, de l’auteur d’une pull request ou de la personne désignée pour effectuer une revue de code. Le suivi de la personne responsable est essentiel pour comprendre l’affectation des ressources et la charge de travail.

Cet attribut sert à suivre la charge de travail des développeurs, à identifier les goulots d’étranglement liés aux ressources et à analyser l’efficacité des transferts entre les membres de l’équipe. Les Dashboards peuvent être filtrés par personne responsable afin d’évaluer la performance individuelle ou collective et de garantir une répartition équilibrée du travail.

Pourquoi c’est important

Essentiel pour analyser la charge de travail des développeurs, la performance de l’équipe et l’efficacité des transferts entre ses différents membres.

Où les obtenir

Disponible dans l’objet « assignee » ou « user » des charges utiles JSON relatives aux problèmes, aux pull requests et aux événements de revue provenant de l’API GitHub.

Exemples
john.doejane.smithdev-team-lead
Auteur
Author
Utilisateur ayant créé l’issue, la pull request ou le commit.
Description

L’auteur est à l’origine d’un artefact donné dans le processus de développement. Par exemple, l’auteur d’une issue est la personne qui a signalé le bug ou demandé la fonctionnalité. L’auteur d’une pull request est le développeur qui a écrit le code.

Dans les analyses, l’auteur peut servir à comprendre l’origine des travaux. L’analyse des auteurs des rapports de bugs peut, par exemple, révéler des tendances liées à certaines équipes ou fonctionnalités. Cet attribut peut également être associé à l’assigné pour analyser les transferts entre intervenants.

Pourquoi c’est important

Identifie l’auteur d’un élément de travail ou d’une modification du code, ce qui peut être utile pour analyser l’origine des reprises, des rapports de bugs ou des demandes de fonctionnalités.

Où les obtenir

Disponible dans l’objet « user » de l’objet principal des réponses de l’API pour les issues, les pull requests et les commits. Le champ est généralement « user.login ».

Exemples
sara.jonesmike.leeautomation-bot
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source.
Description

Cet Attribut enregistre la date et l’heure de l’extraction ou de la mise à jour la plus récente des données. Il fournit des métadonnées sur leur fraîcheur. Il se distingue de l’horodatage de l’événement, qui indique le moment où l’événement métier s’est produit.

Dans l’analyse, ce champ est essentiel pour comprendre l’actualité de la vue du processus. Il permet de savoir si vous consultez des données en temps réel ou un instantané pris à un moment précis, ce qui est important pour les Dashboards opérationnels et le suivi.

Pourquoi c’est important

Indique la fraîcheur des données, un élément essentiel pour garantir que les analyses et les Dashboards reposent sur des informations à jour.

Où les obtenir

Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement (ETL) des données.

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Environnement de déploiement
DeploymentEnvironment
Environnement cible d’un déploiement, par exemple « Staging » ou « Production ».
Description

Cet attribut précise l’environnement dans lequel le code est déployé. Le suivi des déploiements vers différents environnements est essentiel pour comprendre l’ensemble du cycle de vie, du développement à la mise en production.

Il permet d’analyser le sous-processus de déploiement, de mesurer le temps nécessaire pour promouvoir le code de la préproduction à la production et de suivre le taux de réussite des déploiements vers différents environnements. Il est essentiel pour déterminer à quel moment un élément de développement est réellement terminé et livré aux utilisateurs.

Pourquoi c’est important

Distingue les mises en production et les versions de préproduction, ce qui est essentiel pour mesurer le véritable « time-to-market » et analyser les schémas de déploiement.

Où les obtenir

Ces informations sont récupérées via l’API GitHub Deployments, souvent déclenchée par des pipelines CI/CD ou d’autres mécanismes d’automatisation.

Exemples
DéveloppementPréproductionProduction
Est une reprise
IsRework
Indicateur booléen égal à true lorsqu’une activité représente un retour à une étape précédente du processus.
Description

Cet indicateur prend la valeur true lorsqu’un élément de développement recule dans le processus, par exemple lorsqu’une pull request reçoit une revue « Changes Requested » ou lorsqu’une issue est rouverte après avoir été clôturée. Il est dérivé de l’analyse de la séquence des activités.

Cet attribut est essentiel pour quantifier les gaspillages et les inefficacités. Il alimente directement le Dashboard « Rework and Regression Loops » et le KPI « Rework Rate ». En filtrant sur « IsRework = true », les analystes peuvent isoler les reprises et en rechercher les causes.

Pourquoi c’est important

Signale explicitement les activités qui constituent des reprises, ce qui facilite la quantification, la visualisation et l’analyse des causes d’inefficacité du processus.

Où les obtenir

Il s’agit d’un attribut dérivé. La logique consiste à définir un flux de processus standard, puis à signaler toute activité qui s’en écarte en revenant à une étape logique antérieure.

Exemples
truefalse
État de l’élément
State
Statut actuel d’une issue ou d’une pull request, par exemple « open », « closed » ou « merged ».
Description

Cet attribut indique le statut général d’un élément de développement. Pour les issues, les états habituels sont « open » et « closed ». Pour les pull requests, les états comprennent « open », « closed » et « merged ». Il fournit un aperçu de l’avancement de l’élément.

Dans les analyses, l’état sert à distinguer le travail en cours du travail terminé. Il est essentiel pour les Dashboards tels que « Active Development Progress », qui suivent les travaux en cours. Il permet également de définir la fin d’un processus. Par exemple, l’état « merged » ou « closed » peut signaler qu’un cas est terminé.

Pourquoi c’est important

Indique clairement si un élément de travail est en cours ou terminé, ce qui est fondamental pour analyser le cycle de vie et suivre les travaux actifs.

Où les obtenir

Disponible directement dans le champ « state » des charges utiles JSON correspondant aux issues et aux pull requests de l’API GitHub.

Exemples
OuvertClôturéFusionné
État de la revue
ReviewState
Résultat d’une revue de code sur une pull request, par exemple « Approved » ou « Changes Requested ».
Description

Cet attribut enregistre la décision prise par un réviseur. Les états courants comprennent « APPROVED », qui indique que le code peut être fusionné, et « CHANGES_REQUESTED », qui indique qu’une reprise est nécessaire. D’autres états peuvent être « COMMENTED » ou « PENDING ».

Cet attribut est essentiel pour analyser les reprises et la qualité. Une fréquence élevée d’événements « CHANGES_REQUESTED » peut révéler des problèmes de qualité du code initial ou des exigences peu claires. Il alimente directement le Dashboard « Rework and Regression Loops » en identifiant les moments où un élément de développement est renvoyé pour modification.

Pourquoi c’est important

Indique directement les boucles de reprise et les contrôles qualité du processus de revue du code, ce qui aide à localiser les sources d’inefficacité et les problèmes de qualité.

Où les obtenir

Disponible dans le champ « state » d’un objet de revue de pull request provenant de l’API GitHub, par exemple dans une charge utile « PullRequestReviewEvent ».

Exemples
APPROUVÉMODIFICATIONS DEMANDÉESCOMMENTÉ
Étiquettes
Labels
Liste de tags ou de labels appliqués à une issue ou à une pull request à des fins de catégorisation.
Description

Les labels GitHub offrent un moyen flexible d’ajouter des métadonnées aux issues et aux pull requests. Ils peuvent indiquer la priorité, le type de travail, les composants, les équipes ou le statut. La liste brute des labels fournit un contexte riche et non structuré.

Même si des attributs précis tels que Priority et Type sont dérivés des labels, il peut être utile de conserver la liste complète pour les analyses ponctuelles et la découverte d’autres schémas de processus. Elle permet de filtrer et de segmenter les cas selon toute combinaison de labels.

Pourquoi c’est important

Fournit une source flexible et riche de métadonnées pour catégoriser les éléments de travail et permettre des analyses dimensionnelles détaillées et variées.

Où les obtenir

Disponible dans le tableau « labels » de la charge utile JSON des issues et des pull requests de l’API GitHub. Chaque élément du tableau est un objet comportant un champ « name ».

Exemples
bug, interface utilisateur, haute prioritéfonctionnalité, backend, documentation requisedette technique, refactorisation
Hash du commit
CommitHash
Identifiant unique (SHA) d’un commit précis.
Description

Le hash d’un commit est un hash SHA-1 de 40 caractères qui identifie de manière unique un commit dans Git. Il constitue l’identifiant permanent d’une version précise du code. Les commits sont les unités élémentaires de modification du processus de développement.

Bien qu’il soit très granulaire, le hash du commit fournit le niveau de traçabilité le plus précis. Il permet aux analystes de relier directement un événement de processus à la modification exacte du code effectuée. Cette capacité peut être particulièrement utile pour les audits, la Conformité ou l’analyse détaillée des causes profondes d’incidents en production.

Pourquoi c’est important

Établit le lien le plus précis entre une étape du processus et la modification exacte du code, afin d’assurer une traçabilité complète pour les audits et le débogage.

Où les obtenir

Disponible dans les charges utiles des événements push (« head_commit.id ») ou via l’API Commits pour une pull request ou une branche.

Exemples
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nom de branche
BranchName
Nom de la branche Git dans laquelle les modifications du code correspondant à l’élément de développement ont été effectuées.
Description

Une branche est une ligne de développement indépendante, créée pour travailler sur une nouvelle fonctionnalité ou corriger un bug sans modifier la base de code principale. Le nom de la branche contient souvent des informations utiles, telles que le numéro de l’issue ou une brève description du travail.

L’analyse des noms de branches peut aider à comprendre les stratégies de branchement et à vérifier le respect des conventions de développement. Elle facilite également la mise en relation de commits précis avec un élément de développement, afin d’obtenir une vue complète de l’activité de codage.

Pourquoi c’est important

Fournit le contexte de la ligne de développement concernée et aide à appliquer et à analyser les stratégies de branchement ainsi que les conventions de nommage.

Où les obtenir

Disponible dans le champ « ref » des événements push, ou dans les objets « head » et « base » d’une réponse de l’API des pull requests.

Exemples
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numéro de pull request
PullRequestNumber
Identifiant unique d’une pull request associée à l’élément de développement.
Description

Une pull request (PR) est une proposition visant à fusionner un ensemble de modifications du code dans une branche donnée. Le numéro de pull request relie les activités de développement, telles que les envois de code et les revues, à l’élément de développement principal ou à l’issue.

Cet identifiant est essentiel pour suivre l’intégration du code et le sous-processus de revue dans l’ensemble du cycle de développement. Il permet d’analyser en détail le processus de revue du code, notamment les délais de revue, les cycles de reprise détectés pendant la revue et les taux de fusion. Il relie la phase de planification, représentée par l’issue, à la phase d’implémentation, représentée par la PR.

Pourquoi c’est important

Relie les issues aux modifications précises du code et aux processus de revue, ce qui permet d’analyser en détail le cycle de revue du code et son incidence sur le délai global de livraison.

Où les obtenir

Disponible dans le champ « number » de l’objet « pull_request » de nombreuses réponses de l’API GitHub, ou comme identifiant principal de l’API Pull Requests.

Exemples
12345678910
Réviseur
Reviewer
Utilisateur auquel il a été demandé d’effectuer une revue du code d’une pull request.
Description

Un réviseur est un développeur ou un membre de l’équipe chargé d’examiner les modifications du code d’une pull request afin d’en vérifier la qualité, la conformité et le respect des normes. Une pull request peut avoir plusieurs réviseurs.

Cet attribut est essentiel pour analyser le processus de revue du code. Il aide à repérer les goulots d’étranglement liés à certains réviseurs, à comprendre la répartition de la charge de revue et à mesurer le délai de réponse aux demandes de revue. Il constitue un élément clé du calcul du KPI « Average Code Review Cycle Time ».

Pourquoi c’est important

Identifie les personnes participant au processus d’assurance qualité et permet d’analyser la charge de revue, les retards et l’efficacité globale des revues de code.

Où les obtenir

Disponible dans le tableau « requested_reviewers » ou dans l’objet « user » d’un événement de revue de pull request provenant de l’API GitHub.

Exemples
alex.chenmaria.garciasenior-dev-team
Statut du contrôle CI
CiCheckStatus
Statut d’un contrôle d’intégration continue (CI) automatisé, par exemple « passed » ou « failed ».
Description

Cet attribut reflète le résultat des compilations, des tests et des analyses automatisés exécutés sur les modifications apportées au code dans une pull request. Les contrôles CI constituent une étape de validation essentielle dans les flux de développement modernes.

L’analyse de cet attribut aide à évaluer l’efficacité des tests automatisés. Un taux d’échec élevé peut révéler des problèmes de stabilité du code, de suite de tests ou d’environnement de développement. Il prend en charge les activités « Contrôles CI réussis » et « Contrôles CI échoués » et contribue à analyser les retards causés par les compilations défaillantes.

Pourquoi c’est important

Indique la réussite ou l’échec des contrôles qualité automatisés et fournit des informations sur la qualité du code ainsi que sur l’efficacité du pipeline CI.

Où les obtenir

Obtenu à partir du champ « state » ou « conclusion » des objets check run ou status via l’API GitHub Checks ou Statuses.

Exemples
SuccèsÉchecEn attenteErreur
Système source
SourceSystem
Système à partir duquel les données du processus de développement ont été extraites.
Description

Cet Attribut identifie l’origine des données d’événements. Pour ce processus, sa valeur serait systématiquement « GitHub ». Dans un environnement plus complexe où les activités de développement couvrent plusieurs systèmes, par exemple Jira pour la planification, GitHub pour le code et Jenkins pour le déploiement, ce champ sert à distinguer la source de chaque événement.

Dans l’analyse, il aide à retracer les données jusqu’à leur origine à des fins de validation et de résolution des problèmes. Il permet également d’analyser les processus qui traversent plusieurs plateformes et fournit un contexte clair pour chaque activité.

Pourquoi c’est important

Identifie l’origine des données, ce qui est essentiel pour leur validation et pour l’analyse des processus susceptibles de s’étendre sur plusieurs systèmes intégrés.

Où les obtenir

Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données afin d’indiquer la source des enregistrements.

Exemples
GitHubGitHub Enterprise
Temps d’attente lors d’un transfert
HandoffWaitingTime
Temps d’inactivité calculé pendant lequel un élément de développement attend entre des activités réalisées par des personnes différentes.
Description

Cette métrique mesure le temps écoulé entre la fin d’une activité et le début de la suivante, uniquement lorsque la personne responsable change. Par exemple, elle mesure le délai entre un événement « Review Requested » et un événement « Changes Requested in Review » réalisé par un autre utilisateur.

Il s’agit d’une métrique essentielle pour repérer les lacunes de communication et les problèmes de coordination. Elle alimente le Dashboard « Critical Handoff Efficiency » et le KPI « Average Handoff Waiting Time ». Des temps d’attente élevés aux points de transfert signalent souvent des contraintes de ressources ou des processus de notification inefficaces.

Pourquoi c’est important

Repère les retards causés par une mauvaise coordination ou l’indisponibilité de ressources lors des transferts entre différentes équipes ou fonctions, qui constituent souvent des sources majeures d’inefficacité.

Où les obtenir

Calculé en identifiant les activités successives pour lesquelles l’attribut « Assignee » ou « User » change, puis en mesurant l’écart de temps entre ces activités.

Exemples
PT1H15MP2DT4HPT25M
Temps de cycle du développement
DevelopmentCycleTime
Temps total écoulé entre la création d’un élément de développement et son déploiement final ou sa clôture.
Description

Il s’agit d’une métrique au niveau du cas, calculée comme la différence entre le tout premier événement, par exemple « Issue Created », et l’événement final, par exemple « Deployment Succeeded » ou « Issue Closed », pour un élément de développement donné.

Il s’agit de l’un des KPI les plus importants pour mesurer l’efficacité globale du processus de développement. Cette métrique alimente directement le Dashboard « Overall Development Cycle Time » et le KPI « Average Development Cycle Time ». Sa réduction constitue souvent un objectif prioritaire des initiatives d’amélioration des processus.

Pourquoi c’est important

Représente le « time-to-market » de bout en bout d’un élément de développement et constitue donc un KPI essentiel pour mesurer la vitesse et l’efficacité globales du processus.

Où les obtenir

Calculé au niveau du cas en soustrayant l’horodatage de la première activité de celui de la dernière activité.

Exemples
P5DT6H30MP14DT12HP1DT2H
Obligatoire Recommandé Facultatif

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

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus et identifier les goulots d’étranglement.
6 Recommandé 7 Facultatif
Activité Description
Contrôles CI réussis
Représente la réussite des contrôles automatisés, tels que les builds, les tests unitaires ou l’analyse statique, exécutés sur le code d’une pull request. Cet événement est déduit du statut des contrôles signalés par des systèmes tels que GitHub Actions.
Pourquoi c’est important

Ce contrôle qualité automatisé est essentiel pour garantir la stabilité du code. Les échecs ou les durées d’exécution élevées peuvent constituer des goulots d’étranglement importants dans le pipeline de livraison.

Où les obtenir

Déduit de l’API GitHub Checks ou de l’API Statuses. Une exécution de contrôle ou une mise à jour de statut signale « success » ou « completed » avec une conclusion « success ».

Collecte

Surveillez l’API Checks afin de détecter une conclusion « success » pour les suites de contrôles concernées.

Type d’événement inferred
Problème créé
Marque le début du cycle de vie d’un élément de développement et correspond à la création officielle d’une tâche, d’un bug ou d’une demande de fonctionnalité. Cet événement est enregistré explicitement lorsqu’un utilisateur crée un nouveau problème dans un dépôt GitHub.
Pourquoi c’est important

Il s’agit de l’activité de début principale du processus, indispensable pour mesurer la durée totale du cycle de développement et comprendre l’origine initiale du travail.

Où les obtenir

Il s’agit d’un événement explicite capturé dans le flux d’événements de l’API GitHub Issues. Le type d’événement est généralement « opened » pour un numéro de problème donné.

Collecte

Écoutez l’événement « opened » d’un problème au moyen de webhooks ou de l’interrogation de l’API.

Type d’événement explicit
Problème fermé
L’élément de développement est considéré comme terminé et le problème correspondant est officiellement fermé. Cela peut se produire automatiquement lorsqu’une pull request liée est fusionnée ou être effectué manuellement par un membre de l’équipe.
Pourquoi c’est important

Cette activité constitue la fin définitive du processus pour un élément de développement. Elle est indispensable au calcul des temps de cycle de bout en bout.

Où les obtenir

Il s’agit d’un événement explicite capturé dans le flux d’événements de l’API GitHub Issues. Le type d’événement est « closed ».

Collecte

Écoutez l’événement « closed » d’un problème au moyen de webhooks ou de l’interrogation de l’API.

Type d’événement explicit
Pull request approuvée
Un réviseur a officiellement approuvé les modifications d’une pull request, indiquant qu’elles respectent les normes de qualité et les exigences fonctionnelles. Cet événement est enregistré lorsqu’il soumet sa revue avec le statut « approve ».
Pourquoi c’est important

Il s’agit d’un contrôle qualité essentiel et d’une étape majeure avant la fusion. Le délai entre la création de la PR et cette étape constitue un KPI important pour évaluer l’efficacité du processus de revue.

Où les obtenir

Capturé dans l’API GitHub Pull Request ou via des webhooks lorsqu’une revue est envoyée avec l’état « APPROVED ».

Collecte

Filtrez les événements de soumission de revue des pull requests selon l’état « APPROVED ».

Type d’événement explicit
Pull request fusionnée
Les modifications approuvées de la pull request sont officiellement intégrées à la branche cible, comme main ou develop. Il s’agit de l’action finale explicite sur une pull request, qui intègre le nouveau code.
Pourquoi c’est important

Cette étape importante marque la fin du développement et de la revue. Pour de nombreuses équipes, elle constitue la dernière étape avant le déploiement automatisé.

Où les obtenir

Capturé dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action de l’événement est « closed » et l’Attribut « merged » de la charge utile de la pull request est défini sur true.

Collecte

Écoutez l’action « closed » d’une pull request et vérifiez que l’indicateur « merged » est défini sur true.

Type d’événement explicit
Pull request ouverte
Signale qu’un premier bloc de code est prêt pour la revue et l’intégration. Un développeur crée une pull request (PR) afin de proposer des modifications de sa branche de fonctionnalité vers une branche principale. Il s’agit d’un événement explicite dans GitHub.
Pourquoi c’est important

Cette étape importante marque la fin de la phase initiale de développement et le début du processus de revue et d’intégration. Elle est essentielle pour analyser séparément les durées de développement et de revue.

Où les obtenir

Capturé dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action de l’événement est « opened ».

Collecte

Écoutez l’action « opened » d’une pull request au moyen de webhooks ou de l’interrogation de l’API.

Type d’événement explicit
Branche créée
Marque le début du travail de développement actif associé à un problème, lorsqu’un développeur crée une nouvelle branche à partir de la base de code principale. Il s’agit d’un événement explicite enregistré lorsqu’une nouvelle branche est poussée vers le dépôt, son nom contenant souvent le numéro du problème.
Pourquoi c’est important

Indique le passage de la planification au codage actif. La mesure du délai entre la création du problème et cet événement aide à analyser le temps de prise en charge par le développeur et les retards initiaux dans le backlog.

Où les obtenir

Capturé via l’API Git de GitHub ou des webhooks qui écoutent les événements « create » de type « branch ». Il est souvent nécessaire de relier le nom de la branche à un problème au moyen de conventions de nommage, comme « feature/issue-123 ».

Collecte

Analysez les événements webhook « create » des nouvelles branches et associez-les à un problème.

Type d’événement explicit
Code poussé vers la PR
Représente une mise à jour du code soumis à la revue, qu’il s’agisse de la PR initiale ou d’une réponse aux commentaires de revue. Cet événement est enregistré chaque fois qu’un nouveau commit est poussé vers la branche associée à une pull request ouverte.
Pourquoi c’est important

Le suivi de ces événements est essentiel pour identifier les boucles de reprise. Plusieurs pushs après une revue indiquent que des modifications ont été nécessaires et influent sur la durée globale du cycle.

Où les obtenir

Il s’agit d’un événement explicite dans la chronologie de la pull request, souvent libellé comme l’ajout d’un commit. Il peut être capturé à partir du webhook « push » ou par le suivi des commits associés à une PR.

Collecte

Suivez les événements « push » sur une branche associée à une pull request ouverte.

Type d’événement explicit
Contrôles CI échoués
Représente l’échec d’un contrôle automatisé, tel qu’une erreur de build ou l’échec d’un test unitaire, exécuté sur le code d’une pull request. Cet événement est déduit d’un statut d’échec signalé par un système tel que GitHub Actions.
Pourquoi c’est important

Cette activité met en évidence des problèmes de qualité technique qui nécessitent l’intervention d’un développeur et créent une boucle de reprise. L’analyse de la fréquence des échecs peut orienter les améliorations des tests locaux ou de la qualité du code.

Où les obtenir

Déduit de l’API GitHub Checks ou de l’API Statuses. Une exécution de contrôle ou une mise à jour de statut signale « failure » ou « completed » avec une conclusion « failure ».

Collecte

Surveillez l’API Checks afin de détecter une conclusion « failure » pour les suites de contrôles concernées.

Type d’événement inferred
Déploiement réussi
Les modifications du code ont été déployées avec succès dans un environnement donné, comme la préproduction ou la production. Cet événement est généralement capturé via l’API GitHub Deployments, souvent déclenchée par une GitHub Action après une fusion.
Pourquoi c’est important

Marque le passage du code du dépôt vers un environnement actif. Son suivi est essentiel pour mesurer le délai complet entre l’idée et la mise en production.

Où les obtenir

Capturé via l’API Deployments. Un service externe ou une GitHub Action crée un déploiement, puis met à jour son statut sur « success ».

Collecte

Surveillez les événements de statut des déploiements via des webhooks afin de détecter l’état « success ».

Type d’événement inferred
Modifications demandées lors de la revue
Un réviseur a terminé sa revue du code et déterminé que des modifications sont nécessaires avant l’approbation de la pull request. Il soumet officiellement sa revue avec le statut « request_changes ».
Pourquoi c’est important

Cet événement signale explicitement une boucle de reprise. L’analyse de sa fréquence aide à localiser les problèmes de qualité, les exigences peu claires ou les besoins de formation des développeurs.

Où les obtenir

Capturé dans l’API GitHub Pull Request ou via des webhooks lorsqu’une revue est envoyée avec l’état « CHANGES_REQUESTED ».

Collecte

Filtrez les événements de soumission de revue des pull requests selon l’état « CHANGES_REQUESTED ».

Type d’événement explicit
Problème rouvert
Un problème précédemment fermé est réactivé, généralement parce que le correctif était insuffisant ou qu’une régression a été détectée. Il s’agit d’un événement explicite qui relance le cycle de vie de l’élément de développement.
Pourquoi c’est important

Cela signale une boucle de reprise importante et peut indiquer un défaut passé en production ou un correctif incomplet. Le suivi de sa fréquence constitue une mesure importante de la qualité globale du logiciel.

Où les obtenir

Il s’agit d’un événement explicite capturé dans le flux d’événements de l’API GitHub Issues. Le type d’événement est « reopened ».

Collecte

Écoutez l’événement « reopened » d’un problème au moyen de webhooks ou de l’interrogation de l’API.

Type d’événement explicit
Revue demandée
L’auteur d’une pull request demande officiellement à certains membres ou à certaines équipes d’examiner son code. Il s’agit d’une action explicite dans l’interface ou l’API GitHub, qui déclenche des notifications pour les réviseurs sollicités.
Pourquoi c’est important

Cette activité marque le début officiel de la transmission vers le processus de revue de code. Le délai entre cette activité et l’envoi pour revue permet de mesurer la réactivité des réviseurs et les éventuels goulots d’étranglement.

Où les obtenir

Capturé dans le flux d’événements de l’API GitHub Pull Request ou via des webhooks. L’action de l’événement est « review_requested ».

Collecte

Écoutez l’action « review_requested » d’une pull request.

Type d’événement explicit
Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données depuis GitHub

Prêt à commencer ?

Utilisez ce template pour préparer vos données et commencer à optimiser votre cycle de développement logiciel. Repérez les inefficacités et accélérez dès aujourd'hui vos mises en production.

Améliorez votre SDLC : repérez instantanément les inefficacités

Réduisez la durée du cycle de 30 % et optimisez votre processus de développement GitHub.

Démarrer l'essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.