Dans le paysage du développement agile, la clarté est la monnaie du succès. Lorsqu’une équipe commence un travail sur une nouvelle fonctionnalité, la fondation réside dans l’histoire utilisateur. Toutefois, une histoire utilisateur n’est qu’un simple indicateur de conversation. Pour transformer cette conversation en un produit fonctionnel, deux éléments essentiels sont requis : les critères d’acceptation et la définition de terminé. Ces concepts agissent comme des repères qui garantissent la qualité, l’alignement et la prévisibilité.
De nombreuses équipes peinent à distinguer ces deux concepts. Parfois, elles les traitent comme identiques, ce qui entraîne de la confusion lors des tests ou du déploiement. À d’autres moments, elles les négligent complètement, ce qui entraîne une extension du périmètre ou des fonctionnalités incomplètes qui parviennent en production. Ce guide explore les mécanismes, le but et la mise en œuvre des critères d’acceptation et de la définition de terminé afin d’aider votre équipe à livrer de la valeur de manière cohérente.
Qu’est-ce qu’une histoire utilisateur ? 📝
Avant de détailler les composants d’une histoire, il est essentiel de rappeler ce qu’est réellement une histoire utilisateur. Dans les cadres agiles, une histoire utilisateur est une brève description simple d’une fonctionnalité, formulée du point de vue de la personne qui souhaite la nouvelle capacité. Elle suit généralement le format suivant :
- En tant que [type d’utilisateur],
- Je veux [un objectif],
- Afin que [un avantage].
Ce format se concentre sur le valeurfournie à l’utilisateur, plutôt que sur la mise en œuvre technique. Toutefois, ce format seul ne suffit pas à guider le développement. Il ne précise pas les limites du travail ni les normes requises pour la finalisation. C’est là que les critères d’acceptation et la définition de terminé interviennent.
Critères d’acceptation (CA) : les conditions de finalisation ✅
Les critères d’acceptation sont un ensemble de conditions qu’une histoire utilisateur doit satisfaire pour être considérée comme complète du point de vue du propriétaire produit. Ils définissent les limites de l’histoire et fournissent une compréhension claire de ce que doit être le produit final.
Le but des critères d’acceptation
Les critères d’acceptation remplissent plusieurs fonctions au cours du cycle de développement :
- Clarification : Ils éliminent l’ambiguïté. Si un développeur demande : « Le bouton doit-il devenir vert ou bleu au survol ? », les CA doivent répondre à cette question.
- Tests : Ils agissent comme des cas de test. Les ingénieurs QA utilisent ces conditions pour valider la fonctionnalité.
- Accord : Ils garantissent que le propriétaire produit et l’équipe de développement sont d’accord sur ce qui constitue « terminé » pour cette histoire spécifique.
Caractéristiques des bons critères d’acceptation
Les critères d’acceptation efficaces sont précis, mesurables et sans ambiguïté. Évitez les termes vagues comme « convivial » ou « rapide » sans définir de métriques. Précisez plutôt des comportements exacts.
- Atomiques : Chaque critère doit traiter d’un seul besoin.
- Testables : Il doit être possible de vérifier le critère en obtenant un résultat « succès » ou « échec ».
- Indépendant :Les critères ne doivent pas dépendre d’histoires externes pour être validés.
- Relevant :Concentrez-vous sur la valeur pour l’utilisateur, et non sur la structure interne du code.
Exemples de critères d’acceptation
Pensez à une histoire concernant l’ajout d’une fonctionnalité « Mot de passe oublié ». Voici à quoi pourraient ressembler les critères d’acceptation :
- Étant donné que l’utilisateur est sur la page de connexion,
Lorsqu’ils cliquent sur le lien « Mot de passe oublié »,
Alors ils sont redirigés vers la page de récupération du mot de passe. - Étant donné que l’utilisateur saisit un e-mail valide,
Lorsqu’ils soumettent le formulaire,
Alors un message de confirmation est affiché. - Étant donné que l’utilisateur saisit un e-mail non valide,
Lorsqu’ils soumettent le formulaire,
Alors un message d’erreur indique que le format de l’e-mail est incorrect.
Ces exemples suivent la structure Étant donné/Quand/Alors structure (souvent associée à la syntaxe Gherkin), qui favorise la clarté et s’aligne avec les cadres de test automatisé.
Définition de terminé (DoD) : la porte de qualité 🚧
Alors que les critères d’acceptation sont spécifiques à une seule histoire utilisateur, la Définition de terminé est une norme globale appliquée àtous les travaux au sein d’un sprint ou d’une version. Elle représente la liste de contrôle des exigences qui doivent être remplies pour qu’une avancée de travail soit considérée comme potentiellement livrable.
Le but de la Définition de terminé
La DoD agit comme une porte de qualité. Elle garantit que la dette technique ne s’accumule pas et que le produit reste toujours dans un état livrable. Si une histoire remplit ses critères d’acceptation mais ne satisfait pas la Définition de terminé, elle ne peut pas être marquée comme terminée.
Les éléments courants trouvés dans une Définition de terminé incluent :
- Revue de code :Tout le code doit être revu par au moins un pair.
- Tests unitaires :Les tests automatisés doivent passer avec une couverture à 100 % pour la nouvelle logique.
- Documentation : La documentation de l’API ou les guides utilisateurs sont mis à jour.
- Performances : La fonctionnalité respecte les exigences minimales de temps de chargement.
- Accessibilité : La fonctionnalité respecte les lignes directrices WCAG.
- Sécurité : Aucune vulnérabilité connue n’est introduite.
Pourquoi le DoD compte
Sans une Définition de Fait, les équipes tombent souvent dans le piège du « techniquement terminé mais pas réellement prêt ». Une fonctionnalité peut fonctionner comme prévu selon les Critères d’Acceptation, mais elle pourrait avoir endommagé une autre partie du système, manquer de documentation adéquate ou introduire des risques de sécurité. Le DoD prévient cela en imposant une base de qualité sur l’ensemble du backlog.
Critères d’Acceptation vs. Définition de Fait : Les principales différences 🆚
La confusion survient souvent parce que les deux concepts traitent de la « complétude ». Toutefois, leur portée et leur responsabilité diffèrent considérablement. Comprendre cette distinction évite les malentendus entre les développeurs, les testeurs et les product owners.
| Fonctionnalité | Critères d’Acceptation | Définition de Fait |
|---|---|---|
| Portée | Spécifique à une seule Story Utilisateur | Globale pour toute l’équipe ou le projet |
| Responsabilité | Product Owner et Équipe de Développement | Toute l’équipe de développement |
| Flexibilité | Modifications par histoire selon les exigences | Stable, bien qu’elle puisse être mise à jour au fil du temps |
| Objectif | Définit les exigences fonctionnelles | Définit les normes de qualité et non fonctionnelles |
| Vérification | Tests fonctionnels par rapport aux besoins des utilisateurs | Vérification technique et processus |
Imaginez les Critères d’Acceptation comme la destination d’un voyage spécifique, tandis que la Définition de Fait est la vérification de sécurité requise pour chaque véhicule sur la route.
Comment rédiger des critères d’acceptation efficaces 📝
Rédiger les critères d’acceptation est une démarche collaborative. Il ne doit pas être fait en isolation par le propriétaire produit. La meilleure pratique implique le concept des « Trois Amis », où le propriétaire produit, un développeur et un testeur collaborent tôt dans le processus de révision.
Étape 1 : Identifier l’objectif de l’utilisateur
Commencez par reformuler la proposition de valeur. Quel problème l’utilisateur résout-il ? Cela garantit que les critères restent centrés sur l’expérience utilisateur plutôt que sur les détails techniques.
Étape 2 : Définir des scénarios positifs et négatifs
Ne rédigez pas uniquement le parcours idéal. Pensez à ce qui se produit lorsque les choses tournent mal.
- Parcours idéal : L’utilisateur effectue l’action exactement comme prévu.
- Cas limites : Que se passe-t-il avec des caractères spéciaux, des données manquantes ou des connexions lentes ?
- Parcours négatif : Comment le système gère-t-il les entrées non valides de manière élégante ?
Étape 3 : Utiliser un langage clair
Évitez le jargon autant que possible. Si des termes techniques sont nécessaires, assurez-vous qu’ils sont définis. Utilisez le style actif. Par exemple, « Le système doit valider… » est moins clair que « L’utilisateur reçoit un message d’erreur… ».
Étape 4 : Prioriser
Si une histoire est importante, divisez-la. Les critères d’acceptation doivent être réalisables dans le sprint. Si les critères impliquent un travail qui ne peut pas être terminé dans le sprint, l’histoire doit être divisée.
Comment établir une définition du fait robuste 🛠️
La définition du fait n’est pas un document statique. Elle évolue avec la maturité de l’équipe et les changements technologiques. Elle doit être visible de tous, souvent affichée sur un tableau physique ou numérique.
Étape 1 : Consulter l’équipe
La DoD appartient à l’équipe qui réalise le travail. Les développeurs, les testeurs et les concepteurs doivent contribuer à la liste. Si un développeur ajoute une exigence, il est plus susceptible de s’y tenir.
Étape 2 : Catégoriser les exigences
Regroupez les éléments de la DoD en catégories logiques pour rendre la liste de contrôle gérable.
- Qualité du code : Le linting a réussi, aucune alerte, la revue par les pairs est terminée.
- Tests : Des tests unitaires ont été écrits, les tests d’intégration ont réussi, les tests manuels ont été validés.
- Déploiement : Déployé en pré-production, les tests de fumée ont réussi.
- Documentation : Le fichier Readme a été mis à jour, les documents de l’API sont synchronisés.
Étape 3 : Faites-en une fin obligatoire
Si une histoire ne répond pas au CDA, elle ne peut pas être clôturée. Cela exige de la discipline. Il est tentant de dire : « Nous corrigerons la documentation plus tard », mais cela crée une dette technique. L’histoire reste dans « En cours » jusqu’à ce que le CDA soit respecté.
Étape 4 : Revue et amélioration
Pendant les rétrospectives, demandez à l’équipe : « Le CDA a-t-il détecté des problèmes ? » ou « Y a-t-il une exigence que nous oublions constamment ? » Mettez à jour le CDA en fonction de ces retours.
Erreurs courantes à éviter ⚠️
Même les équipes expérimentées font des erreurs lors de la mise en œuvre de ces pratiques. Être conscient des pièges courants peut épargner beaucoup de temps et de frustration.
1. Critères d’acceptation vagues
Écrire des critères comme « Le système doit être sécurisé » est inutile. Ce n’est pas testable. Précisez plutôt : « Le système doit exiger une authentification à deux facteurs pour les comptes d’administrateur. »
2. Le CDA comme simple vérification de cases
Si l’équipe coche la case du CDA sans effectivement accomplir le travail (par exemple, en sautant la revue de code), le CDA perd tout sens. Le CDA doit être respecté, pas simplement lu.
3. Surcharger le CDA
Un CDA comprenant 50 éléments devient écrasant. Concentrez-vous sur les seuils essentiels de qualité. Si une exigence est rarement violée, elle pourrait être une recommandation plutôt qu’un élément obligatoire du CDA.
4. Ignorer les exigences non fonctionnelles
Les équipes se concentrent souvent fortement sur les AC (fonctionnels) et négligent le CDA (non fonctionnels). La performance, la sécurité et l’accessibilité font partie du CDA, pas des AC. Les négliger conduit à des fonctionnalités qui fonctionnent mais sont lentes ou dangereuses.
5. Créer un CDA sans l’adhésion de l’équipe
Si le Product Owner établit le CDA sans l’avis des développeurs, l’équipe peut y résister. Le CDA doit être un accord partagé.
Intégration dans le flux de travail 🔄
Les critères d’acceptation et la définition de fin doivent être intégrés à chaque étape du cycle de développement, et non seulement à la fin.
Phase de révision
Pendant la révision du backlog, le Product Owner rédige les critères d’acceptation. L’équipe les examine pour s’assurer qu’ils sont testables et réalisables. Les questions sont posées et répondues ici, et non pendant le sprint.
Planification du sprint
Lors de l’engagement sur les histoires, l’équipe vérifie que les critères d’acceptation sont clairs. S’ils ne le sont pas, l’histoire n’est pas prête pour le sprint.
Phase de développement
Les développeurs écrivent du code pour répondre aux AC. En même temps, ils s’assurent de respecter le CDA (par exemple, en écrivant des tests, en demandant des revues).
Phase de test
Les ingénieurs QA vérifient les AC par rapport à la fonctionnalité construite. Ils vérifient également le CDA (par exemple, en consultant les rapports de couverture de code, des analyses d’accessibilité).
Revue et clôture
Avant de déplacer une histoire vers « Terminé », l’équipe confirme que les AC et le CDA sont tous deux satisfaits. Sinon, elle retourne dans la file d’attente.
Mesurer le succès 📊
Comment savoir si vos critères d’acceptation et votre définition de fin fonctionnent ? Suivez les indicateurs au fil du temps.
- Taux de défaut :Les bogues trouvés en production diminuent-ils ? Un bon critère de fin de développement devrait détecter les problèmes avant le lancement.
- Taux de rejet :Les histoires sont-elles fréquemment rejetées par le Product Owner ? Cela indique une définition insuffisante des critères d’acceptation.
- Stabilité de la vitesse :La vitesse de l’équipe reste-t-elle constante ? Si les histoires sont fréquemment renvoyées pour des éléments manquants du critère de fin de développement, la vitesse va fluctuer.
- Fréquence du déploiement :Un critère de fin de développement clair permet-il des déploiements plus fluides et plus fréquents ?
Questions fréquemment posées ❓
Voici les questions courantes posées par les équipes lors de la mise en œuvre de ces normes.
Q : Les critères d’acceptation peuvent-ils évoluer pendant une itération ?
R : Idéalement, non. Si les critères d’acceptation évoluent de manière significative, cela peut indiquer que l’histoire n’a pas été suffisamment comprise lors de la phase de préparation. Des clarifications mineures sont acceptables, mais des changements majeurs de portée doivent entraîner une nouvelle histoire ou un ajustement de la portée de l’itération.
Q : Chaque histoire doit-elle avoir une définition de fin unique ?
R : Non. Le critère de fin de développement est global. Toutefois, certaines histoires techniques peuvent avoir des exigences supplémentaires ajoutées à la liste de contrôle pour cet élément spécifique, mais le critère de fin de base s’applique à toutes les histoires.
Q : Que faire si l’équipe ne s’accorde pas sur le critère de fin de développement ?
R : Facilitez une discussion. L’objectif est d’atteindre un consensus. Si un développeur insiste sur une exigence que le testeur conteste, discutez du risque. Si le risque est faible, supprimez-la. Si le risque est élevé, gardez-la.
Q : À quel point les critères d’acceptation doivent-ils être détaillés ?
R : Suffisamment détaillés pour être testables. Si un ingénieur de test peut rédiger directement un cas de test à partir des critères d’acceptation, ils sont suffisamment détaillés. S’ils doivent poser des questions, il faut ajouter plus de détails.
Q : Le test automatisé peut-il remplacer le test manuel dans le critère de fin de développement ?
R : Cela dépend. Pour la logique critique, oui. Pour l’expérience utilisateur ou les éléments visuels, une validation manuelle peut encore être nécessaire. Le critère de fin de développement doit refléter la meilleure pratique en matière d’assurance qualité.
Pensées finales sur la qualité et l’alignement 🌟
Mettre en œuvre les critères d’acceptation et le critère de fin de développement ne s’agit pas de bureaucratie ; c’est une question de respect. C’est le respect de l’utilisateur qui attend une fonctionnalité opérationnelle, le respect du développeur qui souhaite des exigences claires, et le respect du product owner qui a besoin de confiance dans la livraison.
Lorsque ces deux concepts sont utilisés correctement, ils créent un langage commun pour l’équipe. Ils réduisent la nécessité de réunions constantes de clarification. Ils empêchent l’accumulation de dette technique. Et surtout, ils garantissent que chaque histoire achevée ajoute une véritable valeur au produit.
Commencez petit. Définissez un critère de fin de développement basique. Rédigez des critères d’acceptation clairs pour votre prochaine histoire. Révisez-les lors de votre prochaine rétrospective. Au fil du temps, ces pratiques deviendront naturelles, ancrées dans la culture de votre équipe. Le résultat est un flux constant de logiciels de haute qualité qui répondent aux besoins des utilisateurs.