Mis à jour en novembre 2010 Voilà plusieurs mois que j'avais en tête de rédiger un article traitant des spécifications. J'ai toujours été convaincu que l'art de rédiger des spécifications pouvait constituer un levier fort de réussite d'un projet. Dans cet article, je partage donc mon expérience et mes connaissances sur le sujet, j'y décris un processus de rédaction dans le cadre d'une approche Agile ainsi que deux techniques d'écriture. D'une part la rédaction de User Stories (pratique issue de eXtreme Programming) et d'autre part, celle des cas d'utilisation à la Alistair Cockburn (porteur de la méthode Agile Crystal et faisant parti des 17 premiers signataires du manifeste Agile). Pré requis : "accepter la réalité"On ne peut pas comprendre l'approche Agile de rédaction des spécifications sans admettre les réalités suivantes :
Une autre réalité importante concerne les travers de la communication par écrit (voir schéma ci dessous). En effet, les écrits peuvent être interprétés de différentes façons, en particulier lorsque le sujet traité est complexe. Inutile de rappeler que la réalisation d'un logiciel de nos jours est une tâche particulièrement complexe tant fonctionnellement que techniquement. D'autre part, la communication par écrit est unilatérale (pas de questions/réponses).  Source : Alistair Cockburn Or il est malheureusement assez fréquent de constater - dans des projets traditionnels - que le rédacteur du cahier des charges, n'est pas la même personne que le rédacteur des spécifications fonctionnelles générales qui n'est pas la même personne que le rédacteur des spécifications fonctionnelles détaillées qui n'est pas la même personne que celle qui développe qui n'est pas la même personne que celle qui teste. Il arrive même que ces différents acteurs ne se rencontrent jamais dans un projet. Comment dans ces cas là garantir une bonne couverture du besoin ? Autrement dit, on peut tout de suite oublier l'idée de spécifier à l'avance tout un logiciel et faire valider de son sang au client un gros pavé de spécifications indigestes à forte connotation contractuelle. Pavé qu'il validerait sans vraiment le lire, puisqu'au delà du côté "indigestion", on le bouscule afin de démarrer au plus vite les développements (hé oui, le planning est déjà serré !). Dans le cadre d'une approche Agile, on spécifie au fil de l'eau. Chaque itération comporte des activités de spécification au même titre que celles de développement et de test. Processus de spécificationCahier des chargesA bien y réfléchir, le processus de spécification commence dès le cahier des charges (CDC). Un CDC traditionnel est déjà porteur de spécifications relativement détaillées du besoin. Souvent ces premières spécifications sont rédigées par des consultants métier consciencieux et particulièrement soucieux de ne rien oublier quitte à en rajouter et s'y noyer (et noyer le(s) lecteur(s) surtout). Or dans le cadre d'un appel d'offre Agile, le CDC est particulièrement light étant donné qu'au mieux, ce dernier ne contient que la liste des besoins (ou liste d'exigences) sans rentrer dans le détail de chacun. Liste des besoinsCertain consultants Agile chevronnés donnent une première leçon d'agilité à un client en jetant le CDC traditionnel détaillé à la poubelle (c'est une bonne façon de capter l'attention du client ;-) ) pour ensuite prendre un paper board et remplir ce dernier de la liste des besoins (Product Backlog ou liste d'exigence). Liste obtenue en discutant directement avec le client. La liste ne sera peut être pas complète mais en principe les fonctionnalités les plus attendues sont là. Ces dernières sont "estimées" par l'équipe de développement, la durée de l'itération est fixée, le tout en collaboration avec le client. Avant l'itérationAvant de planifier une itération, les besoins prioritaires (candidats au périmètre de la prochaine itération) doivent être ajustés. Les profils porteurs du besoin à couvrir par l'application à développer peuvent assurer cet ajustement qui va consister principalement à formaliser le besoin en User Stories. On va donc s'assurer que ce besoin est mûr, que les pré requis sont ou seront disponibles en temps voulu (décisions, jeux de données,...). La rédaction d'une User Story concentre l'effort sur le besoin de fond laissant de côté les détails d'IHM (au besoin une maquette peut être annexée). Aucune connotation technique n'est permise, le langage naturel de l'utilisateur est privilégié. Une User Story doit être lisible aussi bien par un utilisateur que par un développeur. Par ailleurs, la User Story est porteuse des tests d'acceptation permettant de vérifier la couverture du besoin. Ces tests doivent être rédigés en amont des développements afin de guider au maximum ces derniers. Pendant l'itérationPendant l'itération, on retrouve l'ensemble des activités classiques : analyse du besoin, conception, développement et test. Ces activités peuvent intervenir à n'importe quel moment de l'itération, une fonctionnalité 'A' peut être conçue, développée et testée en début d'itération alors qu'une fonctionnalité 'B' peut être conçue, développée et testée en milieu ou fin d'itération. Au cours de l'itération, le développeur et le rédacteur de la User Story (utilisateur, expert métier, consultant métier AMOA, Product Owner) peuvent compléter cette dernière (un test auquel personne n'avait pensé à ajouter par exemple). Avant la fin de l'itération, l'équipe de développement se charge de mettre à jour la documentation générale du produit (spécifications fonctionnelles détaillées pouvant être rédigées en cas d'utilisation, dossier d'architecture technique, procédure d'installation,...). Au besoin chaque document peut être versionné à chaque itération. Autrement dit l'enjeu de validation des spécifications est faible voir nul, car on accorde plus d'importance au produit partiel que l'on va présenter en démonstration à la fin de l'itération. Fin d'itérationA la fin de l'itération, l'équipe de développement présente donc le produit partiel incrémenté des nouvelles fonctionnalités développées. A cette occasion, le Product Owner accepte ou rejette ces fonctionnalités. C'est bel et bien sur ces dernières que l'enjeu se situe plutôt que sur la validation des spécifications qui ne servent plus à verrouiller contractuellement le périmètre mais à maintenir le produit pour les futurs développeurs qui maintiendrons le produit. Techniques de spécificationsUne bonne spécification fonctionnelle est synthétique, facile (voir agréable) à lire aussi bien par un développeur que par un utilisateur, facile à maintenir et non ambiguë. Autrement dit, c'est tout un challenge. L'objectif est d'aboutir à des spécifications nécessaire et suffisantes. Les techniques de rédaction des cas d'utilisation façon Alistair Cockbrurn ou de rédaction des User Stories permettent d'atteindre cet objectif. Quelques soit la technique choisie, 2 règles d'or doivent être respectées :
Bien appliquées, ces 2 règles permettent d'atteindre une bonne part des objectifs évoqués au début de ce paragraphe. Une dernière précision avant de décrire la façon de rédiger une User Story puis un cas d'utilisation : le périmètre fonctionnel d'une User Story est la plupart du temps inférieur à celui d'un cas d'utilisation "haut niveau", autrement dit un cas d'utilisation peut contenir plusieurs User Story mais l'inverse est rare (à moins de rédiger des cas d'utilisation bas niveau décrivant des mécanismes invisibles pour l'utilisateur). Les 2 techniques sont très complémentaires et peuvent donc être utilisées ensemble. Dans certain contexte exigeants, les User Stories ne peuvent être considérées comme des spécifications mais simplement comme un précieux support permettant de planifier plus facilement les itérations et de piloter les développements par les tests. Dans ce cas, on utilisera les cas d'utilisation en complément afin de formaliser davantage les choses. User StoryRien de mieux qu'un exemple pour poser le décor. Principales caractéristiques :
Plus précisément, une User Story doit être INVEST :
Le pilotage des développements par les tests constitue un facteur qualité important. Une spécification sous forme de test lève toute ambiguïté ou presque, laissant peu de place aux mauvaises interprétations du besoin. Une fonctionnalité n'est pas considérée comme terminée tant que les tests inscrits sur la User Story ne sont pas tous passants. D'autre part, ces tests vont aider le développeur à coder les bons tests unitaires automatisés en approche TDD. Une bonne approche consiste également à utiliser le format bristol A5, pour différentes raisons :
Pendant ou à la fin de l'itération, le contenu des User Stories alimentera au besoin la documentation du produit (spécifications fonctionnelles détaillées par exemple. Après tout il faut pas oublier ceux qui reprendrons le projet en cours de route) ainsi que les plans de test détaillés (pour les tests d'ensemble avant mise en production, généralement réalisés par l'AMOA). Une fois ce travail réalisé, les User Stories peuvent être jetées ou archivées. Pour en savoir plus, je recommande l'ouvrage "User Stories applied" de Mike Cohn. Un livre à acheter les yeux fermé, il regorge de conseils précieux et d'exemples concrets. Même si comme toutes les pratiques Agile, on peut assez facilement se jeter à l'eau sans forcément lire le bouquin. Cas d'utilisationCe que je vais décrire dans ce paragraphe ne concerne pas les cas d'utilisation UML. Dans un contexte Agile, on considère l'UML comme trop difficile d'accès pour un utilisateur ou le client (parfois même pour les développeurs non initiés). On préférera donc utiliser des cas d'utilisation textuels. Là encore, rien ne vaut un exemple. Cet exemple ci dessous est un cas d'utilisation plutôt "haut niveau". On peut au besoin descendre un peu plus et détailler certaines étapes. Dans ce cas, on souligne généralement dans le cas d'utilisation "haut niveau" le mot clef de l'étape en question illustrant le plus le sous cas d'utilisation lié (exemple : "payer", "recherche",...). On établit ainsi un lien entre le cas d'utilisation et ses sous cas d'utilisation. Pour aller plus loin, l'ouvrage suivant st votre ami : Rédiger des cas d'utilisation efficaces. |
|
|
|
Accueil >
Les spécifications Agile |