Structurer un backlog Azure DevOps pour un programme D365

Utiliser le backlog comme modèle de gouvernance

Microsoft fournit un catalogue de processus métier et un arbre de livrables Dynamics 365 importables dans Azure DevOps. Ce sont des accélérateurs utiles, mais la propriété et la hiérarchie doivent encore refléter le programme réel.

Je sépare trois dimensions : le résultat métier, la capacité solution et le travail d'ingénierie. Elles doivent être liées plutôt que compressées dans un seul work item surchargé.

Voir Importer le catalogue de processus métier dans Azure DevOps et Arbre de livrables et types de work items Dynamics 365.

Une hiérarchie pragmatique

Chemins de zone et structure d'itération

Les chemins de zone représentent la dimension de propriété (qui possède ce travail), tandis que les itérations représentent la dimension temporelle (quand est-il planifié). Les deux doivent être configurés avant de peupler le backlog.

Structure de chemin de zone (exemple) :
D365-Programme
├── Finance
│   ├── Comptabilité-Client
│   └── Comptabilité-Générale
├── Supply-Chain
│   ├── Achats
│   └── Stock
├── Intégration
└── Infrastructure
    ├── ALM
    └── Sécurité

Structure d'itération :
D365-Programme
├── Sprints
│   ├── 2026-S01 (7 – 18 juil.)
│   ├── 2026-S02 (21 juil. – 1er août)
│   └── 2026-S03 (4 – 15 août)
├── Releases
│   ├── Release-1.0 (29 août)
│   └── Release-1.1 (3 oct.)
└── Backlog (non planifié)

L'affectation du chemin de zone détermine qui voit le work item dans son tableau d'équipe. L'affectation de l'itération pilote la planification de sprint. Maintenez les chemins de zone stables ; les itérations sont ajoutées selon la cadence de release.

Une user story D365 actionnable

## Contexte métier
Le crédit client est vérifié lors de la confirmation de commande pour FR01 et BE01.

## Règle attendue
Bloquer la confirmation quand l'exposition calculée dépasse le plafond,
sauf pour les commandes interco (type = Journal).

## Périmètre D365
Confirmation SalesTable → module gestion crédit → SalesFormLetter_Confirm.
Vérification standard via CustVendOpenTransManager.

## Critères d'acceptation
- sous le plafond : confirmation réussie, aucun message
- au-dessus : message Infolog explicite, aucun document généré
- interco (type Journal) : comportement standard inchangé
- confirmation par lot : même règle appliquée ; entrée de journal d'erreurs actionnables par commande

## Contraintes non fonctionnelles
Aucun appel HTTP externe dans la transaction de confirmation.
500 commandes traitées en lot en moins de cinq minutes.

## Preuves requises
Classe SysTest liée à la PR, validation UAT par le responsable crédit,
note technique incluant les objets impactés et la mesure de performance.

Définition de Prêt et Définition de Terminé

Exposer le risque technique

Utilisez des tags contrôlés tels que Extension, Intégration, MigrationDonnées, Sécurité, Performance, Reporting et Localisation. Ils permettent des requêtes et des tableaux de bord transverses.

• Objets, modèles et points d'extension impactés.
• Périmètre interface, batch ou entité de données.
• Criticité et fenêtre de déploiement.
• Dépendances envers des équipes externes ou des éditeurs ISV.
• Stratégie de rollback ou de désactivation fonctionnelle.
• Exigence de test de charge ou de sécurité.

Utilisez un Spike pour traiter l'incertitude. Un Spike doit produire une sortie concrète : prototype, mesure, ADR, estimation révisée ou recommandation documentée. Un Spike sans sortie n'est qu'un travail différé.

Intégration des plans de test Azure

Azure Test Plans fournit le pont entre une user story et ses preuves de validation. Dans un programme D365, lier les cas de test aux stories et aux bugs est le principal moyen de répondre à « cette fonctionnalité est-elle entièrement validée ? »

Chaque cas de test enregistre : préconditions, étapes, résultat attendu, résultat réel et pièces jointes. Clore une Story sans cas de test lié et passant viole la Définition de Terminé et doit être détecté en revue de sprint.

Construire la traçabilité de bout en bout

La chaîne de traçabilité minimale est : processus → story → tâches → commit/pull request → artefact de build → plan de test → bug → release. Automatisez les liens via les politiques de branche, les conventions de message de commit et la configuration du pipeline.

Une release doit répondre à trois questions sans s'appuyer sur des emails : quelles exigences sont incluses, quel artefact immuable a été déployé et quelles preuves valident le résultat ?

Requêtes et métriques utiles

• Stories Prêt sans estimation ni critères d'acceptation.
• Pull requests ouvertes depuis plus de deux jours ouvrés sans relecteur.
• Bugs critiques par domaine de processus et environnement.
• Stories terminées sans cas de test lié et passant.
• Éléments de release avec des dépendances non résolues.
• Lead time : Prêt → début dev → acceptation UAT → production.
• Taux de réouverture après UAT — indicateur avancé de critères d'acceptation insuffisants.

Anti-patterns courants

• « Développer l'interface » sans contrat défini, volume attendu ni stratégie de gestion des erreurs.
• Tâches techniques utilisées à la place des critères d'acceptation au niveau story.
• Un bug fermé quand le code est livré mais pas validé dans l'environnement cible.
• Epics permanentes couvrant plusieurs années sans jalon mesurable.
• Tags en texte libre créant de nombreux synonymes (Perf, Performance, perf-problème).
• Une release sans lien vers son package déployable ni checklist de déploiement.

Voir aussi

• Pipeline YAML Azure DevOps pour D365 F&O — le pipeline CI/CD qui exécute ce que le backlog décrit
• Git et X++ — lier les commits et pull requests aux work items
• Déployer un package D365 F&O via LCS — traçabilité de release et gouvernance go/no-go

Références Microsoft Learn

• Configuration du backlog Azure DevOps pour le catalogue de processus métier
• Importer le catalogue de processus métier dans Azure DevOps
• Arbre de livrables et types de work items Dynamics 365
• À propos des work items
• Vue d'ensemble d'Azure Test Plans