Votre template de données pour le cycle de développement logiciel
Votre template de données pour le cycle de développement logiciel
- Attributs recommandés à collecter
- Activités clés à suivre pour votre SDLC
- Guide détaillé d’extraction pour Azure DevOps
Attributs du cycle de vie du développement logiciel
| 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
|
|||
Activités du cycle de vie du développement logiciel
| 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
|
|||
Guides d’extraction
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.
Aucune carte bancaire requise. Commencez en quelques minutes.