Les spécifications fonctionnelles sans peine - 2ième partie: Qu'est-ce qu'une spec?

From The Joel on Software Translation Project

Revision as of 10:02, 23 September 2006 by Alan71 (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Article original: Painless Functional Specifications - Part 2: What's a Spec?
Date de publication: 03 Octobre 2000
Traducteur: Benoit Brodard
Vérifié par: Non-communiqué
Navigation: Retour à Main Page Retour à French FrenchFlag.png




(Avez vous déjà lu la première partie ? Sinon, elle est ici.)

Cette série d'articles traite des spécifications fonctionnelles , pas des spécifications techniques. Les gens confondent les deux. Je ne sais pas s'il y a une terminologie standard, mais voici ce que moi je veux dire lorsque j'emploie ces termes.

  1. Une spécification fonctionnelle décrit comment un produit fonctionnera, entièrement du point de vue de l'utilisateur. Elle ne s'attache pas à la façon d'implémenter la chose. Elle parle de fonctionnalités. Elle spécifie les écrans, les menus, les dialogues et ainsi de suite.
  2. Une spécification technique décrit l'implémentation interne du programme. Elle parle des structures de données, des modèles de bases de données relationnelles, du choix des langages et des outils de programmation, des algorithmes, etc.

Quand vous concevez un produit de A à Z, le plus important est de fixer précisément ce que va éprouver l'utilisateur. Quels sont les écrans, comment ils marchent, ce qu'ils font. Ensuite, vous vous inquiéterez de comment passer d'ici à là. Ça ne sert à rien de se disputer sur le langage de programmation qu'il faudra utiliser avant d'avoir décidé ce que votre produit va faire. Dans cette série d'articles, je parle seulement des spécifications fonctionnelles.

J'ai écrit un court exemple de specs qui devrait vous donner une idée de ce à quoi ressemble une bonne spécification fonctionnelle. Avant que nous allions plus loin, vous êtes prié de lire l'exemple de spec.

Vous l'avez lu ?

Non, vous ne l'avez pas lu. Allez le lire maintenant et revenez, pour que nous puissions parler plus en détail de ce qu'une bonne spec devrait ou ne devrait pas contenir. Je vous attends ici. Merci.

(attente patiente...)

San Juan Old City.jpg

Ah, bien, vous revoilà.

Voici quelques unes des choses que je mets dans toute spec.

Une décharge Simple protection. Si vous mettez un paragraphe disant quelque chose comme "Cette spec n'est pas terminée", les gens ne viendront pas dans votre bureau pour vous arrachez la tête. Le temps passant, quand la spec sera plus complète, vous pourrez changer cela en "cette spécification est terminée, à ma connaissance, mais si j'ai omis quelque chose, merci de me le dire". Ce qui me rappelle que pour toute spec il faut :

Un auteur. Un seul auteur. Certaines entreprises pensent que les spécifications devraient être écrites par une équipe. Si vous avez déjà essayé l'écriture en groupe, vous savez qu'il n'y a pas pire torture. Laissez l'écriture en groupe aux sociétés de conseil en management avec des armées de frais diplômés d'HEC qui ont besoin de s'agiter comme dans une ruche pour justifier leurs énormes tarifs. Vos specs devraient être détenues et écrites par une seule personne. Si votre produit est important, scindez le en plusieurs parties et donnez chacune à une personne différente pour qu'elle en rédige la spec de son côté . D'autres entreprises pensent que c'est prétentieux, ou que ce n'est pas du "bon travail d'équipe" si une personne est créditée pour une spec en mettant son nom dessus. Fadaise. Les gens devraient endosser la responsabilité et la propriété des choses qu'ils spécifient. Si quelque chose ne va pas dans la spec, il devrait y avoir un auteur désigné, avec son nom écrit en lettres capitales sur la spec, qui ait la responsabilité de le corriger.

Des scénarios. Quand vous êtes en train de concevoir un produit, vous avez besoin d'avoir en tête des scénarios réalistes décrivant comment les gens vont l'utiliser. Sinon, vous vous retrouvez à concevoir un produit qui ne correspond plus à aucun usage du monde réel (comme le Cue?Cat ). Listez les différents publics de votre produit, et imaginez pour chacun un utilisateur fictif, complètement imaginaire, mais complètement stéreotypé, qui utilise le produit d'une manière tout à fait typique. Le chapitre 9 de mon livre sur les interfaces utilisateurs (disponible gratuitement en ligne) parle de la façon de créer des utilisateurs fictifs et des scénarios. Voilà où vous les utilisez. Plus le scénario sera vivant et réaliste, meilleur sera votre travail de conception de produit pour vos utilisateurs réels ou imaginaires. C'est pourquoi j'ai tendance à rajouter pas mal de petits détails montés de toutes pièces.

Des non-buts. Quand vous êtes en train de fabriquer un produit avec une équipe, chacun a tendance à avoir sa petite fonctionnalité favorite, réelle ou imaginée, sans laquelle il ne peut vivre. Si vous les réalisez toutes, cela va vous prendre un temps infini et vous coûter beaucoup trop d'argent. Vous devez écrèmer les fonctionnalités dès le départ, et la meilleure façon de le faire, c'est avec une rubrique "Non-buts" dans votre spec. Les choses que nous n'allons pas faire quoi qu'il arrive. Un non-but peut être une fonctionnalité que vous n'aurez pas ("pas d'interface utilisateur télépathique"), ou quelque chose de plus général ("Nous ne tenons pas compte des performances pour cette version. Le produit peut être lent du moment qu'il marche. Si nous avons le temps dans la version 2, nous optimiserons les parties lentes). Ces non-buts seront probablement source de discussions, mais c'est important de les faire surgir le plus tôt possible. "On va pas l'faire" comme dit George Sr.

Un aperçu. C'est un peu la table des matières de votre spec. Cela peut être un simple diagramme, ou une grande discussion de l'architecture. Tout le monde lira cette partie pour comprendre le principe général, ensuite les détails seront plus clairs.

Des détails, des détails, des détails. Finalement, vous rentrez dans les détails. La plupart des gens sauteront cette partie jusqu'à ce qu'ils aient besoin d'un détail particulier. Quand vous concevez un service de type web, un bon moyen de le faire est de donner un nom canonique à chaque écran possible, et de fournir pour chacun un chapitre le décrivant dans les moindres détails, jusqu'à l'étourdissement .

Les détails sont l'élément le plus important d'une spécification fonctionnelle. Vous remarquerez dans l'exemple de spec comme je pars dans des détails faramineux pour parler de tous les cas d'erreur de la page de connexion. Qu'est-ce qui se passe si l'adresse e-mail n'est pas valide ? Si le mot de passe est erroné ? Tous ces cas de figure correspondent à du code réel qui va être écrit, mais, plus important encore, ces cas correspondent aux décisions que quelqu'un va devoir prendre. Quelqu'un doit décider quelle va être la règle pour un mot de passe oublié. Si vous ne décidez pas, vous ne pouvez pas écrire le code. La spécification doit documenter la décision.

Des questions en suspens. Il n'y a pas de problème à laisser des questions en suspens dans la première version des specs. Quand j'écris un premier brouillon, j'ai toujours beaucoup de questions en suspens, mais je les mets en évidence (en utilisant un style spécial que je puisse rechercher) et, si c'est approprié, je discute les différentes solutions possibles. Toutes les questions en suspens devront avoir trouvé réponse lorsque les programmeurs commenceront leur travail. (Vous pourriez penser que çà ne pose pas de problème de laisser les programmeurs commencer toutes les choses faciles et que vous résoudrez les questions en suspens plus tard. Mauvaise idée. Vous aurez assez de difficultés à répondre aux nouvelles questions qui vont surgir quand les programmeurs essaieront d'implémenter le code, sans avoir encore toutes les anciennes questions que vous connaissiez à l'avance et que vous auriez pu résoudre dès le départ. De plus, la manière dont vous résolvez toute partie non triviale peut avoir un impact majeur sur la manière dont le code devrait être écrit.)

Des annotations. Quand vous êtes en train de rédiger une spec, souvenez vous de vos différents lecteurs : les programmeurs, les testeurs, le marketing, les rédacteurs techniques, etc. A mesure que vous écrirez la spec, vous pourrez penser à des petits faits utiles qui seront d'une grande aide à seulement un des groupes. Par exemple, je mets en évidence les messages destinés aux programmeurs, qui décrivent habituellement des détails techniques de l'implémentation, dans des "Notes techniques". Les gens du Marketing ignorent celles-là. Les programmeurs les dévorent. Mes spécifications débordent souvent de "Notes aux testeurs", "Notes au marketing", "Notes de documentation."

El_Yunque_Waterfall

Les specs doivent vivre. Certaines équipes de développement adoptent une mentalité "chute d'eau" : nous allons concevoir le programme d'une seule traite , écrire une spec, l'imprimer, la jeter par dessus le mur aux programmeurs et rentrer chez nous. Tout ce que j'ai à dire, c'est : "Ha ha ha ha ha ha ha ha!"

C'est cette approche qui donne aux specs leur si mauvaise réputation. Beaucoup de gens m'ont dit, "les specs sont inutiles car personne ne les suit, elles ne sont jamais à jour, et elles ne reflètent jamais le produit."

Pardonnez moi. Peut-être que vos specs ne sont pas à jour et ne reflètent pas le produit. Mes specs sont mises à jour fréquemment. Cela continue pendant le développement du produit et la prise de nouvelles décisions. Les specs reflètent toujours notre meilleure compréhension collective de comment le produit va marcher. Les specs ne sont figées qu'une fois le code est terminé (donc, quand toutes les fonctionnalités sont terminées, il peut rester des tests et du debuggage à faire.)

Pour faciliter la vie des gens, je ne sors pas une nouvelle spec quotidiennement. Je maintiens habituellement une version à jour quelque part sur un serveur où l'équipe peut l'utiliser comme référence. Occasionellement, pour certaines étapes, j'imprime un exemplaire de la spec avec des notes de révision afin que les gens n'aient pas à relire tout le pavé -- ils peuvent suivre les notes de révision pour voir les changements effectués.

Qui devrait écrire les specs? Lisez tout sur cela dans la troisième partie.

Personal tools