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

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

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

Ce modèle fournit un guide complet pour la collecte et la préparation de vos données du cycle de vie du développement logiciel (SDLC) depuis GitHub. Vous y trouverez les attributs recommandés à inclure, les activités essentielles à suivre et les conseils pratiques pour l'extraction des données. Utilisez cette ressource pour construire un journal d'événements (event log) précis pour une analyse et une optimisation efficaces des processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements 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 (event log) pour une analyse complète du cycle de vie du développement logiciel et la découverte de processus.
3 Obligatoire 5 Recommandé 16 Facultatif
Nom Description
Activité
ActivityName
Le nom d'un événement ou d'une tâche spécifique 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, telle que « Tâche créée », « Code poussé vers PR », « Demande de tirage approuvée » ou « Déploiement réussi ». Ces événements constituent la séquence d'étapes qui forment le processus de bout en bout pour un élément de développement.

Cet attribut est fondamental pour le Process Mining car il est utilisé pour 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 de processus réel, identifie les chemins communs, met en évidence les déviations et localise les goulots d'étranglement.

Pourquoi c'est important

Cet attribut constitue la colonne vertébrale de la carte de processus, permettant la visualisation et l'analyse de la séquence des événements dans le cycle de vie du développement.

Où obtenir

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

Exemples
Problème crééDemande de tirage ouverteCode `pushé` vers la PRRevue demandéeDemande de tirage fusionnée
Élément de développement
DevelopmentItemId
L'identifiant unique pour une unité de travail de développement, telle qu'une fonctionnalité, une correction de bogue ou une tâche. Il sert d'identifiant principal du cas (case).
Description

L'ID de l'élément de développement suit un élément de travail de sa création à son déploiement final. Il relie toutes les activités associées, telles que la création de branche, les commits, les demandes de tirage (pull requests), les revues et les déploiements, en une seule instance de processus cohérente.

En analyse, cet ID est utilisé pour calculer le temps de cycle de bout en bout d'une tâche de développement. Il permet de reconstituer le parcours complet d'une fonctionnalité ou d'une correction de bogue, autorisant une analyse détaillée des goulots d'étranglement, des boucles de retouches et des variations de processus pour les éléments de travail individuels.

Pourquoi c'est important

C'est la clé essentielle du process mining, reliant tous les événements de développement associés en un seul cas pour visualiser et analyser avec précision le cycle de vie complet du développement logiciel.

Où obtenir

Il s'agit généralement du numéro de la tâche (Issue Number) ou du numéro de la demande de tirage (Pull Request Number) de GitHub. Il peut être extrait du champ 'number' dans la charge utile des événements webhook liés aux tâches ou aux demandes de tirage, ou des réponses de l'API.

Exemples
101PR-2345TASK-812
Heure de début
EventTimestamp
La date et l'heure exactes auxquelles une activité ou un événement de développement spécifique s'est produit.
Description

Cet horodatage marque le début d'une activité. Il est crucial pour ordonner les événements chronologiquement afin de reconstituer le flux de processus pour chaque élément de développement. La séquence et la différence de temps entre ces horodatages sont utilisées pour analyser les performances du processus.

En analyse, cet attribut est essentiel pour calculer toutes les métriques basées sur le temps, y compris les temps de cycle, les temps de traitement et les temps d'attente. Il permet d'identifier les retards entre les étapes et fournit les données nécessaires à l'analyse des goulots d'étranglement et aux tableaux de bord de suivi des performances.

Pourquoi c'est important

Cet horodatage est essentiel pour ordonner correctement les événements et calculer toutes les métriques de performance, telles que les temps de cycle et les durées des goulots d'étranglement.

Où obtenir

Généralement trouvés comme champs 'created_at' ou 'updated_at' dans les charges utiles JSON des API GitHub et des webhooks pour divers objets comme les tâches (issues), les demandes de tirage (pull requests) et les commits.

Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
Dépôt
RepositoryName
Le nom du dépôt de code où l'activité de développement a lieu.
Description

Le dépôt agit comme un identifiant de projet ou de produit, contenant tout le code, les tâches (issues) et les demandes de tirage (pull requests) pour une application ou un composant spécifique. Il offre un moyen de segmenter et de comparer les processus de développement entre différents produits ou équipes.

En analyse, cet attribut permet de filtrer et de comparer les performances des processus entre différents projets. Il aide à répondre à des questions comme « Quel projet a le temps de cycle le plus long ? » ou « Comment le processus de correction de bogue dans le Projet A se compare-t-il au Projet B ? ». Il est essentiel pour le tableau de bord « Débit par projet et par type ».

Pourquoi c'est important

Permet la segmentation et la comparaison des processus de développement entre différents projets, produits ou équipes, rendant possible une analyse plus ciblée.

Où obtenir

Disponible dans l'objet 'repository' dans presque toutes les charges utiles de webhook et d'API GitHub. Le champ spécifique 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
La date et l'heure exactes auxquelles une activité ou un événement de développement spécifique a été achevé.
Description

L'horodatage de fin marque l'achèvement d'une activité. Bien que de nombreux événements dans GitHub soient instantanés (par exemple, « Tâche créée »), certaines activités ont une durée mesurable (par exemple, l'exécution d'une vérification 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 est utilisé pour calculer la métrique « ProcessingTime », essentielle pour comprendre l'effort actif consacré à différentes tâches comme les revues de code ou les vérifications automatisées. L'analyse des temps de traitement aide à identifier les activités inefficaces qui consomment trop de temps.

Pourquoi c'est important

Permet le calcul de temps de traitement précis pour les activités, aidant à distinguer le temps de travail actif du temps d'attente inactif.

Où obtenir

Peut être trouvé comme 'completed_at' dans les objets d'exécution de vérification ou dérivé de l'horodatage d'un événement ultérieur et concluant logiquement.

Exemples
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
Priorité
Priority
Le niveau de priorité attribué à un élément de développement, tel que 'Élevé', 'Moyen' ou 'Faible'.
Description

La priorité indique l'urgence ou l'importance commerciale 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 d'étiquettes (par exemple, 'P1-High', 'P2-Medium'). Un schéma d'étiquetage cohérent est nécessaire pour extraire cette information de manière fiable.

Cet attribut est essentiel pour l'« Analyse des flux basée sur la priorité ». Il permet aux analystes de vérifier si les éléments de haute priorité sont réellement traités plus rapidement que ceux de basse priorité et de mesurer la variance du temps de cycle en fonction de la priorité. Il aide à évaluer l'efficacité du processus de priorisation.

Pourquoi c'est important

Permet d'analyser si les éléments à haute priorité sont traités plus rapidement que ceux à faible priorité, validant ainsi l'efficacité de la stratégie de priorisation.

Où obtenir

Dérivé des étiquettes GitHub appliquées aux problèmes ou aux pull requests. Cela nécessite une convention standardisée pour les étiquettes de priorité.

Exemples
ÉlevéMoyenFaibleCritique
Type d'élément de développement
DevelopmentItemType
La classification de l'élément de travail de développement, tel qu'une fonctionnalité, un bogue, une tâche ou une épopée.
Description

Cet attribut catégorise la nature du travail effectué. Cette information est généralement gérée via des étiquettes ou des modèles de tâches (issues) spécifiques au sein de GitHub. Comprendre le type de travail est crucial pour définir des attentes de performance appropriées, car une correction de bogue pourrait avoir un temps de cycle attendu beaucoup plus court qu'une nouvelle fonctionnalité.

Cet attribut permet une analyse comparative entre différents types de travail. Il aide à analyser si les corrections de bogues sont traitées plus rapidement que les nouvelles fonctionnalités, ou à comprendre l'allocation des ressources pour la dette technique par rapport au nouveau développement. C'est une dimension clé dans le tableau de bord « Débit par projet et par type ».

Pourquoi c'est important

Catégorise les éléments de travail, permettant des comparaisons de performance et l'analyse de la façon dont différents types de travail (par exemple, bugs vs. fonctionnalités) circulent dans le processus.

Où obtenir

Généralement dérivé des étiquettes GitHub appliquées aux tâches (issues) ou aux demandes de tirage (pull requests). Nécessite une convention d'étiquetage cohérente (par exemple, 'type:bug', 'type:feature').

Exemples
BugFonctionnalitéTâcheDette technique
Utilisateur assigné
Assignee
L'utilisateur ou le développeur assigné pour gérer l'élément de développement ou une tâche spécifique, comme une revue de demande de tirage.
Description

Cet attribut identifie l'individu responsable du travail à une étape donnée. Il peut s'agir du responsable (assignee) d'une tâche (issue), de l'auteur d'une demande de tirage (pull request) ou du réviseur sollicité pour une revue de code. Le suivi du responsable est essentiel pour comprendre l'allocation des ressources et la charge de travail.

Cet attribut est utilisé en analyse pour surveiller la charge de travail des développeurs, identifier les goulots d'étranglement des ressources et analyser l'efficacité des transferts entre les différents membres de l'équipe. Les tableaux de bord peuvent être filtrés par responsable pour évaluer la performance individuelle ou d'équipe et assurer une répartition équilibrée du travail.

Pourquoi c'est important

Crucial pour analyser la charge de travail des développeurs, la performance de l'équipe et l'efficacité des transferts entre les différents membres de l'équipe.

Où obtenir

Disponible dans l'objet 'assignee' ou 'user' au sein des charges utiles JSON pour les problèmes, les pull requests et les événements de révision de l'API GitHub.

Exemples
john.doejane.smithdev-team-lead
Auteur
Author
L'utilisateur qui a créé la tâche (issue), la demande de tirage (pull request) ou le commit.
Description

L'auteur est l'initiateur d'un artefact spécifique dans le processus de développement. Par exemple, l'auteur d'une tâche (issue) est la personne qui a signalé le bogue ou demandé la fonctionnalité. L'auteur d'une demande de tirage (pull request) est le développeur qui a écrit le code.

En analyse, l'auteur peut être utilisé pour comprendre les sources de travail. Par exemple, l'analyse des auteurs de rapports de bogues peut révéler des schémas liés à des équipes ou des fonctionnalités spécifiques. Il peut également être utilisé en conjonction avec le responsable (assignee) pour analyser les modèles de transfert.

Pourquoi c'est important

Identifie l'auteur d'un élément de travail ou d'une modification de code, ce qui peut être utile pour analyser les sources de reprise, les rapports de bug ou les demandes de fonctionnalité.

Où obtenir

Disponible dans l'objet 'user' au sein de l'objet principal des réponses API pour les problèmes, 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
Le timestamp 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 la dernière extraction ou mise à jour des données. Il fournit des métadonnées sur la fraîcheur des données analysées. Ceci est distinct de l'horodatage de l'événement, qui enregistre le moment où l'événement métier s'est produit.

En analyse, ce champ est crucial pour comprendre la pertinence de la vue du processus. Il aide les utilisateurs à savoir s'ils consultent des données en temps réel ou un instantané d'un moment précis, ce qui est important pour les tableaux de bord opérationnels et le suivi.

Pourquoi c'est important

Indique la fraîcheur des données, ce qui est essentiel pour garantir que les analyses et les dashboards sont basés sur des informations à jour.

Où obtenir

Ce timestamp est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des données (ETL).

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Environnement de déploiement
DeploymentEnvironment
L'environnement cible pour un déploiement, tel que 'Staging' ou 'Production'.
Description

Cet attribut spécifie l'endroit où le code est déployé. Le suivi des déploiements vers différents environnements est essentiel pour comprendre le cycle de vie complet, du développement à la publication en production.

Cet attribut permet d'analyser le sous-processus de déploiement. Il peut être utilisé pour mesurer le temps nécessaire pour promouvoir le code de l'environnement de staging à la production et pour suivre le taux de succès des déploiements vers différents environnements. Il est essentiel pour savoir quand un élément de développement est réellement 'terminé' et livré aux utilisateurs.

Pourquoi c'est important

Distingue les livraisons de pré-production et de production, ce qui est critique pour mesurer le véritable 'délai de mise sur le marché' et analyser les modèles de déploiement.

Où 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 automatisations.

Exemples
développementstagingproduction
Est un retravail
IsRework
Un indicateur booléen qui est vrai si une activité représente une régression vers une étape précédente du processus.
Description

Cet indicateur est défini à vrai lorsque un élément de développement recule dans le processus, par exemple lorsqu'une demande de tirage (pull request) reçoit une revue « Modifications demandées », ou lorsqu'une tâche (issue) est rouverte après avoir été fermée. Il est dérivé par l'analyse de la séquence des activités.

Cet attribut est essentiel pour quantifier le gaspillage et l'inefficacité. Il soutient directement le tableau de bord « Boucles de retouches et de régression » et le KPI « Taux de retouches ». En filtrant sur 'IsRework = true', les analystes peuvent isoler et investiguer les causes des retouches.

Pourquoi c'est important

Signale explicitement les activités qui constituent des reprises, facilitant la quantification, la visualisation et l'analyse des causes des inefficacités de processus.

Où obtenir

Ceci est un attribut dérivé. La logique implique de définir un flux de processus standard, puis de signaler toute activité qui s'en écarte en revenant à une étape logique antérieure.

Exemples
truefaux
État de l'élément
State
Le statut actuel d'une tâche (issue) ou d'une demande de tirage (pull request), tel que 'open', 'closed' ou 'merged'.
Description

Cet attribut indique le statut de haut niveau d'un élément de développement. Pour les tâches (issues), les états typiques sont 'open' (ouvert) et 'closed' (fermé). Pour les demandes de tirage (pull requests), les états incluent 'open', 'closed' et 'merged' (fusionné). Cela fournit un aperçu de la progression de l'élément.

En analyse, l'état est utilisé pour identifier le travail actif par rapport au travail terminé. Il est essentiel pour les tableaux de bord comme « Progression du développement actif » qui suivent le travail en cours. Il est également utilisé pour définir la fin d'un processus, par exemple, un état 'merged' ou 'closed' pourrait signifier l'achèvement d'un cas (case).

Pourquoi c'est important

Fournit une indication claire de l'état d'avancement ou d'achèvement d'un élément de travail, ce qui est fondamental pour l'analyse du cycle de vie et le suivi du travail actif.

Où obtenir

Directement disponible en tant que champ 'state' dans les charges utiles JSON pour les problèmes et les pull requests de l'API GitHub.

Exemples
openferméfusionné
État de révision
ReviewState
Le résultat d'une revue de code sur une demande de tirage (pull request), tel que 'Approved' (approuvé) ou 'Changes Requested' (modifications demandées).
Description

Cet attribut capture la décision prise par un réviseur. Les états courants incluent « APPROVED » (approuvé), indiquant que le code est prêt à être fusionné, et « CHANGES_REQUESTED » (modifications demandées), indiquant qu'un retravail est nécessaire. D'autres états peuvent inclure « COMMENTED » ou « PENDING ».

Ceci est un attribut critique pour l'analyse des retouches et de la qualité. Une fréquence élevée d'événements « CHANGES_REQUESTED » peut indiquer des problèmes de qualité de code initiale ou des exigences peu claires. Il soutient directement le tableau de bord « Boucles de retouches et de régression » en identifiant le moment où un élément de développement est renvoyé pour modification.

Pourquoi c'est important

Indique directement les boucles de reprise et les jalons qualité au sein du processus de révision de code, aidant à identifier les sources d'inefficacité et les problèmes de qualité.

Où obtenir

Disponible en tant que champ 'state' au sein d'un objet de révision de pull request de l'API GitHub. Par exemple, dans une charge utile 'PullRequestReviewEvent'.

Exemples
APPROUVÉCHANGES_REQUESTEDCOMMENTED
Étiquettes
Labels
Une liste d'étiquettes ou de `tags` appliqués à un `issue` ou une `pull request` pour la catégorisation.
Description

Les étiquettes dans GitHub sont un moyen flexible d'ajouter des métadonnées aux problèmes et aux pull requests. Elles peuvent être utilisées pour indiquer la priorité, le type de travail, les composants, les équipes ou le statut. La liste brute des étiquettes fournit un contexte riche et non structuré.

Bien que des attributs spécifiques comme la priorité et le type soient dérivés des étiquettes, conserver la liste complète peut être utile pour l'analyse ad-hoc et la découverte d'autres modèles de processus. Cela permet un filtrage et une segmentation flexibles des cas basés sur toute combinaison d'étiquettes.

Pourquoi c'est important

Fournit une source de métadonnées riche et flexible pour la catégorisation des éléments de travail, permettant une analyse dimensionnelle approfondie et variée.

Où obtenir

Disponible sous forme de tableau 'labels' dans la charge utile JSON pour les problèmes et les pull requests de l'API GitHub. Chaque élément du tableau est un objet avec un champ 'name'.

Exemples
bug, ui, high-priorityfeature, backend, needs-docsdette technique, refactorisation
Hachage de Commit
CommitHash
L'identifiant unique (SHA) d'un commit de code spécifique.
Description

Un commit hash est un hachage SHA-1 de 40 caractères qui identifie de manière unique un commit dans Git. Il agit comme un ID permanent pour une version spécifique du code. Les commits sont les unités atomiques de changement dans le processus de développement.

Bien que très granulaire, le commit hash offre le niveau ultime de traçabilité. Il permet aux analystes de relier un événement de processus directement au changement de code exact qui a été effectué. Cela peut être inestimable pour l'audit, la conformité ou l'analyse détaillée des causes profondes des incidents de production.

Pourquoi c'est important

Fournit le lien le plus granulaire entre une étape de processus et le changement de code exact, permettant une traçabilité complète pour les audits et le débogage.

Où obtenir

Disponible dans les charges utiles d'événements de push ('head_commit.id') ou via l'API Commits pour une pull request ou une branche.

Exemples
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
Nom de la branche
BranchName
Le nom de la branche Git où les modifications de code pour 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 un correctif de bug sans affecter la base de code principale. Le nom de la branche contient souvent des informations utiles, telles que le numéro de problème ou une courte description du travail.

L'analyse des noms de branches peut aider à comprendre les stratégies de branchement et le respect des conventions de développement. Elle aide également à relier des commits de code spécifiques à un élément de développement, offrant une image complète de l'activité de codage.

Pourquoi c'est important

Fournit un contexte sur la ligne de développement spécifique et aide à appliquer et à analyser les stratégies de branchement et les conventions de nommage.

Où obtenir

Disponible dans le champ 'ref' pour les événements de push, ou dans les objets 'head' et 'base' au sein d'une réponse de l'API pull request.

Exemples
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
Numéro de demande de tirage
PullRequestNumber
L'identifiant unique d'une demande de tirage (pull request) associée à l'élément de développement.
Description

Une pull request (PR) est une proposition de fusionner un ensemble de modifications de code dans une branche spécifique. Le numéro de Pull Request relie les activités de développement, telles que les pushes de code et les révisions, à l'élément de développement ou au problème principal.

Cet identifiant est crucial pour le suivi du sous-processus d'intégration et de révision du code au sein du cycle de vie de développement plus large. Il permet une analyse détaillée du processus de révision de code, y compris les temps de révision, les cycles de reprise identifiés pendant la révision, et les taux de fusion. Il connecte la phase de planification (issue) avec la phase d'implémentation (PR).

Pourquoi c'est important

Lie les problèmes aux modifications de code spécifiques et aux processus de révision, permettant une analyse détaillée du cycle de révision de code et de son impact sur le délai de livraison global.

Où obtenir

Disponible en tant que champ 'number' au sein de l'objet 'pull_request' dans de nombreuses réponses de l'API GitHub, ou en tant qu'identifiant principal de l'API Pull Requests.

Exemples
12345678910
Réviseur
Reviewer
L'utilisateur sollicité pour effectuer une revue de code sur une demande de tirage (pull request).
Description

Un relecteur est un développeur ou un membre de l'équipe désigné pour inspecter les modifications de code dans une pull request afin d'en vérifier la qualité, l'exactitude et la conformité aux normes. Une pull request peut avoir plusieurs relecteurs.

Cet attribut est essentiel pour analyser le processus de révision de code. Il aide à identifier les goulots d'étranglement liés à des relecteurs spécifiques, à comprendre la répartition de la charge de travail de révision et à mesurer le temps nécessaire aux relecteurs pour répondre aux demandes. C'est un composant clé pour le calcul de l'ICP 'Temps de cycle moyen de révision de code'.

Pourquoi c'est important

Identifie les individus impliqués dans le processus d'assurance qualité, permettant l'analyse des charges de travail de révision, des retards et de l'efficacité globale des révisions de code.

Où obtenir

Disponible dans le tableau 'requested_reviewers' ou l'objet 'user' d'un événement de révision de pull request de l'API GitHub.

Exemples
alex.chenmaria.garciaéquipe-développement-senior
Statut des vérifications CI
CiCheckStatus
Le statut d'une vérification d'intégration continue (CI) automatisée, tel que 'passed' (réussi) ou 'failed' (échoué).
Description

Cet attribut reflète le résultat des builds, tests et scans automatisés exécutés sur les modifications de code dans une demande de tirage (pull request). Les vérifications CI sont une porte de qualité critique dans les workflows de développement modernes.

L'analyse de cet attribut aide à comprendre l'efficacité des tests automatisés. Un taux d'échec élevé peut indiquer des problèmes de stabilité du code, de la suite de tests ou de l'environnement de développement. Il prend en charge les activités « Vérifications CI réussies » et « Vérifications CI échouées » et aide à analyser les retards causés par des builds défectueuses.

Pourquoi c'est important

Indique le succès ou l'échec des jalons qualité automatisés, offrant un aperçu de la qualité du code et de l'efficacité du pipeline CI.

Où obtenir

Obtenu à partir du champ 'state' ou 'conclusion' des objets d'exécution de vérification ou de statut via les API GitHub Checks ou Statuses.

Exemples
succèsfailurependingerror
Système source
SourceSystem
Le 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énement. Pour ce processus, la valeur serait systématiquement 'GitHub'. Dans un environnement plus complexe où les activités de développement s'étendent sur plusieurs systèmes (par exemple, Jira pour la planification, GitHub pour le code, Jenkins pour le déploiement), ce champ est utilisé pour distinguer la source de chaque événement.

En analyse, il aide à retracer les données jusqu'à leur origine pour la validation et le dépannage. Il permet également d'analyser les processus qui traversent différentes plateformes, fournissant un contexte clair pour chaque activité.

Pourquoi c'est important

Identifie l'origine des données, ce qui est essentiel pour la validation des données et pour l'analyse des processus qui peuvent s'étendre sur plusieurs systèmes intégrés.

Où obtenir

Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données pour étiqueter la source des enregistrements.

Exemples
GitHubGitHub Enterprise
Temps d'attente de transfert
HandoffWaitingTime
Le temps d'inactivité calculé qu'un élément de développement passe à attendre entre des activités réalisées par différentes personnes.
Description

Cette métrique mesure le temps entre la fin d'une activité et le début de la suivante, mais uniquement lorsque la personne responsable change. Par exemple, le temps entre un événement 'Review Requested' et un événement 'Changes Requested in Review' par un utilisateur différent.

C'est une métrique critique pour identifier les lacunes de communication et les problèmes de coordination. Elle soutient le tableau de bord 'Efficacité critique du transfert' et le KPI 'Temps d'attente moyen des transferts'. Des temps d'attente élevés aux points de transfert sont souvent un signe de contraintes de ressources ou de processus de notification inefficaces.

Pourquoi c'est important

Identifie les retards causés par une mauvaise coordination ou l'indisponibilité des ressources lors des transferts entre différentes équipes ou rôles, souvent sources majeures d'inefficacité.

Où obtenir

Calculé en identifiant les activités séquentielles où l'attribut 'Assignee' ou 'User' change, puis en mesurant l'intervalle de temps entre elles.

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

Ceci est une métrique au niveau du cas (case), calculée comme la différence de temps entre le tout premier événement (par exemple, « Tâche créée ») et l'événement final (par exemple, « Déploiement réussi » ou « Tâche fermée ») pour un seul élément de développement.

C'est l'un des KPI les plus importants pour mesurer l'efficacité globale du processus de développement. Il soutient directement le tableau de bord « Temps de cycle de développement global » et le KPI « Temps de cycle de développement moyen ». Réduire cette métrique est souvent un objectif principal des initiatives d'amélioration des processus.

Pourquoi c'est important

Représente le 'time-to-market' de bout en bout pour un élément de développement, en faisant un KPI critique pour mesurer la vélocité et l'efficacité globale du processus.

Où obtenir

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

Exemples
P5DT6H30MP14DT12HP1DT2H
Temps de traitement
ProcessingTime
La durée calculée d'une activité, représentant le temps de travail actif.
Description

Le Temps de Traitement est le temps écoulé entre le début et la fin d'une activité. Il est calculé comme 'EndTimestamp' moins 'EventTimestamp'. Cette métrique mesure le temps nécessaire pour accomplir une tâche, en excluant tout temps d'attente avant le début de la tâche.

L'analyse du temps de traitement aide à identifier les activités les plus chronophages en termes d'effort actif. Cela diffère du temps de cycle, qui inclut le temps d'attente. Par exemple, une revue de code peut avoir un long temps de cycle mais un court temps de traitement, indiquant que le réviseur est occupé et que la demande de tirage (PR) est en attente.

Pourquoi c'est important

Mesure la durée de travail active, aidant à distinguer le temps passé à travailler sur une tâche du temps passé à l'attendre, ce qui est essentiel pour des améliorations ciblées de l'efficacité.

Où obtenir

Calculé en soustrayant le 'EventTimestamp' du 'EndTimestamp' pour un seul enregistrement d'activité.

Exemples
PT5M15SPT2H30MP1DT12H
Obligatoire Recommandé Facultatif

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

Ce sont les étapes clés du processus et les jalons à enregistrer dans votre journal d'événements pour une découverte précise des processus et l'identification des goulets d'étranglement.
6 Recommandé 7 Facultatif
Activité Description
Demande de tirage approuvée
Un relecteur a formellement approuvé les modifications d'une `pull request`, indiquant qu'elles respectent les normes de qualité et fonctionnelles. Ceci est capturé lorsqu'un relecteur soumet sa révision avec le statut 'approuvé'.
Pourquoi c'est important

C'est une étape clé de qualité et un jalon majeur avant la fusion. Le temps nécessaire pour atteindre cet état depuis la création de la PR est un KPI critique pour l'efficacité du processus de revue.

Où obtenir

Capturé à partir de l'API GitHub Pull Request ou des webhooks lorsqu'une révision est soumise avec l'état 'APPROVED'.

Capture

Filtrer les événements de soumission de révision de pull request pour l'état 'APPROVED'.

Type d'événement explicit
Demande de tirage fusionnée
Les modifications de code approuvées de la demande de tirage (pull request) sont officiellement intégrées dans la branche cible, telle que main ou develop. Il s'agit d'une action explicite et finale sur une demande de tirage qui incorpore le nouveau code.
Pourquoi c'est important

Il s'agit d'une étape critique représentant l'achèvement du développement et de la revue. Pour de nombreuses équipes, c'est la dernière étape avant le déploiement automatisé.

Où obtenir

Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'closed' et l'attribut 'merged' de la charge utile de la pull request est vrai.

Capture

Surveiller l'action 'closed' d'une demande de tirage (pull request) et vérifier si l'indicateur 'merged' est vrai.

Type d'événement explicit
Demande de tirage ouverte
Signale qu'un bloc de code initial est prêt pour la revue et l'intégration. Un développeur crée une demande de tirage (PR) pour 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

Il s'agit d'une étape cruciale qui marque la fin de la phase de développement initiale et le début du pipeline de revue et d'intégration. Elle est essentielle pour analyser séparément les temps de cycle de développement et de revue.

Où obtenir

Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'opened'.

Capture

Écouter l'action 'opened' pour une demande de tirage (pull request) via des webhooks ou l'interrogation de l'API.

Type d'événement explicit
Problème clos
L'élément de développement est considéré comme terminé, et la tâche (issue) correspondante est formellement fermée. Cela peut se produire automatiquement lorsqu'une demande de tirage (pull request) liée est fusionnée ou être effectué manuellement par un membre de l'équipe.
Pourquoi c'est important

Cette activité sert de fin définitive au processus pour un élément de développement. Elle est cruciale pour le calcul des temps de cycle de bout en bout.

Où obtenir

Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est 'closed'.

Capture

Écouter l'événement 'closed' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.

Type d'événement explicit
Problème créé
Marque le début du cycle de vie d'un élément de développement, représentant la création formelle d'une tâche, d'un bogue ou d'une demande de fonctionnalité. Cet événement est explicitement capturé lorsqu'un utilisateur crée une nouvelle tâche (issue) dans un dépôt GitHub.
Pourquoi c'est important

C'est l'activité de démarrage principale du processus, essentielle pour mesurer le temps de cycle de développement total et comprendre les sources initiales de travail.

Où obtenir

Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est généralement 'opened' pour un numéro de tâche (issue) donné.

Capture

Écouter l'événement 'opened' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.

Type d'événement explicit
Vérifications CI réussies
Représente la réussite des vérifications automatisées, telles que les builds, les tests unitaires ou l'analyse statique, exécutées sur le code d'une demande de tirage (pull request). Cet événement est déduit du statut des vérifications signalées par des systèmes comme GitHub Actions.
Pourquoi c'est important

Cette porte de qualité automatisée est cruciale pour assurer la stabilité du code. Les échecs ou les longs temps d'exécution peuvent constituer des goulots d'étranglement significatifs dans le pipeline de livraison.

Où obtenir

Déduit de l'API GitHub Checks ou de l'API Statuses. Une exécution de vérification ou une mise à jour de statut signale un 'success' ou 'completed' avec une conclusion de 'success'.

Capture

Surveiller l'API Checks pour une conclusion 'success' sur les suites de vérification pertinentes.

Type d'événement inferred
Branche créée
Représente le début du travail de développement actif pour une tâche (issue), où un développeur crée une nouvelle branche à partir du code principal. Il s'agit d'un événement explicite capturé lorsqu'une nouvelle branche est poussée vers le dépôt, contenant souvent le numéro de la tâche dans son nom.
Pourquoi c'est important

Indique la transition de la planification au codage actif. Mesurer le temps 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 du backlog.

Où obtenir

Capturé via l'API Git de GitHub ou les webhooks à l'écoute des événements 'create' de type 'branch'. Il est souvent nécessaire de lier le nom de la branche à un problème via des conventions de nommage, comme 'feature/issue-123'.

Capture

Analyser les événements webhook 'create' pour les nouvelles branches et les associer à une tâche.

Type d'événement explicit
Code `pushé` vers la PR
Représente une mise à jour du code soumis pour revue, soit dans le cadre de la PR initiale, soit en réponse aux retours de revue. Cet événement est capturé chaque fois qu'un nouveau commit est poussé vers la branche associée à une demande de tirage (pull request) ouverte.
Pourquoi c'est important

Le suivi de ces événements est crucial pour identifier les boucles de retravail. Des poussées multiples après une revue indiquent que des modifications étaient nécessaires, affectant le temps de cycle global.

Où obtenir

Il s'agit d'un événement explicite dans la chronologie de la demande de tirage (pull request), souvent étiqueté comme un commit ajouté. Il peut être capturé à partir du webhook 'push' ou en surveillant les commits associés à une PR.

Capture

Suivre les événements 'push' sur une branche associée à une demande de tirage (pull request) ouverte.

Type d'événement explicit
Déploiement réussi
Les modifications de code ont été déployées avec succès vers un environnement spécifique, tel que staging ou production. Cet événement est généralement capturé via l'API GitHub Deployments, souvent déclenché par une GitHub Action après une fusion.
Pourquoi c'est important

Marque la transition du code du dépôt vers un environnement de production. Le suivi de cette étape est essentiel pour mesurer le délai de bout en bout, de l'idée à la production.

Où obtenir

Capturé via l'API Deployments. Un service externe ou une action GitHub crée un déploiement puis met à jour son statut à 'success'.

Capture

Surveiller les événements de statut de déploiement via des webhooks pour un état de 'success'.

Type d'événement inferred
Modifications demandées en révision
Un relecteur a terminé sa révision de code et a déterminé que des modifications sont nécessaires avant que la `pull request` puisse être approuvée. Le relecteur soumet officiellement sa révision avec le statut 'demande de modifications'.
Pourquoi c'est important

Cet événement signale explicitement une boucle de retravail. L'analyse de sa fréquence aide à identifier les problèmes de qualité, les exigences peu claires ou les domaines nécessitant une formation des développeurs.

Où obtenir

Capturé à partir de l'API GitHub Pull Request ou des webhooks lorsqu'une révision est soumise avec l'état 'CHANGES_REQUESTED'.

Capture

Filtrer les événements de soumission de révision de pull request pour 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é trouvée. C'est un événement explicite qui redémarre le cycle de vie de l'élément de développement.
Pourquoi c'est important

Ceci signale une boucle de retravail significative, indiquant une potentielle « échappement de défaut en production » ou une correction incomplète. Le suivi de sa fréquence est une mesure clé de la qualité logicielle globale.

Où obtenir

Il s'agit d'un événement explicite capturé à partir du flux d'événements de l'API GitHub Issues. Le type d'événement est 'reopened'.

Capture

Écouter l'événement 'reopened' sur une tâche (issue) via des webhooks ou l'interrogation de l'API.

Type d'événement explicit
Revue demandée
L'auteur d'une demande de tirage (pull request) sollicite formellement des membres d'équipe ou des équipes spécifiques pour revoir son code. Il s'agit d'une action explicite au sein de l'interface utilisateur ou de l'API GitHub qui déclenche des notifications aux réviseurs demandés.
Pourquoi c'est important

Cette activité marque le début officiel du transfert vers le processus de revue de code. Le temps entre cette étape et la soumission d'une revue aide à mesurer la réactivité du réviseur et les goulots d'étranglement potentiels.

Où obtenir

Capturé à partir du flux d'événements de l'API GitHub Pull Request ou des webhooks. L'action de l'événement est 'review_requested'.

Capture

Écouter l'action 'review_requested' pour une demande de tirage (pull request).

Type d'événement explicit
Vérifications CI échouées
Représente l'échec d'une vérification automatisée, comme une erreur de build ou un échec de test unitaire, exécutée sur le code d'une demande de tirage (pull request). Cela est déduit d'un statut d'échec signalé par un système comme GitHub Actions.
Pourquoi c'est important

Cette activité met en évidence des problèmes de qualité technique nécessitant l'intervention du développeur, créant une boucle de retravail. L'analyse de la fréquence des échecs peut orienter les améliorations des tests locaux ou de la qualité du code.

Où obtenir

Déduit de l'API GitHub Checks ou de l'API Statuses. Une exécution de vérification ou une mise à jour de statut signale un 'failure' ou 'completed' avec une conclusion de 'failure'.

Capture

Surveiller l'API Checks pour une conclusion 'failure' sur les suites de vérification pertinentes.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de GitHub