Un guide pour comprendre les critères d'acceptation

Vous avez probablement déjà entendu les termes critères d'acceptation et récits utilisateurs dans le contexte de développement logiciel agile. Pour donner suite à l'article sur les récits utilisateurs, nous nous attaquons maintenant aux critères d’acceptation. Ayant travaillé sur de multiples projets, certains plus complexes que d’autres, pour le compte de nos clients, nous avons pu constater les avantages de critères d'acceptation bien définis. Contribuant à l'amélioration de projets en facilitant la division des tâches, ils sont un atout. Mais ne vous méprenez pas, lorsqu’utilisés incorrectement, cela peut engendrer de la confusion sur les livrables ce qui pourrait avoir un impact négatif sur l'équipe de développement.

Qu’est-ce qu’un critère d'acceptation

Dans le cadre de la méthodologie agile, les critères d’acceptation font référence à un ensemble d’exigences prédéfinies qu’un récit utilisateur doit satisfaire pour être considéré comme complet. Nous ne sommes pas les seuls à l’affirmer. Voici comment certains géants du web définissent les critères d’acceptation.

• Microsoft: « Conditions qu’un produit logiciel doit satisfaire pour être accepté par un utilisateur, un client ou toute autre partie prenante. »
• Google: « Normes ou exigences préétablies qu'un produit ou projet se doit de respecter.»

Pourquoi avez-vous besoin de critères d'acceptation?

Après avoir compris ce que sont les critères d’acceptation, la prochaine question que votre équipe et vous-même devrez, se poser est la suivante: pourquoi en avez-vous besoin? En fait, les critères d’acceptation servent à plusieurs fins pour les équipes transverses, notamment:

• Gérer les attentes
• Définir la portée et réduire l'ambiguïté
• Établir des critères de test pour l’assurance qualité (QA)
• Prévenir les dérapages en milieu de sprint

Qui est responsable de la rédaction des critères d’acceptation?

Maintenant vous voulez mettre en place des critères d’acceptation! Cependant, une question subsiste: qui doit en être le responsable? En fait, pratiquement n’importe qui dans l’équipe peut écrire des critères d’acceptation pour les récits utilisateurs.

En règle générale, ce travail revient au directeur de produit ou au gestionnaire, ou du moins ils sont responsables de faciliter les discussions à ce sujet. Cependant, il est fortement recommandé de faire de la rédaction des critères d’observation une activité de groupe, incluant à la fois les développeurs et les QA.

Quand faut-il rédiger les critères d’acceptation?

De nombreuses équipes choisissent de rédiger les critères d’acceptation pendant un grooming. Au plus tard, les critères doivent être définis avant le début du développement. Il convient également de noter que les écrire trop tôt peut également se retourner contre vous.

Comment formater les critères d’acceptation?

Nous vous recommandons d’utiliser le format étant donné (Given) / lorsque (When) / alors (Then)

• « En tant que (utilisateur), je veux (action prévue), afin que (objectif/résultat de l’action). »
• « Scénario: (expliquer le scénario). Étant donné (la façon dont les choses débutent), lorsque (l'action entreprise), alors (résultat de l’action entreprise). »

Voici un exemple:

En tant que directeur de produit

Je veux noter les idées potentielles

Ainsi, je peux décider de ce que je dois inclure dans ma feuille de route (roadmap).

Scénario: Le directeur de produit ajoute des idées potentielles et classe les idées en fonction des avantages par rapport aux coûts (étant donné) que j’ai ajouté deux idées ou plus et que je les ai notées (lorsque) je clique sur le bouton Classement (alors) les idées sont triées, et les idées les mieux notées se retrouvent en haut.

Principaux défis et meilleures pratiques

Nous espérons que ce guide rapide aura pu dissiper toute incompréhension concernant ce sujet. Nous souhaitons partager quelques réflexions additionnelles.

• Les critères d’acceptation doivent être testables. Cela permettra aux testeurs et aux développeurs de s’assurer que toutes les exigences ont été satisfaites.
• Les critères doivent être clairs et concis. Ne fixez pas de critères trop étroits. Faites en sorte que vos critères soient réalisables. Tout le monde doit pouvoir les comprendre.
• Faites en sorte que vos critères soient réalisables. Tout le monde doit comprendre vos critères d’acceptation.
• Éviter les détails techniques. Les critères d’acceptation doivent fournir la perspective de l’utilisateur.

Merci d’avoir pris le temps de lire cet article de blogue. Faites-nous savoir si vous avez des suggestions concernant les critères d’acceptation et leur mise en œuvre dans les projets de développement logiciel.

Vous avez besoin d’aide pour certains de vos projets? Nous joindre!

Photo: Anton Maksimov juvnsky