Comment Écrire des Critères d’Acceptation: Exemples et bonnes Pratiques

Ici, à Mobindustry, nous fonctionnons avec une approche Agile. Cela signifie que nous utilisons des composants agiles tels que les user stories et les critères d’acceptation. Les équipes et les organisations hautement performantes ont ces composants dans leurs backlogs de produits, et elles savent comment les créer et les utiliser efficacement.

Si votre backlog produit manque d’histoires d’utilisateurs et de critères d’acceptation — ou s’ils ne sont pas clairement définis — vous risquez que vos attentes ne convergent pas avec la réalité., Les User stories et les critères d’acceptation sont chargés de représenter comment l’utilisateur final utilisera votre application et comment votre équipe de développement doit exécuter chaque tâche de développement. Lorsque nous commençons à travailler sur un nouveau produit, Notre équipe collabore avec le client pour définir des user stories.

Une histoire d’utilisateur est une description courte et simple d’une fonctionnalité de produit du point de vue d’une personne qui souhaite utiliser cette fonctionnalité. Les User stories sont utilisées pour définir le backlog produit dans un workflow de développement Agile.,

le Backlog produit est essentiellement une collection d’histoires d’utilisateurs qui informe la spécification fonctionnelle et le développement de fonctionnalités pour un produit ou un service particulier. Les User stories se composent de trois parties: un personnage de l’utilisateur pour lequel l’histoire est écrite, une description de la fonctionnalité dont l’Utilisateur a besoin et une explication du besoin que la fonctionnalité satisfait.

Voici comment écrire une histoire utilisateur:

en tant qu’utilisateur, je veux une (fonctionnalité) pour pouvoir (satisfaire un besoin).

voyons à quoi pourrait ressembler une histoire utilisateur., Nous prendrons Airbnb comme exemple. Imaginons à quoi pourrait ressembler une histoire d’utilisateur typique pour un produit comme Airbnb.

« en tant qu’utilisateur, je souhaite rechercher une destination afin de pouvoir réserver un hébergement dans une ville étrangère. »

définition des critères d’acceptation

maintenant, nous devons nous assurer que les User stories sont complétées correctement et répondent aux demandes du client.

les critères d’acceptation sont les conditions qu’un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou, dans le cas d’une fonctionnalité au niveau du système, le système consommateur.,

les critères D’acceptation sont un ensemble d’instructions, chacune avec un résultat de réussite / échec clair, qui peuvent être mesurées et spécifier des exigences fonctionnelles et non fonctionnelles.

L’écriture de critères d’acceptation est importante non seulement pour établir ce que le client attend du produit, mais aussi pour le processus de développement. Naturellement, différentes personnes voient le même problème sous différents angles. Des critères d’acceptation bien définis offrent une vue uniforme des fonctionnalités que vous prévoyez d’implémenter.,

Tout le monde devrait pouvoir accéder à un tableau Scrum, récupérer un élément de backlog Produit, lire les critères d’acceptation et voir clairement tout ce qui doit être terminé pour que cet élément particulier soit déplacé vers la colonne terminé. Les critères d’acceptation vous indiquent ce qui doit être fait pour qu’une partie particulière d’un produit soit finie.

Pourquoi avons-nous besoin de critères d’acceptation?,

• définition des limites. Les critères d’acceptation aident l’équipe de développement à définir les limites d’une histoire utilisateur. Ils servent comme une forme de confirmation que l’application fonctionne comme prévu, ce qui signifie que l’utilisateur de l’histoire est complète.
• le consensus. Les critères d’acceptation permettent à l’équipe de développement d’être sur la même longueur d’onde que le client. Ils informent l’équipe de développement des conditions à remplir et s’assurent que le client sait à quoi s’attendre de l’application.
• rationalisation des tests d’acceptation., Les critères d’acceptation sont à la base des tests d’acceptation de l’histoire de l’utilisateur. Chaque critère d’acceptation doit être testé indépendamment et avoir des scénarios clairs de succès ou d’échec.
• de Planification et d’estimation. Les critères d’acceptation vous permettent de répartir les User stories entre les tâches afin qu’elles soient correctement évaluées et planifiées.
• décrivant des scénarios négatifs. Les critères d’acceptation peuvent exiger que le système identifie un mot de passe faible et empêche un utilisateur de continuer, par exemple., La saisie d’un format de mot de passe incorrect est un exemple de scénario négatif dans lequel un utilisateur saisit des données incorrectes ou se comporte de manière inattendue. Les critères d’acceptation identifient ces scénarios et expliquent comment le système devrait y répondre.

Qui écrit les critères d’acceptation?,

La Rédaction de critères d’acceptation aide à établir une compréhension commune entre le product owner et l’équipe de développement en ce qui concerne la résolution du problème d’un client ou la création de capacités de produit. Depuis l’acceptation des critères concernent le client et l’équipe, ils doivent être rédigés soit par le client ou un membre de l’équipe.

chez Mobindustry, nos business analysts rédigent tous les critères d’acceptation des user stories. Les analystes commerciaux comprennent les besoins du client et ce que les développeurs doivent savoir pour répondre aux exigences du projet.,

les critères d’acceptation sont documentés et confirmés avant le début du projet, car l’équipe et le client doivent s’entendre sur les résultats qui répondront aux exigences du client.

des Exemples d’articles de l’utilisateur avec les critères d’acceptation

Maintenant que vous avez une compréhension claire de ce que l’utilisateur les histoires et les critères d’acceptation sont, nous allons jeter un oeil à quelques exemples.,

exemple 1

User story: en tant qu’utilisateur, je veux pouvoir m’inscrire au service afin de pouvoir commencer à faire des achats en ligne.

critères d’Acceptation:

• les Utilisateurs ne peuvent soumettre un formulaire en complétant tous les champs requis.
• L’e-mail de l’utilisateur fournit ne doit pas être fourni par un service de messagerie gratuit.
• Les soumissions provenant du même IP ne peuvent être faites que trois fois en 30 minutes.
• Les utilisateurs reçoivent des e-mails de notification après s’être enregistrés avec succès.,

exemple 2

User story: en tant qu’utilisateur, je peux accéder à une notification sur mon appareil immédiatement après l’avoir reçue.

critères d’acceptation:

• glisser / taper une notification amène l’utilisateur directement au message.
• afficher la conversation — si le nouveau message était une réponse, alors il est affiché au-dessus de l’original.
• Le nombre de messages est mis à jour.
• Un message est marqué lu après son affichage.

7 conseils pour écrire de bons critères d’acceptation

les critères d’acceptation ne sont pas faciles à écrire., Malgré le format simple, écrire le texte est un défi. Voici sept conseils pour vous aider à éviter les erreurs courantes lors de la rédaction des critères d’acceptation ou pour revoir les critères écrits par un membre de votre équipe.

• documenter les critères avant le début du processus de développement. De cette façon, l’équipe est plus susceptible d’attraper tous les besoins du client à l’avance. Au départ, il suffit de définir des critères pour un petit nombre d’histoires d’utilisateurs pour compléter les backlogs pour deux sprints. Les critères d’acceptation documentés sont ensuite utilisés par les développeurs pour planifier le processus technique.,
• ne pas rendre les critères d’acceptation trop étroits. Des critères d’acceptation trop spécifiques laissent peu de marge de manœuvre aux développeurs. Pour éviter cela, n’oubliez pas que les critères d’acceptation doivent être une expression d’intention et non une décision finale. De plus, les critères d’acceptation étroits peuvent ne pas prendre en compte toutes les actions de l’utilisateur.
• Gardez vos critères réalisables. Les critères d’acceptation effectifs définissent une quantité minimale raisonnable de fonctionnalités que vous pouvez fournir. Mais si vous continuez à décrire tous les petits détails, il y a un risque que votre équipe soit bloquée sur des centaines de petites tâches.,
• évitez les critères d’acceptation trop larges. Les critères d’acceptation larges rendent une histoire d’utilisateur vague. Des critères d’acceptation efficaces doivent décrire la portée des travaux afin que les développeurs puissent planifier et estimer correctement leurs efforts.
• évitez les détails techniques. Les critères d’acceptation doivent être rédigés dans un langage simple. Vos parties prenantes et vos gestionnaires n’ont peut-être pas d’antécédents techniques, donc l’utilisation d’un langage simple rendra les critères compréhensibles pour tout le monde.
• Parvenir à un consensus., Le même problème peut être résolu de différentes manières par les membres de l’équipe et les parties prenantes en fonction de leurs points de vue. Assurez-vous de communiquer vos critères d’acceptation aux parties prenantes et aux membres de l’équipe et de parvenir à un accord mutuel.
• écrire des critères d’acceptation testables. Cela donnera aux testeurs la possibilité de s’assurer que toutes les exigences sont remplies et permettra aux développeurs de savoir si l’histoire de l’utilisateur est complète.,

Comment écrire des critères d’acceptation

Voici cinq règles générales qui vous aideront à résoudre les problèmes avec la formulation de critères d’acceptation. Ces règles vous permettront de gagner un temps précieux et d’établir une compréhension entre le product owner et l’équipe de développement.

Règle #1: Évitez « Non”

« Non” signifie « en aucun cas”, et donc aucun temps ne sera suffisant pour vérifier la conformité à une telle condition., Si vous réécrivez l’exigence sans utiliser « non », elle sera plus claire et, surtout, vérifiable.

exemple:

User Story

non: en tant qu’Utilisateur, Je ne veux pas avoir à entrer mon mot de passe chaque fois que j’accède à mon compte.
faire: en tant qu’utilisateur, je veux que mon mot de passe soit mémorisé et automatiquement rempli afin que je puisse accéder à mon compte sans entrer à nouveau mon mot de passe.

critères d’acceptation

non: le système ne doit pas échouer.
Do: le système devrait avoir une disponibilité d’au moins 90%.,

Exception

Vous pouvez utiliser « non” dans les critères d’acceptation pour introduire une objection logique, telle que « le formulaire de connexion ne doit pas être rouge.” Dans la plupart des cas, cela s’appliquera aux exigences non fonctionnelles. Dans cet exemple, nous formulons une contrainte qui peut être facilement vérifiée si la gamme de nuances de rouge est clairement définie (par exemple, spécifiée au format RVB).,

Règle n ° 2: Utilisation de la voix active

Active voice est lorsque le sujet dans une phrase est l’interprète de l’action. Si l’entité responsable de l’exécution de l’action n’est pas clairement indiquée, il ne sera pas clair qui ou quoi doit effectuer l’action, et il vous sera plus difficile de vérifier si une exigence est remplie.,

exemple:

User story

non: en tant qu’acheteur en ligne, je veux que les filtres soient appliqués afin que je puisse trouver ce que je veux.
faire: en tant qu’utilisateur, je veux appliquer des filtres de recherche afin que je puisse trouver des éléments.

critères d’acceptation

Non: l’identité du client doit être confirmée. (On ne sait pas qui ou ce qui est responsable de la confirmation de l’identité du client.)
Do: Le Accounting_System doit confirmer la Customer_Indentity. (Notez que les définitions des termes « Accounting_System” et « Customer_Indentity” doivent être ajoutées au glossaire.,)

Règle #3: évitez d’utiliser des pronoms (en particulier ceux non définis)

utilisez des noms à la place des pronoms lorsque vous faites référence à des éléments référencés dans d’autres exigences. Les pronoms doivent être évités car ils peuvent introduire une ambiguïté.,

Ceci est particulièrement important lorsque les critères d’acceptation sont stockés dans des outils de gestion des exigences (Tels que Jira) sous forme d’instructions distinctes qui ne sont pas nécessairement organisées. Utilisez toujours des noms au lieu des pronoms et vous éviterez ce problème.

exemple:

User story

non: en tant que membre du site, je souhaite partager des informations sur moi-même afin que les autres puissent les voir.
faire: en tant que membre du site, je veux ajouter une description de profil afin que les autres puissent en apprendre davantage sur moi.

critères d’acceptation

non: le contrôleur doit envoyer au conducteur l’itinéraire de la journée., Il doit être livré au moins 8 heures avant le quart de travail.
Do: le contrôleur doit envoyer le Driver_Itinerary pour la journée au conducteur au moins 8 heures avant le Driver_Shift.

Règle #4: Éviter les conjonctions

les Conjonctions sont des mots et des phrases telles que « et”, « ou”, « mais” et « ainsi que” qui combinent des phrases simples en plus complexes., Leur utilisation dans les exigences est généralement un signe qu’une exigence peut être divisée en plusieurs exigences distinctes.

exemple:

User story

non: en tant que concepteur D’interface utilisateur, je veux créer et afficher un problème afin de savoir quoi tester.
faire: en tant que concepteur D’interface utilisateur, je veux créer un problème afin de savoir quoi tester. / En tant que concepteur D’interface utilisateur, je souhaite afficher un problème afin de savoir quoi tester.

critères d’acceptation

Non: L’utilisateur doit être approuvé ou non.
Do: Le Security_System doit catégoriser chaque utilisateur comme approuvé ou Not_Trusted.,

Exception

« Et”, « ou” et « non” peut être utilisé pour décrire les conditions logiques et d’ajouter des qualificatifs.

règle #5: éviter les absolus inaccessibles

un absolu (tel que la disponibilité à 100%) est inaccessible. Pensez à la façon de vérifier l’indicateur: il sera possible de prouver que le niveau de disponibilité du système est égal à 100%?, Et même si un tel système pouvait être créé, pouvez-vous vous le permettre?

évitez les mots « tout”, « toujours” et « jamais”, car la vérification de telles exigences absolues nécessitera un nombre infini de tests.

exemple:

User story

non: en tant que voyageur, je veux connaître ma position précise mise à jour en temps réel afin de ne pas me perdre. (« Temps réel » peut être interprété de différentes manières. Par exemple, il peut être vu comme un absolu (l’absence de tout retard), qui ne peut être obtenue et qui n’est pas vérifiable.,)
faire: en tant que voyageur, je veux connaître mon emplacement précis, mis à jour chaque seconde, afin que je ne me perde pas.

critères d’acceptation

non: le système doit avoir une disponibilité à 100%. (100% est un absolu qui ne peut être atteint et ne peut pas être vérifiée.)
Faire: Le système doit avoir une disponibilité d’au moins 98%.

résumé rapide des critères d’acceptation

Nous espérons que cet article a fait la lumière sur le monde des critères d’acceptation et des user stories., Voici les principaux points à retenir:

• Les critères d’acceptation sont les conditions qu’un produit logiciel doit remplir pour être accepté par un utilisateur, un client ou, dans le cas d’une fonctionnalité au niveau du système, le système consommateur.
• Les critères d’acceptation doivent être documentés et remplis avant le début d’un projet, car l’équipe et le client doivent s’entendre sur les résultats qui répondront aux exigences du client.
• rappelez-vous que les critères d’acceptation doivent être une expression d’intention et non une décision finale.
• Les critères D’acceptation effectifs définissent une quantité minimale raisonnable de fonctionnalités.,
• de bons critères d’acceptation doivent décrire la portée des travaux afin que les développeurs puissent planifier et estimer correctement leurs efforts.
• Les critères d’acceptation doivent être rédigés dans un langage simple.
• assurez-vous de communiquer vos critères d’acceptation aux parties prenantes et aux membres de l’équipe et de parvenir à un accord mutuel.
• lorsque vous écrivez des critères d’acceptation, évitez d’utiliser « non”, des conjonctions et des absolus inaccessibles. Formulez des phrases en utilisant la voix active.,

Si vous souhaitez créer des critères d’acceptation et des user stories pour votre application mobile ou si vous avez des questions à ce sujet, contactez Mobindustry pour une consultation gratuite.