Comme vous le savez sûrement, parmi les valeurs et principes que les approches Agiles promeuvent, il y a la collaboration; la collaboration entre les différents intervenants qui participent au développement, à la mise en marché et à l’utilisation du produit.
Trop souvent négligés ou mal compris, les scénarios utilisateurs (user stories) jouent un rôle important au sein d’une équipe de développement et, de façon plus large, de l’équipe responsable du produit dans son ensemble. Ils visent à engager la discussion sur les besoins des utilisateurs, ainsi ils favorisent l’intelligence collective et l’innovation afin de trouver la meilleure solution.
Avec les scénarios utilisateurs, on cherche aussi à comprendre le pourquoi de notre travail. On veut susciter un plus grand engagement de la part des personnes impliquées et les amener à se sentir responsables du produit.
Apprenez-en plus sur le développement de produits Agile. Participez à notre cours.
Il n’y a pas de scénarios parfaits. Comme mentionné précédemment, ils servent justement à donner lieu à des échanges et à accroître la collaboration. L’équipe doit se questionner sur le véritable besoin de l’utilisateur et chercher à le comprendre. Et certains principes peuvent faciliter la discussion :
A. Comme tout bon scénario, le récit tourne autour d’un seul acteur clairement identifié. Les personas sont souvent utilisés afin de susciter l’empathie envers l’utilisateur.
B. Un scénario décrit un besoin et non pas une fonctionnalité. Cette dernière est l’extrant de la discussion, non pas son intrant.
C. Un scénario inclut aussi l’avantage que l’utilisateur obtiendra si le besoin est comblé. Cela situe mieux le contexte et amène l’équipe à discuter de la valeur du travail accompli.
Il est à noter que chaque équipe peut utiliser un soutien visuel qui lui est propre. Il n’est pas nécessaire que le scénario soit écrit au complet dans le titre afin de faciliter la gestion des scénarios. Par contre, il doit être complet dans sa description.
Les trois premiers points sont couverts dans le gabarit type suivant :
En tant que <qui>, je veux <quoi> afin de <pourquoi>.
D. Un scénario utilisateur est indépendant des autres scénarios. Il est conceptuellement autonome et il est l’expression du caractère incrémental de la démarche.
Deux cas se retrouvent régulièrement dans les carnets de produit. Le premier paraît lorsque le développement s’effectue en silos et que nous retrouvons des scénarios pour l’intégrateur, d’autres pour le concepteur ainsi que d’autres pour le développeur. Idéalement, il faut briser cette approche et considérer la somme du travail à faire pour répondre à un besoin utilisateur à l’intérieur du scénario.
Ainsi, le scénario suivant ne permet pas une discussion enrichissante sur le besoin de l’utilisateur :
En tant que Jean, l’utilisateur, je veux avoir une interface afin d’effectuer une action.
Le deuxième cas se cache plus subtilement derrière des préconceptions. Par exemple, nous pensons souvent qu’il faut créer un objet avant de pouvoir l’éditer. Toutefois, un simple ajout à la banque de données nous libérerait de cette contrainte et nous permettrait de prioriser l’édition de l’objet si la valeur d’affaires le demande.
Ce cas particulier est bien couvert dans ce billet-ci qui traite de la dépendance entre les scénarios.
E. Le scénario est un besoin autour duquel l’équipe négocie une solution.
En tant que Jean, l’utilisateur, je veux un bouton « Acheter » rouge (#ff0000) dans le bas de la page du produit afin de pouvoir l’acheter.
Avec un scénario comme celui-ci, l’équipe ne peut pas négocier une solution. Dans ce cas, le scénario est l’expression de la solution et non du besoin. L’équipe peut faire le travail, mais elle se désengagera rapidement du produit et ne se sentira jamais responsable de la valeur d’affaires.
F. La valeur d’un scénario doit sans cesse être remise en question.
En tant que Jean, l’utilisateur, je veux avoir la liste des MP3 afin de voir les chansons que j’ai.
Dans ce cas-ci, y a-t-il vraiment une valeur à ce que Jean voit les chansons qu’il possède? En remettant en question cette valeur, on pourrait apprendre que Jean cherche une chanson en particulier quand il n’en connaît pas le titre, mais alors qu’il connaît le groupe. Cela orienterait la discussion dans une autre direction complètement.
G. Le scénario doit être testable. On doit donc pouvoir rapidement établir que le besoin est comblé ou pas. Les scénarios avec des qualificatifs du type « plus rapide » ou « plus beau » deviennent très subjectifs et nuisent à la discussion. Ces scénarios cachent souvent des éléments requis non fonctionnels dont on devrait discuter et qui devraient être traités comme tels.
H. Plus un scénario est petit plus le besoin sera bien compris et plus la solution répondra au besoin.
En tant que Jean, l’utilisateur, je veux acheter un livre afin de m’instruire.
Dans le cas ci-dessus, il sera très complexe de bien répondre à ce besoin tellement il est gros. Ce scénario est considéré comme une épopée (epic) et devra être divisé et subdivisé en des besoins plus petits.
I. Il est possible d’estimer un scénario. Si nous ne pouvons le faire, c’est une indication que le besoin ou la solution ne sont pas maîtrisés. Dans les deux cas, on doit poursuivre la discussion. Il est fort possible qu’à ce moment une investigation soit insérée dans le carnet de produit afin de valider une hypothèse d’affaires ou technologique.
En somme
La qualité d’un scénario utilisateur est liée à la qualité de la discussion et elle aura une incidence directe sur la capacité de l’équipe à répondre correctement aux besoins de l’utilisateur.
En distinguant clairement le quoi du comment, on permet aux développeurs de laisser libre cours à leur talent et à leur créativité pour arriver collectivement à la meilleure façon de faire.
J’espère que ce billet vous aura éclairé sur l’importance des scénarios utilisateurs. Ces derniers favorisent une meilleure collaboration dans l’équipe de projet et aident à comprendre l’importance des interactions au sein de celle-ci.
Références
Ces éléments proviennent, entre autres, de la norme INVEST décrite par Bill Wake en réponse aux objectifs SMART.
Pour une réflexion plus élaborée sur la façon d’écrire des scénarios utilisateurs, référez-vous au livre de Mike Cohn intitulé : User Stories Applied: For Agile Software Development.
Pas de commentaire