Une idée de fonctionnalité est comme un matériau brut que l’on peut s’amuser à sculpter. Je l’ai remarqué lors d’ateliers en questionnant les équipes que j’accompagne sur les fonctionnalités qu’elles veulent développer et la manière dont elles comptent les valider. J’utilise les trames “User story” et BDD (Behaviour Driven Development) pour capturer l’essence du besoin et la manière dont la réponse pourra être observée une fois la fonctionnalité développée. Je trouve beaucoup de valeur à ce type d’atelier car, d’une part, il permet aux équipes de se former aux user stories et aux scénarios BDD en utilisant leur propres sujets et d’autre part, de s’imprégner du format de l’atelier qu’elles peuvent réutiliser.
Le questionnement sur la fonctionnalité
Lorsqu’une équipe m’amène un besoin, j’essaie de comprendre à quel niveau il se situe et remonte avec eux au besoin “macro”. Je n’y passe pas trop de temps, sauf si je sens que cette vision manquait à l’équipe.
Qui sont les utilisateurs ?
J’interroge ensuite l’équipe sur les utilisateurs de la fonctionnalité. J’essaie de fermer assez rapidement les options lorsqu’une proposition est faite pour faire réagir les participants : “donc cette fonctionnalité concerne principalement les utilisateurs X ?”. A ce moment là, il est utile d’identifier les différents profils des utilisateurs s’il y en a et les lister.
Que veulent-ils de différent ?
Je demande à l’équipe ce que les utilisateurs ne sont pas en capacité de faire aujourd’hui mais veulent faire demain. S’agit-il de quelque chose de complètement nouveau, sont-il déjà capable de le faire aujourd’hui mais d’une manière non optimale ? Est ce que tous les utilisateurs listés veulent la même chose ? (Sinon, c’est l’occasion de séparer la fonctionnalité par type d’utilisateur).
En quoi cette fonctionnalité va t-elle changer leur vie ou celle de l’entreprise ?
J’essaie maintenant de comprendre avec eux l’effet que va produire cette fonctionnalité. Supposons que cette fonctionnalité soit disponible, que ce passe t-il ? Que fait l’utilisateur / l’entreprise de différent dans son quotidien ?
Le résultat est matérialisé par les expressions suivantes :
| En tant que … Je veux … Afin de … |
Il est à noter que ce résultat ne doit pas être l’objectif recherché (afin d’éviter qu’une seule personne ne s’en charge par exemple). Il est préférable de le considérer comme le marqueur de cette expérience de co-construction qui apporte beaucoup dans la compréhension du besoin.
Le questionnement sur les critères d’acceptance
Comme pour le questionnement sur la fonctionnalité, celui sur les critères d’acceptance va tourner autour de trois questions :
Quel est le contexte de départ ?
Je demande à l’équipe dans quel état devrait se trouver l’application pour accéder à la nouvelle fonctionnalité. Qu’est ce qui peut amener l’application à cet état ? Je pars généralement de rien, c’est à dire de l’application éteinte, pour avancer petit à petit vers les données minimales à disposer pour que la fonctionnalité prenne du sens.
Quel événement fait prendre vie à la fonctionnalité ?
Qu’est ce qui permet de dire que la fonctionnalité est active ? Comment passe t-on du contexte de départ à celui-là ? Y a-t-il plusieurs chemins pour accéder à ce nouvel état ? Si oui, il sera intéressant de les séparer en plusieurs scénarios.
Quel effet a la fonctionnalité ?
Quel résultat produit la fonctionnalité ? Qu’observe t-on ? C’est l’occasion de capturer du détail sur ce qu’a produit la fonctionnalité, sous forme de maquette ou d’exemples.
Le résultat de l’atelier est matérialisé par les expressions suivantes :
| Etant donné … Quand … Alors … |
Disposer d’un réel exemple
Une fois les trois réponses obtenues, je demande à l’équipe de remplacer tout le contenu générique par des exemples très précis. Ainsi, la validation de la fonctionnalité sera facilité en comparant les données souhaitées par celles produites.
| Etant donné un utilisateur X avec un solde à zéro Quand l’utilisateur effectue une opération de crédit Alors le compte de l’utilisateur X se retrouve crédité de la somme demandée |
Ce scénario générique peut intégrer des données réelles pour lever toute ambiguïté sur la validation de la fonctionnalité.
| Etant donné l’utilisateur “Jean Pierre” avec un solde à zéro sur son compte 98736 Quand “Jean Pierre” effectue une opération de crédit de 460 sur ce compte Alors le solde du compte 98736 s’élève à 460. |
La valeur de ces questions pour l’équipe
Le résultat de cet atelier n’est pas tant l’obtention d’une user story et d’un ou plusieurs critères d’acceptance. La valeur se trouve surtout dans les échanges qui ont eu lieu entre les personnes de l’équipe pour les construire. De ces interactions vont naître de la clarification et de la transmission du savoir concernant le sujet traité. C’est beaucoup de temps économisé sur les incompréhensions, le rework, surtout si cela arrive tardivement dans la chaîne de valeur.
Référence : Specification by Example de Gojko Adzic
photo credit: Stéphane Daniel M.Hovington 02 via photopin (license)
