Votre template de données du cycle de développement logiciel
Votre template de données du cycle de développement logiciel
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction
Attributs du cycle de vie du développement logiciel
| 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
|
|||
Activités du cycle de vie du développement logiciel
| 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
|
|||
Guides d'extraction
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.
Aucune carte bancaire requise, configuration en quelques minutes.