Écrire des histoires efficaces dans Développement agile 2.0
Les stories bien écrites sont faciles à comprendre pour tous les développeurs et les membres de l’équipe, comme les tests ou la documentation.
Les stories permettent au groupe d’affectation d’estimer avec précision l’effort requis pour implémenter le travail conformément à la définition de terminé. La définition de terminé correspond aux critères de sortie convenus par le groupe, qui déterminent quand une story est terminée.
- Description : la description de la story se rapporte à un profil d’utilisateur, tel qu’administrateur, et décrit une valeur commerciale ou traite une dette technique.
- Critères d’acceptation : les critères d’acceptation des stories sont mesurables et testables.
Descriptions des stories
- Rôle du profil de l’utilisateur dans le système
- Le besoin exprimé par le profil de l’utilisateur
- le bénéfice pour toutes les personnes concernées comme 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>, afin que < avantage > ».
- Exemples de description correcte de story
- Description : en tant que développeur, je souhaite publier l’état actuel de mon application dans un ensemble de mises à jour, afin de pouvoir la déployer sur un système de production.
- Description : en tant que client, je souhaite recevoir des notifications lorsque des commentaires sont saisis pour un incident afin d’être informé de l’état.
- Description : en tant que gestionnaire des changements, je souhaite activer l’évaluation des risques pour un changement donné en établissant une liste de questions avec des réponses à choix multiples.
- Exemple de description de story incorrecte
Description : des notifications sont envoyées lorsque des incidents sont créés.
Cette description est médiocre car :- La description n’indique pas qui ou quoi envoie les notifications, ni la forme que prend la notification, comme l’e-mail.
- La description ne comprend aucune information sur les avantages, l’intérêt commercial n’est donc pas clair.
Il pourrait être mieux écrit comme suit :
Description : en tant que créateur 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, afin qu’elles puissent être informées de la création d’un incident les concernant.
Critères d’acceptation des stories
Les critères d’acceptation définissent les limites d’une user story et servent à confirmer que le logiciel fonctionne comme prévu, ce qui signifie que la story est terminée. Les critères d’acceptation sont une partie essentielle de la « Définition de Terminé » pour une story.
- Critères d’acceptation pertinents
Les bons critères d’acceptation doivent inclure, le cas échéant :
- Facilité d’utilisation : Assurez-vous d’inclure des mesures de convivialité dans les critères d’acceptation. Indiquez comment répondre à la question : Est-il facile à utiliser ? La clé est d’identifier les bonnes mesures et de s’assurer que chacune est quantifiable.
- Fonctionnalité : Identifiez les tâches utilisateur, les processus métier ou les fonctions spécifiques qui doivent être en place à la fin du projet. Une exigence fonctionnelle peut être : L’utilisateur peut choisir parmi plusieurs tailles.
- Gestion des erreurs : énumérez les tickets d’erreur et la façon dont chacun doit être géré. Par exemple, si un utilisateur effectue les étapes dans le mauvais ordre, comment le logiciel le gérera-t-il ?
- Performance : 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 résistance : décrivez comment le système réagit lorsqu’il est soumis à un stress en raison d’un 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 résistance. Par exemple : le système répond-il dans un seuil de 250 millisecondes lorsque 100 utilisateurs soumettent des requêtes simultanément ?
- Exemple de critères d’acceptation pertinents
Description : En tant que client, je souhaite commander et payer le livre via un formulaire Web sécurisé, afin que les informations de ma carte de crédit soient en sécurité.
Critères d’acceptation :- Tous les champs obligatoires doivent être remplis avant qu’un client puisse soumettre un formulaire.
- Les informations du formulaire sont stockées dans la base de données des commandes client.
- Le paiement peut être effectué par carte de crédit Amex, Master Card ou Visa.
- Le système calcule et applique avec précision la taxe de vente.
- Le système calcule et applique avec précision les frais d’expédition.
- Le client pourra vérifier l’exactitude de la commande.
- Un e-mail de confirmation est envoyé au client qui soumet le formulaire.
- La protection contre le spam fonctionne.
- Exemple de critères d’acceptation non pertinents
Description : en tant que client, je souhaite recevoir des notifications lorsqu’un incident est commenté, afin d’être informé de son état.
Critères d’acceptation : les personnes appropriées sont informées lorsque des incidents sont commentés.
Les critères d’acceptation sont médiocres car ils ne donnent pas assez de détails pour tester, par exemple, il n’est pas clair qui sont les personnes appropriées.
Les critères d’acceptation pourraient être mieux rédigés 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 concernant l’incident consigné.