Parlons un peu des spécifications fonctionnelles, affectueusement surnommées specs sous nos lattitudes.

Tous les soucis de l’humanité, y compris le réchauffement climatique, pourraient être annihilés par l’introduction d’une étape systématique d’écriture de specs dans les process de dev.

En fait, la méthode “specs sur un coin de table” est mon pire cauchemar.

Je ne sais travailler que d’une manière : avec des specs rigoureuses et pédagogues.

Des specs rigoureuses

Un document rigoureux décrit des fonctionnalités, contre-validées par les interessés, à jour et quantifiables.

Des fonctionnalités

Les foncionnalités du sujet de notre spec’ sont les services que doit rendre le logiciel pour résoudre le problème concret d’un utilisateur.

Les discussion de la pertinence de ces solutions pour le client, ou des moyens techniques pour les implémenter sont à considérer orthogonalement.

Diviser les préoccupations (Comment résoudre le problème de l’utilisateur ? Comment implémenter nos idées ? ) permet de donner à chacune l’attention qu’elle mérite.

Contre-validées

Elles doivent être validées par le client ou le ProductOwner, pour le compte des utilisateurs.

Comme ce document devient la référence de l’équipe, il doit refléter parfaitement le besoin de l’utilisateur, ou, du moins, l’idée que le client ou le Product Owner s’en fait.

D’un point de vue stratégique, il faut que le document reflète les préoccupations de la personne/l’entreprise qui va le payer.

D’un point de vue pratique, il faut que le document reflète les besoin de la personne/l’entreprise qui va l’utiliser.

À jour

Tout changement de stratégie ou de compréhension du besoin doit être transmis par écrit, par l’evolution du document.

Quantifiables

Des fonctionnalités quantifiables sont testables. C’est le seul moyen de vérifier qu’elles ont été implémentées.

Des specs pédagogues

Un document pédagogue ne suppose pas, de la part du lecteur, la connaissance d’un contexte particulier au projet.

Les intervenants, le vocabulaire métier, les précédentes itérations seront inconnues pour un nouveau membre de l’équipe. Supposer que quiconque lira ces document connait tous ces détails est dangereux.

Rédigée avec un vocabulaire précis et défini.

Une équipe de chercheur à l’University of Southern Denmark a montré que 78.7 % des incompréhensions dans les équipes de développement logiciel sont dues à l’utilisation de termes vagues et généraux à la place de termes précis. Ces mot généraux n’ont absolument pas le meme sens pour les différents intervenants.

C’est vrai dans la plupart des métiers techniques, surtout si la technologie est récente. C’est otu a fait normal et difficile à éviter : nous n’avons pas vraiment de termes universels pour discuter logiciel. Nous exprimons nos idées avec des mots franglais que nous entendons çà et là.

Le meilleur moyen d’éviter les incompréhensions et d’utiliser au maximum des mots plus précis et surtout d’expliquer un maximum les mots que nous utilisons. Surtout à l’écrit.

N. D. A. : Il n’y pas vraiment eu d’étude à l’University of Southern Denmark . C’est juste une figure de style, mais ne me dites pas que vous n’avez jamais rencontré ce genre de situation !

Chaque fonctionnalité doit être décrite explicitement et complètement

La description d’une fonctionnalité ne doit laisser aucun doute sur les point importants.

Toute notion implicite ou soumis à l’interprétation sera mal interprété.

Pour chaque fonctionnalité, ces quelques questions sont pour moi un bon point de départ :

  • Qui utilise la fonctionnalité ?

  • Dans quel but ?

  • Sur quelle machine/OS/browser ?

  • Quelles sont les entrées ?

  • Quel doit être la sortie ?

Plusieurs de ces réponses peuvent être factorisées pour l’ensemble de la spec’, mais il faut y répondre au moins une fois.

Ceci est d’autant plus vrai dans la rédaction des demandes d’évolutions/corrections de bug sur un projet existant. Ces demandes sont souvent écrites par des intervenants qui conaissent très bien le logiciel pour en avoir suivi le déroulement depuis le début, et sont souvent lues par des “jeunes” de l’équipe qui ne le connaissent pas du tout, surtout dans une industrie à fort turnover comme celle du logiciel.

Les Objections

Ce discours rencontre beaucoup d’objections.

Evidemment ce que je présente est une méthode idéale. L’idée n’est pas de l’appliquer telle quelle mais de tendre vers quelque chose qui y ressemble. Toutes les équipes sont différentes et toutes les équipes ont leur méthodes.

Néanmoins, voici quelques objections que je rencontre, et auxquelles il me parait important de répondre.

Ces objections sont une réponse à “Essayons de mettre en place une étape plus systématique d’écritures de specs rigoureuses avant de se lancer dans les devs”.

Objection n° 1 : Nous n’avons pas le temps

Nous n’avons pas le temps. Nous ne sommes pas assez nombreux.

Ce que j’entends derrière ces phrases, c’est l’expression d’une idée terrifiante : l’étape d’écriture propre et rigoureuse des specs serait une étape parasite, coûteuse, inutile, dont on se passerait volontiers, et que l’on autoriserait juste pour faire plaisir à celui qui la demande.

C’est le symptôme d’un sentiment d’urgence qui pousse à croire que tout le temps qui n’est pas passé à coder ne produit pas de valeur et ne rapporte pas d’argent. Le coût de l’écriture d’une spec’ propre et rigoureuse serait un coût parasite qu’il faut réduire à tout prix, comme une taxe farfelue ou les frais de port de l’encre de la machine à écrire.

Au contraire, écrire des specs c’est gagner du temps.

Que ce soit une évolution, une correction de bug, ou la genèse d’un nouveau produit révolutionnaire le problème est le même. Une discussion autour d’un café, ou un bout de papier griffonné sur le coin du bureau ne permet pas de transmettre complètement et les nuances des fonctionnalités attendues par le client/PO/utilisateur. Toute incompréhension qui n’est pas découverte à temps est une source de problème : refaire des pan entier de code, gérer de la frustration, du stress.

En d’autres termes, là, on va doucement, parcequ’on est pressé.

Entre l’idée qui germe et la concrétisation de cette idée par une fonctionnalité logicielle, il y aura des aller-retour, des itérations. Entre le Product Owner et le client, entre le Product Owner et l’équipe de dev. Beaucoup d’aller-retour. Beaucoup de personnes. Beaucoup d’idées.

Chacun de ces aller-retours coûte du temps et de l’énergie à tous ses intervenants.

On peut réduire ce coût de deux manières.

  • en réduisant le coût de chaque itération

Pour ça, privilégier un dialogue le plus fluide possible, qui permet des corrections rapides. Typiquement, éviter que le dialogue soit un process de commit-déploiement-test-retour. C’est fastidieux d’écrire du code, c’est long de déployer le soft pour le montrer. Autant le faire le moins possible et plutôt faire un maximum d’itérations en utilisant des maquettes, des schémas, des mots.

Si quelque chose a été mal compris dans la chaîne client->PO->…->équipe de dev, le meilleur moment pour détecter et corriger l’incompréhension, c’est avant d’écrire la moindre ligne de code.

  • en réduisant le nombre d’itérations

Faire en sorte que chaque aller et chaque retour soit le plus précis et explicite possible pour assurer la meilleure communication possible de nos idées. Chaque incompréhension implique une itération supplémentaire.

Objection n°2 : Elles ne seront pas maintenues et on en reviendra au point de départ.

C’est vrai que ça demande une discipline. Mais sur le long terme, on gagne du temps.

Quand une évolution est demandée, on change le code. Essayons d’avoir la même discipline avec la spec’ . Le code permet au développeur de produire du logiciel avec le PC, la spec’ permet au chef de projet de produire du logiciel avec le développeur. Si le chef de projet tient sa spec à jour, le code sera à jour.

Objection n°3 : On a toujours fait sans, ça a toujours très bien marché.

C’est vrai.

Dans une start-up, une équipe de 2 ou 3, il n’y a pas toujours des process bien définis. On se lance, on essaie de livrer, on a des contraintes financières et temporelles. Un équilibre informel se met en place. L’alchimie entre les membres de l’équipe donne de bon résultat. On se comprends bien, on connait tous bien le projet, on a des itérations rapides.

Ca marche.

Puis le projet murit, les clients se multiplient, l’équipe grossit. A ce moment là, des nouveaux membres arrivent, qui ont peut être des habitudes différentes. Des caractères différents. Une moins bonne connaissance du projet, du client. On est plus nombreux. Et surtout, on est peut-être un peu plus fatigués.

À ce moment là, mettre en place des process plus rigoureux peut devenir un vrai avantage. Les nouveaux arrivants ne sont pas perdu dans un chaos qui n’est pas le leur. Les plus anciens peuvent déléguer sans soucis, convaincu que l’information passe bien, même avec les nouveaux. Les erreurs stratégiques sont réduites, car on est plus sur d’avoir bien compris ce que veut le client.

Objection n°4 : C’est l’agilité ! On ne fait plus de specs !

L’agilité n’a jamais été synonyme de “pas du tout de specs”. C’est plutôt la démarche, entre autre, de “accepter que les specs changent en cours de route”. C’est exact, je ne connais pas d’autre manière de faire. Les specs vont changer. Et tracer ces changement aide encore à comprendre l’historique et le but du projet sans ambiguité.

Conclusion

La résistance

Finalement, Joel Spolsky a montré que la vrai résistance est face à l’action : personne n’aime écrire des specs. Tout le monde sait, au fond, que c’est mieux, c’est juste pénible.

Les devs aiment coder.

Les chefs de Projet Ils aiment la relation client.

Embauchons des gens qui aiment ça ? Je le fais, moi. Pas de problèmes. C’est ma spécialité.

Un avantage compétitif

Dans notre industrie, beaucoup d’encre coule au sujet des avantages compétitif de tel ou tel outil : un langage révolutionnaire, une architecture magique, la panacée de la gestion de version.

Mais l’excellence n’est pas dans une botte secrète.

Regardons Michael Jordan ? Est-ce qu’il a mené les Bulls à la victoire 6 fois, sans faillir, grâce à des bottes secrètes ? Non. Il a pratiqué les bases de son art encore et encore. Le tir parfait. La passe parfaite. L’excellence est dans l’exécution parfaite des fondamentaux.

Faisons l’expérience avec le logiciel : prenez n’importe quel livre qui ressemble de près ou de loin à “programmer pour les nuls”. Chapitre 1 : les specs. Avant Hello World. Avant la boucle for. Avant les designs pattern.

Pour être excellent, soyons les Michael Jordan du logiciel : appliquons les fondamentaux. Écrivons des specs parfaites.