Qu’est-ce que L’Histoire de L’Utilisateur et les critères D’acceptation (exemples)

Un Guide parfait pour les critères D’acceptation de L’Histoire de l’utilisateur avec des scénarios réels:

dans l’industrie du Développement Logiciel, le mot « exigence » définit notre objectif, ce dont les clients ont exactement besoin et ce

Qu’il s’agisse d’une société de produits qui fabrique des produits logiciels ou d’une société de services qui offre des services dans divers domaines logiciels, la base principale pour chacun d’entre eux est l’exigence et le succès est défini par la façon dont les exigences sont satisfaites.,

le terme « exigence » a des noms différents dans différentes méthodologies de projet.

en cascade, il est appelé « document D’Exigence/Spécification », en Agile ou SCRUM, il est appelé « Epic », « User Story ».

sous le modèle Waterfall, les documents requis sont d’énormes documents de 200 pages ou plus car l’ensemble du produit est implémenté en une seule phase. Mais ce n’est pas le cas avec Agile/SCRUM car dans ces méthodologies, les exigences sont données pour les petites fonctionnalités ou fonctionnalités car le produit est préparé étape par étape.,

dans cet article, j’ai fait de mon mieux pour partager toutes mes 4 années d’expérience sur le travail avec les histoires D’utilisateurs et leurs critères d’acceptation associés ainsi que des scénarios de la vie réelle faciles et simples pour votre meilleure compréhension.

Permettez-nous de re-visiter les bases en premier.

qu’est Ce qu’un Utilisateur de l’Histoire?

Un article de l’utilisateur est une exigence pour toute fonctionnalité ou caractéristique qui est écrit en une ou deux lignes et max jusqu’à 5 lignes. Une histoire d’utilisateur est généralement l’exigence la plus simple possible et concerne une et une seule fonctionnalité (ou une fonctionnalité).,

Le plus couramment utilisé, le format standard pour un Utilisateur de création d’Histoire, est indiqué ci-dessous:

dans un <rôle de l’utilisateur/client, Je veux < objectif à accomplir> afin que je puisse <raison de l’objectif>.

exemple:

en tant qu’utilisateur WhatsApp, je veux une icône de caméra dans la boîte d’écriture de chat pour capturer et envoyer des photos afin que je puisse cliquer et partager mes photos simultanément avec tous mes amis.

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

un critère d’acceptation est un ensemble de conditions ou de règles commerciales acceptées que la fonctionnalité ou la fonctionnalité doit satisfaire et respecter, afin d’être acceptée par le propriétaire du produit/les parties prenantes.

c’est une partie très importante de l’achèvement de l’histoire de l’utilisateur et il devrait être étudié par le propriétaire du produit et L’Analyste commercial très méticuleusement car manquer un seul critère peut coûter cher. Il s’agit d’une simple liste numérotée ou à puces.

son format est le suivant:

« étant donné une condition préalable lorsque je fais une action, j’attends le résultat”.

Exemple (w.r.,t à l’histoire utilisateur ci-dessus):

• considérons que je discute avec un ami et que je devrais être capable de capturer une image.
• Lorsque je clique sur une image, je devrais être en mesure d’ajouter une légende à l’image avant de l’envoyer.
• S’il y a un problème avec le démarrage de l’appareil photo de mon téléphone, un message d’erreur du type ‘Camera could not be started’. etc., doit être indiquée en conséquence.

Par conséquent, L’histoire utilisateur définit l’exigence pour toute fonctionnalité ou caractéristique tandis que les critères d’acceptation définissent la « définition de fait » pour l’histoire utilisateur ou l’exigence.,

en tant qu’assurance qualité, il est très important de bien comprendre l’histoire de l’utilisateur et ses critères d’acceptation, sans qu’il ne reste un seul doute au « début des tests ». Pour aller de l’avant, comprenons pourquoi il est extrêmement important de creuser « profondément » dans les histoires des utilisateurs et les critères d’acceptation.

approfondir les User stories

pour commencer, comprenons d’abord l’importance d’une étude « approfondie » d’une chose fondamentale et fondamentale, à savoir les User Stories.

Les cas suivants sont mes propres expériences réelles.,

Cas #1:

avant 3 ans, je travaillais sur un projet D’Application Mobile et le produit était une application conçue pour les livreurs.

vous auriez vu un livreur venir chez vous pour la livraison. Et ils ont un téléphone portable sur lequel ils vous demandent de donner votre signature après la livraison. Cette signature se reflète sur le portail des fournisseurs de services de messagerie comme DTDC, FedEx, etc.

imaginons que l’application mobile vient d’être lancée et que leurs portails existent déjà.,

problème: pour un Sprint, votre Product owner a une histoire d’utilisateur pour cette application mobile qui  » en tant qu’administrateur du portail, je devrais être en mesure de voir la signature prise par le livreur au moment de la livraison”. Ici, le portail (application web) est modifié et mis à jour en conséquence pour refléter la signature.

en tant qu’assurance qualité, vous devez vérifier si la signature capturée dans l’application mobile reflète comme prévu dans le portail.,

Si vous regardez cette histoire d’utilisateur, cela semble simple mais il y a une exigence cachée ici que  » pour les livraisons historiques, il n’y avait pas de fonctionnalité de réflexion de signature, alors que devrait-il se passer si les gars du portail voient les livraisons historiques? »Les données historiques devraient-elles être effacées? Devrions-nous autoriser les plantages ou les erreurs pour ces données?

bien sûr, pas du tout, cela devrait être géré gracieusement.,

Solution: lorsque les tables DB respectives sont mises à jour pour ajouter une nouvelle colonne pour L’emplacement de la Signature, les anciennes données doivent avoir une valeur NULL ou 0 qui doit être vérifiée et un message indiquant « aucune signature n’existe » doit être affiché.

cela peut être appelé comme un manque du propriétaire du produit ou de L’Analyste commercial, mais cela doit être fait. Implémenter une fonctionnalité avec succès mais casser quelque chose avec elle n’est pas souhaitable par les clients. Cela doit être fait avec la même histoire utilisateur et dans le même sprint.,

Case #2

il y a 6 ans, je travaillais sur une Application de financement de la planification de la retraite (sans BA) qui était une application mondiale où les gens de la Finance comme CA, les conseillers financiers pouvaient l’utiliser pour différentes devises pour projeter les plans d’investissement, l’épargne, etc., sur une grande période à leurs clients.

problème: le Product Owner vous donne une histoire D’utilisateur qui  » en tant que conseiller, je veux voir le rapport de mon client en fonction des détails financiers fournis”.,

ici, il y avait 2 Exigences cachées et je l’appellerais une histoire incomplète parce que:

a] les rapports devraient prendre en compte le taux de conversion quotidien des devises et non l’historique comme dans le dernier rapport consulté et

b] Si la devise est modifiée après avoir fourni les détails financiers du client, les rapports devraient

Solution: j’ai soulevé cette préoccupation directement avec notre Product Owner et lui ai fait savoir que les deux devaient être faits le plus tôt possible. Il était d’accord avec moi et a créé 2 histoires différentes pour les sprints à venir avec priorité.,

Take Away: ceux-ci ont été pris parce que nous étions tous très bien au courant des produits, leur conception, leur structure, etc. Une telle connaissance ne peut être obtenue qu’en comprenant complètement le produit, en comprenant l’interopérabilité des modules et en étudiant minutieusement l’histoire de l’utilisateur, même s’il s’agit d’un liner 2.

prenez des notes pour faciliter les choses et discutez avec les BA et les développeurs de leur pensée.,

examen approfondi des critères d’acceptation

comprendre les critères d’acceptation et toutes les autres conditions& règles de manière exhaustive est encore plus important que de sous-estimer une histoire d’utilisateur. Parce que si une exigence est incomplète ou vague, elle peut être reprise dans le sprint suivant, mais si un critère d’acceptation est manqué, l’histoire de l’utilisateur elle-même ne peut pas être publiée.

je suppose que nous aurions tous utilisé net banking à un moment donné et la plupart d’entre nous l’utilisent tous les jours et je télécharge beaucoup mes relevés historiques., Si vous l’observez attentivement, certaines options spécifiques sont disponibles pour les télécharger.

Il y a une option pour sélectionner le type de fichier pour télécharger votre instruction. Il y a une option à choisir si vous souhaitez télécharger uniquement les crédits/débit /les deux.

imaginez maintenant que le Product Owner vous donne cette histoire Utilisateur « en tant que client, je souhaite télécharger mon relevé de compte afin de pouvoir voir toutes mes transactions effectuées pour une période spécifique”.,

avec les critères D’acceptation suivants:

• étant donné que je suis sur la page de L’historique de téléchargement de L’instruction, je dois sélectionner la période pour laquelle je souhaite télécharger l’instruction.
• étant donné que je suis sur la page de la déclaration historique de téléchargement, je dois sélectionner le compte pour lequel je souhaite télécharger la déclaration.
• étant donné que je suis sur la page de la déclaration historique de téléchargement, Je ne devrais pas être autorisé à télécharger la déclaration pour une date ultérieure.,
• étant donné que je suis sur la page de la déclaration historique de téléchargement, Je ne devrais pas être autorisé à sélectionner la date  » de  » 10 ans au-delà dans le passé.
• étant donné que je télécharge ma déclaration, je devrais pouvoir afficher le fichier téléchargé.
• étant donné que je suis sur la page de la déclaration historique de téléchargement, je devrais pouvoir télécharger ma déclaration aux formats doc, excel et pdf.

Si vous passez par cette acceptation, il manque 3 choses ici:

• nom et format du nom du fichier qui sera téléchargé.,
• quelles informations (noms de colonnes) doivent être affichées dans le fichier.
• la liste des options pour sélectionner le type de transaction souhaité par le client, c’est-à-dire uniquement les débits ou les crédits, ou les deux.

de tels cas peuvent se produire de temps en temps, mais étudiez toujours bien chaque critère d’acceptation et essayez de le visualiser en référence à l’histoire de l’utilisateur. Plus vous étudiez en profondeur les conditions et les règles métier, plus vos connaissances sur la fonctionnalité seront importantes.

Les bogues trouvés à l’étape initiale ne coûtent rien comparé à ce que cela peut coûter à l’Étape « Test ».,

Importance de trouver des divergences dans les User Story/critères D’acceptation

Il est toujours important de faire une plongée profonde dans les user stories et les critères d’acceptation à un stade précoce avant même que le développement ou les tests ne commencent.

parce que cela implique:

#1) Perte de temps:

Si les divergences ou les erreurs dans l’histoire de l’utilisateur / les critères d’acceptation sont trouvées lorsque le développement est en cours ou que les tests sont en cours, beaucoup de retouches peuvent devoir être effectuées pendant le temps de sprint restant.,

Il n’arrive pas que même si le propriétaire du produit a manqué peu de choses, il déplacera l’histoire de l’utilisateur vers le sprint à venir. 95% de chances sont qu’ils demandent à l’équipe de faire la mise en œuvre nécessaire et de la publier dans le même sprint.

Par conséquent, cela devient un cauchemar pour l’équipe car ils doivent passer du temps supplémentaire, venir le week-end ou travailler tard le soir. Cela peut être évité en étudiant et en discutant le plus tôt possible de l’histoire de l’Utilisateur/des critères d’acceptation.

#2) gaspillage d’Efforts:

Les développeurs et L’assurance qualité doivent revoir à nouveau le code implémenté et les cas de test., La mise à jour, l’ajout et la suppression selon les exigences ne sont pas une tâche facile. Cela devient trop douloureux car il y a déjà une pression pour livrer à temps.

dans une telle situation, il y a des risques d’erreurs dans la phase de développement ou de test. Si vous rencontrez une telle situation, optez pour « Devqa Pairing ». Comme une cerise sur le gâteau, vous ne pouvez pas obtenir une indemnisation pour le travail supplémentaire.

Conclusion

une compréhension approfondie de L’Histoire de l’Utilisateur et des critères d’acceptation ne peut être obtenue qu’en consacrant énormément de temps à son étude.,

Il n’y a pas d’outil ou de cours spécifique disponible sur le marché pour le faire pour vous car il s’agit de la pensée logique, de l’expérience et des connaissances sur le produit.

participer activement à la réunion de pré-plan, parler au BA, étudier par vous-même ne peut que vous aider à y parvenir. Plus vous mettez d’efforts, plus vous apprenez et grandissez.

que ce soit L’assurance qualité ou les développeurs, tout le monde doit être sur la même longueur d’onde sur les histoires des utilisateurs et leurs critères d’acceptation, alors seulement les attentes du client peuvent être réalisées avec succès.,

avez-vous quelque chose de nouveau à partager avec nous vos expériences de travail avec les articles de l’Utilisateur? Veuillez exprimer vos pensées ci-dessous!!