Gestion des spécifications

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.