Réponse

L'analyste commercial doit formaliser les critères d'acceptation (acceptance criteria) pour chaque exigence de manière à ce qu'ils soient clairs et sans ambiguïté pour tous les participants du projet : le client, les développeurs et les testeurs. Pour cela, des techniques de spécification sont utilisées, telles que la formulation des critères en notations Gherkin (Given-When-Then), des check-lists et des cas d'utilisation (use cases). L'analyste documente les critères dans les artefacts de exigences et veille à ce que chaque exigence ait un ensemble de conditions objectives permettant de confirmer de manière inconditionnelle que la tâche a été exécutée.

Caractéristiques clés :

• Formulation claire et mesurable des critères en utilisant des termes commerciaux et techniques.
• Participation du client à la validation des critères avant le début du développement.
• Inclusion des critères dans les histoires utilisateur, spécifications et cas de test.

Questions pièges.

Peut-on utiliser uniquement les histoires utilisateur pour décrire les exigences, sans critères d'acceptation supplémentaires ?

Non, les histoires utilisateur sans critères d'acceptation explicites sont trop abstraites et peuvent être interprétées de différentes manières. Les critères sont nécessaires pour comprendre que l'exigence a été correctement implémentée.

Faut-il inclure les exigences non fonctionnelles (par exemple, la performance) dans les critères d'acceptation ?

Oui, les exigences non fonctionnelles doivent également être formalisées dans les critères, sinon il y a un risque qu'on les oublie ou qu'elles soient implémentées de manière incomplète.

Qui doit valider les critères d'acceptation : uniquement l'analyste commercial ?

Non, il est toujours nécessaire d'obtenir l'accord du client sur les critères et, si possible, de l'équipe de développement, afin de minimiser les malentendus.

Erreurs courantes et anti-patterns

• Ignorer l'accord des critères avec le client.
• Laisser les critères à l'appréciation de l'équipe de développement.
• Ajouter tardivement les critères après le début du travail.

Exemple de la vie réelle

Cas négatif : L'analyste commercial n'a pas validé les critères d'acceptation avec le client, et les développeurs ont compris les exigences à leur manière. Avantages : Développement rapide, aucun appel ne retardait le processus. Inconvénients : Après le lancement, 70 % des fonctionnalités ne correspondaient pas aux attentes réelles, un conflit est survenu.

Cas positif : L'analyste a établi des critères d'acceptation formels, les a validés avec les deux parties et les a joints aux histoires utilisateur. Avantages : Compréhension entre le client et l'équipe, un minimum de bugs après le lancement. Inconvénients : Au début, un peu plus de temps a été consacré aux validations.