Dans la série des “Signature Book” de chez Addison Wesley,“User Stories Applied” est mon troisième livre approuvé par Kent Beck après “ATDD, by example” et “Test-Driven Development, by example”. Il m’a été prêté par un ami, merci Damien pour le prêt longue durée ;)

Il a été écrit par Mike Cohn qui est l’un des membres foundateurs de Agile Alliance et un développeur reconnu par ses pairs. Il est notamment l’un des spécialistes de Scrum, mettant en place cette méthodologie depuis plus de 20 ans et ayant écrit plusieurs livres sur le déploiement de l’agilité dans les projets informatiques.

Comment recueillir efficacement les besoins utilisateurs ? Comment rester au plus proche de ces besoins sans passer des mois à écrire des documents ? Comment différer le recueil de ces besoins au moment le plus opportun ? Comment estimer le travail à faire pour développer ces besoins ?
C’est pour répondre à toutes ces questions et bien d’autres que Mike Cohn nous présente les Users Stories apparues tout d’abord en eXtreme Programming et ayant évoluées depuis pour s’imposer comme l’une des meilleures méthodes de recueil de besoins dans un projet agile.

J’ai apprécié ce livre, assez facile à lire grâce à un découpage en petits paragraphes. A chaque fin de chapitre, on trouve un résumé (ce qui est une bonne idée si l’on veut reparcourir rapidement le livre plus tard pour se rafraîchir les idées) ainsi que des questions, moyen amusant de savoir ce que l’on a retenu de notre lecture.

Le livre est découpé en cinq parties :
    1. Getting started : présentation générale de ce qu’est une User Story et de comment on travaille avec.
    2. Estimating and Plannig : comment estimer une User Story et comment planifier son développement
    3. Frequently Discussed Topics : bonnes pratiques et questions récurrentes sur les User Stories
   4. An Example : exemple avec mise en situation sur une boutique d’articles de pêche et de plongée souhaitant développer son e-commerce.
    5. Appendices : un premier appendice sur l’eXtreme Programming, méthodologie où sont apparues les User Stories et un deuxième contenant les réponses aux questions de fin de chapitre.

Je vais maintenant synthétiser les idées des résumés présents à chaque fin de chapitre des trois premières parties afin d’en faire un mémo.

La première partie, Getting Started, est découpée en sept chapitres consacrés à la découverte des user stories et de leur écriture.

Chapitre 1 : Vue d’ensemble
    - Une story card contient une courte description d’une fonctionnalité à valeur ajoutée pour l’utilisateur ou le client
    - La story card est la partie visible d’une story mais le plus important reste la communication entre le client et les développeurs
    - L’équipe client inclut les personnes qui s’assureront que le logiciel répond aux attentes des utilisateurs. Elle peut inclure des testeurs, un responsable produit, des utilisateurs finaux et autres
    - C’est l’équipe client qui rédige les story cards car c’est elle la mieux placée pour exprimer les besoins utilisateurs et parce que c’est elle qui sera en charge de détailler ces besoins avec les développeurs ainsi que de les prioriser
    - Les stories sont priorisées selon la valeur qu’elles apportent à l’entreprise
    - Les livraisons et les itérations sont plannifiées en plaçant les stories dans les itérations
    - La vélocité représente la capacité de travail que peut fournir les développeurs pendant une itération
    - La somme des estimations des stories placées dans une itération ne peut pas excéder la vélocité prévue par les développeurs
    - Si une story ne rentre pas dans l’itération, elle peut être découplée en plusieurs stories plus petites
    - Les tests d’acceptation permettent de valider que la fonctionnalité développée est bien celle que l’équipe client avait en tête quand elle a rédigié la story
    - Les users stories révèlent leur valeur à l’utilisation car elle favorise la communication verbale, sont compréhensibles de la même façon par les développeurs et l’équipe client, sont utilisées pour planifier les itérations, fonctionnent bien dans les processus de développement itératif et surtout parce qu’elle encourage à retarder le recueil des détails concernant une story

Chapitre 2 : Écrire des stories
    - Idéalement les user stories sont indépendantes les unes des autres. Ce n’est pas toujours possible mais pour faciliter cela, il faut essayer de les écrire de façon à ce qu’elle puisse être développées dans n’importe quel ordre
    - Les détails d’une user story sont négociés entre l’utilisateur et les développeurs
    - Les stories devraient être écrites de façon à refléter clairement la plus-value pour le client/utilisateur. La meilleure façon d’arriver à cela est de les faire écrire par le client/utilisateur lui-même.
    - Les stories peuvent être légèrement détaillées mais trop de détails peuvent amener à penser que la conversation entre développeur et client n’est pas nécessaire
    - La meilleure façon d’annoter une story est de la compléter avec des cas tests
    - Si des stories sont trop grosses ou trop complexes, elles peuvent être divisées en plusieurs plus petites.
    - Si des stories sont trop petites, elles peuvent être regroupées pour en faire une seule
    - Les stories doivent être testables

Chapitre 3 : Les rôles utilisateur
    - La plupart des équipes projet n’envisage qu’un seul type d’utilisateur. Ce qui peut amener à oublier certaines fonctionnalités
    - Pour éviter cela, il faut identifier tous les utilisateurs qui peuvent interagir avec le logiciel
    - Identifier des caractéristiques spécifiques à chaque utilisateur permet de mieux cerner les différences entre plusieurs rôles
    - Certains rôles peuvent tirer bénéfice d’être associés à des persona. Un persona est une représentation imagée d’un rôle. Un persona possède un nom, un visage et suffisamment de détails pour qu’il soit le plus réaliste possible
    - Dans certains cas, des personnage extrêmes peuvent être utiles pour explorer des stories qui auraient pu être oubliées

Chapitre 4 : La collecte des stories
    - L’idée que les besoins existent quelque part et qu’il suffit de les capturer est fausse
    - La métaphore de la pêche au chalut des besoins est plus utile : elle regroupe l’idée que les besoins peuvent être de différentes tailles, qu’ils peuvent changer souvent et qu’il faut une certaine technique pour les trouver
    - Les user stories peuvent être collectées en interviewant les utilisateurs, en les observant utiliser le logiciel, par des questionnaires et en mettant en place des ateliers d’écriture de stories
    - Les meilleurs résultats sont obtenus en faisant une combinaison de ces méthodes plutôt que de ne s’appuyer que sur l’une d’entre-elles.
    - Les questions les plus pertinentes sont les questions ouvertes, déchargées de contexte (ex : “Tell me about how you’d like to search for a job“ plutôt que “Will you search for a job by title ?“)

Chapitre 5 : Travailler avec des représentants d’utilisateurs
    - Les représentants utilisateurs (i.e. proxy) sont moins pertinents que des utilisateurs finaux pour le recueil de besoins
    - Le supérieur hiérarchique des utilisateurs peut ne pas être un bon user proxy s’il n’est pas utilisateur lui-même
    - Le responsable de développement est un mauvais choix pour un user proxy car même s’il est impliqué dans le suivi des développement au jour le jour, il est souvent trop éloigné du profil utilisateur
    - Dans les entreprises de taille conséquent, le user proxy vient souvent du service marketing. Ce peut être un bon choix mais il faut veiller à ne pas privilégier la quantité à la qualité
    - Les commerciaux peuvent être de bons user proxy si ils sont au contact régulier des utilisateurs. Attention à ce qu’ils ne se focalisent pas sur les fonctionnalités qui sont en relation directe avec leur chiffre de ventes
    - Les experts métier sont d’excellents user proxy mais il faut veiller à ce qu’ils ne dérivent pas sur des fonctionnalités nécessitant leur expertise du métier
    - Les clients, dans le sens de ceux qui achètent le logiciel, peuvent être de bons user proxy si ils sont en contact régulier avec les utilisateurs finaux.

Chapitre 6 : Les tests d’acceptation
    - Les tests d’acceptation sont utilisés pour exprimer les détails résultant des conversations entre client et développeurs
    - Les tests d’acceptation permettent de documenter les hypothèses sur des détails qui n’auraient pas été discutés entre client et développeurs
    - Les tests d’acceptation permettent de valider qu’une story est complètement développée
    - Les tests d’acceptation devraient être écrits par le client plutôt que par le développeur
    - Les tests d’acceptation sont écrits avant que le développeur ne commence à coder
    - Il y a suffisamment de tests lorsque l’écriture d’un test de plus n’apporte rien de plus
    - FIT et FitNesse sont de bons outils pour que le client écrive facilement des tests d’acceptation

Chapitre 7 : Bonnes pratiques pour bonnes stories
    - Commencer par identifier des rôles utilisateur
    - Lorsque l’on divise une story, il faut essayer de la diviser de manière à réunir tous les niveaux de l’application
    - Compléter les user stories par toute la documentation nécessaire au domaine ou à l’environnement du projet
    - Utiliser des cartes contraintes qui resteront afficher au mur pour s’assurer de respecter les règles transverses à toutes les user stories
    - Détailler plus en avant les user stories qui seront commencé au plus vite
    - Laisser l’interface utilisateur en dehors des user stories autant que possible
    - Inclure le rôle utilisateur dans l’écriture de la user story
    - Ecrire les user stories à la voie active (ex: “A Job Seeker can post a resume“ plutôt que “A resume can be posted by a Job Seeker“)
    - Ecrire les user stories pour un seul utilisateur plutôt que plusieurs
    - Laisser le client écrire les user stories plutôt que le développeur
    - Garder la taille des user stories raisonnable et ne pas oublier qu’elles servent essentiellement de mémo aux conversations
    - Ne pas numéroter les story cards

La deuxième partie, Estimating and Planning, est composée de quatre chapitres consacrés à l’estimation et à l’élaboration du planning.

Chapitre 8 : Estimer des User Stories
    - Estimer les stories en story points qui sont des estimations relatives à la complexité ou la durée d’une story
    - Les estimations doivent être faites par l’équipe. Tous les membres de l’équipe partagent cette estimation et non pas de manière individuelle
    - La triangularisation est une méthode qui peut être utile et qui consiste à estimer une user story par rapport à d’autres
    - Le pair programmnig n’a pas d’impact sur l’estimation d’un user story, seulement sur la vélocité de l’équipe

Chapitre 9 : Planifier une livraison (release)
    - Avant de pouvoir planifier une livraison, il faut connaître approximativement quand le client veut son produit et quelles sont les priorités relatives des stories
    - Les stories devraient être priorisées les unes par rapport aux autres (première , deuxième, troisième, etc) plutôt que par groupe (très importantes, importantes, peu importantes, etc)
    - Les stories sont priorisées par le client mais avec les conseils des développeurs
    - Les estimations, faites en jours idéaux, sont converties en jours calendaires grâce à la vélocité
    - Il est souvent nécessaire d’estimer la vélocité initiale d’une équipe, à moins que celle-ci n’est déjà été constituée pour un projet antérieur

Chapitre 10 : Planifier une itération (sprint)
    - La planification d’une itération va un peu plus dans le détail que la planification d’une livraison mais restreinte à l’itération à venir
    - Pour planifier une itération, l’équipe discute chaque user story en la divisant en tâches
    - Le but du découpage en tâches est d’encourager plusieurs développeurs à travailler sur la même user story
    - Chaque développeur accepte les responsabilités d’une tâche

Chapitre 11 : Mesurer et surveiller la vélocité
    - Seules les stories terminées (i.e. qui passent les tests d’acceptation) sont comptabilisées pour le calcul de la vélocité. Les stories en cours seront comptées sur la prochaine itération
    - Un bon moyen de comparer la vélocité actuelle et celle prévue est de faire un graphe avec à la fois les story points accomplis durant l’itération en cours et ceux prévus
    - La tendance de la vélocité ne peut être fait qu’après 2 ou 3 premières itérations car les premières itérations ne sont pas significatives
    - Le nombre d’heures effectivement réalisées sur une tâche ne modifie en rien la vélocité
    - Afficher de grands et compréhensibles graphiques dans un espace où tout le monde peut les voir
    - Un cumulative story point chart permet de voir le nombre total de story points effectués jusqu’à la fin de l’itération
    - L’ iteration burdown chart (à ne pas confondre avec le daily burndown chart) montre à la fois la progression sous la forme de story points accomplis par itération ainsi que le reste à faire jusqu’à la fin de la release
    - Le daily burndown chart est très utile pendant une itération pour voir le temps passé et le reste à faire jusqu’à la fin de l’itération
    - Capitaliser et surveiller le nombre de bugs par story point peut-être utile pour vérifier que l’accroissement de la vélocité ne se fait pas aux dépens de la qualité

La troisième partie, Frequently Discussed Topics, est composée de cinq chapitres consacrés aux bonnes pratiques et questions récurrentes sur les user stories. Nous nous intéresserons ici aux deux premiers.

Chapitre 12 : Ce que les user stories ne sont pas
    - Ce ne sont ni des spécifications de type IEEE 830, ni des use cases, ni des scénarios d’interaction
    - Peu importe le temps et l’effort qu’il passe à réfléchir et réfléchir encore, personne ne peut prévoir totalement et parfaitement un système non trivial
    - Le retour d’expérience d’un utilisateur qui définit lui-même ses besoins et qui manipule fréquemment les fonctionnalités qui en découlent, est très enrichissant
    - Il est plus important de chercher à atteindre l’attendu d’un utilisateur plutôt que la liste des attributs d’une solution
    - Les user stories se rapprochent des use cases mais les use cases tendent à être plus gros et sont plus sujets à contenir des hypothèses sur l’interface utilisateur
    - Les use cases sont destinés à être des artefacts permanents alors que les user stories servent principalement de support pour conversations

Chapitre 13 : Pourquoi utiliser les user stories
    - Les user stories forcent à la communication orale contrairement à d’autres techniques de spécification
    - Ceci permet un retour d’expérience rapide ce qui amène à une meilleure compréhension des besoins
    - Les user stories sont compréhensibles aussi bien par le client que les développeurs
    - Les user stories sont à la bonne échelle pour une planification itérative
    - Les user stories encouragent le report au moment le plus propice de la description en détails
    - Les user stories encouragent la participation de tous
    - Les user stories peuvent aussi avoir quelques défauts :
        - sur de gros projets, il peut être fastidieux d’organiser des centaines voir des milliers de stories
        - il peut être nécessaire de les compléter avec d’autres documentations pour avoir de la traçabilité