Votre modèle de données pour le cycle de vie du développement logiciel
Votre modèle de données pour le cycle de vie du développement logiciel
- 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
|
L'identifiant unique pour une seule unité de travail, telle qu'une fonctionnalité, un bogue ou une user story, qui sert d'identifiant de cas pour le processus. | ||
|
Description
L'Élément de Développement représente une pièce de travail distincte suivie au sein d'Azure DevOps. Chaque élément, identifié par son ID unique, est l'objet central autour duquel gravitent toutes les activités de processus, de la création et planification au développement, aux tests et au déploiement. Dans l'analyse de Process Mining, cet attribut est fondamental pour corréler tous les événements liés en un seul parcours de cas. Il permet la reconstruction du cycle de vie de bout en bout pour chaque élément de travail, facilitant l'analyse des temps de cycle, des déviations de processus et des boucles de retravail sur une base individuelle par élément.
Pourquoi c'est important
Ceci est l'identifiant principal qui connecte toutes les étapes du processus en un cas cohérent, rendant possible l'analyse de bout en bout du cycle de vie du développement logiciel.
Où obtenir
Cela 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
|
L'horodatage précis indiquant quand une activité ou un événement spécifique s'est produit pour un élément de développement. | ||
|
Description
L'Heure de l'événement capture la date et l'heure de chaque activité dans le cycle de vie du développement. Cet horodatage est l'élément temporel fondamental utilisé pour ordonner les événements chronologiquement et calculer les durées entre eux. En analyse, cet attribut est critique pour le calcul de toutes les métriques basées sur le temps, y compris les temps de cycle, les temps de traitement et les temps d'attente. Il permet la création d'un journal d'événements ordonné chronologiquement, qui est l'entrée requise pour toute analyse de Process Mining. Il est utilisé pour diagnostiquer les retards, mesurer les performances par rapport aux SLA et suivre les tendances dans le temps.
Pourquoi c'est important
Cet horodatage fournit l'ordre chronologique des événements, ce qui est essentiel pour calculer tous les KPI basés sur la durée et comprendre le flux de processus et les goulots d'étranglement.
Où obtenir
Ceci est la 'Date de Modification' associée à chaque mise à jour dans l'historique d'un élément de travail. Pour les événements externes comme les builds ou les déploiements, c'est l'horodatage d'achèvement de cet événement.
Exemples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
Nom de l'activité
ActivityName
|
Le nom de l'événement ou de la tâche spécifique qui s'est produit à un moment donné du cycle de vie de développement pour un élément de travail. | ||
|
Description
Le Nom de l'Activité décrit une étape ou un jalon spécifique du processus, tel que 'Développement Démarré', 'Pull Request Créée', ou 'Déployé en Production'. Ces activités sont dérivées des changements d'état de l'élément de travail, des événements liés comme les builds ou les pull requests, ou des événements personnalisés. Cet attribut est essentiel pour construire la cartographie des processus, qui représente visuellement le workflow. Il permet aux analystes de comprendre la séquence des événements, d'identifier les chemins courants, de découvrir les goulots d'étranglement entre des activités spécifiques et d'analyser la fréquence de chaque étape.
Pourquoi c'est important
Cela définit les étapes du processus, constituant l'ossature de la cartographie des processus et permettant l'analyse du workflow, des goulots d'étranglement et des déviations.
Où obtenir
Ceci est généralement dérivé des changements dans le champ 'État' d'un élément de travail, ou d'événements liés comme les builds, les commits et les pull requests. L'Historique de l'Élément de Travail fournit les données brutes pour ces événements.
Exemples
Développement commencéPull Request ComplétéeTests QA ÉchouésDéployé en productionÉlément de Travail Fermé
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L'horodatage indiquant la dernière fois que les données de ce processus ont été actualisées à partir du système source. | ||
|
Description
Cet attribut enregistre la dernière date d'extraction et de mise à jour du jeu de données depuis Azure DevOps. Il fournit une indication claire de la fraîcheur des données et de la période couverte par l'analyse. Dans toute analyse de processus, connaître l'actualité des données est essentiel pour prendre des décisions éclairées. Cet horodatage aide les utilisateurs à comprendre s'ils examinent des informations en temps réel ou un instantané historique, ce qui affecte la pertinence des résultats.
Pourquoi c'est important
Cela informe les utilisateurs sur la fraîcheur des données, garantissant que les analyses et les décisions sont basées sur une période de temps bien définie.
Où obtenir
Il s'agit d'un horodatage de métadonnées généré et stocké pendant le processus d'extraction, de transformation et de chargement (ETL) des données.
Exemples
2024-05-20T08:00:00Z
|
|||
|
Système source
SourceSystem
|
Le système à partir duquel les données de 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 pour une vue de processus plus large. Pour ce modèle spécifique, la valeur est systématiquement Azure DevOps. Bien qu'il puisse sembler statique dans une analyse mono-système, il fournit un contexte essentiel sur l'origine des données, ce qui est crucial pour la gouvernance des données, le dépannage et les futures intégrations avec d'autres systèmes comme ServiceNow ou SAP.
Pourquoi c'est important
Cela fournit un contexte crucial sur l'origine des données, ce qui est important pour la gouvernance des données, la validation et l'analyse des processus multi-systèmes.
Où obtenir
Il s'agit d'une valeur statique qui doit être ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter le jeu de données.
Exemples
Azure DevOps
|
|||
|
Attribué à
AssignedTo
|
L'utilisateur ou le membre de l'équipe auquel l'élément de développement est actuellement assigné. | ||
|
Description
Cet attribut identifie l'individu responsable de l'élément de travail à un stade donné du processus. L'affectation peut changer plusieurs fois tout au long du cycle de vie de l'élément, par exemple, d'un développeur à un testeur, puis à un responsable de déploiement. L'analyse par 'Assigné à' est critique pour le tableau de bord « Aperçu de la Charge de Travail des Développeurs et Testeurs ». Elle aide à comprendre l'allocation des ressources, à identifier les membres de l'équipe surchargés et à analyser les différences de performance entre individus ou équipes.
Pourquoi c'est important
Cela permet une analyse basée sur les ressources, aidant à comprendre la répartition de la charge de travail, à identifier les goulots d'étranglement spécifiques aux ressources et à gérer la capacité des équipes.
Où obtenir
Cela correspond au champ 'Assigné à' sur un Élément de Travail dans Azure DevOps. La valeur est capturée à partir de l'historique de l'élément de travail pour chaque événement.
Exemples
jane.doe@example.comjohn.smith@example.comnon_assigné
|
|||
|
Est un retravail
IsRework
|
Un indicateur booléen signalant si un élément de développement est revenu à une étape précédente de son cycle de vie. | ||
|
Description
Ce drapeau est défini sur vrai si un élément de travail présente une boucle de retravail, par exemple, en passant de 'Tests QA Terminés' à 'Développement Démarré'. Il est calculé en analysant la séquence des activités pour un cas et en détectant les progressions non linéaires. Cet attribut est essentiel pour le tableau de bord « Fréquence du Retravail et des Retests » et le KPI « Fréquence des Boucles de Retravail ». Il permet un filtrage et une quantification faciles du retravail, aidant à identifier les problèmes de qualité, les lacunes de communication ou les tests insuffisants qui entraînent des inefficacités.
Pourquoi c'est important
Cela identifie et quantifie directement le retravail, aidant à mettre en évidence les problèmes de qualité et les inefficacités de processus qui prolongent les temps de cycle.
Où 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
truefaux
|
|||
|
État
State
|
Le statut actuel de l'élément de développement au sein de son workflow, tel que 'Nouveau', 'Actif', 'Résolu' ou 'Fermé'. | ||
|
Description
L'attribut État représente le statut formel d'un élément de travail à tout moment, tel que défini par le modèle de processus du projet. Les transitions entre ces états sont la source principale pour générer les activités dans le journal d'événements. Bien que l'attribut 'Activité' soit souvent une version plus descriptive d'un changement d'état, l'attribut 'État' brut est utile pour le filtrage et l'analyse. Il aide à comprendre combien de temps les éléments passent dans des états particuliers et est fondamental pour construire le tableau de bord 'Durée des Étapes' et analyser les transferts.
Pourquoi c'est important
Cela indique le statut de l'élément de travail dans son cycle de vie, ce qui est fondamental pour comprendre le flux de processus et calculer le temps passé dans les différentes étapes.
Où obtenir
Cela correspond au champ 'État' sur un Élément de Travail dans Azure DevOps.
Exemples
NouveauActifEn QARésoluClôturé
|
|||
|
Heure de fin
EndTime
|
L'horodatage indiquant quand une activité a été complétée. Il est utilisé pour 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 de la précédente. Cependant, avoir une heure de fin distincte permet un calcul plus précis du temps de traitement des activités et du temps d'inactivité entre les activités. Cet attribut est crucial pour le calcul du KPI ProcessingTime et pour effectuer une analyse détaillée des goulots d'étranglement. Il aide à différencier le temps passé à travailler activement sur une tâche du temps passé à attendre que l'étape suivante commence, ce qui est essentiel pour le tableau de bord « Analyse des Transferts d'Étapes ».
Pourquoi c'est important
Cela permet le calcul précis des temps de traitement des activités et des temps d'inactivité, ce qui est fondamental pour l'analyse des goulots d'étranglement et les améliorations de l'efficacité.
Où obtenir
Ceci est souvent dérivé. Il peut s'agir de l'heure de début de l'événement suivant pour le même cas, ou il peut être explicitement enregistré si le système source capture à la fois 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
|
Le nom de l'équipe de développement responsable de l'élément de travail. | ||
|
Description
Le Nom de l'Équipe identifie l'équipe spécifique à laquelle un élément de travail est assigné. Dans Azure DevOps, le travail est souvent organisé par équipes, qui peuvent être des sous-ensembles d'un projet plus vaste. Cet attribut permet de segmenter l'analyse des processus par équipe. Il est inestimable pour comparer les processus et les performances entre différentes équipes, identifier les meilleures pratiques dans les équipes très performantes et trouver les domaines où des équipes spécifiques pourraient avoir besoin de support ou d'améliorations de processus.
Pourquoi c'est important
Cela permet une analyse comparative entre différentes équipes, aidant à identifier les variations de performance et à partager les meilleures pratiques au sein de l'organisation.
Où obtenir
Ceci est souvent dérivé du 'Chemin de Zone' d'un élément de travail, car les équipes sont généralement mappées à des chemins de zone spécifiques dans Azure DevOps.
Exemples
Équipe PhoenixÉquipe OmegaCœur de PlateformeÉquipe Frontend
|
|||
|
Priorité
Priority
|
Un classement numérique ou descriptif de l'importance de l'élément de développement par rapport à d'autres éléments. | ||
|
Description
La Priorité indique l'importance de la planification d'un élément de travail. Une priorité plus élevée suggère qu'un élément doit être traité plus rapidement que les éléments de priorité inférieure. Les valeurs courantes sont numériques, telles que 1, 2, 3, 4, 1 étant la plus élevée. Cet attribut est essentiel pour le tableau de bord « Débit et Temps de Cycle Basés sur la Priorité ». L'analyse des données avec cet attribut aide à déterminer si le système de priorisation est efficace, c'est-à-dire si les éléments à haute priorité progressent réellement plus vite que ceux à basse priorité.
Pourquoi c'est important
Cela permet d'analyser si le processus accélère efficacement les éléments à haute priorité, ce qui est essentiel pour évaluer le succès des stratégies de priorisation.
Où obtenir
Cela correspond au champ 'Priorité' sur un Élément de Travail dans Azure DevOps.
Exemples
1234
|
|||
|
Temps de cycle de développement
DevelopmentCycleTime
|
Le temps total écoulé entre la création d'un élément de développement et son déploiement en production. | ||
|
Description
Le Temps de Cycle de Développement est un indicateur clé de performance qui mesure la durée de bout en bout du processus de développement pour un seul élément de travail. Il est calculé comme la différence entre l'horodatage de l'activité 'Deployed to Production' et l'activité 'Work Item Created'. Cette métrique calculée est le KPI principal pour le tableau de bord du temps de cycle de développement de bout en bout et les tendances historiques des temps de cycle. Elle fournit une mesure holistique de la vélocité et de l'efficacité du processus, et son suivi dans le temps montre l'impact des initiatives d'amélioration des processus.
Pourquoi c'est important
Il s'agit d'un KPI critique qui mesure la vitesse et l'efficacité globales du processus de développement de bout en bout.
Où obtenir
Ceci est calculé en prenant l'horodatage de l'événement de déploiement final et en soustrayant l'horodatage de l'événement de création pour chaque cas.
Exemples
10 jours 4 heures 30 minutes25 jours 8 heures 0 minutes5 jours 2 heures 15 minutes
|
|||
|
Type d'Élément de Travail
WorkItemType
|
La classification de l'élément de développement, tel que Bogue, Fonctionnalité, User Story ou Tâche. | ||
|
Description
Le Type d'Élément de Travail catégorise la nature du travail effectué. Différents types d'éléments de travail suivent souvent des chemins de processus distincts et ont des attentes de performance ou des SLAs différentes. Par exemple, un 'Bogue' pourrait suivre un chemin accéléré par rapport à une 'Fonctionnalité'. Cet attribut est essentiel pour l'analyse comparative. Il vous permet de filtrer la cartographie des processus ou les KPI par type de travail pour comprendre si certains processus sont plus efficaces pour les bogues par rapport aux fonctionnalités, ou pour suivre les tendances historiques des temps de cycle pour différentes catégories de travail.
Pourquoi c'est important
Cela permet la segmentation de l'analyse des processus, facilitant la comparaison des workflows et des performances pour différentes catégories de travail comme les bogues et les fonctionnalités.
Où obtenir
Cela correspond au champ 'Type d'Élément de Travail' sur un Élément de Travail dans Azure DevOps.
Exemples
BugFeatureUser StoryTâche
|
|||
|
Chemin d'Itération
IterationPath
|
Le sprint de développement ou la période limitée (timebox) auquel l'élément de travail est assigné. | ||
|
Description
Le Chemin d'Itération, ou sprint, représente une période de développement à durée fixe. Les éléments de travail sont assignés à une itération pour être complétés dans ce délai. L'analyse par Chemin d'Itération aide à comprendre la performance des processus sprint par sprint. Elle peut être utilisée pour suivre si les temps de cycle s'améliorent au fil des sprints successifs, pour analyser le travail reporté et pour évaluer la prévisibilité de la planification des sprints.
Pourquoi c'est important
Cela permet une analyse par sprint, aidant les équipes à évaluer leurs performances au fil du temps et à améliorer leurs pratiques agiles.
Où obtenir
Cela correspond au champ 'Chemin d'Itération' sur un Élément de Travail dans Azure DevOps.
Exemples
Plateforme E-commerce\Sprint 12Plateforme E-commerce\Sprint 13Relance 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é est utilisée pour classer l'impact d'un bogue, des défaillances critiques du système aux problèmes cosmétiques mineurs. Cela est distinct de la priorité, qui dicte l'ordre de travail. Un bogue de haute gravité peut avoir une faible priorité s'il existe une solution de contournement facilement disponible. Cet attribut fournit une autre dimension pour l'analyse, en particulier pour le tableau de bord « Débit et Temps de Cycle Basés sur la Priorité ». Il permet d'étudier des questions telles que : « Corrigeons-nous les bogues les plus critiques en premier ? » et aide à comprendre le profil de risque du travail en cours de traitement.
Pourquoi c'est important
Cela aide à catégoriser les éléments de travail selon leur impact commercial, permettant d'analyser l'efficacité avec laquelle l'équipe aborde les problèmes à fort impact.
Où obtenir
Cela correspond au champ 'Gravité' sur un Élément de Travail, généralement pour les bogues, dans Azure DevOps.
Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
|
|||
|
ID de Pull Request
PullRequestId
|
L'identifiant d'une pull request liée à l'élément de développement. | ||
|
Description
Cet attribut lie un élément de travail à une pull request spécifique, qui est le mécanisme de soumission et de revue des modifications de code. Un seul élément de travail peut être associé à plusieurs pull requests. Disposer de l'ID de la Pull Request permet une analyse plus granulaire de la partie revue de code et intégration du cycle de vie. Il peut être utilisé pour mesurer le temps entre la création et l'achèvement d'une pull request, et pour analyser la fréquence des rejets ou des demandes de modifications importantes, ce qui peut être un indicateur de la qualité du code ou d'exigences peu claires.
Pourquoi c'est important
Cela relie le travail de développement aux activités spécifiques de revue de code, permettant une analyse détaillée de l'intégration du code et du processus d'assurance qualité.
Où obtenir
Cette information se trouve dans la section 'Liens' ou 'Développement' d'un élément de travail dans Azure DevOps.
Exemples
452145334589
|
|||
|
Nom du Projet
ProjectName
|
Le nom du projet Azure DevOps auquel l'élément de développement appartient. | ||
|
Description
Cet attribut identifie le projet spécifique au sein de l'organisation Azure DevOps où se trouve l'élément de travail. Il fournit un contexte de haut niveau, en particulier dans les organisations avec de nombreux projets. Le Nom du Projet est une dimension critique pour le filtrage et la comparaison. Il supporte le tableau de bord « Tendances Historiques des Temps de Cycle » en permettant de segmenter l'analyse par projet, révélant si certains projets sont plus ou moins efficaces que d'autres, ou si les améliorations de processus dans un projet ont eu un impact positif.
Pourquoi c'est important
Cela fournit un regroupement de haut niveau pour l'analyse, permettant la comparaison des performances et l'analyse des tendances entre différents projets.
Où obtenir
Cela correspond au champ 'Projet d'Équipe' sur un Élément de Travail dans Azure DevOps.
Exemples
Plateforme E-commerceRelance Application MobileModernisation de l'entrepôt de données
|
|||
|
Temps d'attente d'approbation
ApprovalWaitingTime
|
Le temps qu'un élément de développement passe à attendre une approbation après qu'une demande a été faite. | ||
|
Description
Cette métrique mesure la durée des périodes d'attente spécifiques où un élément de travail est en attente d'une approbation. Un excellent exemple est le temps entre 'UAT Démarrée' et 'UAT Approuvée'. Elle est calculée en mesurant le temps entre ces deux activités spécifiques pour un cas donné. Cet attribut calculé soutient directement le tableau de bord « Analyse des Temps d'Attente d'Approbation » et le KPI correspondant. En isolant ces retards spécifiques, les équipes peuvent cibler les processus de communication et de prise de décision pour réduire le temps d'inactivité et accélérer le cycle de vie global.
Pourquoi c'est important
Cela mesure spécifiquement les retards causés par l'attente de décisions ou d'approbations, soulignant les opportunités d'améliorer les processus de communication et de prise de décision.
Où obtenir
Ceci est calculé en trouvant des activités d'approbation de début et de fin spécifiques dans le journal d'événements (par exemple, 'UAT Démarrée' et 'UAT Approuvée') et en calculant la différence de temps.
Exemples
3 jours 2 heures1 jour 8 heures 30 minutes4 heures
|
|||
|
Temps de Transfert d'Étape
StageHandoffTime
|
La durée du temps d'inactivité entre l'achèvement d'une étape majeure et le début de la suivante. | ||
|
Description
Le Temps de Transfert d'Étape mesure la période d'attente entre des étapes de processus séquentielles, par exemple, le temps entre 'Développement Terminé' et 'Tests QA Démarrés'. Il est calculé en identifiant ces transitions clés et en mesurant l'écart de temps entre la fin de la première activité et le début de la seconde. Cette métrique est l'objet du tableau de bord « Analyse des Durées d'Étape et des Transferts ». Isoler et mesurer le temps de transfert est crucial pour identifier les goulots d'étranglement cachés où le travail est inactif, souvent en raison d'indisponibilité des ressources, de retards de communication ou de processus inefficaces.
Pourquoi c'est important
Cela quantifie les temps d'attente entre les étapes du processus, exposant directement les goulots d'étranglement cachés et les retards qui ne font pas partie du travail actif.
Où obtenir
Il s'agit d'un attribut calculé. Il nécessite d'identifier des paires d'activités séquentielles qui représentent un transfert, puis de calculer la différence de temps entre elles.
Exemples
2 heures 15 minutes1 jour 4 heures0 heures 30 minutes
|
|||
Activités du Cycle de Vie du Développement Logiciel
| Activité | Description | ||
|---|---|---|---|
|
Déployé en production
|
Marque le déploiement réussi du code associé à l'élément de travail vers l'environnement de production. Il s'agit d'un événement explicite capturé à partir des journaux de déploiement d'Azure Pipelines. | ||
|
Pourquoi c'est important
Il s'agit d'un jalon critique représentant la livraison de valeur. Il sert de point d'arrivée pour le calcul du temps de lead et du temps de cycle.
Où obtenir
Capturé à partir des données de pipeline de livraison des Pipelines Azure, spécifiquement l'événement de complétion d'un déploiement vers une étape de 'Production' qui est liée à l'élément de travail.
Capture
Capturé à partir d'un événement de complétion de déploiement de pipeline de livraison.
Type d'événement
explicit
|
|||
|
Développement commencé
|
Cette activité signifie qu'un développeur a commencé à travailler activement sur l'élément. Elle est capturée en inférant un changement d'état de l'élément de travail vers 'Actif', 'En Cours', ou 'Engagé'. | ||
|
Pourquoi c'est important
Marque le début de la phase de développement actif. L'analyse du temps entre 'Créé' et 'Développement Démarré' révèle les temps d'attente du backlog.
Où obtenir
Inférent 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'.
Capture
Inférent de la modification du champ 'State' à 'Active' ou 'In Progress'.
Type d'événement
inferred
|
|||
|
Élément de Travail Créé
|
Cette activité marque le début du cycle de vie du développement, représentant la création d'un nouvel élément de travail tel qu'une User Story, un Bogue ou une Tâche. Elle est capturée explicitement lorsqu'un nouvel enregistrement est sauvegardé dans Azure DevOps Boards. | ||
|
Pourquoi c'est important
Ceci est l'événement de départ principal du processus. Il est essentiel pour mesurer le temps de cycle de développement de bout en bout et comprendre les sources initiales de travail.
Où obtenir
Cet événement est capturé à partir de la 'Date de Création' sur l'élément de travail lui-même. Le tableau de l'historique des éléments de travail enregistre également cette transition d'état initiale.
Capture
Capturé à partir du champ 'Created Date' de l'élément de travail.
Type d'événement
explicit
|
|||
|
Pull Request Complétée
|
Représente l'achèvement réussi d'une revue de code, où la pull request est approuvée et le code est fusionné dans la branche cible. Cet événement est explicitement enregistré dans Azure Repos. | ||
|
Pourquoi c'est important
Marque la fin de la phase de revue de code, un goulot d'étranglement courant. L'analyse du temps entre la création et l'achèvement d'une Pull Request révèle l'efficacité du cycle de revue.
Où obtenir
Capturé à partir de l'événement de complétion ou de fusion d'une pull request dans Azure Repos qui est liée à un élément de travail.
Capture
Capturé à partir de l'événement de fusion de pull request lié à un é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 révision via une pull request. Cet événement lie l'élément de travail à un changement de code spécifique dans Azure Repos. | ||
|
Pourquoi c'est important
Il s'agit d'un transfert clé du développement à la revue de code. Le suivi de cela aide à mesurer la durée du codage et identifie quand le code est prêt pour la revue par les pairs.
Où obtenir
Capturé à partir des données d'Azure Repos en liant l'événement de création de pull request à son élément de travail associé. Il s'agit souvent d'un lien explicite créé par le développeur.
Capture
Capturé à partir de l'événement de création de pull request d'Azure Repos lié à un élément de travail.
Type d'événement
explicit
|
|||
|
Tests QA Démarrés
|
Représente le début de la phase formelle de tests d'assurance qualité. Cette activité est déduite lorsqu'un élément de travail change d'état pour 'En QA', 'En Test', ou une valeur similaire. | ||
|
Pourquoi c'est important
Marque le début du cycle QA. L'analyse de la durée de cette phase est cruciale pour comprendre les goulots d'étranglement des tests et leur efficacité.
Où obtenir
Inférent de l'historique de l'élément de travail en suivant un changement du champ System.State vers 'In QA' ou un autre état de test désigné.
Capture
Inférent de la modification du champ 'State' à 'In QA' ou 'Testing'.
Type d'événement
inferred
|
|||
|
UAT Approuvée
|
Cette activité signifie que les parties prenantes métier ont approuvé les changements après les Tests d'Acceptation Utilisateur (UAT). Elle est généralement déduite d'un changement d'état de 'En UAT' à 'UAT Approuvée' ou 'Prêt pour le Déploiement'. | ||
|
Pourquoi c'est important
Il s'agit d'un jalon d'approbation critique qui confirme que l'élément de travail répond aux exigences métier et est prêt pour le déploiement en production.
Où obtenir
Inférent de l'historique de l'élément de travail en détectant un changement du champ System.State d'un état UAT à un état approuvé ou prêt pour la publication.
Capture
Inférent de la modification du champ 'State' de 'In UAT' à 'Ready for Release'.
Type d'événement
inferred
|
|||
|
Build réussie
|
Cette activité confirme que le code source, y compris les nouvelles modifications, a été compilé et packagé avec succès par un pipeline de build. Il s'agit d'un événement explicite enregistré par Azure Pipelines. | ||
|
Pourquoi c'est important
Sert de porte de qualité critique, garantissant que le nouveau code s'intègre correctement sans casser la build. Les échecs à ce stade peuvent indiquer des problèmes d'intégration.
Où obtenir
Capturé à partir des événements de complétion de build des Pipelines Azure. La build doit être liée à l'élément de travail, soit directement, soit via la pull request associée.
Capture
Capturé à partir de l'événement de complétion de build des Pipelines Azure.
Type d'événement
explicit
|
|||
|
Développement terminé
|
Signifie 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. Cela est généralement déduit d'un changement d'état de l'élément de travail vers 'Résolu' ou 'Prêt pour les Tests'. | ||
|
Pourquoi c'est important
Ceci marque un transfert majeur de l'équipe de développement à l'équipe QA. Mesurer le temps jusqu'à 'Tests QA Démarrés' aide à identifier les retards de transfert.
Où obtenir
Inférent de l'historique de l'élément de travail lorsque le champ System.State passe à une valeur comme 'Resolved' ou un état personnalisé indiquant la préparation pour la QA.
Capture
Inférent de la modification du champ 'State' à 'Resolved'.
Type d'événement
inferred
|
|||
|
Élément de Travail Annulé
|
Indique que l'élément de travail a été annulé et ne sera pas terminé ou déployé. Ceci est capturé par un changement d'état vers 'Removed', 'Cancelled' ou un état similaire. | ||
|
Pourquoi c'est important
Ceci représente une fin de processus alternative et infructueuse. 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ù obtenir
Inférent de l'historique de l'élément de travail lorsque le champ System.State est changé à un état terminal dans la catégorie 'Removed'.
Capture
Inférent de la modification du champ 'State' à '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 bien défini et prêt pour le développement. Cela est généralement déduit d'un changement dans le champ 'État' vers une valeur comme 'Approuvé' ou 'Prêt pour le Dev'. | ||
|
Pourquoi c'est important
Le suivi des approbations aide à analyser le temps entre la soumission d'idées et l'engagement de développement. Il met en évidence les retards potentiels dans les phases de planification et de raffinement du backlog.
Où obtenir
Inférent de l'historique de l'élément de travail en détectant un changement du champ System.State à 'Approved' ou un état personnalisé similaire.
Capture
Inférent de la modification du champ 'State' à 'Approved'.
Type d'événement
inferred
|
|||
|
Élément de Travail Fermé
|
Représente la clôture finale de l'élément de travail après le déploiement et toute validation post-déploiement. Il est capturé par un changement d'état vers 'Fermé' ou 'Terminé'. | ||
|
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. C'est le point d'arrivée définitif du cycle de vie.
Où obtenir
Inférent de l'historique de l'élément de travail lorsque le champ System.State est changé à 'Closed' ou un état terminal similaire dans la catégorie 'Completed'.
Capture
Inférent de la modification du champ 'State' à 'Closed'.
Type d'événement
inferred
|
|||
|
Tests QA Échoués
|
Indique que l'élément de travail a échoué aux tests d'assurance qualité et est renvoyé au développement. Ceci est capturé par un changement d'état d'un état de test vers un état 'In Progress' ou 'Active'. | ||
|
Pourquoi c'est important
Cette activité est essentielle pour identifier les boucles de retravail. Une fréquence élevée de cet événement indique des problèmes de qualité du code, d'exigences ou de processus de test.
Où obtenir
Inférent de l'historique de l'élément de travail en détectant une transition d'un état comme 'In QA' vers un état comme 'Active' ou 'In Progress'.
Capture
Inférent de la modification du champ 'State' de 'In QA' à 'Active'.
Type d'événement
inferred
|
|||
|
Tests QA Terminés
|
Marque l'achèvement réussi de la phase d'assurance qualité. Cela est déduit lorsque l'état de l'élément de travail passe d'un état de test à un état tel que 'Prêt pour l'UAT' ou 'QA Approuvé'. | ||
|
Pourquoi c'est important
Il s'agit d'une porte de qualité clé indiquant que l'élément est prêt pour les tests d'acceptation utilisateur ou le déploiement. Les retards après ce point peuvent indiquer des goulots d'étranglement de l'UAT ou de la planification du déploiement.
Où obtenir
Inférent de l'historique de l'élément de travail lorsque le champ System.State passe de 'In QA' à un état subséquent comme 'Ready for UAT' ou 'Done'.
Capture
Inférent de la modification du champ 'State' de 'In QA' à 'Ready for UAT'.
Type d'événement
inferred
|
|||
|
UAT Démarrée
|
Représente le début des Tests d'Acceptation Utilisateur (UAT), où les parties prenantes métier valident la fonctionnalité. Cela est généralement déduit d'un changement d'état vers 'En UAT' ou un statut similaire. | ||
|
Pourquoi c'est important
Mesure le début de la validation finale avant le déploiement. La durée de l'UAT et les temps d'attente pour approbation sont essentiels à analyser pour l'optimisation des processus.
Où obtenir
Inférent de l'historique de l'élément de travail lorsque le champ System.State est mis à jour vers un état personnalisé représentant l'UAT, tel que 'In UAT'.
Capture
Inférent de la modification du champ 'State' à 'In UAT'.
Type d'événement
inferred
|
|||