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

Azure DevOps
Votre modèle de données pour le cycle de développement logiciel

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

Ce modèle vous guide dans la préparation des données de votre cycle de développement logiciel pour le Process Mining. Il présente les attributs essentiels à recueillir, les principales activités à suivre et des conseils pratiques pour extraire ces informations d’Azure DevOps. Vous pourrez ainsi structurer vos données pour analyser et améliorer vos processus.
  • Attributs recommandés à recueillir
  • Activités clés à suivre dans votre cycle de développement logiciel
  • Instructions détaillées pour l’extraction depuis Azure DevOps
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du cycle de développement logiciel

Voici les champs de données recommandés dans votre journal d’événements pour analyser et améliorer le cycle de développement logiciel.
5 Obligatoire 7 Recommandé 6 Facultatif
Nom Description
Élément de développement
DevelopmentItem
Identifiant unique d’une unité de travail, telle qu’une fonctionnalité, un bug ou une User Story. Il sert d’identifiant de cas pour le processus.
Description

L’élément de développement désigne une unité de travail distincte suivie dans Azure DevOps. Chaque élément, identifié par un ID unique, est au centre des activités du processus, de sa création et de sa planification jusqu’à son développement, ses tests et son déploiement.

Dans une analyse de Process Mining, cet attribut est essentiel pour regrouper tous les événements associés dans un même parcours. Il permet de reconstituer le cycle de vie complet de chaque élément de travail et d’analyser, pour chacun, les temps de cycle, les écarts du processus et les boucles de reprise.

Pourquoi est-ce important ?

Cet identifiant central relie toutes les étapes du processus au sein d’un même cas et permet d’analyser le cycle de développement logiciel de bout en bout.

Où trouver ces données

Il correspond au champ « ID » d’un élément de travail dans Azure DevOps Boards. Il est accessible via l’API REST Azure DevOps pour le suivi des éléments de travail.

Exemples
10234102351023610237
Heure de l’événement
EventTime
Horodatage précis indiquant le moment où une activité ou un événement donné s’est produit pour un élément de développement.
Description

L’heure de l’événement indique la date et l’heure de chaque activité du cycle de développement. Cet horodatage permet d’ordonner les événements chronologiquement et de calculer les durées qui les séparent.

Cet attribut est essentiel 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 de créer un journal d’événements ordonné dans le temps, nécessaire à toute analyse de Process Mining. Il sert à diagnostiquer les retards, à mesurer les résultats par rapport aux SLA et à suivre les tendances dans le temps.

Pourquoi est-ce important ?

Cet horodatage établit l’ordre chronologique des événements. Il est indispensable pour calculer les KPI de durée et comprendre le déroulement du processus ainsi que ses goulots d’étranglement.

Où trouver ces données

Il s’agit du champ « Changed Date » associé à chaque mise à jour de l’historique d’un élément de travail. Pour les événements externes, comme les builds ou les déploiements, il correspond à l’horodatage de fin de l’événement.

Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Nom de l’activité
ActivityName
Nom de l’événement ou de la tâche qui s’est produit à un moment donné du cycle de développement d’un élément de travail.
Description

Le nom de l’activité désigne une étape ou un jalon précis du processus, par exemple « Début du développement », « Pull Request créée » ou « Déployé en production ». Ces activités sont déduites des changements d’état de l’élément de travail, d’événements associés comme les builds ou les pull requests, ou d’événements personnalisés.

Cet attribut est indispensable pour construire la carte du processus, qui en donne une représentation visuelle. Il permet aux analystes de comprendre l’ordre des événements, de repérer les parcours fréquents, de détecter les goulots d’étranglement entre certaines activités et d’analyser la fréquence de chaque étape.

Pourquoi est-ce important ?

Il définit les étapes du processus, constitue la structure de la carte du processus et permet d’analyser le flux de travail, les goulots d’étranglement et les écarts.

Où trouver ces données

Il est généralement déduit des changements du champ « State » d’un élément de travail ou d’événements associés, comme les builds, les commits et les pull requests. L’historique de l’élément de travail fournit les données brutes de ces événements.

Exemples
Début du développementPull Request terminéeÉchec des tests QADéployé en productionÉlément de travail clôturé
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant la dernière actualisation des données du processus depuis le système source.
Description

Cet attribut indique la date de la dernière extraction et mise à jour des données depuis Azure DevOps. Il renseigne clairement sur leur fraîcheur et sur la période couverte par l’analyse.

Pour analyser un processus, il est important de connaître l’ancienneté des données afin de prendre des décisions éclairées. Cet horodatage permet de savoir si les informations consultées sont en temps réel ou correspondent à un instantané historique, ce qui influe sur la pertinence des résultats.

Pourquoi est-ce important ?

Il renseigne sur l’actualité des données et permet de connaître la période sur laquelle reposent les analyses et les décisions.

Où trouver ces données

Il s’agit d’un horodatage de métadonnées généré et enregistré lors du processus d’extraction, de transformation et de chargement des données (ETL).

Exemples
2024-05-20T08:00:00Z
Système source
SourceSystem
Système depuis lequel les données du processus ont été extraites, en l’occurrence Azure DevOps.
Description

Cet attribut indique le système d’origine des données. Il est particulièrement utile lorsque les données de plusieurs systèmes sont réunies pour obtenir une vue plus large du processus. Dans ce modèle, la valeur est toujours Azure DevOps.

Même si elle semble fixe dans une analyse portant sur un seul système, cette information précise l’origine des données. Elle est importante pour leur gouvernance, le dépannage et les futures intégrations avec d’autres systèmes, comme ServiceNow ou SAP.

Pourquoi est-ce important ?

Il précise l’origine des données, une information importante pour leur gouvernance, leur validation et l’analyse des processus couvrant plusieurs systèmes.

Où trouver ces données

Cette valeur statique doit être ajoutée lors de l’extraction et de la transformation des données afin d’identifier le jeu de données.

Exemples
Azure DevOps
Affecté à
AssignedTo
Utilisateur ou membre de l’équipe auquel l’élément de développement est actuellement affecté.
Description

Cet attribut identifie la personne responsable de l’élément de travail à une étape donnée du processus. L’affectation peut changer plusieurs fois au cours du cycle de vie de l’élément, par exemple lorsqu’il passe d’un développeur à un testeur, puis à un responsable des mises en production.

L’analyse par personne affectée est essentielle au Dashboard de suivi de la charge des développeurs et des testeurs. Elle aide à comprendre la répartition des ressources, à repérer les membres de l’équipe surchargés et à comparer les résultats entre personnes ou équipes.

Pourquoi est-ce important ?

Il permet d’analyser la répartition de la charge, de repérer les goulots d’étranglement liés aux ressources et de gérer la capacité de l’équipe.

Où trouver ces données

Il correspond au champ « Assigned To » d’un élément de travail dans Azure DevOps. La valeur est extraite de l’historique de l’élément pour chaque événement.

Exemples
jane.doe@example.comjohn.smith@example.comnon affecté
État
State
État actuel de l’élément de développement dans son flux de travail, par exemple « Nouveau », « Actif », « Résolu » ou « Fermé ».
Description

L’attribut État indique le statut officiel d’un élément de travail à un moment donné, conformément au modèle de processus du projet. Les transitions entre ces états constituent la principale source de génération des activités dans le journal d’événements.

L’attribut « Activité » décrit souvent plus précisément un changement d’état, mais l’attribut brut « État » reste utile pour le filtrage et l’analyse. Il permet de savoir combien de temps les éléments passent dans certains états. Il est également indispensable pour créer le Dashboard de durée des étapes et analyser les transferts entre équipes.

Pourquoi est-ce important ?

Il indique le statut de l’élément de travail au cours de son cycle de vie. Cette information est essentielle pour comprendre le déroulement du processus et calculer le temps passé à chaque étape.

Où trouver ces données

Cela correspond au champ « State » d’un élément de travail dans Azure DevOps.

Exemples
NouveauActifEn assurance qualitéRésoluFermé
Heure de fin
EndTime
Horodatage indiquant la fin d’une activité. Il sert à calculer sa durée de traitement.
Description

L’heure de fin marque la conclusion d’une activité. Dans de nombreux journaux d’événements, l’heure de début de l’activité suivante sert d’heure de fin à l’activité précédente. Toutefois, disposer d’une heure de fin distincte permet de calculer plus précisément la durée de traitement de chaque activité et le temps d’inactivité entre deux activités.

Cet attribut est essentiel au calcul du KPI de durée de traitement et à l’analyse détaillée des goulots d’étranglement. Il permet de distinguer le temps consacré à une tâche du temps d’attente avant le début de l’étape suivante, une distinction importante pour le Dashboard d’analyse des transmissions entre étapes.

Pourquoi est-ce important ?

Il permet de calculer précisément les durées de traitement des activités et les temps d’inactivité, deux éléments essentiels à l’analyse des goulots d’étranglement et à l’amélioration de l’efficacité.

Où trouver ces données

Cette valeur est souvent déduite. Elle peut correspondre à l’heure de début de l’événement suivant pour le même cas, ou être enregistrée explicitement si le système source consigne les heures de début et de fin des tâches.

Exemples
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Nom de l’équipe
TeamName
Nom de l’équipe de développement responsable de l’élément de travail.
Description

Le nom de l’équipe désigne l’équipe à laquelle un élément de travail est attribué. Dans Azure DevOps, le travail est souvent organisé par équipes, qui peuvent constituer des sous-ensembles d’un projet plus vaste.

Cet attribut permet de segmenter l’analyse des processus par équipe. Il est particulièrement utile pour comparer les processus et les résultats des différentes équipes, repérer les pratiques efficaces et déterminer où certaines équipes pourraient avoir besoin d’assistance ou d’améliorations de leurs processus.

Pourquoi est-ce important ?

Il permet de comparer les équipes, de repérer les écarts de performance et de partager les bonnes pratiques dans l’ensemble de l’organisation.

Où trouver ces données

Cette information est souvent déduite du champ « Area Path » d’un élément de travail, car les équipes sont généralement associées à des chemins de zone spécifiques dans Azure DevOps.

Exemples
Équipe PhoenixÉquipe OmegaPlateforme centraleÉquipe front-end
Priorité
Priority
Classement numérique ou descriptif de l’importance de l’élément de développement par rapport aux autres éléments.
Description

La priorité indique l’importance d’un élément de travail dans la planification. Une priorité élevée signifie que l’élément doit être traité plus rapidement que ceux de priorité inférieure. Les valeurs sont souvent numériques, par exemple 1, 2, 3 et 4, la valeur 1 correspondant à la priorité la plus élevée.

Cet attribut est essentiel au Dashboard de débit et de temps de cycle par priorité. Son analyse permet de vérifier l’efficacité du système de priorisation : les éléments prioritaires avancent-ils réellement plus vite dans le processus que les autres ?

Pourquoi est-ce important ?

Il permet de vérifier si le processus accélère effectivement le traitement des éléments prioritaires, un point essentiel pour évaluer l’efficacité des stratégies de priorisation.

Où trouver ces données

Cela correspond au champ « Priority » d’un élément de travail dans Azure DevOps.

Exemples
1234
Reprise
IsRework
Indicateur booléen précisant si un élément de développement est revenu à une étape antérieure de son cycle de vie.
Description

Cet indicateur prend la valeur vrai lorsqu’un élément de travail suit une boucle de reprise, par exemple lorsqu’il passe de « Tests d’assurance qualité terminés » à « Développement commencé ». Il est calculé en analysant la séquence d’activités d’un cas et en repérant les progressions non linéaires.

Cet attribut est essentiel au Dashboard de fréquence des reprises et des nouveaux tests, ainsi qu’à l’indicateur de fréquence des boucles de reprise. Il facilite le filtrage et la quantification des reprises, et aide à repérer les problèmes de qualité, les lacunes de communication ou les tests insuffisants qui nuisent à l’efficacité.

Pourquoi est-ce important ?

Il repère et quantifie directement les reprises, ce qui aide à mettre en évidence les problèmes de qualité et les inefficacités qui allongent les temps de cycle.

Où trouver ces données

Cet attribut calculé est obtenu en analysant la séquence des activités dans le journal d’événements de chaque cas.

Exemples
truefalse
Type d’élément de travail
WorkItemType
Catégorie de l’élément de développement, par exemple Bug, Feature, User Story ou Task.
Description

Le type d’élément de travail indique la nature du travail effectué. Les différents types suivent souvent des parcours distincts et répondent à des attentes de performance ou à des SLA différents. Par exemple, un Bug peut suivre un parcours accéléré par rapport à une Feature.

Cet attribut est essentiel aux comparaisons. Il permet de filtrer la carte du processus ou les KPI selon le type de travail, afin de déterminer si certains processus sont plus efficaces pour les bugs que pour les fonctionnalités, ou de suivre l’évolution historique des temps de cycle par catégorie.

Pourquoi est-ce important ?

Il permet de segmenter l’analyse du processus et de comparer les flux de travail et les résultats selon les catégories de travail, comme les bugs et les fonctionnalités.

Où trouver ces données

Il correspond au champ « Work Item Type » d’un élément de travail dans Azure DevOps.

Exemples
BoguesFonctionnalitéRécit utilisateurTask
Chemin d’itération
IterationPath
Sprint ou période de développement à laquelle l’élément de travail est attribué.
Description

Le chemin d’itération, ou sprint, désigne une période de développement définie dans le temps. Les éléments de travail sont affectés à une itération afin d’être terminés pendant cette période.

L’analyse par chemin d’itération permet d’évaluer les performances du processus sprint après sprint. Elle peut servir à suivre l’évolution du temps de cycle, à analyser le travail reporté et à évaluer la prévisibilité de la planification des sprints.

Pourquoi est-ce important ?

Il permet d’analyser les résultats sprint par sprint, afin que les équipes puissent évaluer leur évolution et améliorer leurs pratiques agiles.

Où trouver ces données

Cela correspond au champ « Iteration Path » d’un élément de travail dans Azure DevOps.

Exemples
Plateforme de commerce en ligne\Sprint 12Plateforme de commerce en ligne\Sprint 13Relance de l’application mobile\Phase 2\Sprint 4
Gravité
Severity
Indique les conséquences d’un bogue ou d’un problème sur le système ou les utilisateurs finaux.
Description

La gravité sert à classer les conséquences d’un bogue, depuis les pannes critiques du système jusqu’aux défauts esthétiques mineurs. Elle se distingue de la priorité, qui détermine l’ordre de traitement. Un bogue grave peut être peu prioritaire si une solution de contournement est facilement disponible.

Cet attribut apporte un autre angle d’analyse, notamment pour le Dashboard de débit et de temps de cycle par priorité. Il permet de répondre à des questions telles que « Corrigeons-nous d’abord les bogues les plus graves ? » et de mieux comprendre le niveau de risque associé aux éléments traités.

Pourquoi est-ce important ?

Il permet de classer les éléments de travail selon leurs conséquences pour l’activité et d’analyser la capacité de l’équipe à traiter les problèmes les plus importants.

Où trouver ces données

Cela correspond au champ « Severity » d’un élément de travail dans Azure DevOps, généralement pour les bogues.

Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
Identifiant de la demande de fusion
PullRequestId
Identifiant d’une demande de fusion associée à l’élément de développement.
Description

Cet attribut relie un élément de travail à une demande de fusion, qui sert à soumettre et à examiner des modifications de code. Un même élément de travail peut être associé à plusieurs demandes de fusion.

L’identifiant de la demande de fusion permet d’analyser plus finement les étapes de revue de code et d’intégration. Il peut servir à mesurer le délai entre la création et la clôture d’une demande de fusion, ainsi qu’à déterminer la fréquence des refus ou des modifications importantes, qui peuvent révéler des problèmes de qualité du code ou des exigences imprécises.

Pourquoi est-ce important ?

Il relie le travail de développement aux activités de revue de code correspondantes et permet d’analyser en détail l’intégration du code et le processus d’assurance qualité.

Où trouver ces données

Cette information figure dans la section « Links » ou « Development » d’un élément de travail dans Azure DevOps.

Exemples
452145334589
Nom du projet
ProjectName
Nom du projet Azure DevOps auquel appartient l’élément de développement.
Description

Cet attribut désigne le projet de l’organisation Azure DevOps dans lequel se trouve l’élément de travail. Il apporte un contexte général, notamment dans les organisations qui gèrent de nombreux projets.

Le nom du projet est un critère important pour le filtrage et la comparaison. Il alimente le Dashboard des tendances historiques du temps de cycle en permettant de segmenter l’analyse par projet. Vous pouvez ainsi voir si certains projets sont plus ou moins efficaces que d’autres, ou si les améliorations apportées à un projet ont eu des effets positifs.

Pourquoi est-ce important ?

Il fournit un regroupement général pour l’analyse et permet de comparer les performances et les tendances entre différents projets.

Où trouver ces données

Cela correspond au champ « Team Project » d’un élément de travail dans Azure DevOps.

Exemples
Plateforme de commerce en ligneRelance de l’application mobileModernisation de l’entrepôt de données
Temps d’attente d’approbation
ApprovalWaitingTime
Temps pendant lequel un élément de développement attend une approbation après l’envoi d’une demande.
Description

Cette métrique mesure la durée des périodes pendant lesquelles un élément de travail attend une approbation. Par exemple, elle peut mesurer le délai entre « Tests d’acceptation utilisateur commencés » et « Tests d’acceptation utilisateur approuvés ». Pour un cas donné, elle est calculée en mesurant le temps écoulé entre ces deux activités.

Cet attribut calculé alimente directement le Dashboard d’analyse du temps d’attente d’approbation et l’indicateur correspondant. En isolant ces retards, les équipes peuvent améliorer la communication et la prise de décision afin de réduire les temps d’inactivité et d’accélérer le cycle de vie global.

Pourquoi est-ce important ?

Il mesure précisément les retards dus à l’attente d’une décision ou d’une approbation et met en évidence les possibilités d’améliorer la communication et la prise de décision.

Où trouver ces données

Il se calcule en repérant dans le journal d’événements les activités de début et de fin de l’approbation, par exemple « Tests d’acceptation utilisateur commencés » et « Tests d’acceptation utilisateur approuvés », puis en mesurant le temps écoulé entre elles.

Exemples
3 jours 2 heures1 jour 8 heures 30 minutes4 heures
Temps d’attente entre les étapes
StageHandoffTime
Durée d’inactivité entre la fin d’une étape majeure et le début de la suivante.
Description

Le temps d’attente entre les étapes mesure la période d’inactivité entre deux étapes consécutives du processus, par exemple entre « Développement terminé » et « Tests d’assurance qualité commencés ». Il est calculé en repérant ces transitions clés, puis en mesurant le délai entre la fin de la première activité et le début de la seconde.

Cette métrique est au cœur du Dashboard de durée des étapes et d’analyse des transferts. Mesurer séparément le temps d’attente entre les étapes permet de repérer les goulots d’étranglement cachés, lorsque le travail reste en attente, souvent faute de ressources disponibles, en raison de retards de communication ou de processus inefficaces.

Pourquoi est-ce important ?

Il quantifie les temps d’attente entre les étapes du processus et révèle les goulots d’étranglement ainsi que les retards qui ne correspondent pas à du travail actif.

Où trouver ces données

Cet attribut est calculé en repérant les paires d’activités consécutives qui correspondent à un transfert, puis en mesurant le temps écoulé entre elles.

Exemples
2 heures 15 minutes1 jour 4 heures30 minutes
Obligatoire Recommandé Facultatif

Activités du cycle de développement logiciel

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir le processus et repérer les goulots d’étranglement.
7 Recommandé 8 Facultatif
Activité Description
Début des tests QA
Cette activité correspond au début de la phase formelle de tests d’assurance qualité. Elle est déduite lorsque l’état de l’élément de travail passe à « In QA », « Testing » ou à une valeur équivalente.
Pourquoi est-ce important ?

Elle marque le début du cycle de QA. L’analyse de la durée de cette phase est importante pour comprendre les goulots d’étranglement et l’efficacité des tests.

Où trouver ces données

Déduite de l’historique de l’élément de travail en repérant le passage du champ System.State à « In QA » ou à un autre état de test désigné.

Données à recueillir

Déduite du passage du champ State à « In QA » ou « Testing ».

Type d’événement inferred
Début du développement
Cette activité indique qu’un développeur a commencé à travailler sur l’élément. Elle est déduite du changement d’état de l’élément de travail vers « Actif », « In Progress » ou « Committed ».
Pourquoi est-ce important ?

Elle marque le début de la phase de développement active. L’analyse du délai entre « Créé » et « Début du développement » révèle le temps d’attente dans le backlog.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State passe d’un état « Nouveau » ou « Approuvé » à un état « In Progress ».

Données à recueillir

Déduite du passage du champ State à « Actif » ou « In Progress ».

Type d’événement inferred
Déployé en production
Cet événement marque le déploiement réussi en production du code associé à l’élément de travail. Il est enregistré explicitement dans les journaux de mise en production d’Azure Pipelines.
Pourquoi est-ce important ?

Cette étape importante correspond à la livraison de la valeur. Elle sert de point final pour calculer le délai de bout en bout et le temps de cycle.

Où trouver ces données

Événement extrait des données du pipeline de mise en production d’Azure Pipelines, plus précisément de la fin d’un déploiement vers une étape « Production » associée à l’élément de travail.

Données à recueillir

Événement de fin du déploiement dans un pipeline de mise en production.

Type d’événement explicit
Élément de travail créé
Cette activité marque le début du cycle de développement : elle correspond à la création d’un élément de travail, par exemple une User Story, un Bug ou une Task. Elle est enregistrée lorsqu’une nouvelle fiche est sauvegardée dans Azure DevOps Boards.
Pourquoi est-ce important ?

Il s’agit de l’événement de début principal du processus. Il est indispensable pour mesurer le temps de cycle de développement de bout en bout et comprendre l’origine des demandes de travail.

Où trouver ces données

Cet événement est enregistré à partir du champ « Created Date » de l’élément de travail. La table d’historique de l’élément consigne également cette transition d’état initiale.

Données à recueillir

Valeur extraite du champ « Created Date » de l’élément de travail.

Type d’événement explicit
Pull Request créée
Cet événement indique que le développeur a terminé la première version du code et soumis les modifications à la revue au moyen d’une pull request. Il relie l’élément de travail à une modification de code précise dans Azure Repos.
Pourquoi est-ce important ?

Il s’agit d’une étape clé entre le développement et la revue de code. Son suivi permet de mesurer la durée du codage et de savoir quand le code est prêt pour une revue par les pairs.

Où trouver ces données

Événement extrait des données Azure Repos en reliant la création de la pull request à l’élément de travail associé. Le développeur établit souvent ce lien explicitement.

Données à recueillir

Événement de création d’une pull request dans Azure Repos, associé à un élément de travail.

Type d’événement explicit
Pull Request terminée
Cet événement correspond à la fin réussie de la revue de code : la pull request est approuvée et le code est fusionné dans la branche cible. Il est enregistré explicitement dans Azure Repos.
Pourquoi est-ce important ?

Il marque la fin de la revue de code, une étape souvent à l’origine de goulots d’étranglement. L’analyse du délai entre la création et la clôture de la PR permet d’évaluer l’efficacité du cycle de revue.

Où trouver ces données

Événement de clôture ou de fusion d’une pull request dans Azure Repos, associée à un élément de travail.

Données à recueillir

Événement de fusion d’une pull request associé à un élément de travail.

Type d’événement explicit
Tests d’acceptation utilisateur approuvés
Cette activité indique que les parties prenantes métier ont approuvé les modifications après les tests d’acceptation utilisateur. Elle est généralement déduite du passage de l’état « In UAT » à « UAT Approved » ou « Ready for Release ».
Pourquoi est-ce important ?

Cette approbation importante confirme que l’élément de travail répond aux exigences métier et qu’il est prêt à être déployé en production.

Où trouver ces données

Déduite de l’historique de l’élément de travail en repérant le passage du champ System.State d’un état UAT à un état approuvé ou indiquant que l’élément est prêt pour la mise en production.

Données à recueillir

Déduite du passage du champ State de « In UAT » à « Ready for Release ».

Type d’événement inferred
Build réussi
Cette activité confirme que le code source, y compris les nouvelles modifications, a été compilé et empaqueté avec succès par un pipeline de build. Azure Pipelines enregistre explicitement cet événement.
Pourquoi est-ce important ?

Cette étape constitue un contrôle qualité important : elle vérifie que le nouveau code s’intègre correctement sans faire échouer le build. Un échec peut signaler des problèmes d’intégration.

Où trouver ces données

Événement extrait des données de fin de build d’Azure Pipelines. Le build doit être associé à l’élément de travail, directement ou par l’intermédiaire de la pull request correspondante.

Données à recueillir

Événement de fin de build enregistré par Azure Pipelines.

Type d’événement explicit
Début des tests d’acceptation utilisateur
Cet événement marque le début des tests d’acceptation utilisateur (UAT), au cours desquels les parties prenantes métier valident les fonctionnalités. Il est généralement déduit du passage à l’état « In UAT » ou à un statut équivalent.
Pourquoi est-ce important ?

Il indique le début de la validation finale avant la mise en production. Il est important d’analyser la durée des UAT et les temps d’attente des approbations pour optimiser le processus.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State est mis à jour vers un état personnalisé correspondant aux UAT, par exemple « In UAT ».

Données à recueillir

Déduite du passage du champ State à « In UAT ».

Type d’événement inferred
Développement terminé
Cette activité indique que le développement et les tests unitaires sont terminés et que l’élément est prêt pour les tests formels. Elle est généralement déduite du passage de l’état de l’élément de travail à « Resolved » ou « Ready for Test ».
Pourquoi est-ce important ?

Cette étape marque une transmission importante entre l’équipe de développement et l’équipe d’assurance qualité (QA). Mesurer le délai jusqu’au « Début des tests QA » permet de repérer les retards de transmission.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State passe à une valeur telle que « Resolved » ou à un état personnalisé indiquant que l’élément est prêt pour la QA.

Données à recueillir

Déduite du passage du champ State à « Resolved ».

Type d’événement inferred
Échec des tests QA
Cet événement indique que l’élément de travail a échoué aux tests d’assurance qualité et est renvoyé à l’équipe de développement. Il est enregistré lorsque l’état passe d’un état de test à « In Progress », « Active » ou un état équivalent.
Pourquoi est-ce important ?

Cette activité est essentielle pour repérer les boucles de reprise. Si elle se produit souvent, cela peut révéler des problèmes de qualité du code, d’exigences ou de processus de test.

Où trouver ces données

Déduite de l’historique de l’élément de travail en repérant une transition d’un état tel que « In QA » vers un état tel que « Active » ou « In Progress ».

Données à recueillir

Déduite du passage du champ State de « In QA » à « Active ».

Type d’événement inferred
Élément de travail annulé
Cet événement indique que l’élément de travail a été annulé et ne sera ni terminé ni déployé. Il est enregistré lorsque l’état passe à « Removed », « Cancelled » ou à un état équivalent.
Pourquoi est-ce important ?

Il s’agit d’une autre issue possible du processus, qui n’aboutit pas. L’analyse des éléments annulés peut révéler des problèmes de planification, de priorisation ou de définition des exigences.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State passe à un état terminal de la catégorie « Removed ».

Données à recueillir

Déduite du passage du champ State à « Removed » ou « Cancelled ».

Type d’événement inferred
Élément de travail approuvé
Cette activité correspond à l’approbation formelle d’un élément de travail, qui confirme que celui-ci est clairement défini et prêt à être développé. Elle est généralement déduite du changement du champ « State » vers une valeur telle que « Approuvé » ou « Ready for Dev ».
Pourquoi est-ce important ?

Le suivi des approbations permet d’analyser le délai entre la soumission d’une idée et le lancement de son développement. Il met en évidence les retards éventuels lors de la planification et de la préparation du backlog.

Où trouver ces données

Déduite de l’historique de l’élément de travail en repérant le passage du champ System.State à « Approuvé » ou à un état personnalisé équivalent.

Données à recueillir

Déduite du passage du champ State à « Approuvé ».

Type d’événement inferred
Élément de travail clôturé
Cet événement correspond à la clôture définitive de l’élément de travail après son déploiement et les éventuelles validations postérieures. Il est enregistré lorsque l’état passe à « Closed » ou « Done ».
Pourquoi est-ce important ?

Cette activité marque la fin définitive et réussie du processus pour un élément de travail. Elle constitue le point final de son cycle de vie.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State passe à « Closed » ou à un état terminal équivalent de la catégorie « Completed ».

Données à recueillir

Déduite du passage du champ State à « Closed ».

Type d’événement inferred
Tests QA terminés
Cette activité marque la fin réussie de la phase d’assurance qualité. Elle est déduite lorsque l’état de l’élément de travail passe d’un état de test à un état tel que « Ready for UAT » ou « QA Approved ».
Pourquoi est-ce important ?

Il s’agit d’un contrôle qualité important qui indique que l’élément est prêt pour les tests d’acceptation utilisateur ou la mise en production. Les retards à partir de cette étape peuvent révéler des goulots d’étranglement liés aux tests d’acceptation ou à la planification de la mise en production.

Où trouver ces données

Déduite de l’historique de l’élément de travail lorsque le champ System.State passe de « In QA » à un état ultérieur tel que « Ready for UAT » ou « Done ».

Données à recueillir

Déduite du passage du champ State de « In QA » à « Ready for UAT ».

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’Azure DevOps

Prêt à commencer ?

Commencez dès aujourd’hui à améliorer votre cycle de développement logiciel. Ce modèle constitue une première étape pour mieux comprendre vos processus.

Optimisez dès aujourd’hui votre cycle de développement logiciel dans Azure DevOps !

Réduisez le temps de cycle de 30 % et éliminez les goulots d’étranglement de votre flux de travail de développement logiciel.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.