Lorsqu’une méthodologie Agile comme Scrum est utilisée pour la gestion d’un projet, il n’est évidemment pas question de rédiger des spécifications fonctionnelles exhaustive avant le démarrage, comme c’est encore le cas avec des méthodes plus classiques. Ces spécifications fonctionnelles sont remplacées par des user stories, qui vont guider les développements tout au long du projet. Voyons donc en quoi peut bien consister ces user stories.
En quoi consiste une user story ?
Comment l’appeler ? On parle de user story ou de récit utilisateur (en bon français, mais il faut reconnaître que ça « sonne » moins bien). L’expression « scénario client » est également utilisée, et est sans doute en français ce qui se rapproche le plus de la nature d’une user story.
En pratique, au lieu d’avoir des spécifications monolithiques pour guider les développements, les besoins du client vont être découpés en unités fonctionnelles, ou incréments fonctionnels. Les user stories sont issues de l’eXtreme Programming (XP). En résumé, chaque user story va décrire une fonctionnalité attendue par le client. Elle se présente sous une forme narrative, décrit le point de vue de l’utilisateur et n’aborde aucun point technique. La narration commence généralement par l’expression « En tant que… » et décrit un objectif à réaliser. Par exemple, « En tant qu’utilisateur, je veux pouvoir me connecter à l’application ». Vient ensuite la description de la fonctionnalité sous la forme d’une histoire, avec la description des contraintes, des pré-requis et des objectifs à atteindre.
Chaque user story se voit attribuer une priorité et le développement de la solution se fait de façon incrémentale. Avec un découpage suffisamment fin des user stories, on évite l’effet tunnel sur le projet, les fonctionnalités sont livrées en production plus rapidement et plus fréquemment, et les développements validés au fur et à mesure de leur réalisation.
Comment obtenir des user stories de qualité ?
Le découpage des besoins en user stories est un défi de taille. Elles doivent être suffisamment granulaires pour en permettre le développement, mais contenir tout de même assez d’informations pour être facilement compréhensible.
La rédaction d’une bonne user story se base sur six grands piliers de qualité : INVEST.
– Independant : chaque story doit être indépendante et produire les valeurs attendues pour la fonctionnalité décrite. Deux stories ne peuvent pas être dépendante. Si la story1 dépend de la story2, le temps de développement investi pour sa réalisation ne sera rentabilisé qu’à la fin de la réalisation de la story2. D’autre part, si pour une raison ou pour une autre, la priorité de la story2 venait à être réduite ou pire, si sa réalisation était annulée, tout le temps passé sur la story1 serait perdu.
– Negociable : n’importe quelle story peut à tout moment être remise en question. Afin que la négociation soit possible entre l’équipe métier et l’équipe de développement, le langage utilisé pour la rédaction de la user story doit être compréhensible de tous.
– Valuable : une user story doit apporter de la valeur au projet. Même si ça peut paraître évident, il arrive qu’une fois la user story identifiée, on soit incapable de décrire exactement quel bénéfice sa réalisation apportera à l’utilisateur. Dans ce cas, c’est très certainement qu’il existe une autre user story proche qui apporte qui apporte plus de valeur, ou qu’il ne s’agit pas réellement d’une user story, mais plutôt d’une tâche technique.
– Estimable : il doit être possible pour l’équipe de développement d’estimer l’effort à fournir pour la réalisation de la user story. L’équipe doit être en mesure de déterminer la meilleure solution technique pour réaliser de la user story.
– Sized : la user story doit être la plus petite possible. Pour réduire la taille d’une user story, il est possible de la découper en éléments plus petits.
– Testable : chaque user story développée doit pouvoir être testée. Le ou les scénarios de tests doivent être décrits de façon suffisamment précise pour que l’équipe métier, en les appliquant, soit en mesure de valider la user story.
Pourquoi réduire la taille des user stories ?
L’intérêt d’avoir des user stories courtes, c’est de réduire le cycle de réalisation et sa durée. Avoir plus de user stories plus courtes permet d’obtenir une priorisation plus fine car il est plus facile d’identifier les fonctionnalités prioritaires. D’autre part, l’intégration de nouveaux membres dans l’équipe de développement pourra se faire plus facilement en leur confiant la réalisation de courtes user stories plutôt que de lourdes fonctionnalités. Il est plus facile de suivre l’avancement des développements et de prévenir tout débordement. On réduit ainsi les risques car les user stories sont plus facile à comprendre et à réaliser.
D’autre part, avec des user stories courtes, la satisfaction de l’équipe va grandissante car il en passe plus et plus souvent à l’état « Terminé ». La dynamique de l’équipe s’en trouve généralement améliorée, tout comme sa motivation. Là où des développement interminables peuvent rapidement miner le moral d’une équipe, la réalisation rapide de user stories courtes auront l’effet inverse.
De l’usage des post-it XP
Afin de mieux représenter les user stories auprès des équipes de développement et d’en obtenir une représentation concrète, nous allons utiliser un outil d’une rare efficacité : le post-it.
Chaque user story fera l’objet d’un post-it xp. L’ensemble de ces post-it sera accroché à un tableau accessible et visible de l’ensemble des équipes. De cette façon, chaque user story a une représentation unique et peut être manipulée par n’importe quel membre de l’équipe. Il est possible d’un coup d’œil de visualiser l’ensemble des user stories, les personnes qui sont responsables de leur développement et leur état d’avancement.
Les avantages de l’utilisation des user story
Mettre en place un développement incrémental avec les user stories plutôt qu’un développement monolithique permet d’éviter l’effet tunnel tant redouté. Plus les user stories seront courtes, et moins il y aura de variables à prendre en compte et de risques pour le projet.
Les mises en production peuvent être rapprochées et ainsi les fonctionnalités testées. L’application obtenue est bien plus robuste. Chaque membre de l’équipe a une vision commune des tests à réussir et des objectifs à atteindre.
D’autre part, si le client change d’avis ou demande la modification d’une fonctionnalité, les risques encourus sont minimisés. La modification d’une user story n’aura donc qu’un impact limité sur l’ensemble du projet, car l’effort nécessaire pour la nouvelle réalisation sera lui-même limité.
Une alternative aux post-it XP est d’utiliser le logiciel agile Nutcache pour créer un storyboard.
