Ce n'est pas une nouveauté, les spécifications sont souvent montrées du doigts à chaque dérapage d'un projet informatique. Je ne sais pas pour vous mais dans mes différentes expériences, j'ai souvent eu à faire à des specs tenant intégralement sur un "Post-It". C'est un classique. Pire, dernièrement, j'ai même eu à faire à des specs écrites sur un grain de riz. Comme me l'a fait remarquer à juste titre un collègue : "tes specs, c'est le titre de ton projet". Bien vu! Alors, pourquoi n'arrive-t-on pas à avoir ce type de document? Quelle est sa taille optimale? A quel niveau de détail doit-on aller?
Pourquoi n'arrive-t-on pas à avoir ce type de document? D'abord, posons nous une autre question : qui doit rédiger les spécifications? Le client? Le chef de projet? Le développeur?(oups!)... Dans mes différentes expériences, c'est celui qui était demandeur du produit et qui maîtrisait le mieux le métier qui rédigeait son expression de besoin. Par exemple, chez un éditeur, c'est le chef de produit qui me fournissait généralement ce document. Pour d'autres collègues qui réalisaient des développements "plus métiers", les consultants-formateurs étaient mis fortement à contribution tout simplement parce qu'ils avaient un contact très rapproché avec les utilisateurs et donc une connaissance très "terrain". Cela peut-il être le chef de projet? Oui s'il a et prend le temps de s'investir dans le métier de son projet. En tout cas, je crois qu'il est bon d'ailleurs que le chef de projet soit moteur dans cette action et qu'il aide son client à spécifier ses besoins dès lors qu'il n'y a pas d'assistance à maîtrise d'ouvrage (généralement dans les petites structures). Il en est de même pour le développeur qui peut aider son utilisateur à la rédaction (Attention, le développeur ne peut pas être mandaté pour rédiger seul les spécifications,. Ce serait un non sens). Dans tous les cas, le rédacteur doit avoir une coloration informatique (ou bien de se faire aider par quelqu'un qui en a une) pour produire un contenu exploitable par le développement.
Mais alors, pourquoi n'arrive-t-on pas à avoir ce type de document? Et bien appelons un chat "un chat" : la rédaction des spécifications peut-être d'un ennui considérable. Il faut comprendre le métier, en faire une rétro-analyse, extraire toutes ses règles de gestion. Tout ça prend du temps. Et ce temps, le métier ne l'a pas forcément car il doit continuer à produire. D'autre part, les processus de travail ne sont bien souvent pas décrits. Honnêtement, vous en avez vu des documents décrivant les cycles de travail d'un service? Chacun y va de sa petite adaptation et c'est naturel. Bref, il est plus facile de jeter quelques phrases pendant une réunion (voire dans un couloir) pour expliquer ce dont on a besoin. D'où les specs "Post-It" mondialement connues mais malheureusement insuffisantes pour produire une application car elles laissent trop de zones d'ombre au développeur. Pire, elles permettent de s'engouffrer dans ce "no spec land" et d'inventer un métier qu'on ne connait pas. Résultat : la qualité attendue n'est pas au rendez-vous et cela donne lieu à des aller-retours avec le développement, des retards de livraison et des coûts explosifs, etc, etc...
Quelle est sa taille optimale? J'ai tendance à croire que des spécifications doivent être synthétiques. J'ai déjà eu un cas dans la vraie vie où les spécifications faisaient 300 pages. Ca arrive... Le développeur a reçu cela comme un pavé dans la figure (Karine, si tu te reconnais...) . Donc, soit le rédacteur est un littéraire et n'a pas compris que la valeur artistique de son document n'est pas l'objectif du travail demandé, soit il n'a pas l'esprit de synthèse. Il faut l'aider à reformuler sa demande. Il peut aussi s'agir d'un métier trop gros à décrire et là il faut découper le projet en sous lots car, de toute façon, le développeur ne retiendra pas le contenu de ces 300 pages. Dans la plupart des projets que j'ai rencontré, 10 pages par lot sont généralement suffisantes.
A quel niveau de détail doit-on aller? Là encore, je crois qu'il faut être synthétique. Dans une de mes précédentes entreprises, nous avions mené un travail sur le contenu des documents de spécifications. Nous avions pris partie de remplacer des pans complets de texte par des diagrammes UML. Par exemple, montrez les composants du projet dans un diagramme de classes. Montrez ensuite leur comportements à travers de diagrammes d'activité. Ne cherchez pas à respecter la norme à fond pour aller jusqu'à la génération de code. Enrichissez plutôt vos diagrammes avec des commentaires. Il peuvent d'ailleurs décrire des règles de gestion. Donnez leur alors des numéros, des codes. Je me fais un peu de pub au passage en vous rappelant que vous pouvez faire tout cela rapidement avec Violet UML Editor. En tant que développeur expérimenté, j'aime bien avoir des maquettes dès lors qu'une interface graphique doit être produite. Un powerpoint est largement suffisant pour cela. Enfin, je pense que la démarche de spécification doit être itérative. On ne peut pas tout décrire d'un seul trait. C'est d'ailleurs ce que préconise SCRUM. Produisez un document de spécifications générales et et détaillez le à chaque étape d'implémentation. Vous aurez en plus économisé votre énergie si vous décidez finalement de ne pas tout réaliser.
Que peut-on en conclure? Que des specs "grains de riz" ne sont bien évidemment pas acceptables car elles coûtent cher à l'entreprise en temps et en argent. En tant que développeur, nous pouvons être acteur de notre bonheur ou de notre malheur. Précisons ce que nous attendons en terme de documentation et exigeons une spécification générale. Si le projet démarre sans, organisez une réunion pour l'obtenir. Les "Post-Its" ont la peau dure mais nous finirons bien par nous en débarrasser!
Aucun commentaire:
Enregistrer un commentaire