Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Les spécifications fonctionnelles sans peine - 1ière Partie: Pourquoi se prendre la tête?


Par Joël Spolsky
Traduit par Benoit Brodard
2 octobre 2000

Quand le Test de Joël est paru pour la première fois , un des points les plus délicats relevés par les lecteurs concernait la rédaction de spécifications. Apparemment, les specs, c'est comme le fil dentaire : tout le monde sait qu'il faudrait s'en servir, mais personne ne le fait.

Pouquoi les gens ne veulent-ils pas écrire de specs? Les gens prétendent que c'est parce qu'ils économisent du temps en sautant la phase de rédaction des specs. Ils se comportent comme si écrire des specs était un luxe réservé aux ingénieurs de la navette spatiale de la NASA, ou à ceux qui travaillent pour de gigantesques compagnies d'assurance ayant pignon sur rue. Non sens! Premièrement, ne pas rédiger de specs est le seul gros risque que vous prenez inutilement dans un projet informatique. C'est aussi stupide que de se préparer à traverser le Sahara avec pour seul équipement vos habits sur le dos, en espérant "faire avec". Les programmeurs et ingénieurs logiciel qui plongent dans le code sans rédiger une spécification ont tendance à se prendre pour de vrais rambos tirant des rafales d'arme automatique. Grossière erreur. Ils sont terriblement peu productifs. Ils écrivent un code très mauvais, produisent des logiciels à trois balles, et ils menacent leurs projets en prenant d'énormes risques dont on se passerait bien.

Je crois que pour tout projet non trivial (plus d'une semaine de code ou plus d'un programmeur), si vous n'avez pas de specs, vous passerez toujours plus de temps que prévu pour un code de moins bonne qualité. Voici pourquoi.

La fonction la plus importante d'une spec est de concevoir l'architecture du programme. Même si vous travaillez seul sur du code et que vous écrivez une spec dans votre seul intérêt, le fait d'écrire cette spec -- détaillant la marche du programme par le menu -- vous forcera à effectivement concevoir le programme.

Rendons une petite visite imaginaire à deux programmeurs dans deux entreprises. Rapideau, chez IllicoPrestoSoftware, n'écrit jamais de specs. "Des specs ? On n'a pas besoin de foutues specs!". Au même moment, M. Dupont, chez SoftBlindé Entrepreneurs SA, refuse d'écrire la moindre ligne de code avant que les specs n'aient été complètement détaillées. Ce ne sont que deux de mes nombreux amis imaginaires.

Rapideau et M. Dupont ont une chose en commun : ils ont tous les deux la responsabilité de la compatibilité ascendante de la version 2.0 de leur produit respectif.

Rapideau décide que le meilleur moyen de fournir cette compatibilité ascendante est d'écrire un convertisseur qui transforme les fichiers 1.0 en fichiers 2.0, tout simplement. Il se lance là dedans. Tap, tap, tap, clic, clic, clac. Les disques durs tournent, la poussière vole. Au bout de deux semaines, il a un convertisseur acceptable. Mais les clients de Rapideau ne sont pas satisfaits. Son code les obligera à mettre à jour immédiatement tout le monde dans la société avec cette nouvelle version. Le plus gros client de Rapideau, ServiceRapide SA, refuse d'acheter le nouveau logiciel. ServiceRapide SA veut obtenir la garantie que la version 2.0 pourra encore marcher avec des fichiers version 1.0, sans les convertir. Rapideau décide d'écrire un convertisseur descendant et le branche dans la fonction "Enregistrer". C'est un peu le bazar, parce que quand vous utilisez des fonctionnalités de la version 2.0, ça semble marcher, jusqu'à ce que vous sauvegardiez au format 1.0. C'est seulement à ce moment que vous apprenez que la fonctionnalité utilisée il y a une demi-heure ne marche pas dans l'ancien format. Finalement, le convertisseur descendant a requis deux semaines supplémentaires et ce n'est pas la panacée. Temps écoulé : 4 semaines.

Maintenant, M. Dupont, chez SoftBlindé SA (SBSA pour les intimes), est un de ces gars maniaques qui refusent d'écrire du code tant qu'ils n'ont pas une spécification. Il passe environ 20 minutes à déterminer la fonctionnalité de compatibilité ascendante comme Rapideau l'a fait, et arrive à une spécification qui en gros dit :

  • Quand on ouvre un fichier créé avec une version antérieure du produit, le fichier est converti au nouveau format.

La spécification est présentée au client qui dit : "Attendez une minute! Nous ne voulons pas migrer tout le monde en même temps !" Donc M. Dupont, pousse sa réflexion, et met à jour la spec :

  • Quand on ouvre un fichier créé avec une version antérieure du produit, le fichier est converti au nouveau format en mémoire. Quand le fichier est enregistré, l'utilisateur à le choix de le reconvertir à nouveau.

20 minutes supplémentaires se sont écoulées.

Le chef de M. Dupont, un objet-maniaque, regarde cette spec et trouve que quelque chose ne va pas. Il suggère une architecture différente.

  • Le code sera factorisé pour utiliser 2 interfaces : V1 et V2. V1 contient toutes les fonctionnalités V1.0 et V2.0 qui hérite de V1, ajoute toutes les nouvelles fonctionnalités. Maintenant, V1::Save peut supporter la compatibilité ascendante tandis que V2::Save peut être utilisé pour enregistrer tout ce qui est nouveau. Si vous avez ouvert un fichier V1 et essayez d'utiliser une fonctionnalité V2, le programme peut vous avertir immédiatement, et vous n'aurez qu'à convertir votre fichier ou vous résigner à ne pas utiliser la fonctionnalité.

20 minutes de plus.

M. Dupont tempête. Cette factorisation va prendre 3 semaines au lieu des 2 estimées initialement ! Mais cela résout tous les soucis du client, d'une manière élégante. Donc il code cette solution.

Temps total écoulé pour M. Dupont : 3 semaines et 1 heure. Temps écoulé pour Rapideau : 4 semaines, mais son code n'est pas aussi bon.

La morale de cette histoire, c'est qu'avec un exemple bien ficelé vous pouvez prouver à peu près n'importe quoi! Euh. Non, c'est pas ce que je voulais dire. La morale de l'histoire c'est que lorsque vous planifiez votre produit en language humain, cela prend quelques minutes pour balayer plusieurs possibilités, réviser ou améliorer votre architecture. Cela ne pose de problème à personne d'effacer un paragraphe dans un traitement de texte. Mais lorsque vous concevez votre produit avec un langage de programmation, la conception itérative prend des semaines. Pire encore, un programmeur qui a travaillé 2 semaines sur du code va être relativement attaché à ce code, aussi mauvais soit-il. Rien de ce que pourraient dire le chef et les clients de Rapideau ne pourra le convaincre de jeter à la poubelle son magnifique code de conversion, même si ça n'est pas la meilleure architecture. En conséquence, le produit final a tendance à être un compromis entre la mauvaise conception initiale et la conception idéale. C'est "la meilleure architecture que nous puissions avoir, étant donné que nous avions déjà écrit tout ce code et ne voulions pas le jeter à la poubelle". Pas vraiment aussi bien que "la meilleure architecture que nous puissions trouver, point."

C'est donc l'énorme raison numéro 1 d'écrire une spec. L'énorme raison numéro 2 est d'économiser du temps en communiquant. Quand vous écrivez une spec, vous ne devez communiquer qu'une seule fois la manière dont le programme est supposé fonctionner. Chacun dans l'équipe peut tout simplement lire la spec. Les gens de l'Assurance Qualité la lisent pour savoir comment le programme est sensé marché et comment le tester. Les gens du Marketing l'utilisent pour écrire leurs vagues whitepapers vaporeux à balancer sur le site web au sujet de produits qui n'existent pas encore. Les gens du Business Developpement le lisent de travers pour raconter des fantaisies sur la manière dont le produit guérira la calvitie, l'acnée et autres ... mais cela attire les investisseurs, donc c'est parfait. Les développeurs la lisent pour savoir quel code écrire. Les clients la lisent afin d'être sûrs que les développeurs préparent un produit pour lequel ils sont prêts à payer. Les rédacteurs techniques la lisent et sortent un joli manuel (qui est perdu ou jeté, mais c'est une autre histoire). Les responsables la lisent pour avoir l'air de savoir ce qui se passe pendant les réunions de suivi. Et ainsi de suite.

Quand vous n'avez pas de spec, toutes cette communication a bien lieu, parce qu'elle doit avoir lieu, mais elle a lieu comme ça vient. Les gens de l'Assurance Qualité jouent un peu avec le programme l'air de ne pas y toucher, et quand quelque chose parait étrange, il vont interrompre une fois de plus les programmeurs, pour leur poser une autre question stupide sur la manière dont le truc fonctionne. A part le fait que cela sape la productivité des développeurs, ceux-ci ont tendance à donner une réponse correspondant au code qu'ils ont écrit plutôt que la "réponse juste". En somme, les gens de l'Assurance Qualité testent le programme par rapport au programme, et non le programme par rapport à sa conception. Ce qui serait, euh, un tout petit peu plus utile.

Quand vous n'avez pas de spec, le plus (tristement) comique est ce qui arrive aux pauvres rédacteurs techniques. Souvent, les rédacteurs techniques n'ont pas pouvoir pour interrompre les développeurs. Dans de nombreuses entreprises, si les rédacteurs techniques prennent l'habitude d'interrompre les programmeurs pour leur demander comment quelque chose est supposé marcher, les programmeurs vont voir leur responsable, pleurent qu'ils n'arrivent à rien à cause de ces [censuré] de rédacteurs, et le prient de bien vouloir les tenir à l'écart, et le responsable d'obtempérer pour essayer de gagner sur la productivité et d'interdire aux rédacteurs techniques de gâcher une miette supplémentaire du temps précieux des développeurs. Vous pouvez toujours reconnaître ces entreprises, car leurs fichiers d'aide et leurs manuels ne vous donnent pas plus d'information que ce que vous pouvez déduire vous-mêmes de l'écran. Quand vous voyez ce message à l'écran :

  • Souhaitez-vous activer le support LRF-1914 ?

... et que vous cliquez "Aide", un sujet d'aide tragicomique s'affiche, du style :

  • Vous permet de choisir le support LRF-1914 (par défaut) ou non. Si vous souhaitez le support LRF-1914, choisissez "Oui" ou pressez "O". Si vous ne souhaitez pas le support LRF-1914, choisissez "Non" ou pressez "N".

Hum, merci. Il est assez évident ici que les rédacteurs techniques ont essayé de dissimuler le fait qu'ils ne savaient pas en quoi consistait le support LRF-1914. Ils n'ont pas pu interroger le programmeur parce que (a) ils sont intimidés, ou (b) le programmeur est à Tataouine les Bains et ils sont à Paris, ou (c) le management leur a interdit d'interrompre les développeurs, ou tout un tas d'autres pathologies institutionnelles trop nombreuses à citer, mais le problème fondamental est qu'il n'y avait pas de specs .

L'énorme raison numéro 3 d'avoir une spec, c'est que sans une spec détaillée, il est impossible de faire un planning. Ne pas avoir de planning est parfait s'il s'agit de votre thèse de doctorat et que vous pensez passer 14 ans sur la chose, ou si vous êtes développeurs sur le prochain Duke Nukem et que l' on sortira le produit quand on sera fin prêts. Mais pour presque tous types d'affaires sérieuses, vous devez juste savoir combien de temps les choses vont vous prendre, parce que développer un produit coûte de l'argent. Vous n'achèteriez pas un jean sans connaître son prix. Alors comment une entreprise responsable peut-elle décider de fabriquer un produit sans même savoir le temps que cela prendra, et donc combien cela coûtera ? Pour plus d'infos sur la planification, lisez les plannings de développement sans peine.

Une erreur terriblement répandue est de débattre de comment concevoir quelque chose, puis de ne jamais terminer la discussion. Brian Valentin, le développeur en chef de Windows 2000, était connu pour sa devise "Des décisions en moins de 10 minutes, ou la prochaine est gratuite!".

Dans trop de structures de développement, chaque fois qu'un débat de conception surgit, personne ne réussit jamais à emporter une décision, le plus souvent pour des raisons politiques. Du coup les programmeurs ne travaillent que sur les sujets bien établis où il y a consensus. Comme le temps passe, toutes les décisions compliquées sont remises à la fin. Voilà les projets qui ont le plus de chance d'échouer. Si vous démarrez une nouvelle entreprise autour d'une nouvelle technologie et observez que votre entreprise est de par son fonctionnement incapable de prendre des décisions, vous pouvez aussi bien tout arrêter immédiatement et rendre leur argent aux investisseurs, parce que vous ne sortirez jamais rien.

Ecrire une spec est un excellent moyen de fixer une fois pour toutes ces décisions de conception agaçantes, petites et grandes, qui restent masquées si vous n'avez pas de spec. Même de petits choix peuvent être arrêtés avec une spec. Par exemple, vous construisez un site web avec adhésion, vous pouvez vous entendre sur le fait que si l'utilisateur oublie son mot de passe, vous lui enverrez par mél. Parfait. Mais ce n'est pas suffisant pour écrire le code. Pour cela, vous devez connaître la formulation finale de ce mél. Dans la plupart des entreprises, on ne fait pas confiance au développeur dans le choix des mots que lira l'utilisateur (et à raison en général ). Donc il sera sûrement fait appel à une personne du département marketing ou des relations publiques, ou un diplômé ès lettres pour trouver la formulation précise du message. "Cher Groumpf, Voici le mot de passe que vous avez oublié. Essayez d'être moins négligeant dans le futur." Quand vous vous forcez à écrire des specs de qualité, complètes (et j'en dirai beaucoup plus à ce sujet prochainement), vous notez toutes ces choses et vous les corrigez, ou au moins vous les signalez avec un grand drapeau rouge.

Bien. Nous sommes sur la même longueur d'onde à présent. Les specs sont les mamelles de tout projet. Je soupçonne que la plupart d'entre vous comprend cela et que ma véhémence, certes distrayante, ne vous apprend rien de nouveau. Alors pourquoi personne n'écrit-il de specs? Ce n'est pas pour économiser du temps, ce n'est pas le cas et je pense que la plupart des développeurs le reconnaissent (Dans la plupart des organisations, les seules specs qui existent sont des textes d'une page, dans un style télégraphique, que le programmeur a bâclé dans Notepad après avoir écrit le code et après avoir expliqué la foutue fonctionnalité à la 300ème personne).

Je pense que c'est parce que beaucoup de personnes n'aiment pas écrire. Fixer un écran blanc est très frustrant. Personnellement, j'ai dépassé ma crainte d'écrire en suivant un cours à la fac qui nécessitait un essai de 3-5 pages par semaine. L'écriture est comme un muscle. Plus vous écrivez, plus vous pourrez écrire. Si vous devez écrire des specs et n'y arrivez pas, commencez un journal, créez un weblog, suivez un cours d'écriture créative, ou écrivez juste une belle lettre à chaque proche ou ancien coturne que vous avez snobbés depuis 4 ans. Tout ce qui implique de coucher des mots sur le papier améliorera vos capacités à écrire des specs. Si vous êtes chef de projet, et que les personnes supposées écrire les specs ne le font pas, envoyez les dans un de ces séminaires d'écriture créative à la campagne.

Si vous n'avez jamais travaillé dans une entreprise qui écrit des spécifications fonctionnelles, vous n'en avez peut-être jamais vu une. Dans le prochain article de cette série, je vous montrerai un court exemple de spec que vous pourrez analyser, et nous parlerons de ce qu'une bonne spec doit contenir. Lire la suite, tout de suite !



Cet article est paru en version originale anglaise sous le titre Painless Functional Specifications  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky