Azure Boards

À la fin de ce tutoriel, vous saurez utiliser Azure Boards sur le projet ado-lab : créer des work items (Epic, Feature, User Story, Task, Bug), organiser le backlog produit, planifier un sprint, suivre le board Kanban, et lier le travail au code — sans secrets en clair.

Niveau : Débutant · Temps estimé : 40–55 min · Versions testées : Azure DevOps Services (portail 2026), process Agile, Azure CLI + extension azure-devops · Dernière vérification : 2026-09-10

Prérequis

• Organisation, projets et permissions : projet ado-lab, process Agile, droits Contributors ou Project Administrator
• Hub Démarrer avec Azure DevOps et Entra ID : bases (MFA)
• Navigateur récent ; optionnel : Azure CLI + az extension add --name azure-devops
• Budget : 0 € côté ADO Free tier (pas de ressource Azure dans ce chapitre)

Coût estimé : gratuit pour Boards sur un projet lab. Les minutes de pipeline et labs Bicep en canadacentral viennent plus tard (#6+, #14+).

Ce que nous allons construire

Projet ado-lab (process Agile)
  ├── Area Path / Iteration Path (team defaults)
  ├── Hierarchy : Epic → Feature → User Story → Task
  ├── Product backlog priorisé + Bug
  ├── Sprint 1 (dates + capacité)
  ├── Board Kanban (colonnes New → Active → Resolved → Closed)
  └── (Option) WI créés via az boards

(Schéma à remplacer par une image locale Excalidraw / draw.io, alt : « Azure Boards : hiérarchie work items, backlog, sprint et board Kanban ».)

Ce chapitre ouvre le suivi du travail. Le suivant (#5) versionne le code dans Azure Repos (Git, branches, pull requests) et relie commits / PR aux work items.

Étape 1 — Boards en 3 minutes

Azure Boards centralise le travail agile : work items, backlogs, sprints (iterations) et boards. Avec le process Agile (choix P4) :

États typiques Agile : New → Active → Resolved → Closed (libellés exacts selon le process). Le board visualise ces états en colonnes.

Étape 2 — Team, Area Path et Iteration Path

1. Ouvrez le projet ado-lab → Boards.
2. Project settings → Teams : notez la team par défaut (ado-lab Team).
3. Project settings → Project configuration → Areas / Iterations : – Area Path : découpage produit (ex. ado-lab, éventuellement ado-labFrontend). – Iteration Path : sprints / releases (ex. ado-labSprint 1).

Pour le lab :

1. Créez sous Iterations : Sprint 1 (dates : aujourd’hui → +14 jours).
2. Assignez Sprint 1 à la team : Project settings → Teams → Iterations → Set as default / select.
3. Laissez Area = racine ado-lab sauf si vous isolez volontairement un sous-équipe.

az devops configure --defaults organization=https://dev.azure.com/lab-devopelastichayway project=ado-lab
az boards iteration project list -o table

Étape 3 — Créer la hiérarchie de work items (UI)

1. Boards → Work items → New Work Item → Epic. – Title : Parcours lab Azure DevOps P4 – Save.
2. + New Work Item → Feature (ou depuis l’Epic → Add link → Child) : – Title : Boards et suivi agile – Parent : l’Epic ci‑dessus.
3. Créez une User Story enfant de la Feature : – Title : En tant que lab, je priorise mon backlog sprint – Description : critères d’acceptation en puces (Given/When/Then ou checklist).
4. Sous la Story, ajoutez 2 Tasks : – Créer Sprint 1 et dates – Déplacer la story sur le board
5. Créez un Bug indépendant (ou lié à la Story) : – Title : Board : colonne Resolved manquante en lab – Severity / Repro steps : texte libre (pas de secrets).

Vérifiez la hiérarchie : Boards → Backlogs → basculez la vue Epics / Features / Stories (sélecteur de niveau).

Étape 4 — Product backlog : prioriser

1. Boards → Backlogs → niveau Stories.
2. Glissez les items pour définir l’ordre de priorité (stack rank).
3. Renseignez Effort / Story Points (champ Agile) sur la User Story — ex. 3.
4. Sur les Tasks : Remaining Work (heures), ex. 2 et 1.

Bonnes pratiques lab :

• Une Story = un résultat testable ; évitez les « fourre‑tout ».
• Les Bugs urgents peuvent remonter en haut du backlog ou entrer directement dans le sprint selon votre convention d’équipe.
• N’utilisez pas le backlog comme dump de notes perso : titres actionnables.

# Créer une User Story (CLI) — adapter les titres
az boards work-item create 
  --title "Story CLI : lier WI au commit" 
  --type "User Story" 
  --description "Critères : commit message avec #ID" 
  -o table

Ne passez aucun PAT en argument de commande visible dans un script versionné ; authentifiez via az login / flux navigateur ou variable d’environnement hors dépôt.

Étape 5 — Planifier le sprint

1. Boards → Sprints → sélectionnez Sprint 1.
2. Depuis le backlog (panneau de droite ou vue Planning) : glissez la User Story (+ Tasks) vers Sprint 1.
3. Ouvrez le sprint → Capacity (si affiché) : indiquez capacité journalière fictive (ex. 6 h/jour) pour visualiser la charge.
4. Vérifiez que l’Iteration Path des WI = ado-labSprint 1.

Checklist sprint lab :

• [ ] Dates d’iteration renseignées
• [ ] Au moins une Story + Tasks dans le sprint
• [ ] Effort / Remaining Work non vides (pour lire le burndown plus tard)
• [ ] Assignees : vous‑même (compte MFA)

Étape 6 — Board Kanban : faire avancer le travail

1. Boards → Boards (board de la team) ou Sprints → Taskboard.
2. Sur le board Stories : déplacez la carte New → Active quand vous « démarrez ».
3. Créez une colonne optionnelle (Configure team settings → Columns) seulement si besoin pédagogique — ne surchargez pas le lab.
4. Passez la Story en Resolved puis Closed après validation des critères.
5. Sur le Taskboard sprint : cochez / déplacez les Tasks ; mettez Remaining Work à 0 une fois terminé.

Astuce : double‑cliquez une carte pour éditer Description, Discussion, Links. La Discussion @mentionne des collègues Entra — utile en équipe, inutile pour spammer.

Étape 7 — Lier work items au code (aperçu Repos)

Dès #5 (Azure Repos), le lien WI ↔ Git devient concret :

• Message de commit : Fix board column #123 (remplacez 123 par l’ID du WI).
• Pull request : section Work items → ajoutez l’ID.
• Depuis le WI : onglet Links / Development → commits, branches, PR.

Pour l’instant (sans forcément pousser de code) :

1. Ouvrez votre User Story → Links → Add link → Existing ou notez l’ID (ex. 42) pour le prochain tuto.
2. Gardez cet ID : vous l’utiliserez dans une branche feature/42-backlog-sprint en #5.

# Exemple de message (à utiliser après clone Git #5) — pas de secret
git commit -m "docs: critères acceptation backlog #42"

Étape 8 — Vérification de fin de parcours

1. Epic → Feature → User Story → Tasks visibles dans Backlogs (niveaux).
2. Un Bug existe et est priorisé ou lié.
3. Sprint 1 a des dates et contient au moins une Story.
4. Le board montre le déplacement d’état (Active / Resolved / Closed).
5. Vous connaissez l’ID d’au moins un WI pour le lier au Git (#5).
6. Aucun PAT, mot de passe ou connection string dans Description / Discussion / pièces jointes.

Commande bonus :

az boards query --wiql "SELECT [System.Id], [System.Title], [System.WorkItemType] FROM WorkItems WHERE [System.TeamProject] = @project AND [System.State] <> 'Closed'" -o table

Nettoyage

• Gardez Epic / Feature / Story utiles comme fil rouge de la série.
• Fermez (Closed) les WI de test purement jetables.
• Ne supprimez pas l’iteration Sprint 1 si des WI y sont encore liés — créez Sprint 2 pour la suite si besoin.
• Retirez les pièces jointes contenant des captures avec tokens accidentels.
• Révoquez tout PAT CLI de démo : User settings → Personal access tokens.

Erreurs fréquentes

Quiz (3 questions)

1. Dans le process Agile P4, quel enchaînement hiérarchique est le plus cohérent ? – A. Task → Epic → Bug uniquement
– B. Epic → Feature → User Story → Task
– C. Pipeline → Agent → Artifact

2. À quoi sert principalement l’Iteration Path ? – A. Remplacer Azure Repos
– B. Situer le travail dans un sprint / une période (ex. Sprint 1)
– C. Définir la région canadacentral

3. Comment relier typiquement un commit Git à un work item ? – A. En collant un PAT dans le message de commit
– B. En mentionnant l’ID du WI dans le commit / la PR (ex. #42)
– C. En créant une service connection OIDC depuis Boards

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

• Doc officielle : Azure Boards documentation, About work items, Agile process
• CLI : az boards
• Suite série : Azure Repos Git (#5), Pipelines YAML (#6), sécurité (#19)

Maillage série Azure DevOps (P4)