Réponse directe
De bons critères de recette indiquent contexte, acteur, comportement observable et résultat attendu pour le parcours principal et les alternatives importantes. Ils couvrent saisie invalide, permissions, changements de données, panne de dépendance et frontières pertinentes d’accessibilité, sécurité, performance et exploitation. Chaque critère possède méthode de vérification, environnement et décideur. Séparez la recette propre à une story de la définition de fini commune au produit, puis appliquez les deux avant acceptation. La forme Étant donné, Quand, Alors peut clarifier les exemples sans être obligatoire. Réussir la recette prouve un comportement convenu, pas adoption, revenu ou adéquation marché.
Commencer tant que l’ambiguïté peut changer le plan
Rédigez pendant l’affinage du brief, avant l’engagement d’implémentation. Impliquez produit, design, ingénierie, qualité et les spécialistes nécessaires. Demandez ce que l’utilisateur accomplit, quel état doit précéder et quelle observation prouve le succès. Sans accord sur le résultat, l’élément n’est pas prêt pour une estimation ou réalisation fiable.
Arrêtez et découpez les critères qui combinent plusieurs résultats, utilisent des adjectifs vagues ou imposent une technique sans raison. Intuitif, rapide, sécurisé ou fluide exigent des frontières observables. Deux personnes autorisées doivent pouvoir conclure pareil, tout en laissant les choix d’implémentation aux responsables de la solution.
Inventorier comportement, données et échecs
Pour chaque parcours, listez acteur et rôle, état initial, action, résultat interface, mutation de données, messages, effets de bord et événements d’audit ou de mesure pertinents. Ajoutez états vide, chargement, invalide, doublon, non autorisé, expiré, hors-ligne et dépendance en panne. Incluez locale, appareil et technologies d’assistance requises.
Séparez règles métier et détail visuel, puis identifiez la source de vérité de chaque règle. Consignez dépendances et comportement face à une réponse tardive, partielle ou rejetée. Ne copiez pas de données sensibles dans les exemples. Utilisez des fixtures représentatives et nommez qui approuve une exception lorsqu’un jugement ne peut être entièrement automatisé.
Écrire des exemples et attribuer la vérification
Utilisez une phrase claire ou Étant donné, Quand, Alors si cette structure réduit les interprétations. Un exemple exerce une règle significative. Ajoutez cas négatifs et limites au lieu de répéter le seul chemin heureux. Liez critère, story, design, contrat API ou politique pour résoudre les conflits depuis un propriétaire explicite.
Pour chaque critère, nommez niveau et preuve: test unitaire ou intégration, parcours navigateur ou appareil, revue accessibilité, sécurité, mesure de performance ou approbation manuelle. Précisez environnement et données. Tout n’a pas besoin d’automatisation, mais un contrôle manuel exige étapes, résultat et trace.
Accepter avec les portes de qualité communes
Examinez critères spécifiques et définition de fini, qui peut inclure revue, tests, accessibilité, sécurité, déploiement, supervision et documentation. Consignez version candidate et critères échoués ou dérogés. Une dérogation nomme responsable, justification, impact, échéance ou revue et mesure de réduction. Ne transformez pas silencieusement un échec en limitation connue.
Définissez la recette par des preuves observables, par exemple un parcours testé, un build approuvé, des contrôles reproductibles, un runbook d’incident et une transmission vérifiée. Rien de cela ne prouve rétention, revenu ou adéquation marché. Séparez preuve de livraison, approbation d’un fournisseur externe et résultat business.
Préserver les critères jusqu’à la transmission
Gardez contrôles exécutables, scripts manuels, fixtures, rapports et décisions dans les systèmes possédés. Mettez-les à jour si le produit change et conservez l’histoire utile. Lors de la transmission, une autre personne exécute les parcours critiques et retrouve les règles sources. La recette devient connaissance opératoire réutilisable plutôt que visa unique.
Gardez dépôts, domaines, stores, analytics, organisations cloud et identifiants de production sous une propriété explicite de l’entreprise. Accordez des accès limités et révocables, puis répétez la transmission avant la dernière facture. L’étiquette du prestataire compte moins que la capacité d’une autre personne autorisée à inspecter, déployer, reprendre et poursuivre le produit.
Critères de décision
Posez les mêmes questions à chaque option avant de choisir.
| Option | Utile lorsque | À vérifier avant de choisir |
|---|---|---|
| Utiliser des critères courts en langage clair | Le comportement est direct et une phrase observable crée une compréhension commune. | Inclure contexte, action, résultat et états négatifs importants sans jargon technique. |
| Utiliser Étant donné, Quand, Alors | Les règles varient selon état ou acteur et des scénarios concrets réduisent les écarts. | Focaliser chaque scénario sur une règle sans transformer la syntaxe en script UI exhaustif. |
| Ajouter une porte spécialiste | Sécurité, accessibilité, données, performance ou contrainte réglementée exige une revue qualifiée. | Nommer standard, relecteur, preuve et périmètre, séparés d’une approbation externe. |
| Renvoyer pour clarification | Comportement, autorité, source de données ou vérification reste ambigu. | Résoudre avant implémentation plutôt que demander à la réalisation de deviner. |
Questions fréquentes
Quand écrire les critères de recette ?
Avant l’engagement de réalisation, puis les affiner avec les preuves. Un changement reste possible mais son effet doit être explicite.
Sont-ils identiques à la définition de fini ?
Non. Les critères portent sur un comportement précis. La définition de fini décrit un niveau de qualité partagé pour l’incrément. Les deux peuvent s’appliquer.
Qui approuve les critères ?
Nommez le décideur produit avec ingénierie et spécialistes pertinents. L’implémenteur ne devrait pas définir et approuver seul un comportement important.
Leur réussite garantit-elle le succès ?
Non. Elle prouve un comportement dans des limites testées. Adoption, rétention, revenu, approbation externe et marché exigent d’autres preuves.
Sources primaires et preuves
- À propos d’IVRYN 2026-08-15
- Travaux et preuves IVRYN 2026-08-15
- Méthodologie produit IVRYN 2026-08-15
- Guide GOV.UK de la phase de découverte 2026-08-15
- Guide GOV.UK de la phase alpha 2026-08-15
- Cadre NIST de développement logiciel sécurisé 2026-08-15
- Référence Gherkin de Cucumber 2026-08-15
- Guide Scrum officiel 2026-08-15