C’est sûrement un débat sans fin. Qui n’a jamais eu ou entendu cette discussion concernant la gestion de projet : est-il préférable de rédiger des spécifications fonctionnelles détaillées (sur Word par exemple) ou de de privilégier les user stories ? Chacune de ces deux méthodes possède ses avantages et ses inconvénients.
Les spécifications fonctionnelles
Un peu d’histoire pour commencer. Une spécification détaillée est plutôt liée au fameux cycle en V, qui est une méthode de gestion de projet divisée en plusieurs étapes bien ordonnées dans le but de livrer un produit bien spécifié. La spécification se fait donc en une seule fois en amont, puis une fois cette étape terminée, le reste du projet peut commencer : la conception, le développement, les différentes phases de test puis la recette et la livraison. Les phases se succèdent mais impossible de passer à l’étape suivante sans avoir fini celle qui est en cours.
Les avantages des spécifications détaillées peuvent être de plusieurs ordres selon votre profil :
Côté clients, une spécification complète permet de se projeter dans l’avenir et d’obtenir une vision du futur produit livré. Certains clients sont ainsi rassurés quand ils voient vraiment en détails les règles sur les fonctionnalités. De plus, certains n’hésitent pas à consacrer un temps certain à la lecture d’une spécification.
Côté développeurs, avoir une spécification complète permet aux « Back end » de bien modéliser la base de données en début de projet. Une approche qui peut être bénéfique en fonction du projet.
Côté business analyst et testeurs, voire même développeurs, avoir un document propre, documenté est toujours d’une grande aide pour la prise en main d’un projet, pour les nouveaux arrivants et surtout pour l’historique du projet. Une spécification détaillée sur un document Word par exemple est structurée avec des paragraphes. Résultat, inutile de chercher les fonctionnalités dans des cinquantaines de JIRA créés pour les users stories (dans le cas de ceux qui utilisent JIRA par exemple). Les informations sont structurées et on ne se perd pas.
Quels sont alors les inconvénients d’une spécification détaillée ?
Côté clients, il arrive qu’ils oublient une fonctionnalité ou lisent une spécification en diagonal et la valide. Généralement, quand les clients valident, il est difficile de retourner en arrière, ou d’ajouter et de supprimer des fonctionnalités, parce que l’équipe projet a un budget et un timing à respecter. Le projet devient donc moins flexible et il en résulte des clients insatisfaits.
Côté développeurs, soyons honnêtes, tous les développeurs ne liront pas les 30 pages de spécifications détaillées, surtout s’il ne s’agit pas d’un nouveau projet qui commence. Par expérience, j’ai remarqué qu’ils se penchent quand même dans leur lecture pour un nouveau projet, mais s’il ne s’agit que de changements ou de nouvelles fonctionnalités, ils se contentent d’une lecture en diagonale des nouvelles fonctionnalités et préfèrent plutôt poser des questions directement… même si les réponses aux questions se trouvent dans la spécification.
Côté business analyst, rédiger une spécification qui serait “parfaite” est quasi impossible, alors que c’est un prérequis du cycle en V pour le bon déroulement du projet. Il n’est pas rare qu’un business analyst ou qu’un client oublie une information utile, que le client valide la spécification et que le développeur ne se pose pas de questions par rapport à ce qui est écrit. Résultat des courses : le produit n’est pas conforme à l’attente !
S’il existe sûrement d’autres avantages et inconvénients d’une spécification Word, tels sont les principaux. Mais qu’en est-il alors des user stories ?
Le principe de « user story »
Une user story peut être associée à plusieurs méthodologies agiles, dont le Scrum et Xtrem programming par exemple. Ici, nous parlerons donc plutôt des user stories de l’agilité Scrum. Tout d’abord avec le Scrum, il n’y a plus de distinctions entre développeurs, business analysts ou testeurs, il existe juste une équipe de développement qui inclut toutes ces spécialités. Cette équipe a pour but de mettre en place un produit « fini » à la fin du sprint. Tous les membres de l’équipe de développement sont donc tous responsables de la qualité de ce produit fini.
Principal avantage d’une user story ? Elle permet vraiment d’être « agile » :
Côtés clients, dans le cas d’un oubli, il n’est jamais trop tard. Ils peuvent faire part de leurs souhaits au product owner qui se chargera de l’ajouter dans le backlog et de les prioriser lors des différents sprints planning. Le projet devient donc plus flexible.
Côté équipe de développement, cela leur permettrait de bien distinguer les différentes tâches qui sont regroupées par fonctionnalité. Ainsi, même si la notion du temps est assez élastique en agilité, l’estimation est mieux affinée et le temps de développement est mieux respecté, au profit de toute l’équipe. Aussi, les user stories sont largement moins chargées en informations, mais tout aussi complètes qu’une spécification, leur écriture est plus facile et peut se faire par petites fonctionnalités tout au long des sprints, la relecture peut se faire rapidement et il est plus facile de s’assurer que toute l‘équipe soit bien en phase et comprenne la même chose.
Et bien sûr, il y a aussi des inconvénients. Parmi lesquels :
Côté clients, ils ont moins la possibilité de se projeter dans le futur, tout simplement parce qu’ils n’ont pas forcément à leur disposition toutes les user stories en début de projet.
Côté projet lui-même, le risque de perdre la cohérence globale des fonctionnalités est réel : les user stories mettent en avant les petites fonctionnalités et, à force de se focaliser dans les détails, il est possible que les user stories ne soient pas harmonisées entre elles.
Côté équipe de développement, contrairement à une spécification, une « vraie » user story ne contient que du texte, généralement sous la forme suivante : « En tant que… je veux… dans le but de… » Il n’y a ni diagramme, ni tableau, ce qui fait qu’une information contenue dans un tableau ou un diagramme doit être réécrite. Une manipulation qui, dans le cas d’une fonctionnalité complexe, peut considérablement compliquer la compréhension et la relecture. Cependant, il reste quand même possible, dans le cadre de l’agilité, d’utiliser des mock-ups, des storyboards ou des diagrammes. Mais le problème, ici, est que les informations sont encore dispatchées. En fonction des outils utilisés donc, la recherche d’information est plus pénible car certaines phrases sont redondantes pour les user stories. L’outil utilisé peut ne pas permettre d’optimiser la recherche d’informations et les noyer facilement dans des dizaines de stories. Aussi, ne connaissant pas forcément en détail le contenu des user stories à venir, l’équipe doit se montrer plus vigilante pour le choix des technologies utilisées afin qu’un changement dans un futur sprint ne soit pas trop complexe à mettre en place.
En résumé, les deux façons de faire possèdent chacune leurs inconvénients et leurs avantages. Ainsi, les spécifications fonctionnelles détaillées permettent d’être plutôt « proactifs », c’est-à-dire qu’on essaie de capitaliser et d’anticiper l’avenir (la conception de la base, la recherche et la récupération d’informations, etc.). Une bonne capitalisation se repose sur le fait que le produit est toujours d’actualité et utilisable. Or pour rester utilisable, un produit doit être continuellement amélioré. Une spécification détaillée nécessite donc d’être revue et optimisée en permanence en fonction de la vie du projet.
Les user stories quant à elles permettent d’être plutôt « réactifs », c’est-à-dire qu’on pense plutôt au moment présent et au futur très proche. Si besoin, et sous l’aval du product owner, les user stories peuvent être révisées et réajustées lors des prochains sprints. Pour autant, elles ne nous privent pas non plus de la proactivité, car il est possible de bien écrire plusieurs user stories à l’avance et de les ajouter au backlog pour priorisation.
Il est donc possible, voire même indispensable, d’allier proactivité et réactivité pour le bon fonctionnement du projet. Il ne faut pas se cacher sous les méthodologies pour être moins réactifs ou proactifs, il faut simplement trouver la bonne solution qui peut faire cohabiter les deux.
Sources :
10 tips writing good user stories
Pour approfondir au sujet de la conception logiciel :
méthode de rédaction exigences d’un projet/
Pas encore de commentaires