Introduction
Dans le domaine du développement Agile, les histoires utilisateur servent de blocs de construction essentiels à la communication entre les équipes de développement et les parties prenantes. Toutefois, pour garantir que ces histoires soient correctement mises en œuvre et atteignent les objectifs souhaités, les critères d’acceptation sont indispensables. Les critères d’acceptation définissent les conditions spécifiques et les attentes que doit remplir une histoire utilisateur pour être considérée comme complète. Mais quelle est la meilleure façon de structurer ces critères ? Dans cet article, nous examinons trois modèles populaires de critères d’acceptation : Given-When-Then, Behavior-Outcome-Expectation et Role-Feature-Reason. Nous analyserons les avantages et inconvénients de chacun de ces modèles et discuterons de leurs utilisations efficaces selon les contextes.
Modèles courants de critères d’acceptation
Les critères d’acceptation sont essentiels pour définir le périmètre d’une histoire utilisateur et garantir que l’équipe de développement comprend ce qui doit être mis en œuvre. Voici trois modèles courants :
- Given-When-Then (GWT) :
- Given : Un précondition ou contexte qui établit le cadre.
- When : L’action ou l’événement qui déclenche l’histoire utilisateur.
- Then : Le résultat ou le résultat attendu.
Exemple :
- Given un utilisateur enregistré est connecté
- When ils cliquent sur le bouton « Ajouter au panier »
- Then l’article doit être ajouté à leur panier
- Behavior-Outcome-Expectation (BOE) :
- Behavior : L’action ou le comportement abordé par l’histoire utilisateur.
- Outcome : Le résultat ou le changement d’état attendu à partir de ce comportement.
- Expectation : Toute autre information ou condition supplémentaire.
Exemple :
- Behavior : L’utilisateur soumet un formulaire de contact
- Outcome : Un e-mail contenant les données du formulaire est envoyé à l’équipe de support
- Attente : L’e-mail contient les informations de contact de l’utilisateur et son message
- Rôle-Fonctionnalité-Raisonnement (RFR) :
- Rôle : Le rôle ou la personne concernée dans l’histoire utilisateur.
- Fonctionnalité : La fonctionnalité ou fonction spécifique décrite.
- Raisonnement : Le but ou la justification de la fonctionnalité.
Exemple :
- Rôle :Administrateur
- Fonctionnalité : Capacité à supprimer les comptes utilisateurs
- Raisonnement : Pour maintenir l’intégrité de la base de données utilisateurs et supprimer les comptes inactifs
Ce ne sont que quelques exemples de modèles de critères d’acceptation. Le choix du modèle dépend souvent des préférences de l’équipe et de la complexité de l’histoire utilisateur. Il est important que les critères d’acceptation soient clairs, précis et vérifiables afin de garantir que l’histoire utilisateur soit correctement mise en œuvre. En outre, les critères d’acceptation doivent couvrir à la fois les exigences fonctionnelles et non fonctionnelles, selon les besoins de l’histoire utilisateur.
Résumé des modèles de critères d’acceptation
Voici un tableau comparant les avantages et inconvénients des trois modèles de critères d’acceptation (Given-When-Then, Behavior-Outcome-Expectation et Role-Feature-Reason), ainsi que leurs aspects connexes :
| Aspect | Given-When-Then (GWT) | Comportement-Résultat-Attente (BOE) | Rôle-Fonctionnalité-Raisonnement (RFR) |
|---|---|---|---|
| Avantages | |||
| Clarté | Fournit une structure claire pour exprimer les exigences de l’histoire utilisateur. | Sépare explicitement le comportement, le résultat et les attentes pour plus de clarté. | Met l’accent sur le rôle, la fonctionnalité et le raisonnement pour une meilleure compréhension. |
| Testabilité | Facile à convertir en cas de test. | Encourage à préciser des conditions vérifiables pour la validation. | Peut être utilisé pour dériver des cas de test en se concentrant sur les rôles et les fonctionnalités. |
| Flexibilité | Adéquat pour une large gamme d’histoires d’utilisateurs, des simples aux complexes. | Permet une flexibilité dans la description des interactions utilisateur et des résultats attendus. | Adaptable à divers scénarios et aide à justifier la nécessité des fonctionnalités. |
| Lisibilité | Lisible et compréhensible par les membres techniques et non techniques de l’équipe. | Concis et structuré, ce qui facilite la revue par les parties prenantes. | Fournit un contexte sur la raison pour laquelle une fonctionnalité est nécessaire, aidant à la priorisation. |
| Inconvénients | |||
| Surcharge | Peut devenir verbeux pour des histoires d’utilisateurs très complexes, entraînant des critères longs. | Peut ne pas capturer certaines exigences non fonctionnelles ou contraintes. | Exige une explication supplémentaire si le rôle, la fonctionnalité ou la raison n’est pas évident. |
| Manque de contexte | Peut ne pas capturer efficacement le contexte global de l’histoire utilisateur. | Peut manquer les objectifs commerciaux plus larges ou les motivations derrière l’histoire utilisateur. | Repose sur la compréhension implicite par les parties prenantes du rôle, de la fonctionnalité et de la raison. |
| Pas idéal pour les exigences non fonctionnelles. | Moins adapté à la spécification des exigences non fonctionnelles (par exemple, performance, sécurité). | Peut ne pas mettre l’accent sur les aspects non fonctionnels à moins qu’ils ne soient explicitement inclus dans les attentes. | Les exigences non fonctionnelles peuvent être négligées si elles ne sont pas explicitement indiquées. |
Ce sont certains des principaux avantages et inconvénients associés à chacun des modèles de critères d’acceptation. Le choix du modèle doit tenir compte des besoins spécifiques de l’histoire utilisateur, du projet et de la familiarité de l’équipe avec le modèle. En pratique, les équipes utilisent souvent une combinaison de ces modèles selon les besoins afin de fournir des critères d’acceptation complets pour les histoires utilisateur.
Résumé
Les critères d’acceptation des histoires utilisateur jouent un rôle crucial dans le développement logiciel Agile, en définissant les limites et les attentes pour chaque histoire. Pour optimiser ce processus, cet article compare trois modèles de critères d’acceptation largement utilisés : Given-When-Then, Behavior-Outcome-Expectation et Role-Feature-Reason. Nous examinons les forces et faiblesses de chaque modèle, en offrant des perspectives sur le moment où les appliquer en fonction de la complexité de l’histoire utilisateur et des besoins de l’équipe. À la fin, vous aurez une compréhension claire de la manière de choisir le modèle le plus adapté pour élaborer des critères d’acceptation efficaces pour vos projets Agile.