La phrase « en tant que… » n’est jamais que le titre de la story. Une histoire se raconte… C’est une expression de besoins essentiellement orale.
User Story Origin
Reprenons le contexte d’origine de création de ce concept. C’est par exemple un responsable PME qui souhaite une nouvelle gestion commerciale. Les commerciaux et autres collaborateurs sont les Utilisateurs de ce nouveau système spécifié à partir d’histoires d’utilisation (future). Ce client a embauché quelques Développeurs (freelances par exemple) qui sont là pour développer avec lui.
User Story : c’est de l’oral
C’est ce qui explique l’importance de la communication orale (omniprésente dans l’agile de toute façon). Les stories développées semaines n ont été discutées dans les semaines précédentes.
Quand ?
- Lors de raffinages
- pour estimer l’effort (lorsque l’on travaille en capacitaire type vélocité).
Et également…
- au moment de la planification de l’itération (de trois semaines initialement et aujourd’hui une semaine dans XP)
- lors de l’automatisation des tests d’acceptation
- lors du développement de la story (programmation)
- lors du passage des tests d’acceptation
- lors de la mise en production
Sans compter les innombrables occasions informelles.
Oral ? Ouh la la !
Mais… Oral ?!? Rien d’écrit ?!?
Bien sûr la story est écrite. Sur des cartes « bristol » initialement avant d’utiliser des post-its et des items dans les outils aujourd’hui tels que Jira (d’où le terme « carte » dans des publications). Mais le point fort, antérieur au stories dans XP, est le test d’acceptation. Une story a nécessairement des tests d’acceptation. Autrement dit des dispositifs qui vont permettre au client d’accepter (ou pas) la story telle que développée par l’équipe.
Tests d’acceptation
Le test d’acceptation est le contrat entre Client – PO et Développeurs :
« Si nous, Développeurs, créons un produit qui satisfait à ces tests, alors toi Client, tu l’acceptes. Inversement, si un test ne passe pas, tu as le droit de rejeter la story ».
Cela va sans dire, les tests sont spécifiés, écrits, avant le développement. Le contraire ne serait pas très fair-play. Cela dit, écrire des tests n’est pas forcément si trivial.
- cas nominal
- cas limite
- cas d’erreur…
Le Client ou PO non averti aura vite oublié des cas d’erreur ou des cas limites… Il se fait alors aider par un Testeur.
Notez aussi que les tests d’acceptation sont automatisés, ce qui autorise la vérification systématique de la non-régression.
La question qui se pose est celle du maintien des tests. Disons trois ou quatre tests par story, une dizaine de stories par mois… Au bout d’un trimestre, vous disposez de plus de 200 tests automatisés. L’éternel problème ici est la preuve de l’intérêt. Il est relativement facile de calculer le coût de l’automatisation de tests. Cela dit, concernant le bénéfice, il suffit de considérer un défaut sérieux en production. Nous constatons vite que le « retour sur investissement » de l’automatisation se justifie par la diminution drastique de ces défauts bloquants.
Écrire les tests d’acceptation (les programmer) avant le développement constitue un dispositif de qualité intrinsèque, pilier du Lean et du flux tiré continu. Ainsi, un éventuel défaut est détecté immédiatement et donc est plus facile à corriger. Sans compter qu’il ne se propage pas. La règle d’or :
La barre (résultat des tests) toujours verte
est donc un incontournable. À comparer avec la stratégie classique de tests a posteriori.
En résumé, c’est au final le Client ou PO qui accepte – ou pas – le développement. Charge à lui de s’armer de tests suffisamment complets pour ne pas accepter n’importe quoi. Il reste de toute façon la question lancinante :
- accepter une story ?
- accepter un système qui inclut une nouvelle story ?
Dans le 2nd cas, la non-régression a été vérifiée. Là encore, les tests automatisés sont d’une aide très précieuse.