Écrire des stories efficaces dans Agile Development 2.0
Les stories bien écrites sont faciles à comprendre par tous les développeurs et membres de l'équipe, tels que le personnel en charge des tests ou de la documentation.
Les stories permettent au groupe d'affectation d'estimer avec précision l'effort nécessaire pour implémenter le travail en fonction de la définition du fini. La définition du fini est le critère de sortie accepté par le groupe, qui détermine quand une story est terminée.
- Description : la description de la story se rapporte à un profil d'utilisateur, tel que l'administrateur, et décrit une valeur commerciale ou aborde une dette technique.
- Critères d'acceptation : les critères d'acceptation de la story sont mesurables et testables.
Descriptions des stories
- le rôle du profil d'utilisateur dans le système ;
- le besoin exprimé par le profil de l'utilisateur ;
- l'avantage pour toutes les personnes concernées, telles que les développeurs, les utilisateurs et autres.
En règle générale, la description d’une story est exprimée comme suit : « En tant que <rôle>, je veux < objectif ou besoin >, de sorte que < bénéfice> ».
- Exemples de bonnes descriptions de stories
- Description : en tant que développeur, je souhaite publier l'état actuel de mon application dans un ensemble de mises à jour, de sorte de pouvoir le déployer vers un système de production.
- Description : en tant que client, je souhaite recevoir des notifications lorsque des commentaires sont saisis pour un incident, de sorte d'être tenu informé de son état.
- Description : en tant que gestionnaire du changement, je souhaite activer l'évaluation du risque pour tout changement donné en établissant une liste de questions avec des réponses à choix multiple.
- Exemples de mauvaises descriptions de stories
Description : des notifications sont envoyées lorsque des incidents sont créés.
Cette description est mauvaise pour les raisons suivantes :- Elle n'indique pas qui ou ce qui envoie les notifications, ni la forme que celles-ci prennent, par exemple l'e-mail.
- Elle n'inclut aucune information sur les avantages, ce qui fait que la valeur commerciale n'est pas claire.
Elle pourrait être mieux écrite comme suit :
Description : en tant que concepteur d'incident, je souhaite que des notifications par e-mail soient envoyées à un ensemble prédéfini de parties intéressées lorsque je crée un incident, de sorte qu'elles puissent être informées lorsqu'un incident les affectant est créé.
Critères d'acceptation des stories
Les critères d'acceptation définissent les limites d'une story d'utilisateur, et servent à confirmer quand le logiciel fonctionne comme prévu, ce qui signifie que la story est terminée. Les critères d'acceptation font partie intégrante de la « Définition du fini » d'une story.
- Bons critères d'acceptation
De bons critères d'acceptation doivent inclure les éléments suivants, le cas échéant :
- Utilisabilité : assurez-vous d'inclure des mesures d'utilisabilité dans les critères d'acceptation. Indiquez comment répondre à la question : est-ce facile à utiliser ? La clé consiste à identifier les bonnes mesures et à s'assurer que chacune d'elles est quantifiable.
- Fonctionnalité : identifiez les tâches utilisateur, les processus business ou les fonctions spécifiques devant être en place à la fin du projet. Une exigence fonctionnelle peut être : l'utilisateur peut choisir entre plusieurs tailles.
- Gestion des erreurs : énumérez les cas d'erreur et comment chacun doit être traité. Par exemple, si un utilisateur effectue les étapes dans le mauvais ordre, comment le logiciel le gérera-t-il ?
- Performances : testez les performances du système du point de vue d'un utilisateur individuel. Par exemple : l'interface utilisateur est-elle réactive ?
- Tests de contrainte : décrivez comment le système répond lorsqu'il est soumis à la contrainte d'un trop grand nombre d'utilisateurs, de transactions ou de requêtes. Les critères d'acceptation doivent définir des seuils acceptables pour les tests de contrainte. Par exemple : le système répond-il sous un seuil de 250 millisecondes lorsque 100 utilisateurs soumettent des requêtes simultanément ?
- Exemple de bons critères d'acceptation
Description : en tant que client, je souhaite commander et payer le livre via un formulaire Web sécurisé, de sorte que mes informations de carte de crédit soient sécurisées.
Critères d'acceptation :- Tous les champs obligatoires doivent être remplis avant qu'un client puisse soumettre un formulaire.
- Les informations issues du formulaire sont stockées dans la base de données des commandes des clients.
- Le paiement peut être effectué par carte de crédit Amex, Master Card ou Visa.
- Le système doit calculer et appliquer précisément la taxe sur la vente.
- Le système doit calculer et appliquer précisément les frais d'expédition.
- Le client doit être en mesure de vérifier l'exactitude de la commande.
- Un e-mail de confirmation est envoyé au client qui soumet le formulaire.
- La protection contre les courriers indésirables fonctionne.
- Exemple de mauvais critères d'acceptation
Description : en tant que client, je souhaite recevoir des notifications lorsqu'un incident est commenté, de sorte d'être tenu informé de son état.
Critères d'acceptation : les personnes appropriées sont notifiées lorsque des incidents sont commentés.
Ces critères d'acceptation sont mauvais car ils ne donnent pas assez de détails en vue des tests. Par exemple, l'identité des personnes appropriées n'est pas claire.
Les critères d'acceptation pourraient être mieux écrits comme suit :- En tant qu'utilisateur ESS, créez un incident.
- Sélectionnez Notifier les parties intéressées.
- Enregistrez l'incident.
- Connectez-vous en tant que partie intéressée.
- Vérifiez que vous avez reçu un e-mail pour l'incident porté au journal.