Réponse.

Historiquement, la formulation des critères d'acceptation est restée entre les mains des testeurs ou de l'équipe de développement. Cependant, avec le passage à des processus agiles évolutifs (SAFe, LeSS, Scrum-of-Scrums), en l'absence de scénarios de test formalisés, des risques d'incongruité dans les attentes entre les différents participants d'un grand projet apparaissent : les affaires, les tests, les développeurs et le support peuvent interpréter différemment l'achèvement d'une tâche.

Le problème dans les projets multi-équipes ou distribués : différentes zones de responsabilité, différents processus et outils, différences linguistiques ou culturelles entre les équipes. Même des exigences détaillées peuvent devenir des critères d'acceptation conflictuels ou incomplets, entraînant des bugs et le mécontentement des affaires.

La solution réside dans l'implication précoce de l'analyste système dans la formulation des critères d'acceptation, la connexion des exigences entre les équipes, une formalisation stricte et une discussion collective des scénarios et des cas limites lors d'une démonstration commune ou d'un atelier de groupe.

Caractéristiques clés :

Les critères d'acceptation doivent être clairs, mesurables, reproductibles et validables.
Accord préalable des critères (check-list manuelle + exemples de données/comportements attendus).
Traçabilité mutuelle : les critères doivent toujours faire référence aux exigences, cas et histoires d'utilisateur, afin de pouvoir suivre chaque objectif.

Questions pièges.

Peut-on laisser entièrement la formulation des critères d'acceptation aux testeurs ?

Non, l'analyste doit participer. Il possède la pleine compréhension du contexte commercial et connaît toutes les nuances des exigences.

Faut-il couvrir les critères d'acceptation uniquement avec des scénarios positifs ?

Non, il est impératif d'ajouter des cas négatifs et des cas limites, sinon des lacunes dans l'implémentation et le test apparaîtront.

Peut-on définir les critères d'acceptation oralement dans des projets multi-équipes ?

Non, les accords verbaux ne supportent pas la charge de l'interaction distribuée et mènent à des conflits. Les critères sont acceptés uniquement de manière formalisée (par exemple, sous forme de Gherkin/BDD ou de check-lists structurées).

Erreurs typiques et anti-patterns

Formulation des critères d'acceptation "par défaut", sans lien avec les exigences et les spécifications.
Absence de retour d'information des équipes finales.
Ignorer les scénarios d'interaction entre les composants de différentes équipes, en particulier lors des intégrations.

Exemple de la vie réelle

Cas négatif : Dans une application bancaire, les critères d'acceptation pour la fonctionnalité de transfert ont été approuvés uniquement avec une équipe. La seconde équipe a réalisé ses interfaces internes sans tenir compte du premier ensemble de critères, ce qui a conduit à des incohérences dans les formats d'identifiant de transaction.

Avantages :

Début rapide de l'implémentation.

Inconvénients :

Nécessité de refactoriser l'API.
Perte de temps pour résoudre les conflits.

Cas positif : L'analyste a organisé une série d'ateliers avec des scénarios visuels et des détails pour toutes les équipes impliquées, avec une formalisation écrite obligatoire des critères d'acceptation dans Confluence/JIRA avec une traçabilité bidirectionnelle vers les exigences.