8 min lecture • Guide 801 of 877
Rédaction des Critères d'Acceptation
Des critères d'acceptation clairs alignent les attentes. GitScrum aide à suivre la complétion des critères et garantit que rien n'est oublié avant qu'une story soit marquée comme terminée.
Bases des Critères d'Acceptation
Objectif
POURQUOI LES CRITÈRES D'ACCEPTATION COMPTENT :
┌─────────────────────────────────────────────────────────────┐
│ │
│ SANS CRITÈRES CLAIRS : │
│ ─────────────────────── │
│ Développeur : "Je pense que c'est terminé" │
│ PO : "Ce n'est pas ce que je voulais dire" │
│ Développeur : "Retour à la case départ..." │
│ → Reprises, frustration, retards │
│ │
│ AVEC CRITÈRES CLAIRS : │
│ ──────────────────── │
│ Développeur : "Tous les critères vérifiés" │
│ PO : "Parfait, on peut livrer" │
│ → Réussite dès le premier essai, tous alignés │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ LES CRITÈRES D'ACCEPTATION DÉFINISSENT : │
│ ─────────────────────────────────────── │
│ │
│ PÉRIMÈTRE : │
│ Ce qui est inclus, ce qui ne l'est pas │
│ "Réinitialisation mot de passe par email uniquement" │
│ │
│ COMPORTEMENT : │
│ Comment la fonctionnalité doit fonctionner │
│ "Affiche erreur si email non trouvé" │
│ │
│ CONDITIONS : │
│ Cas limites et scénarios spéciaux │
│ "Le lien expire après 24 heures" │
│ │
│ RÉSULTATS MESURABLES : │
│ Performance, accessibilité │
│ "La page charge en moins de 2 secondes" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DE BONS CRITÈRES SONT : │
│ ────────────────────── │
│ ✅ Testables (on peut vérifier oui/non) │
│ ✅ Clairs (aucune ambiguïté) │
│ ✅ Concis (pas un roman) │
│ ✅ Indépendants (on peut tester chacun) │
│ ✅ Axés sur le résultat (pas l'implémentation) │
└─────────────────────────────────────────────────────────────┘
Formats de Rédaction
Format Given-When-Then
FORMAT GIVEN-WHEN-THEN (ÉTANT DONNÉ-QUAND-ALORS) :
┌─────────────────────────────────────────────────────────────┐
│ │
│ STRUCTURE : │
│ ────────── │
│ ÉTANT DONNÉ [précondition/contexte] │
│ QUAND [action/déclencheur] │
│ ALORS [résultat attendu] │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLE : Réinitialisation du Mot de Passe │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ STORY : En tant qu'utilisateur, je veux réinitialiser ││
│ │ mon mot de passe ││
│ │ ││
│ │ CRITÈRES D'ACCEPTATION : ││
│ │ ││
│ │ 1. ÉTANT DONNÉ que je suis sur la page de connexion ││
│ │ QUAND je clique sur "Mot de passe oublié" ││
│ │ ALORS je vois le formulaire de réinitialisation ││
│ │ ││
│ │ 2. ÉTANT DONNÉ que j'ai saisi un email enregistré ││
│ │ QUAND je soumets la demande ││
│ │ ALORS je reçois un email en moins d'une minute ││
│ │ ││
│ │ 3. ÉTANT DONNÉ que j'ai saisi un email non enregistré ││
│ │ QUAND je soumets la demande ││
│ │ ALORS je vois "Aucun compte avec cet email" ││
│ │ ││
│ │ 4. ÉTANT DONNÉ que je clique sur le lien dans l'email ││
│ │ QUAND je définis un nouveau mot de passe ││
│ │ ALORS je peux me connecter avec le nouveau MDP ││
│ │ ││
│ │ 5. ÉTANT DONNÉ que le lien a plus de 24 heures ││
│ │ QUAND je clique sur le lien ││
│ │ ALORS je vois "Lien expiré, demandez un nouveau" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AVANTAGES : │
│ • Structuré et cohérent │
│ • Facile à convertir en tests automatisés │
│ • Préconditions claires │
└─────────────────────────────────────────────────────────────┘
Format Liste de Contrôle
FORMAT CHECKLIST :
┌─────────────────────────────────────────────────────────────┐
│ │
│ STRUCTURE : │
│ ────────── │
│ □ Critère 1 - description claire et testable │
│ □ Critère 2 - un seul aspect par critère │
│ □ Critère 3 - vérifiable oui/non │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EXEMPLE : Formulaire de Contact │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ □ L'utilisateur peut saisir nom, email et message ││
│ │ □ Le champ email valide le format de l'adresse ││
│ │ □ Le message affiche erreur si champs vides ││
│ │ □ La soumission envoie email à support@entreprise.fr ││
│ │ □ L'utilisateur voit confirmation après envoi ││
│ │ □ Le formulaire fonctionne sur mobile et desktop ││
│ │ □ Le temps de soumission < 3 secondes ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AVANTAGES : │
│ • Simple et direct │
│ • Facile à parcourir │
│ • Idéal pour le suivi de progression │
└─────────────────────────────────────────────────────────────┘
Erreurs Courantes à Éviter
Anti-Patterns des Critères
PIÈGES À ÉVITER :
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ TROP VAGUE : │
│ "Le système doit être rapide" │
│ "L'interface doit être intuitive" │
│ │
│ ✅ CORRIGÉ : │
│ "La page charge en moins de 2 secondes" │
│ "L'utilisateur trouve le bouton en < 5 secondes" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ TROP TECHNIQUE : │
│ "Utiliser React avec hooks useState" │
│ "Implémenter avec un pattern singleton" │
│ │
│ ✅ CORRIGÉ : │
│ "Le formulaire conserve les données entre pages" │
│ "Une seule instance de configuration active" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ NON TESTABLE : │
│ "L'utilisateur doit être satisfait" │
│ "Le design doit être moderne" │
│ │
│ ✅ CORRIGÉ : │
│ "Score NPS de l'enquête post-utilisation ≥ 8" │
│ "Design conforme au guide de style v2.0" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ❌ PLUSIEURS CRITÈRES EN UN : │
│ "L'utilisateur peut s'inscrire, se connecter et gérer │
│ son profil" │
│ │
│ ✅ CORRIGÉ : │
│ "L'utilisateur peut créer un compte" │
│ "L'utilisateur peut se connecter avec ses identifiants" │
│ "L'utilisateur peut modifier son profil" │
└─────────────────────────────────────────────────────────────┘
Intégration avec GitScrum
Suivi des Critères
CRITÈRES D'ACCEPTATION DANS GITSCRUM :
┌─────────────────────────────────────────────────────────────┐
│ │
│ DANS LA DESCRIPTION DE TÂCHE : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 📋 TASK-123 : Implémenter recherche utilisateur ││
│ │ ││
│ │ Description : ││
│ │ Ajouter une fonction de recherche dans le dashboard ││
│ │ ││
│ │ Critères d'Acceptation : ││
│ │ □ La recherche filtre par nom et email ││
│ │ □ Les résultats apparaissent en temps réel ││
│ │ □ Message "Aucun résultat" si vide ││
│ │ □ Maximum 20 résultats par page ││
│ │ □ Fonctionne avec accents et majuscules ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AVANTAGES GITSCRUM : │
│ • Critères liés directement à la tâche │
│ • Historique des modifications des critères │
│ • Visibilité pour toute l'équipe │
│ • Intégration avec Definition of Done │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Processus de Rédaction
WORKFLOW RECOMMANDÉ :
┌─────────────────────────────────────────────────────────────┐
│ │
│ 1. ÉBAUCHE INITIALE (Product Owner) │
│ • Écrire les critères basés sur les besoins │
│ • Identifier les cas principaux │
│ │
│ 2. RAFFINEMENT (Équipe) │
│ • Discussion pendant le grooming │
│ • Ajout des cas limites │
│ • Clarification des ambiguïtés │
│ │
│ 3. VALIDATION (Dev + QA) │
│ • Vérifier que chaque critère est testable │
│ • Identifier les critères manquants │
│ • Confirmer la faisabilité │
│ │
│ 4. DOCUMENTATION (Tous) │
│ • Mettre à jour dans GitScrum │
│ • Lier aux tests automatisés si possible │
│ • Versionner les changements │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RÈGLE D'OR : │
│ "Si vous ne pouvez pas le tester, ce n'est pas │
│ un bon critère d'acceptation" │
└─────────────────────────────────────────────────────────────┘