Ce ne sont que des histoires ! De toutes petites histoires, qui pourtant vont permettre de faire de grandes choses ! Je parle de « User Stories », et je ne suis pas le seul à m’interroger (depuis un certain temps déjà) sur la traduction adéquate de ces histoires d’utilisateurs [ Comment traduire User Story en français ? et Des histoires d’utilisateurs].
Scénario idéal (qui se renouvelle en ce moment pour mon plus grand plaisir !) : Un client appelle ayeba, il veut sortir un nouveau site Internet dans 5 mois, il commence à avoir une bonne idée de ce qu’il veut, il a eu le « go » pour le budget avec un peu de retard, le cahier des charges n’est pas encore commencé… Et… Cela commence a être un peu serré en terme de délai pour pouvoir profiter du prochain évènement idéal pour le lancement du site…
Après analyse, c’est tout à fait faisable en méthode classique (waterfall) : 1 mois pour le cahier des charges, quelques propositions de prestataires, sélection, un peu de temps de validation interne, 1 mois pour faire des spécifications, un peu de temps de validation, on attaque le développement, réception du développement, mise en production… et GO, c’est lancé ! Si tout se passe bien alors cela devrait marcher… Humm… Même mon client, me fait remarquer que le dernier mois… eh bien… il faudra gérer la crise…
En regardant de plus près, les personnes qui me présentent le projet lors de la réunion de lancement ne me parlent pas exactement du même projet… Ils n’emploient pas les mêmes mots, n’ont pas exactement les mêmes références sur Internet… La rédaction d’un cahier des charges avec une approche classique risque fortement de conduire à des déceptions de certains des acteurs du projet (avant même d’avoir commencé) et peut-être même de tous lorsque le développement sera engagé, ou terminé, et qu’ils ne pourront plus modifier leur demande initiale…
L’approche « user story » : « en tant qu’utilisateur, je veux … ainsi j’obtiens… » va permettre de faire converger l’équipe client vers le même projet, de tirer partie de toutes les idées… Et bien sur d’obtenir des propositions des prestataires plus ajustées au besoin réel. Chaque histoire, indépendante des autres, peut-être priorisée en fonction du bénéfice que l’utilisateur va en tirer et ainsi déterminer plus facilement un plan de sortie général des prochaines livraisons du site, avec en premier ce qu’il faut, puis ce qu’il faudrait, puis ce que l’on pourrait avoir… et évitant de passer du temps sur ce qu’il n’est pas nécessaire d’avoir cette fois.
La suite ? Je vous la raconte bientôt !
En attendant je vous recommande la lecture de : User Stories Applied et/ou Agile Estimating and Planning de Mike Cohn pour débuter dans l’utilisation de petites histoires qui vous feront réussir à avoir un bon produit.
Publié sur ayeba.fr : http://ayeba.fr/2009/08/16/user-story-stories-quelles-histoires/
