Ceux qui connaissent mal les méthodes de gestion de projet agiles peuvent avoir l’impression que les équipes travaillent sans spécifications. Les objectifs varient d’un sprint à l’autre, on ne sait pas exactement ce qu’il y aura dans le sprint suivant… Pourtant, c’est loin d’être le cas. Dire qu’un projet agile n’a pas de spécifications est totalement faux. Ce qui est vrai en revanche, c’est que le mode de conception des spécifications fonctionnelles agiles est totalement différent de celui d’une méthode classique.
Petit rappel sur les spécifications fonctionnelles
Les spécifications fonctionnelles ont pour objectif de décrire précisément l’ensemble des fonctions d’un logiciel ou d’une application, et de fixer ainsi le périmètre fonctionnel du projet.
La rédaction des spécifications est basée sur l’expression des besoins du client, généralement regroupés et reformulés dans un cahier des charges. La spécification d’une fonction va donc décrire dans le détail les services qu’elle va fournir à l’application ou à l’utilisateur. Pour un site web, on pourra retrouver par exemple l’affichage de la page d’accueil, l’affichage des menus, l’identification des utilisateurs, le suivi des visiteurs, la gestion du panier s’il s’agit d’un site de e-commerce…
Les spécifications fonctionnelles vont donc décrire les aspects métier de l’application, et leur mise en place, leur organisation.
A ce stade, les solutions techniques ne sont pas abordées. C’est-à-dire que les différentes fonctions de l’application vont être détaillées, mais pas les moyens de les mettre en œuvre. L’architecture, les technologies et le matériel seront décrits dans les spécifications techniques.
Un aspect parfois oublié des spécifications fonctionnelles est qu’elles doivent inclure également des scénarios de tests. En effet, il est important à ce stade de prévoir la façon dont il sera possible de vérifier que la fonction développée correspond bien à la fonctionnalité décrite.
Rédaction des spécifications dans le cadre d’une gestion de projet classique
Dans le cadre d’une gestion de projet en cascade ou avec un cycle en V, le périmètre fonctionnel est parfaitement cadré dès le début. Cela signifie que l’on définit une liste exhaustive des fonctionnalités avant de les décrire une par une.
Chaque fonctionnalité va être détaillée de façon à ce qu’elle soit compréhensible par le client, qui pourra ainsi vérifier que la description correspond bien à ce qu’il attend, et par l’équipe de développement, qui pourra en réaliser une version fidèle.
Dans une méthode de gestion de projet classique, la phase de réalisation ne peut démarrer que lorsque l’intégralité des spécifications fonctionnelles a été rédigée, et validée par le client. Cela signifie qu’il peut parfois se passer des semaines, voire des mois, entre le début de la rédaction des spécifications fonctionnelles, et le début des développements.
Cette façon de faire est donc adaptée à des projets dont on connaît bien les fonctionnalités, le cœur du métier, et qui ne variera pas, ou très peu au cours du temps.
Ce processus de rédaction des spécifications fonctionnelles une fois pour toutes avant le démarrage de la réalisation pose tout de même quelques problèmes.
Pour commencer, il est très rare que les utilisateurs soient en mesure de décrire de façon exhaustive l’ensemble des fonctionnalités qu’ils veulent voir embarquées dans l’application. De plus, le processus s’étalant dans le temps, il est très probable que l’analyse des besoins, la rédaction du cahier des charges, la rédaction des spécifications fonctionnelles, les développements et les tests soient effectués par des personnes différentes. Il va donc falloir assurer une bonne communication entre tous les acteurs afin de ne pas perdre d’information. La transmission de ces informations est rendue encore plus compliquée lors de projets très longs, car il est courant que des personnes partent et que d’autres arrivent, sans jamais se croiser.
Se pose également la question de la maintenance des spécifications fonctionnelles. Même si les besoins varient peu au cours du projet (dans le cas contraire, mieux vaut opter pour une méthode agile), il faudra mettre à jour régulièrement les spécifications pour tenir compte des avancées, et des éventuels problèmes identifiés lors de la réalisation.
Les spécifications fonctionnelles agiles
Comme nous venons de le voir, il est très compliqué, voire illusoire, de pouvoir rédiger des spécifications fonctionnelles exhaustives.
Peut-on alors développer sans se baser sur des spécifications ?
Non, bien entendu. La gestion de projet ne laisse pas de place (ou si peu) à l’improvisation. Il faut donc des spécifications fonctionnelles, pour traduire les besoins du client en fonctions applicatives, et pour guider ensuite les équipes techniques dans leurs réalisations.
Les spécifications fonctionnelles agiles ne vont donc pas être rédigées intégralement dès le début du projet. Elles prendront corps au contraire tout au long de son déroulement. Chaque spécification fonctionnelle sera rédigée juste avant son développement. Afin que ce processus soit efficace, il va falloir beaucoup de rigueur, et une communication sans faille entre le product owner d’un côté, et l’équipe de développement de l’autre.
Contrairement à une méthode classique, la responsabilité de la rédaction des spécifications fonctionnelles est partagée. Le client, au travers de son product owner va aider à décrire son besoin et les spécifications. L’équipe de développement va déterminer l’architecture et les solutions techniques à mettre en œuvre, et les testeurs vont identifier les cas limites à vérifier. L’identification des tests en amont des développements va permettre d’une part d’affiner les spécifications, et d’autre part de vérifier plus rapidement la conformité du comportement de l’application.
Procéder de cette façon présente plusieurs avantages.
Le projet se déroulant sous la forme d’itérations, les spécifications fonctionnelles agiles bénéficient au moment où elles sont rédigées, de l’ensemble de l’historique du projet. Vous disposez à ce moment précis de toutes les informations compilées depuis le début du projet, y compris les contraintes nouvelles qui auraient pu être identifiées lors des sprints précédents. D’autre part, les spécifications fonctionnelles agiles étant rédigées juste avant les développements, l’équipe de développement les a encore en tête au moment de la réalisation. C’est beaucoup plus simple que lorsqu’il faut reprendre un document rédigé plusieurs semaines auparavant, alors que l’on n’avait peut-être même pas encore intégré le projet. Les développeurs n’en seront donc que plus efficaces puisqu’ils n’auront pas à aller à la recherche d’informations auprès des précédents rédacteurs.
Tout comme les développements sont unitaires, les spécifications fonctionnelles agiles le sont également. Une spécification fonctionnelle agile se concentre sur une unique fonction de l’application, souvent présentée sous la forme d’une user story. Cela permet de mieux se concentrer sur la fonctionnalité en question, en faisant abstraction d’informations qui pourraient venir parasiter la compréhension du besoin.
Par contre, les spécifications fonctionnelles agiles nécessitent de travailler en flux tendu. Il est donc particulièrement risqué de rédiger les spécifications correspondant aux développements qui seront réalisés dans le sprint en cours. Il est important d’anticiper, et de créer les spécifications fonctionnelles en amont, avant le début du sprint de développement. Si vous disposez des spécifications fonctionnelles au moment du découpage des user stories et de leur répartition en différentes tâches, l’estimation de la charge de réalisation du sprint sera grandement facilitée et donc beaucoup plus précise.
Pour conclure sur les spécifications fonctionnelles agiles
Les spécifications fonctionnelles agiles représentent un mode différent de fonctionnement d’un projet. Elles apportent de la souplesse (elles peuvent être adaptées), de la précision (on se concentre sur une fonctionnalité unitaire) et de la fiabilité (bénéfice de l’historique du projet et informations récentes). En revanche, elles demandent de la rigueur, de façon à ce que leur préparation en amont des sprints facilite ensuite le travail des développeurs.
N’hésitez pas à tester gratuitement durant 14 jours la solution complète de gestion de projet agile Nutcache, qui met à la disposition de vos équipes un ensemble complet d’outils pour la gestion de vos spécifications fonctionnelles.
