par Courtney

22 septembre 2010 (Dernière mise à jour le 17 avril 2019)

Tags:Agile

Les critères d’acceptation définissent ce qui doit être fait pour compléter une User Story agile. Ils spécifient les limites de l’histoire et sont utilisés pour confirmer quand il fonctionne comme prévu. Voici un guide d’introduction à la rédaction et à l’utilisation des critères d’acceptation.,

liste de critères d’Acceptation

Découvrez les 13 caractéristiques de efficace les critères d’acceptation

assurez-vous que vos critères d’acceptation fournir des articles de l’utilisateur, et un produit précieux.

la semaine dernière, j’ai décrit les os de l’histoire de l’utilisateur dans le premier article de notre série d’introduction sur les histoires de l’utilisateur. En bref, une histoire d’utilisateur est une description d’un objectif qu’une personne devrait être en mesure d’atteindre lors de l’utilisation de votre site Web/application/Logiciel. Ces histoires sont souvent écrites dans ce format: comme je veux pour cela .,

Par exemple: en tant que membre Flickr, je veux pouvoir attribuer différents niveaux de confidentialité à mes photos afin de pouvoir contrôler avec qui je partage quelles photos.

Ce post ajoute un peu de chair à l’idée de user stories, sous la forme de critères d’acceptation.

Où sont les détails?

à première vue, il peut sembler que les User stories ne fournissent pas assez d’informations pour faire passer une équipe d’une idée à un produit. C’est là que les critères d’acceptation venir. Mais d’abord, voici quelques arrière-plan., En 2001, Ron Jeffries a écrit sur les trois C de l’histoire utilisateur:

  • Les histoires de cartes sont traditionnellement écrites sur des cartes de notes, et ces cartes peuvent être annotées avec des détails supplémentaires
  • Conversation – les détails derrière l’histoire sortent grâce à des conversations avec le propriétaire du produit
  • Les tests de Confirmation – acceptation confirment

dans un projet suivant un processus Agile, l’équipe de développement discute des user stories lors de réunions avec le Product Owner., (Le Product Owner est la personne qui représente le client pour la chose que vous développez et qui écrit les user stories). Le propriétaire du produit présente d’abord l’histoire de l’utilisateur, puis la conversation commence.

Par exemple: en tant que participant à la conférence, je veux pouvoir m’inscrire en ligne, afin de pouvoir m’inscrire rapidement et réduire la paperasse.

dans ce cas, les questions pour le propriétaire du produit peuvent inclure:

  • Quelles informations doivent être collectées pour permettre à un utilisateur de s’inscrire?
  • Où ces informations doivent être collectées et livrées?,
  • l’utilisateur peut-il payer en ligne dans le cadre du processus d’inscription?
  • l’utilisateur à envoyer un accusé de réception?

– Vous saisir les enjeux et les idées soulevées dans cette séance de questions réponses dans l’histoire de l’critères d’acceptation.

Exemple de critères d’acceptation

les critères d’Acceptation définir les limites d’un article de l’utilisateur, et sont utilisés pour confirmer lorsqu’une histoire est terminée et fonctionnent comme prévu.

Donc, pour l’exemple ci-dessus, les critères d’acceptation peuvent inclure:

  • Un utilisateur ne peut pas envoyer un formulaire sans remplir tous les champs obligatoires.,
  • Les informations du formulaire sont stockées dans la base de données des enregistrements.
  • La Protection contre le spam fonctionne.
  • les Utilisateurs peuvent payer par carte de crédit.
  • un e-mail d’accusé de réception est envoyé à l’utilisateur après avoir soumis le formulaire.

comme vous pouvez le voir, vous écrivez des critères d’acceptation dans un langage simple, tout comme l’histoire de l’utilisateur. Lorsque l’équipe de développement a fini de travailler sur l’histoire de l’utilisateur, elle démontre la fonctionnalité au propriétaire du produit. Ce faisant, ils montrent comment ils ont satisfait à chacun des critères.,

autres critères d’acceptation des exemples

Pour plus d’exemples, vous pouvez télécharger notre article de l’utilisateur exemples PDF.

critères d’acceptation et définition de done

Les gens sont parfois incertains de la différence entre les critères d’acceptation et la définition de done. La principale différence est que la définition de done s’applique à tout votre travail, alors que les critères d’acceptation sont spécifiques aux histoires individuelles.

en Savoir plus sur la différence entre la définition de fait et les critères d’acceptation.,

avantages de l’utilisation des critères d’acceptation

inclure les critères d’acceptation dans vos user stories présente plusieurs avantages. Ils:

  • demandez à l’équipe de réfléchir à la façon dont une fonctionnalité ou un élément de fonctionnalité fonctionnera du point de vue de l’utilisateur
  • supprimer l’ambiguïté des exigences
  • formez les tests qui confirmeront qu’une fonctionnalité ou un élément de fonctionnalité fonctionne et est complet.,

Introduction aux histoires d’utilisateur — série de blog

  1. guide du Débutant à l’utilisateur d’histoires
  2. Ajout de critères d’acceptation des articles de l’utilisateur
  3. histoires d’Utilisateur et le processus de développement
  4. de cas d’Utilisation vs histoires d’utilisateur
  5. Amener les parties prenantes à travers des articles de l’utilisateur
  6. Création de l’utilisateur des histoires avec l’histoire de la cartographie
  7. Amélioration de l’utilisateur des histoires avec une définition de prêt
  8. article de l’Utilisateur exemples

lecture

je vous recommande vraiment ce post par Sandy Mamoli., (Sandy est un coach Agile Wellington et scrum master, avec qui nous travaillons sur Digital New Zealand). Après cela, vous voudrez peut-être consulter cette présentation sur les histoires d’utilisateurs efficaces de Mike Cohn. Si vous travaillez dans Scrum, cet article montre comment ajouter des critères d’acceptation lorsque vous créez des user stories dans Scrum.

Démarrage d’un nouveau projet? Consultez notre kit de Lancement de projet Agile pour en savoir plus sur la cartographie des histoires d’utilisateurs et la hiérarchisation des histoires d’utilisateurs lors de la découverte du projet.