Microsoft AZ-400: Planification Agile et gestion du travail — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

La planification Agile et la gestion du travail dans Azure DevOps reposent sur un modèle de données clair, des pratiques de flux et d’itération disciplinées, et une visibilité transversale aux équipes. Azure Boards fournit une hiérarchie robuste de types d’éléments de travail et des configurations flexibles par équipe, tandis que GitHub Projects offre une planification moderne, pilotée par l’automatisation, étroitement intégrée avec les Issues et les Pull Requests. Une adoption efficace dépend de définitions rigoureuses (Definition of Done, critères d’acceptation), d’une estimation cohérente (story points et dimensionnement relatif), et d’informations exploitables (requêtes, plans de livraison et métriques, y compris DORA). Les sections suivantes détaillent comment concevoir, mettre en œuvre et opérer ces pratiques à grande échelle.

Modèle de données Azure Boards, modèles de processus et configuration d’équipe

Les types d’éléments de travail et leur hiérarchie constituent l’épine dorsale de la planification. Dans le processus Agile par défaut, la hiérarchie de portefeuille est Epic > Feature > User Story, avec Task et Bug comme éléments de niveau exécution. Les liens Enfant capturent la décomposition (User Story → Task) et les Bugs peuvent être gérés au même niveau de backlog que les User Stories ou triés indépendamment selon la politique de l’équipe. Les types de liens sont essentiels :

Parent/Child : capture la hiérarchie de décomposition et pilote la consolidation de la progression et de l’effort.
Predecessor/Successor : exprime les relations de planification et de dépendance entre les éléments de travail ; celles-ci apparaissent dans les Delivery Plans sous forme de lignes de dépendance.
Related/Duplicate/Blocked by : modélise les relations non hiérarchiques et les obstacles.
Liens d’artefact : connecte les éléments de travail au code (commits, branches, PRs), aux builds et aux releases, permettant une traçabilité de bout en bout.

Les modèles de processus Azure DevOps définissent les états, les champs et la dénomination des WIT :

Agile : l’élément de niveau exigence est la User Story ; les équipes qui avancent rapidement choisissent souvent celui-ci.
Scrum : l’élément de niveau exigence est le Product Backlog Item (PBI) ; les sprints et les artefacts Scrum sont des citoyens de première classe et les Bugs peuvent être configurés pour se comporter comme des PBI.
CMMI : l’élément de niveau exigence est le Requirement et il inclut des WIT pour Change Request, Risk et Review — choisissez celui-ci lorsque vous devez suivre les risques et les revues formelles.
Processus personnalisés (hérités) : dans Azure DevOps Services, étendez un processus système via l’héritage pour ajouter des WIT, des états, des règles et des champs personnalisés tout en préservant la compatibilité du service. Utilisez les catégories pour placer un WIT personnalisé au bon niveau de backlog. Évitez la sur-personnalisation qui fragmente le reporting ; standardisez les champs tels que les Story Points et le Remaining Work.

Les équipes sont des partitions légères configurées via :

Area paths : délimitent la propriété et le filtrage du backlog ; les équipes sélectionnent un ou plusieurs chemins de zone (et incluent éventuellement les zones enfants) pour définir « leur » travail.
Iteration paths : représentent la cadence des livraisons et les sprints ; une équipe choisit les itérations par défaut et actuelles pour la planification.
Backlogs et tableaux d’équipe : chaque équipe choisit les niveaux de portefeuille (Epic, Feature) à afficher, les styles de carte et les mappages de colonnes par équipe sans impacter les autres équipes.
Tableaux de bord d’équipe : organisent une visibilité partagée à l’aide de widgets pour la Velocity, le Burndown/Burnup, le Cumulative Flow Diagram (CFD), les graphiques de Lead/Cycle Time et les vues Analytics personnalisées.

Livraison basée sur le flux avec Kanban et gouvernance

Kanban dans Azure Boards modélise le flux continu de l’engagement à l’achèvement. Configurez les colonnes pour les mapper aux états du flux de travail et divisez éventuellement les états critiques en sous-colonnes En cours/Terminé pour améliorer la comptabilisation du débit et réduire les files d’attente cachées. Définissez des limites explicites de WIP (Work In Progress) par colonne et par couloir (swimlane) ; appliquez-les de manière opérationnelle — le dépassement d’une limite déclenche une conversation d’amélioration plutôt qu’une croissance silencieuse du backlog. Utilisez des couloirs dédiés (par exemple, Accélérer) pour séparer visuellement les éléments hautement prioritaires et définir un WIP plus strict pour ce couloir.

La Definition of Done (DoD) ancre la qualité et la prévisibilité ; encodez-la sous forme de politiques de tableau, de champs obligatoires ou de listes de contrôle sur des transitions spécifiques, et de liaison de tests d’acceptation. Par exemple, exigez un lien Testé par vers un Cas de test réussi avant de passer à Terminé, et capturez les étapes de vérification du déploiement lors du passage à Livré.

Utilisez les analytiques pour gérer la santé du flux :

Le Cumulative Flow Diagram valide l’équilibre du WIP et détecte les goulots d’étranglement lorsque les bandes s’élargissent.
Le Lead Time mesure le temps écoulé entre la création et l’achèvement ; le Cycle Time se concentre sur le temps écoulé entre l’entrée à l’état Actif et l’achèvement. Le widget de graphique Cycle Time rapporte le temps écoulé après qu’un élément de travail passe à l’état Actif, s’alignant sur l’analyse des goulots d’étranglement.
Les graphiques de débit (Throughput) suivent les éléments terminés par période ; surveillez la stabilité et la tendance.

Planification de l’itération, affinage du backlog et prévision basée sur la vélocité

La planification de sprint transforme la priorité en un engagement limité dans le temps (timeboxé). Le backlog de sprint liste les PBI ou les User Stories extraits pour l’itération, décomposés en Tâches avec un Travail restant (Remaining Work) en heures. Utilisez la Capacité du sprint (Sprint Capacity) pour modéliser la disponibilité des personnes :

Capacité par personne en heures/jour par activité (Development, Testing, UX).
Jours de congé individuels et d’équipe pour refléter les jours fériés et les vacances.
Équilibrage de la charge au niveau de l’activité en associant les tâches aux activités et en examinant la capacité par rapport au travail planifié.

La vélocité résume les story points livrés par sprint. Utilisez le graphique de Vélocité pour établir une bande stable ; évitez l’« inflation des points ». Sur les backlogs de produit, activez la fonction de Prévision (Forecasting) pour projeter le nombre d’itérations à venir nécessaires pour consommer (burn down) le backlog à la vélocité moyenne historique de l’équipe (basée sur plusieurs sprints récents) et à la durée de l’itération. Assurez la fiabilité de la prévision en excluant le travail partiellement terminé et en maintenant une Définition de Terminé (DoD) stricte.

L’affinage du backlog impose la clarté et le dimensionnement relatif :

Critères d’acceptation : enregistrez des énoncés clairs et testables dans le champ Acceptance Criteria de l’élément de travail ; préférez le format Given-When-Then pour réduire l’ambiguïté et accélérer la conception des tests.
Story points : estimez la complexité et l’incertitude relatives au niveau de l’exigence ; ne convertissez pas les points en heures — les tâches portent le Travail restant (Remaining Work).
Estimation relative (Planning Poker) : utilisez une base de référence partagée et une séquence (Fibonacci ou Fibonacci modifiée) pour converger rapidement. Les équipes peuvent utiliser des extensions de la Marketplace pour exécuter le Planning Poker dans Azure Boards, en écrivant les estimations dans les champs Story Points/Effort pour un reporting cohérent.

Les bogues doivent être triés et soit traités comme des exigences (estimés en points et planifiés dans le backlog), soit gérés comme des tâches au sein du sprint ; choisissez une seule politique par équipe pour maintenir la cohérence de la vélocité.

Planification inter-équipes, requêtes, rapports, GitHub Projects et métriques DevOps

Les programmes d’envergure nécessitent une visibilité sur l’ensemble des équipes et des dépôts :

Plans de livraison : créez des chronologies multi-équipes filtrées par chemins de zone/itération. Visualisez le travail par itération avec des lignes de dépendance (à partir des liens Prédécesseur/Successeur) et des marqueurs pour les jalons (dates de livraison, engagements externes). Affichez la progression agrégée des Features et des Epics et exposez des champs personnalisés (par ex., Risque) pour les revues de gouvernance.
Requêtes et rapports : construisez des requêtes de type Liste plate pour répondre à la question « quels éléments correspondent à ces filtres », des requêtes de type Arborescence d’éléments de travail pour naviguer dans la hiérarchie avec des cumuls, et des requêtes de type Liens directs pour analyser un saut de lien (par ex., Feature → Stories ou Bug → commits). Enregistrez et partagez des requêtes, ajoutez des graphiques (secteurs, barres, tendance) et épinglez-les aux tableaux de bord. Pour des rapports de qualité analytique, utilisez le service Azure DevOps Analytics et OData avec Power BI pour produire des graphiques d’avancement (burndown) de portefeuille, des cartes de chaleur des risques de dépendance et des visualisations DORA. Les rapports intégrés incluent la vélocité (Velocity), le Burndown/Burnup, le CFD, le Lead Time, le Cycle Time et l’utilisation de la capacité du sprint (Sprint Capacity).

GitHub Projects intègre la planification avec les Issues et les PRs :

Tableaux de projet : créez des vues Kanban ou tableau au niveau de l’organisation ou du dépôt, définissez des champs personnalisés (Statut, Itération, Priorité) et filtrez par équipe.
Règles d’automatisation : configurez des workflows intégrés pour définir le statut lorsqu’une Issue ou une PR est ouverte, fusionnée ou fermée ; archivez automatiquement les éléments terminés ; assignez ou étiquetez en fonction des changements de champ ; et déplacez les éléments entre les vues. Combinez avec GitHub Actions pour des automatisations avancées.
Intégration des Issues et des PRs : les Issues et les PRs sont des éléments de première classe dans Projects. Utilisez des mots-clés dans les descriptions de PR (Fixes #123) pour lier et fermer automatiquement les Issues. Le statut et les réviseurs sont visibles sur le tableau, permettant une traçabilité du code au plan.

Les métriques DevOps doivent relier le code, le déploiement et les résultats :

Métriques DORA :
- Fréquence de déploiement : comptez les déploiements en production par jour/semaine ; la source provient des événements de release du pipeline.
- Délai de livraison des changements (Lead time for changes) : mesurez depuis le commit du code (ou la fusion de la PR) jusqu’au déploiement en production ; assurez-vous que les pipelines émettent des horodatages de déploiement et corrélez-les aux commits.
- Taux d’échec des changements : ratio des déploiements en production qui entraînent un incident impactant le client ou un rollback ; intégrez avec les tags de gestion des incidents et les résultats du pipeline.
- Temps moyen de restauration (MTTR) : temps écoulé entre le début de l’incident et la restauration du service ; basé sur les alertes de surveillance et les heures de clôture des incidents. Corrélez les métriques DORA avec les analyses du tableau (Lead/Cycle time) pour détecter si la contrainte se situe au niveau de la planification ou de la livraison. Utilisez des tableaux de bord pour présenter les deux ensembles de métriques au même public pour une amélioration continue.

Scénario de problème pratique

La division Publicité de Microsoft aligne huit équipes pluridisciplinaires qui livrent une plateforme de gestion de campagnes partagée. La base de code se trouve dans GitHub ; l’organisation a besoin d’engagements trimestriels fiables, d’une visibilité claire sur les dépendances et de métriques de flux et DORA exploitables sans multiplier les outils.

Choisir le processus Agile d’Azure DevOps et configurer les équipes

Pourquoi : Le processus Agile fournit la hiérarchie Epic > Feature > User Story qui équilibre la simplicité avec les cumuls de portefeuille. Créez huit équipes, chacune avec son propre chemin de zone et ses chemins d’itération actuels/futurs, permettant l’autonomie dans les tableaux et les tableaux de bord tout en préservant les rapports à l’échelle de l’organisation.

Définir la gouvernance Kanban et la configuration du tableau

Pourquoi : Un flux continu entre les sprints réduit le temps d’attente. Configurez des colonnes mappées à des états avec des divisions En cours/Terminé (Doing/Done) pour En progression et Revue de code. Définissez des limites WIP par colonne et ajoutez un couloir (swimlane) Accélérer avec un WIP plus bas. Ajoutez des politiques de tableau énonçant la Définition de Terminé (Definition of Done) (tests unitaires réussis, PR approuvée, liste de vérification du déploiement complétée) pour contrôler le passage à l’état Terminé.

Mettre en œuvre l’affinage du backlog et la discipline d’estimation

Pourquoi : Des engagements prévisibles nécessitent un dimensionnement et une clarté cohérents. Capturez les critères d’acceptation en utilisant le format Given-When-Then sur les User Stories. Standardisez les Story Points via le Planning Poker (Fibonacci 1–13) à l’aide d’une extension Azure Boards, et conservez les estimations des tâches en heures de travail restant (Remaining Work) pour prendre en charge la capacité du sprint (Sprint Capacity).

Planifier les sprints avec la capacité et la prévision basée sur la vélocité

Pourquoi : La planification de la capacité réduit le sur-engagement. Saisissez les capacités individuelles par activité et les jours de congé. Utilisez le graphique de vélocité (Velocity) des six derniers sprints pour définir un objectif de sprint réaliste. Activez la prévision du backlog (Forecasting) pour projeter le nombre de sprints nécessaires pour atteindre les objectifs trimestriels des Epics, alignant ainsi les attentes des parties prenantes.

Établir des Plans de livraison pour la visibilité inter-équipes

Pourquoi : Les dépendances et les jalons doivent être visibles sur une chronologie unique. Créez un Plan de livraison incluant les huit équipes et les niveaux de portefeuille. Ajoutez des marqueurs de jalon pour les dates de livraison trimestrielles et les événements du marché. Utilisez les liens Prédécesseur/Successeur pour afficher les lignes de dépendance et faire remonter les risques lorsque des éléments s’étendent sur plusieurs itérations.

Intégrer GitHub Projects pour des vues d’exécution centrées sur le dépôt

Pourquoi : Les développeurs vivent dans GitHub ; Projects maintient le contexte d’exécution proche du code. Créez un GitHub Project au niveau de l’organisation avec des vues tableau et table. Ajoutez des règles d’automatisation pour passer le statut à En cours lors de l’ouverture d’une PR, à Terminé lors de la fusion d’une PR, et pour archiver automatiquement les Issues fermées. Utilisez « Fixes #<id> » dans les PRs pour fermer les Issues liées et refléter le statut dans le tableau.

Lier le code et le travail pour la traçabilité

Pourquoi : La traçabilité de bout en bout permet des rapports et des audits précis. Imposez la référence à l’ID de l’élément de travail Azure Boards dans les messages de commit et les descriptions de PR ; utilisez des liens d’artefact sur les éléments de travail pour que les Plans de livraison et les analyses puissent agréger la progression à partir de l’activité du code.

Instrumenter les métriques de flux et DORA sur les tableaux de bord

Pourquoi : Des métriques partagées et automatisées stimulent l’amélioration. Sur les tableaux de bord d’équipe, épinglez les graphiques CFD, Lead Time et Cycle Time pour gérer le flux. Sur un tableau de bord de programme, affichez la vélocité (Velocity), le résumé du Plan de livraison et les métriques DORA : calculez la fréquence de déploiement et le délai de livraison en utilisant les événements de déploiement des pipelines depuis les étapes de production ; dérivez le taux d’échec des changements et le MTTR en étiquetant les incidents et en les corrélant aux déploiements. Cette vue unifiée met en évidence si les contraintes se situent dans la planification (lead/cycle time du tableau) ou dans la livraison (DORA).

Cette approche équilibre l’autonomie des équipes (tableaux, capacité et tableaux de bord spécifiques à l’équipe) avec la gouvernance du programme (Plans de livraison, dépendances et jalons). Azure Boards fournit une planification hiérarchique et des analyses, GitHub Projects rationalise le suivi quotidien des développeurs avec une automatisation liée aux Issues et aux PRs, et les métriques DORA font le pont entre la planification et les résultats opérationnels pour des engagements crédibles et basés sur les données.

← Gestion des paquets et des artefacts · Tous les domaines

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →