Que sont les critères d'acceptation ? Écrire des conditions sur lesquelles tout le monde s'accorde

Les critères d’acceptation sont les conditions qu’un travail doit remplir avant que quiconque le déclare terminé. Ils sont écrits avant que le travail commence, par la personne qui le demande, et validés avec celles qui vont le construire et le tester.

Leur rôle est d’avancer une dispute dans le temps. Sans eux, “est-ce que c’est fini ?” se règle après le travail, par celui qui y croit le plus fort. Avec eux, c’était réglé avant, par des gens qui étaient calmes.

Ce qu’ils ne sont pas

Pas une description de la fonctionnalité. “L’utilisateur peut filtrer le rapport” est un résumé. Un critère dit ce qui doit être vrai : quels filtres, ce qui se passe quand aucun ne correspond, dans quel état on se retrouve après un rechargement.

Pas une maquette. Les critères décrivent des résultats, pas des mises en page. “Une liste déroulante en haut à droite” décide de la solution et la retire à celui qui est le mieux placé pour la choisir.

Pas des cas de test. Un critère est une condition ; un cas de test est une procédure pour en vérifier une. Plusieurs cas de test pendent en général à un seul critère, et ils sont écrits plus tard, par quelqu’un qui n’est pas forcément la même personne.

Les deux formats utilisés

Une liste de vérification est le plus simple des deux, et il suffit pour la plupart des travaux.

Terminé quand :
- Une personne connectée ne voit que ses propres commandes
- Une commande sans ligne apparaît quand même, avec un total de 0,00
- La liste se charge en moins de deux secondes pour un compte de 10 000 commandes
- Le tri par date tient d'une page de résultats à l'autre

Étant donné, quand, alors est plus formel, et son cérémonial supplémentaire se justifie quand le comportement dépend de l’état.

Étant donné une cliente dont la carte a expiré
Quand elle envoie le formulaire de paiement
Alors le paiement est refusé
Et les champs de la carte gardent les valeurs qu'elle a saisies
Et le message dit quel champ corriger

La valeur est dans l’étant donné. La plupart des malentendus vivent dans l’état de départ - un compte d’essai, un jeton expiré, une liste vide - plutôt que dans l’action, et le format oblige quelqu’un à le nommer.

Aucun des deux n’est meilleur. Prenez la liste de vérification par défaut et allez chercher étant-donné-quand-alors là où la même action doit se comporter différemment selon la situation.

Ce qui sépare un bon critère d’un mauvais

Le test, c’est de savoir si deux personnes pourraient être en désaccord sur le fait qu’il est rempli.

Faible

La page devrait se charger rapidement et afficher des résultats pertinents

Mieux

La première page de résultats apparaît en moins de deux secondes pour un compte de 10 000 commandes, et n'affiche que les commandes de ce compte

Quatre habitudes produisent la plupart des mauvais :

• Des adjectifs au lieu de seuils. Rapide, intuitif, robuste, convivial. Aucun ne peut être vérifié ; on peut discuter de tous.
• Seulement le chemin heureux. Des critères qui décrivent ce qui se passe quand tout marche laissent chaque échec au jugement de quelqu’un à quatre heures de l’après-midi le jour de la mise en production.
• Des solutions. “Ajouter une fenêtre de confirmation” au lieu de “l’utilisateur ne peut pas supprimer une facture sans confirmer”.
• Tout d’un coup. Une story avec dix-neuf critères, ce sont plusieurs stories, et elle restera à moitié faite pendant quinze jours.

Qui les écrit, et quand

Celui qui demande le travail les rédige, et ils sont validés avant que quiconque commence. C’est la partie que les équipes sautent, et la sauter est ce qui transforme une tâche de deux jours en une semaine de clarifications.

Ce n’est pas forcément lourd. Un développeur qui lit le brouillon et demande “qu’est-ce qui doit se passer si elle n’a pas encore de commande ?”, c’est tout le processus qui fonctionne : la question est bon marché maintenant et chère une fois que le code existe.

Écrivez-les là où vit le travail, pas dans un message de chat. Des critères qui n’existent que dans le souvenir qu’une personne a d’une réunion produisent exactement la dispute qu’ils devaient empêcher.

Là où ils finissent par compter

Deux endroits, et ce sont eux qui justifient l’effort.

L’acceptation. Les gens qui font la recette utilisateur ont besoin de quelque chose contre quoi accepter. Sans critères, cela devient un sondage d’opinions sur un logiciel que quelqu’un a déjà payé.

Le tri des bugs. La dispute la plus fastidieuse du logiciel est de savoir si quelque chose est un défaut ou une demande d’évolution, et elle se tranche par ce qui avait été convenu. Un défaut est un comportement qui contredit un critère ; tout le reste est une demande nouvelle, aussi raisonnable soit-elle. Les équipes sans critères écrits ont cette dispute une fois par livraison, indéfiniment.

C’est aussi pour cela que le signalement d’un défaut devrait dire ce qui était attendu autant que ce qui s’est passé - c’est la même phrase que le critère qu’il contredit.

Le guide du rapport de bug couvre le reste de ce dont ce signalement a besoin, et son modèle a une ligne pour le comportement attendu.

La version courte

Des conditions, écrites avant le travail, validées par ceux qui l’ont demandé et ceux qui vont le construire, assez précises pour que deux personnes ne puissent pas être en désaccord sur le fait qu’elles sont remplies. Une liste de vérification suffit en général ; étant-donné-quand-alors quand l’état de départ décide du résultat. Couvrez ce qui se passe quand les choses échouent, pas seulement quand elles marchent.