Je vous ai déjà parlé de différentes méthodes de gestion de projet. Entre autre, j’ai déjà écrit des articles sur le cycle en V et le cycle itératif, ainsi que sur les méthodes agiles. Ces méthodes, et plus particulièrement les méthodes agiles, sont globalement axées sur la gestion des développements. Comprenez par là que leur but est d’arriver à la création d’un produit fini avec le meilleur rapport qualité/coût/délai.
Bien souvent, quand on met en place une méthode de travail, on se focalise sur les phases de réalisation du travail. Puis on s’intéresse à ce qui a lieu en aval, le processus qualité et les étapes de livraison. Par contre, on aborde assez rarement la manière dont les spécifications sont réalisées et gérées.
C’est paradoxal : à quoi bon améliorer les processus de développement, si le travail à effectuer est mal défini ?
Spécifications agiles
Une − mauvaise − réponse est apportée par certaines personnes qui interprètent mal les principes agiles. Quand on applique les méthodes agiles, on cherche la satisfaction du client plutôt que l’accomplissement d’un cahier des charges figé. Malheureusement, cela se traduit parfois par la disparition de toute forme de spécification. Au lieu d’apporter une souplesse salutaire, cela peut conduire à un va-et-vient incessant entre le client et l’équipe technique en charge de la réalisation.
La mise en place de cycles itératifs a pour but évident de fluidifier le cheminement expression-de-besoin / spécification / réalisation. À chaque itération, le besoin du client est écouté, analysé, interprété, rediscuté. Les zones d’ombre sont identifiées et laissées de côté pour les prochaines itérations.
Le corollaire de cela, c’est que chaque itération doit pouvoir être réalisée dans des conditions essentielles de stabilité. La méthode Scrum prévoit d’ailleurs deux rôles bien spéciaux : le product owner représente le client et peut répondre aux questions concernant le produit ; le scrum master protège l’équipe des requêtes impromptues.
Mon expérience
J’ai déjà expliqué dans un précédent article comment nous appliquons les méthodes agiles dans mon entreprise. Pour résumer : des cycles de développement d’un mois, séparés en sprints hebdomadaires ; 2 ou 3 sprints de développement, un sprint de stabilisation (tests, débugs), un sprint de MEP (mise en pré-production, validation, mise en production).
La mise en place de ces cycles a eu des effets très positifs. Nous perdons moins de temps tout en augmentant la qualité de notre travail. Nous continuons à identifier les points qui peuvent être encore améliorés.
L’application de cette méthode de travail a toutefois mis en exergue les lacunes que nous avions au niveau de la gestion de nos spécifications fonctionnelles. C’est assez facile de s’en rendre compte : pour qu’un projet soit développé, il faut que sa spécification soit écrite et validée avant la fin du mois précédant le cycle de développement. Si la spec n’est pas prête ou si elle est incomplète, elle devrait être simplement refusée et repoussée au cycle d’après ; mais bien souvent, cela a amené à des négociations concernant les dates de livraison, le niveau de précision, ou la latitude de validation technique autorisée sur les spécifications fonctionnelles.
Ce qui m’a amené à réfléchir au processus global qui mène à l’élaboration des spécifications.
Les étapes
Pour commencer, toute évolution fonctionnelle (nouvelle fonctionnalité ou amélioration d’une fonctionnalité existante) commence par une idée. Cela peut être une simple suggestion ou une conviction forte, exposée succinctement ou être relativement élaborée. Cette idée peut être amenée par n’importe quel membre de l’entreprise ; dans les faits, seul un nombre réduit de personnes participent réellement de cette manière, majoritairement celles occupant des postes-clés (PDG, directeur technique, directeur des contenus, directeur commercial, responsable de la direction artistique, chef de projet fonctionnel, responsable du développement commercial, gestionnaire de la communauté, responsable du référencement).
Ces idées sont discutées chaque semaine en comité restreint (PDG, directeur technique, chef de projet fonctionnel) afin d’en évaluer la faisabilité et la valeur stratégique pour l’entreprise, à partir de leurs apports fonctionnels et/ou commerciaux et de leurs coûts, eux-mêmes fonction de leur complexité technique. Les personnes étant à l’origine de chaque idée sont habituellement conviées à ces discussions, pour fournir les précisions nécessaires à cette évaluation.
Si une idée est validée, elle devient un projet, placé entre les mains du chef de projet fonctionnel. Il a pour mission d’écrire une expression de besoin, en association avec la personne ayant exprimé l’idée initiale. Cette expression de besoin est plus importante qu’on pourrait le croire, car elle va servir de base de travail pour l’écriture de la spécification fonctionnelle finale.
Armé de l’expression de besoin, le chef de projet fonctionnel va consulter chaque personne dont les remarques doivent être prises en compte. C’est à ce moment que sont intégrées les notions de référencement, les aspects communautaires, les contraintes ergonomiques ou de design, ou encore les implications techniques. Le chef de projet a alors un rôle primordial ; il doit comprendre les différents aspects du projet, proposer des solutions, remonter les points de blocage. C’est à la fois un manager et un leader ; un manager car il doit faire travailler ensemble des intervenants qui n’ont pas de rapport hiérarchiques entre eux (ni entre lui et eux) ; un leader car il a pour but de faire aboutir le projet et a donc la possibilité − jusqu’à un certain point − de faire des choix et prendre des décisions.
Une fois que les différents impératifs ont été pris en compte, le chef de projet écrit la spec fonctionnelle. Si on revient à notre organisation en cycles mensuels, cette spécification doit avoir été validée d’un point de vue business (par le PDG) et technique (par le directeur technique) avant la fin du mois, si on veut que le projet soit développé le mois suivant.
Le découpage en lots
Certains projets sont trop conséquents pour pouvoir être réalisés en un seul cycle de développement. On peut alors découpé le projet en plusieurs lots fonctionnels, l’objectif étant de pouvoir livrer une version utilisable à la fin de chaque cycle de développement. Les spécifications doivent prendre cela en compte.
La difficulté de l’exercice est de ne pas occulter un aspect important du projet, sous prétexte qu’il est tronçonné. Si la précipitation occasionne une erreur au niveau du référencement, par exemple, il sera long et difficile de la rattraper.
Les révisions
Il n’en reste pas moins qu’une spécification vit au cours du temps. Rien ne reste gravé dans le marbre jusqu’à la fin des temps. Dans une démarche agile, il faut être préparé à faire face au changement ; il faut même le vouloir, car on sait que la perfection n’existe pas et qu’une fonctionnalité doit être améliorée au fil du temps.
Il est donc important de ne pas s’arrêter à l’écriture de la spécification initiale. Il faut prendre en compte un cycle de révision et de réécriture, qui reprend les étapes vues précédemment. Seule l’expression de besoin est mise de côté, devenue inutile.
L’idéal est de laisser passer au moins un mois entre chaque évolution d’une spécification. Ça permet de prendre du recul par rapport au résultat d’un développement et de la réponse des utilisateurs.
Dans tous les cas, les évolutions peuvent porter d’un cycle à un autre. Il est hors de question de faire évoluer une spécification en cours de développement. À force de demander des modifications alors que « la peinture n’est même pas sèche », on sombrerait dans une sorte d’immobilisme permanent.
Articles très intéressant , Merci .
ceci est vraiment dommage car j’ai déjà vu des PDG ou autre personnes à poste clé ne rien y comprendre au développement et encore moins au processus de développement .
Je suis totalement d’accords avec ce paragraphes
le découpages en lot me fait penser au methodes CMMI .
Cependant je pense qu il y a un décalage lorsque comme dans votre exemple, les spécif sont rédiger avec des intervenant interne a l ‘entreprise et un client . J’ai l’impression que le client est toujours en retard pour valider les spécif et donc tous nos cycle de developpement sont décalés . De même le client réclame toujours des modifications .
C’est vrai. Mais je parle ici des spécifications fonctionnelles, pas des spécifications techniques. Les personnes qui peuvent faire les bons choix fonctionnels n’ont pas forcément besoin de comprendre les impacts techniques ; je suis là pour fournir l’information. L’idée est de donner la bonne direction, de faire les choix cruciaux pour l’entreprise, ses utilisateurs et ses clients.
Sinon, c’est vrai qu’être notre propre client aide beaucoup. Cela fluidifie énormément le processus. S’il fallait communiquer avec un client extérieur, il faudrait sûrement être plus ferme sur les dates auxquelles les différentes étapes de réalisation des specs doivent être terminées.
Un client (qu’il soit interne ou externe) doit être éduqué ; il faut lui faire comprendre que les demandes de modifications ne posent aucun problème, mais qu’elle doivent intervenir entre les itérations, pas au cours d’un cycle de développement.
Quelques remarques :
Avec la crise (mais c’était déjà le cas dans des entreprises de taille moyenne ou un sou est un sou) les décideurs associent à l’idée :
– un coût,
– un délai (le fameux Time To Market)
Le coût correspond à ce que l’on fait dans la vie courante (j’achète pas une voiture, j’achète une voiture pour un budget max). Alors pourquoi pas dans l’informatique ?
Ensuite entre l’idée et l’expression de besoin, je fais 2 choses :
– exprimer une cible par les décideurs (pour décrire ce que l’on aura pour le prix et éviter les évolutions toujours coûteuses)
– plan d’action pour assurer l’adhésion de ce que l’on appelle le management opérationnel
Sans avoir pratiqué, mais pour avoir vu faire, je ne suis pas un adepte des méthodes agiles car je trouve qu’elles génèrent beaucoup de coûts annexes et que l’on n’anticipe pas le coût final.
Globalement d’accord.
Par contre, les méthodes agiles permettent au client d’en avoir pour son argent. Avec des itérations plus courtes, le bilan «quel résultat j’obtiens par rapport à l’argent que j’ai mis» se fait plus fréquemment. Le client voit concrètement où il en est, et peut décider de passer à l’itération suivante ou de tout arrêter et d’en rester là. Et les coûts associés à chaque itération sont mieux maîtrisés que sur de longs projets en mode tunnel.
Mais bon, on s’éloigne du sujet, là.
Selon vous, quel est le meilleur format pour une spéc fonctionnelle aussi bien en terme de facilité de maintenance côté MOA et facilité d’utilisation côté technique ? Word, google docs, autre ?
De même comment faut-il faciliter la visualisation des anciennes versions ou faut-il uniquement privilégier la dernière version ?
@max : Comme bien souvent, les spécifications sont une question d’organisation et de process, pas une question d’outil. Il est donc préférable de commencer par faire des spécifications bancales en utilisant des outils inadaptés, plutôt que de ne pas faire de spec du tout.
Un point important : Une spécification fonctionnelle n’est pas une spécification technique. La seconde doit être écrite à partir de la première, et elle peuvent prendre des formes très différentes.
Un exemple :
– La spécification fonctionnelle est écrite sur un wiki. Elle contient des liens vers les images de maquette. C’est facile et rapide à utiliser, tout le monde sait où trouver l’information.
– Au fil des discussions, la spec fonctionnelle évolue. Une seule personne est habilitée à la modifier.
– Une fois qu’elle est stable, on fait une spec technique minimale, qui peut être une page de wiki ou une pièce-jointe associée à un ticket (dans un système de buglist ou de todo-list). Elle est complétée par un diagramme UML, un squelette de code (objets contenant la signature des méthodes, et la documentation associée) ou des tests unitaires (si vous pratiquez les TDD).
Il faut privilégier l’accès à la dernière version des spécifications. Elle doit être disponible immédiatement, sans avoir à faire de tri parmi des milliers d’autres similaires. Par contre, il peut être très intéressant de pouvoir remonter dans le temps et de comparer les différentes versions, même si ça demande un effort supplémentaire. Les wikis sont très forts à ce jeu-là.