User stories Mémo

User stories Mémo Les user stories Le principe des user stories est une technique de spécification de logiciels basée sur des scénarios d’utilisation des fonctions de base d’un logiciel en phase de conception. Leur créateur, Mike Cohn,1 les différencie des use cases et des scénarios d’interaction en disant : -­‐ ils mettent l’accent sur la communication verbale (ils sont ensuite écrits et affichés) -­‐ ils sont compréhensibles par tous les publics -­‐ ils ont une taille adaptée à la planification (petites fiches à petits scénarios !) -­‐ ils sont conçus pour le développement itératif (Scrum, XP) -­‐ ils n’imposent pas de rentrer dans les détails au départ -­‐ ils sont compatibles avec le « opportunistic design » (agilité & hacking s/w & h/w) -­‐ ils encouragent la conception participative -­‐ ils favorisent le développement de connaissances tacites Comme leur nom l’indique les user stories mettent en œuvre d’une part un utilisateur fictif mais défini de manière précise, et d’autre part des scénarios courts, élémentaires, qui représentent le recours à ce que l’analyse fonctionnelle appelle fonction de service. Cette approche permet de spécifier ce que veut l’utilisateur (au lieu de ce qu’il demande). Les stories sont élaborées ensemble, client et développeur, à partir du profil des users également définis ensemble. Les responsabilités sont réparties (et parfois partagées) comme suit entre les différents acteurs. Responsabilités des développeurs : -­‐ ils participent au choix des users, de leurs rôles et des personnages qui les jouent, -­‐ ils doivent comprendre les rôles des différents users et en quoi ils diffèrent, -­‐ en cours de développement ils doivent parvenir à déterminer comment les différents users souhaiteront voir le logiciel se comporter, -­‐ ils doivent être capables de s’assurer que les rôles attribués aux users ne sont pas outrepassés ou sur-­‐interprétés. Responsabilités des clients : -­‐ ils doivent considérer un large choix de users possibles et identifier ceux qui sont susceptibles de remplir les rôles appropriés, -­‐ ils participent à la sélection des rôles des users et des personnages, -­‐ ils s’assurent du fait que le logiciel ne se focalise pas sur un sous-­‐ensemble spécifique de users, -­‐ au moment de la rédaction des scénarios ils s’assurent que chacun d’entre eux peuvent être associés avec au moins un user ou personnage, 1 COHN Mike (2004) User Stories Applied For Agile Software Development, Pearson Education Boston MA. Ce mémo ne donne qu’un aperçu très incomplet du contenu de cet ouvrage. Si vous envisagez un développement basé sur ces méthodes il est vivement conseillé de l’emprunter en bibliothèque ou d’en faire l’acquisition. -­‐ au cours du développement du logiciel ils déterminent la meilleure façon qu’aura le logiciel de se comporter pour chacun des users, -­‐ ils doivent être capables de s’assurer que les rôles attribués aux users ne sont pas outrepassés ou sur-­‐interprétés. Une autre caractéristique importante de la méthode des user stories est de spécifier un système de métrique par points afin d’évaluer quantitativement les projets traités. Des recommandations pour fiabiliser ce système et le normaliser dans un projet (ajustement, etc.). L’ouvrage de Mike Cohn décrit d’autres points et donne de nombreux conseils pour la mise en œuvre de sa méthode. La liste des alertes (catalog of story smells) Story too small : les scénarios doivent être suffisamment conséquents pour représenter une vraie tâche à réaliser. Interdependant stories : trop de dépendances entre les scénarios. Goldplating : ajout de fonctions superflues situées au-­‐delà des attentes du client. Too many details : donner trop de détails sur un scénario (diminuer la taille des fiches). Including user interface too soon : il faut attendre le dernier moment ou les premières itérations de développement pour détailler l’interface. Ne pas le faire avant ! Thinking too far ahead : être trop précis trop loin. La précision doit diminuer avec l’éloignement. Splitting too many stories : éviter de diviser trop de scénarios pendant les itérations. Le mieux est de les diviser avant si, -­‐ ils sont trop gros pour tenir dans une itération, -­‐ ils contiennent des sous-­‐scénarios dont le client ne veut conserver que les plus prioritaires. Customer has trouble prioritizing : il est possible qu’une difficulté à prioriser révèle des scénarios trop gros, dans ce cas les réduire. Customer won’t write and prioritize the stories : vu la responsabilité du client dans ce process, le fait qu’un client soit incapable de prioriser n’est pas bon signe. Il faut l’aider à décider, mais le laisser décider. Lorsqu’une de ces alertes se produit la responsabilité de la correction incombe à la fois au développeur ET au client. Il faut dans tous les cas régler le problème sans tarder pour éviter de rencontrer des écueils ensuite.