Dans le développement agile, l’histoire d’utilisateur est un élément fondamental pour livrer de la valeur au client. Ces descriptions concises de fonctionnalités souhaitées capturent le « qui », le « quoi » et le « pourquoi » d’une fonctionnalité ou d’une exigence. Toutefois, pour s’assurer que les histoires d’utilisateurs sont à la fois actionnables et testables, les équipes agiles utilisent souvent une technique appelée « Give / When / Then » (GWT) pour les critères d’acceptation. Cette méthode permet de définir de manière claire et sans ambiguïté le comportement attendu d’une histoire d’utilisateur.
Qu’est-ce que les critères d’acceptation ?
Les critères d’acceptation sont des conditions ou des règles que doit remplir une histoire d’utilisateur pour être considérée comme complète. Ils agissent comme un pont entre la vision du propriétaire du produit et la mise en œuvre par l’équipe de développement. En essence, ils définissent les limites et les attentes pour chaque histoire d’utilisateur. Sans critères d’acceptation bien définis, une histoire d’utilisateur peut prêter à interprétation, entraînant des malentendus et des reprises potentielles.
La structure des critères d’acceptation Give / When / Then
Give / When / Then est un format pour rédiger les critères d’acceptation, emprunté au développement piloté par le comportement (BDD). Il encourage une manière plus structurée et compréhensible d’exprimer le comportement souhaité d’une histoire d’utilisateur. Ce format se compose de trois parties :
- Give: Cette section décrit le contexte ou l’état initial du système. Elle établit le cadre du scénario que vous décrivez. En essence, elle fournit les informations de fond nécessaires pour comprendre le scénario.
- When: Cette section représente l’action ou l’événement qui déclenche le comportement décrit dans l’histoire d’utilisateur. Il s’agit de l’événement spécifique que l’utilisateur effectue ou qui se produit dans le système.
- Then: Cette section décrit le résultat ou le résultat attendu de l’action ou de l’événement décrit dans la section « When ». Elle définit ce qui doit se produire en conséquence de l’action, souvent en termes de changements observables dans le système ou l’application.
Les avantages des critères d’acceptation Give / When / Then
- Clarté: Le format GWT offre une manière structurée et facile à comprendre d’exprimer le comportement attendu d’une histoire d’utilisateur. Cela réduit les ambiguïtés et garantit que tous les membres de l’équipe de développement, y compris les développeurs, les testeurs et les propriétaires de produit, ont une compréhension claire de ce qui doit être fait.
- Testabilité: Le format s’y prête naturellement pour les cas de test. Chacun des composants « Given », « When » et « Then » peut être traduit en scénarios de test spécifiques, ce qui facilite la validation que l’histoire d’utilisateur a été correctement mise en œuvre.
- Alignement: Les critères d’acceptation GWT encouragent la collaboration entre les membres de l’équipe. Les propriétaires de produit, les développeurs et les testeurs peuvent travailler ensemble pour définir et affiner les critères, garantissant que tous sont sur la même longueur d’onde concernant la portée et les attentes de l’histoire.
Exemples de critères d’acceptation Give / When / Then
Prenons un exemple simple pour un site e-commerce :
Histoire d’utilisateur: En tant que client, je souhaite pouvoir ajouter des articles à mon panier afin de pouvoir les acheter plus tard.
Critères d’acceptation (GWT):
- Given Je suis sur la page du produit
- When Je clique sur le bouton « Ajouter au panier » pour un produit
- Then Le produit doit être ajouté à mon panier d’achat
- Et L’icône du panier dans la barre de navigation doit afficher le nombre mis à jour des articles
- Et Je devrais voir un message de confirmation indiquant l’ajout du produit au panier
Dans cet exemple, les critères d’acceptation fournissent une compréhension claire de ce qui est attendu de l’histoire utilisateur, la rendant actionable et testable.
Description du problème Étude de cas :
Examinons une étude de cas pour une application de covoiturage populaire comme Uber. Le problème en cours est d’améliorer l’expérience utilisateur en introduisant une fonctionnalité qui permet aux passagers de planifier à l’avance des trajets pour des dates et heures spécifiques.
Histoires d’utilisateurs avec des critères d’acceptation GWT :
Histoire d’utilisateur 1 : Planifier un trajet à l’avance
En tant que passager, je souhaite pouvoir planifier un trajet pour une date et une heure spécifiques à l’avance, afin que je puisse mieux planifier mes trajets.
Critères d’acceptation (GWT) :
- Étant donné J’ai installé l’application de covoiturage et je suis connecté
- Lorsque J’ouvre l’application et j’indique ma destination, la date et l’heure du trajet
- Alors L’application doit afficher les conducteurs disponibles pour la date et l’heure sélectionnées
- Et Je devrais pouvoir confirmer et planifier le trajet
- Et Je devrais recevoir une notification de confirmation avec les détails du trajet planifié
Histoire d’utilisateur 2 : Modifier ou annuler un trajet planifié
En tant que passager, je souhaite avoir la possibilité de modifier ou d’annuler un trajet planifié, au cas où mes plans changeraient.
Critères d’acceptation (GWT) :
- Étant donnéJ’ai un trajet programmé
- LorsqueJ’ouvre l’application et je me rends à mes trajets programmés
- AlorsJe devrais voir une liste de mes trajets programmés à venir
- EtJe devrais pouvoir sélectionner un trajet pour modifier la date et l’heure ou l’annuler
- EtSi j’édite le trajet, l’application devrait afficher les conducteurs disponibles pour la date et l’heure mises à jour
- EtJe devrais recevoir une notification de confirmation pour tout changement effectué
User Story 3 : Informer les conducteurs des trajets programmés
En tant que conducteur, je souhaite recevoir des notifications lorsque un passager programme un trajet avec moi, afin que je puisse planifier ma disponibilité.
Critères d’acceptation (GWT) :
- Étant donnéJe suis un conducteur actif avec l’application de covoiturage ouverte
- Lorsqueun passager programme un trajet avec moi pour une date et une heure précises
- AlorsJe devrais recevoir une notification en temps réel avec les détails du trajet programmé
- EtL’application devrait afficher le trajet programmé sur mon tableau de bord de conducteur
- EtJe devrais pouvoir accepter ou refuser le trajet programmé dans un délai raisonnable
User Story 4 : Fournir un retour pour les trajets programmés
En tant que passager, je souhaite pouvoir donner des commentaires et noter les conducteurs pour les trajets planifiés, afin d’aider à maintenir la qualité du service.
Critères d’acceptation (GWT) :
- Étant donnéJ’ai terminé un trajet planifié
- LorsqueJ’ouvre l’application après la fin du trajet
- AlorsJe devrais avoir la possibilité de noter le conducteur et de donner un retour
- EtLa note du conducteur devrait être mise à jour en fonction de mon retour
- EtJe devrais recevoir un message de remerciement pour avoir fourni un retour
Ces histoires d’utilisateurs et leurs critères d’acceptation associés Give / When / Then abordent le problème de l’introduction d’une fonctionnalité de planification de trajets dans une application de covoiturage. En suivant cette approche structurée, l’équipe de développement peut garantir une compréhension claire des exigences et du comportement attendu de la nouvelle fonctionnalité, aboutissant finalement à une meilleure expérience utilisateur.
Conclusion
Les critères d’acceptation Give / When / Then offrent une approche structurée pour définir le comportement attendu des histoires d’utilisateurs dans le développement Agile. En divisant les critères en trois sections distinctes – Give, When et Then – les équipes peuvent atteindre une plus grande clarté, une meilleure testabilité et une meilleure alignement, aboutissant finalement à un développement de produit plus réussi. Intégrer ce format à votre processus Agile peut aider votre équipe à livrer un logiciel de haute qualité qui répond aux attentes des utilisateurs.