Votre template de données pour le cycle de développement logiciel

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

Votre template de données pour le cycle de développement logiciel

Ce template vous fournit une feuille de route claire pour préparer les données de votre cycle de développement logiciel au Process Mining. Il présente les attributs essentiels à collecter, les principales activités à suivre et des indications pratiques pour extraire ces informations spécifiquement depuis Azure DevOps. Utilisez cette ressource pour structurer correctement vos données et faciliter l’analyse ainsi que l’optimisation de vos processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre pour votre SDLC
  • Guide détaillé d’extraction pour Azure DevOps
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs du cycle de vie du développement logiciel

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser et optimiser de manière complète le cycle de vie du 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, qui sert d’identifiant de cas pour le processus.
Description

L’élément de développement représente une unité de travail distincte suivie dans Azure DevOps. Chaque élément, identifié par son ID unique, constitue l’objet central autour duquel s’articulent toutes les activités du processus, de la création et de la planification au développement, aux tests et au déploiement.

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

Pourquoi c’est important

Il s’agit de l’identifiant central qui relie toutes les étapes du processus au sein d’un cas cohérent et rend possible l’analyse de bout en bout du cycle de vie du développement logiciel.

Où les obtenir

Cela correspond au champ « ID » d’un élément de travail dans Azure DevOps Boards. Cette information est accessible via l’API REST Azure DevOps dédiée au 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 enregistre la date et l’heure de chaque activité du cycle de développement. Cet horodatage constitue l’élément temporel fondamental pour classer les événements par ordre chronologique et calculer les durées qui les séparent.

Dans une analyse, cet attribut est essentiel au calcul de toutes les métriques temporelles, notamment les temps de cycle, les temps de traitement et les temps d’attente. Il permet de créer un journal d’événements ordonné dans le temps, indispensable à toute analyse de Process Mining. Il sert à diagnostiquer les retards, à mesurer la performance par rapport aux SLA et à suivre les tendances au fil du temps.

Pourquoi c’est important

Cet horodatage fournit l’ordre chronologique des événements, indispensable au calcul de tous les KPI fondés sur la durée et à la compréhension du déroulement du processus ainsi que de ses goulots d’étranglement.

Où les obtenir

Il s’agit de la « Changed Date » associée à chaque mise à jour de l’historique d’un élément de travail. Pour les événements externes tels que les builds ou les déploiements, il s’agit de 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 spécifique survenu à un moment donné du cycle de développement d’un élément de travail.
Description

Le nom de l’activité décrit une étape ou un jalon précis du processus, par exemple « Development Started », « Pull Request Created » ou « Deployed to Production ». Ces activités sont dérivées des changements d’état de l’élément de travail, d’événements associés tels que les builds ou les pull requests, ou d’événements personnalisés.

Cet attribut est essentiel à la construction de la carte de processus, qui représente visuellement le flux de travail. Il permet aux analystes de comprendre la séquence des événements, d’identifier les parcours courants, de détecter les goulots d’étranglement entre des activités précises et d’analyser la fréquence de chaque étape.

Pourquoi c’est important

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

Où les obtenir

Cette information est généralement déduite des modifications du champ « State » d’un élément de travail ou d’événements associés tels que les builds, les commits et les Pull Requests. L’historique de l’élément de travail fournit les données brutes nécessaires à ces événements.

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

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

Dans toute analyse de processus, il est essentiel de connaître l’actualité des données pour prendre des décisions éclairées. Cet horodatage permet de déterminer 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 c’est important

Il renseigne les utilisateurs sur la fraîcheur des données et garantit que les analyses et les décisions reposent sur une période clairement définie.

Où les obtenir

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 à partir duquel les données du processus ont été extraites, en l’occurrence Azure DevOps.
Description

Cet attribut identifie le système d’origine des données. Il est particulièrement utile dans les environnements où les données de plusieurs systèmes sont combinées afin d’obtenir une vision plus large du processus. Pour ce modèle, la valeur est toujours Azure DevOps.

Même si cette valeur peut sembler statique dans une analyse portant sur un seul système, elle fournit un contexte essentiel sur l’origine des données. Elle est importante pour la gouvernance des données, le dépannage et les futures intégrations avec d’autres systèmes tels que ServiceNow ou SAP.

Pourquoi c’est important

Il fournit un contexte important sur l’origine des données, indispensable à la gouvernance des données, à la validation et à l’analyse des processus couvrant plusieurs systèmes.

Où les obtenir

Il s’agit d’une valeur statique qui 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
Attribué à
AssignedTo
Utilisateur ou membre de l’équipe auquel l’élément de développement est actuellement attribué.
Description

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

L’analyse par « Assigned To » est essentielle au Dashboard Developer and Tester Workload Overview. Elle permet de comprendre la répartition des ressources, d’identifier les membres de l’équipe surchargés et d’analyser les écarts de performance entre les personnes ou les équipes.

Pourquoi c’est important

Il permet d’analyser le processus selon les ressources, de comprendre la répartition de la charge de travail, d’identifier les goulots d’étranglement propres à certaines ressources et de gérer la capacité des équipes.

Où les obtenir

Cela 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 de travail pour chaque événement.

Exemples
jane.doe@example.comjohn.smith@example.comNon attribué
Est une reprise
IsRework
Indicateur booléen précisant si un élément de développement est revenu à une étape précédente de son cycle de vie.
Description

Cet indicateur prend la valeur true lorsqu’un élément de travail présente une boucle de reprise, par exemple lorsqu’il passe de « QA Testing Completed » à « Development Started ». Il est calculé en analysant la séquence des activités d’un cas et en détectant les progressions non linéaires.

Cet attribut est essentiel au Dashboard Rework and Retesting Frequency et au KPI Rework Loop Frequency. Il permet de filtrer et de quantifier facilement les reprises, afin de repérer les problèmes de qualité, les lacunes de communication ou les tests insuffisants qui entraînent des inefficacités.

Pourquoi c’est important

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

Où les obtenir

Il s’agit d’un attribut calculé, dérivé de l’analyse de la séquence des activités dans le journal d’événements pour chaque cas.

Exemples
truefalse
État
State
Le statut actuel de l’élément de développement dans son flux de travail, par exemple « New », « Active », « Resolved » ou « Closed ».
Description

L’attribut State représente le statut officiel d’un élément de travail à un moment donné, tel qu’il est défini par le 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.

Bien que l’attribut « Activity » soit souvent une version plus descriptive d’un changement d’état, l’attribut brut « State » est utile pour le filtrage et l’analyse. Il aide à comprendre le temps passé par les éléments dans certains états et constitue un élément fondamental pour créer le Dashboard Stage Duration et analyser les transferts.

Pourquoi c’est important

Il indique le statut de l’élément de travail dans son cycle de vie, ce qui est fondamental pour comprendre le flux du processus et calculer le temps passé à chaque étape.

Où les obtenir

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

Exemples
NouveauActifEn assurance qualitéRésoluClôturé
Heure de fin
EndTime
Horodatage indiquant le moment où une activité a été terminée. Il sert à calculer le temps de traitement d’une activité.
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 l’activité et le temps d’inactivité entre les activités.

Cet attribut est essentiel au calcul du KPI ProcessingTime et à l’analyse détaillée des goulots d’étranglement. Il permet de distinguer le temps consacré au travail actif sur une tâche du temps d’attente avant le début de l’étape suivante, ce qui est essentiel pour le Dashboard Stage Handoff Analysis.

Pourquoi c’est important

Il permet de calculer précisément les durées de traitement des activités et les temps d’inactivité, ce qui constitue un fondement de l’analyse des goulots d’étranglement et de l’amélioration de l’efficacité.

Où les obtenir

Cette valeur est souvent dérivée. 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 capture 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 identifie l’équipe précise à 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 du processus par équipe. Il est très utile pour comparer les processus et les performances de différentes équipes, identifier les bonnes pratiques des équipes les plus performantes et repérer les domaines dans lesquels certaines équipes ont besoin d’un accompagnement ou d’améliorations.

Pourquoi c’est important

Il permet de comparer les différentes équipes, d’identifier les écarts de performance et de partager les bonnes pratiques dans l’ensemble de l’organisation.

Où les obtenir

Cette valeur est souvent dérivée de l’« Area Path » d’un élément de travail, car les équipes sont généralement associées à des chemins de zone précis dans Azure DevOps.

Exemples
Équipe PhoenixEscouade OmegaCœur de la plateformeÉquipe frontend
Priorité
Priority
Classement numérique ou descriptif indiquant 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 généralement que l’élément doit être traité plus rapidement qu’un élément de priorité moindre. Les valeurs sont souvent numériques, par exemple 1, 2, 3 et 4, la valeur 1 étant la plus élevée.

Cet attribut est essentiel au Dashboard Priority-Based Throughput & Cycle Time. Son analyse permet de déterminer si le système de priorisation est efficace, c’est-à-dire si les éléments prioritaires progressent effectivement plus vite dans le processus que les éléments moins prioritaires.

Pourquoi c’est important

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

Où les obtenir

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

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

Le type d’élément de travail catégorise la nature du travail effectué. Les différents types d’éléments suivent souvent des parcours distincts et sont associés à 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 à l’analyse comparative. 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 pour différentes catégories de travail.

Pourquoi c’est important

Il permet de segmenter l’analyse du processus et de comparer les flux de travail ainsi que les performances pour différentes catégories de travail, comme les bugs et les fonctionnalités.

Où les obtenir

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

Exemples
BugFonctionnalitéUser StoryTâche
Chemin d’itération
IterationPath
Sprint de développement ou période limitée dans le temps auquel l’élément de travail est attribué.
Description

Le chemin d’itération, ou sprint, représente une période de développement définie et limitée dans le temps. Les éléments de travail sont affectés à une itération afin d’être terminés au cours de cette période.

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

Pourquoi c’est important

Il permet une analyse par sprint, afin que les équipes évaluent leur performance au fil du temps et améliorent leurs pratiques agiles.

Où les obtenir

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

Exemples
Plateforme e-commerce\Sprint 12Plateforme e-commerce\Sprint 13Refonte de l’application mobile\Phase 2\Sprint 4
Gravité
Severity
Indique l’impact d’un bug ou d’un problème sur le système ou les utilisateurs finaux.
Description

La gravité sert à classer l’impact d’un bug, depuis les défaillances critiques du système jusqu’aux problèmes esthétiques mineurs. Elle se distingue de la priorité, qui détermine l’ordre de traitement. Un bug de gravité élevée peut avoir une faible priorité lorsqu’une solution de contournement est facilement disponible.

Cet attribut apporte une dimension supplémentaire à l’analyse, notamment dans le Dashboard Priority-Based Throughput & Cycle Time. Il permet d’examiner des questions telles que « Corrigeons-nous les bugs les plus critiques en premier ? » et de mieux comprendre le profil de risque du travail traité.

Pourquoi c’est important

Il aide à classer les éléments de travail selon leur impact métier et permet d’analyser l’efficacité avec laquelle l’équipe traite les problèmes à fort impact.

Où les obtenir

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

Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
ID de la Pull Request
PullRequestId
Identifiant d’une Pull Request liée à l’élément de développement.
Description

Cet attribut relie un élément de travail à une Pull Request précise, qui sert à soumettre et à réviser les modifications du code. Un même élément de travail peut être associé à plusieurs Pull Requests.

L’ID de la Pull Request permet une analyse plus détaillée de la révision et de l’intégration du code. Il peut servir à mesurer le temps écoulé entre la création et la finalisation d’une Pull Request, ainsi qu’à analyser la fréquence des rejets ou des modifications importantes, qui peuvent révéler des problèmes de qualité du code ou des exigences peu claires.

Pourquoi c’est important

Il relie le travail de développement aux activités précises de révision du code et permet une analyse détaillée de l’intégration du code et du processus d’assurance qualité.

Où les obtenir

Cette information se trouve 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 identifie le projet précis de l’organisation Azure DevOps dans lequel se trouve l’élément de travail. Il fournit un contexte général particulièrement utile dans les organisations qui gèrent de nombreux projets.

Le nom du projet constitue une dimension importante pour le filtrage et la comparaison. Il alimente le Dashboard Historical Cycle Time Trends en permettant de segmenter l’analyse par projet, de déterminer si certains projets sont plus ou moins efficaces que d’autres et de vérifier si les améliorations apportées à un projet ont produit des effets positifs.

Pourquoi c’est 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ù les obtenir

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

Exemples
Plateforme e-commerceRefonte 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 d’attente précises pendant lesquelles un élément de travail est en attente d’approbation. Un exemple courant est le temps écoulé entre « UAT Started » et « UAT Approved ». Il est calculé en mesurant le temps qui sépare ces deux activités pour un cas donné.

Cet attribut calculé alimente directement le Dashboard Approval Waiting Time Analysis et le KPI correspondant. En isolant ces retards, les équipes peuvent améliorer les processus de communication et de décision afin de réduire les temps d’inactivité et d’accélérer le cycle de vie global.

Pourquoi c’est important

Il mesure précisément les retards liés à l’attente de décisions ou d’approbations et met en évidence les possibilités d’améliorer les processus de communication et de décision.

Où les obtenir

Il est calculé en recherchant dans le journal d’événements les activités précises de début et de fin de l’approbation, par exemple « UAT Started » et « UAT Approved », puis en calculant l’écart de temps.

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

Le temps de transfert entre étapes mesure la période d’attente entre deux étapes successives du processus, par exemple le temps entre « Development Completed » et « QA Testing Started ». Il est calculé en identifiant ces transitions clés et en mesurant l’écart entre la fin de la première activité et le début de la seconde.

Cette métrique est au cœur des Dashboards Stage Duration et Handoff Analysis. Isoler et mesurer le temps de transfert est essentiel pour identifier les goulots d’étranglement cachés où le travail reste inactif, souvent en raison de l’indisponibilité des ressources, de retards de communication ou de processus inefficaces.

Pourquoi c’est important

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

Où les obtenir

Il s’agit d’un attribut calculé. Il faut identifier les paires d’activités successives qui représentent un transfert, puis calculer l’écart de temps qui les sépare.

Exemples
2 heures 15 minutes1 jour 4 heures0 heure 30 minutes
Obligatoire Recommandé Facultatif

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

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus et identifier les goulots d’étranglement.
7 Recommandé 8 Facultatif
Activité Description
Début des tests d'assurance qualité
Représente le début de la phase formelle de tests d'assurance qualité. Cette activité est déduite lorsque l'état d'un élément de travail passe à « In QA », « Testing » ou à une valeur similaire.
Pourquoi c’est important

Cette étape marque le début du cycle d'assurance qualité. L'analyse de la durée de cette phase est essentielle pour comprendre les goulots d'étranglement et l'efficacité des tests.

Où les obtenir

Déduit de l’historique de l’élément de travail en suivant une modification du champ System.State vers « In QA » ou un autre état de test désigné.

Collecte

Déduit de la modification du champ State vers « In QA » ou « Testing ».

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

Cette étape marque le début de la phase de développement actif. L'analyse du délai entre « Created » et « Development Started » révèle la durée d'attente dans la file du backlog.

Où les obtenir

Déduit de l'historique de l'élément de travail lorsque le champ System.State passe d'un état « New » ou « Approved » à un état « In Progress ».

Collecte

Déduit du changement du champ State vers « Active » ou « In Progress ».

Type d’événement inferred
Déployé en production
Marque le déploiement réussi du code associé à l’élément de travail dans l’environnement de production. Il s’agit d’un événement explicite enregistré dans les journaux de mise en production d’Azure Pipelines.
Pourquoi c’est important

Il s’agit d’un jalon important, qui représente la livraison de la valeur. Il sert de point final pour calculer le délai de livraison et le temps de cycle.

Où les obtenir

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

Collecte

Enregistré à partir d’un événement de fin de déploiement du pipeline de mise en production.

Type d’événement explicit
Élément de travail créé
Cette activité marque le début du cycle de vie du développement. Elle correspond à la création d'un nouvel élément de travail, tel qu'une User Story, un Bug ou une Task. Elle est enregistrée explicitement lorsqu'un nouvel enregistrement est sauvegardé dans Azure DevOps Boards.
Pourquoi c’est important

Il s'agit de l'événement de début principal du processus. Il est essentiel pour mesurer le délai de cycle de développement de bout en bout et comprendre l'origine initiale du travail.

Où les obtenir

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

Collecte

Enregistré à partir du champ « Created Date » de l'élément de travail.

Type d’événement explicit
Pull Request créée
Indique que le développeur a terminé le codage initial et soumis les modifications pour revue au moyen d'une Pull Request. Cet événement relie l'élément de travail à une modification de code précise dans Azure Repos.
Pourquoi c’est important

Il s'agit d'un transfert important entre le développement et la revue de code. Son suivi permet de mesurer la durée du codage et de déterminer à quel moment le code est prêt pour la revue par les pairs.

Où les obtenir

Enregistré à partir des données Azure Repos en reliant l'événement de création de la Pull Request à l'élément de travail associé. Ce lien est souvent établi explicitement par le développeur.

Collecte

Enregistré à partir de l'événement de création d'une Pull Request Azure Repos liée à un élément de travail.

Type d’événement explicit
Pull Request terminée
Représente l'achèvement réussi d'une revue de code : la Pull Request est approuvée et le code est fusionné dans la branche cible. Cet événement est enregistré explicitement dans Azure Repos.
Pourquoi c’est important

Cette étape marque la fin de la phase de revue de code, qui constitue souvent un goulot d'étranglement. L'analyse du délai entre la création et l'achèvement de la Pull Request révèle l'efficacité du cycle de revue.

Où les obtenir

Enregistré à partir de l'événement d'achèvement ou de fusion d'une Pull Request dans Azure Repos, lorsque celle-ci est liée à un élément de travail.

Collecte

Enregistré à partir de l'événement de fusion d'une Pull Request liée à un élément de travail.

Type d’événement explicit
UAT approuvée
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 d’un changement d’état de « In UAT » vers « UAT Approved » ou « Ready for Release ».
Pourquoi c’est important

Il s’agit d’un jalon d’approbation important, qui confirme que l’élément de travail répond aux exigences métier et est prêt pour un déploiement en production.

Où les obtenir

Déduit de l’historique de l’élément de travail en détectant une modification du champ System.State, depuis un état d’UAT vers un état approuvé ou prêt pour la mise en production.

Collecte

Déduit de la modification du champ State, de « In UAT » vers « 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. Il s'agit d'un événement explicite enregistré par Azure Pipelines.
Pourquoi c’est important

Cette étape constitue un contrôle qualité important : elle garantit que le nouveau code s'intègre correctement sans interrompre le build. Les échecs à ce stade peuvent révéler des problèmes d'intégration.

Où les obtenir

Enregistré à partir des événements d'achèvement de build d'Azure Pipelines. Le build doit être lié à l'élément de travail, directement ou par l'intermédiaire de la Pull Request associée.

Collecte

Enregistré à partir de l'événement d'achèvement d'un build Azure Pipelines.

Type d’événement explicit
Développement terminé
Indique que toutes les activités de développement et de tests unitaires sont terminées et que l'élément est prêt pour les tests formels. Cette étape est généralement déduite d'un changement d'état de l'élément de travail vers « Resolved » ou « Ready for Test ».
Pourquoi c’est important

Cette étape marque un transfert important de l'équipe de développement vers l'équipe d'assurance qualité. Mesurer le délai jusqu'au début des tests d'assurance qualité permet d'identifier les retards de transfert.

Où les obtenir

Déduit de l'historique de l'élément de travail lorsque le champ System.State prend une valeur telle que « Resolved » ou un état personnalisé indiquant que l'élément est prêt pour l'assurance qualité.

Collecte

Déduit du changement du champ State vers « Resolved ».

Type d’événement inferred
Échec des tests QA
Indique que l’élément de travail a échoué aux tests d’assurance qualité et est renvoyé au développement. Cette situation est identifiée par un changement d’état, depuis un état de test vers un état « In Progress » ou « Active ».
Pourquoi c’est important

Cette activité est essentielle pour identifier les boucles de reprise. Une fréquence élevée de cet événement peut révéler des problèmes liés à la qualité du code, aux exigences ou aux processus de test.

Où les obtenir

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

Collecte

Déduit de la modification du champ State, de « In QA » vers « Active ».

Type d’événement inferred
Élément de travail annulé
Indique que l’élément de travail a été annulé et ne sera ni terminé ni déployé. Cette situation est enregistrée lorsqu’un changement d’état le fait passer à « Removed », « Cancelled » ou un état similaire.
Pourquoi c’est important

Représente une issue alternative et infructueuse du processus. 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ù les obtenir

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

Collecte

Déduit de la modification du champ State vers « Removed » ou « Cancelled ».

Type d’événement inferred
Élément de travail approuvé
Représente l'approbation formelle d'un élément de travail, confirmant qu'il est correctement défini et prêt pour le développement. Cette étape est généralement déduite d'un changement du champ « State » vers une valeur telle que « Approved » ou « Ready for Dev ».
Pourquoi c’est important

Le suivi des approbations permet d'analyser le délai entre la soumission d'une idée et l'engagement de développement. Il met en évidence les retards potentiels lors des phases de planification et d'affinage du backlog.

Où les obtenir

Déduit de l'historique de l'élément de travail en détectant une modification du champ System.State vers « Approved » ou vers un état personnalisé similaire.

Collecte

Déduit du changement du champ State vers « Approved ».

Type d’événement inferred
Élément de travail fermé
Représente la clôture définitive de l’élément de travail après le déploiement et les éventuelles validations post-déploiement. Cette étape est enregistrée lorsqu’un changement d’état le fait passer à « Closed » ou « Done ».
Pourquoi c’est important

Cette activité marque l’achèvement final et réussi de l’ensemble du processus pour un élément de travail. Elle constitue le point final définitif de son cycle de vie.

Où les obtenir

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

Collecte

Déduit de la modification du champ State vers « Closed ».

Type d’événement inferred
Tests QA terminés
Marque la fin réussie de la phase d’assurance qualité. Cette étape 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 c’est important

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

Où les obtenir

Déduit 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 ».

Collecte

Déduit de la modification du champ State, de « In QA » vers « Ready for UAT ».

Type d’événement inferred
UAT démarrée
Représente le début des tests d’acceptation utilisateur, au cours desquels les parties prenantes métier valident les fonctionnalités. Cette étape est généralement déduite d’un changement d’état vers « In UAT » ou un statut similaire.
Pourquoi c’est important

Mesure le début de la validation finale avant la mise en production. La durée de l’UAT et les délais d’attente liés à l’approbation doivent être analysés attentivement pour optimiser le processus.

Où les obtenir

Déduit de l’historique de l’élément de travail lorsque le champ System.State est mis à jour avec un état personnalisé représentant l’UAT, tel que « In UAT ».

Collecte

Déduit de la modification du champ State vers « In UAT ».

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Azure DevOps

Prêt à commencer ?

Commencez dès aujourd’hui à optimiser votre cycle de développement logiciel. Ce template constitue la première étape vers des analyses précieuses de vos processus.

Optimisez votre SDLC dans Azure DevOps dès aujourd’hui !

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

Démarrer l’essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.