Sinon « on » risque de mauvaises surprises genre « Mais dans votre spéc approuvée le … ce n’était pas du tout ce qui était demandé ! ».

Certains décideurs sont très à cheval sur la « spéc » validée lors de la négociation …

Ton article confirme ce que je pensais, mais beaucoup de questions restent en suspens, j’y reviens par la suite.

Tout d’abord, je plussoie pour dire que Word n’est à mon avis pas la panacée pour les spécifications « itératives ». L’idée du wiki m’intéresse mais je n’ai jamais testé pour l’instant. Cependant, avec ce type d’outil, on se confronte à la difficulté de générer un document papier « propre ».

En ce qui concerne les questions en suspens :
1° Quelle fréquence pour les itérations? Le problème étant qu’à chaque version majeure, il faut faire valider par la MOA qui peut se lasser (et donc perdre de la pertinence dans son intervention).

2° Quel contenu pour les spécs? En scrum, les dévs ont besoin des « user stories » pour commencer un sprint. Est-ce que dans ce cas là, les spécs sont le recueil de ces user stories ou est-ce que l’on doit s’efforcer de décrire des cas d’utilisations de type UML?

3° Comment s’intègre le process de rédaction des spécs avec le projet dans sa globalité?
A moins que je sois complètement à côté de la plaque, je suppose qu’une partie des spécs est rédigée en amont de la phase de développement. Dans ce cas, à quel moment décider que les spécifications sont assez « matures » (?) pour passer aux dévs?

Puisque j’ai lancé l’idée il ne me reste plus qu’à écrire une spécification pour mes robots et à la publier sur le Touilleur Express, histoire d’appuyer mon charabia un peu emballé, qui manque d’explications.

Concernant l’Agilité, j’essayais de dire qu’il est important d’expliquer qu’il est tout à fait possible d’être Agile et d’écrire une spécification, et qu’il est conseillé de se poser avant de se lancer trop rapidement dans un projet.

On en reparle autour d’une biere
A bientot

Nicolas

1. tu commences par critiquer les vendeurs d’agilité soit, mais j’ai du mal à voir la relation avec l’écriture des specs. N’y a t’il que les agilistes qui n’écrivent pas de specs papiers ? (note : l’agilité d’ailleurs ne dit jamais de ne pas écrire de docs, seulement de ne pas oublier que le résultat attendu est du code, pas la doc).

2. ensuite, tu insistes sur la forme. Tout à fait d’accord, une doc intéressante mal présentée ne sera pas lu comme il se doit. Mais tu écris 3 paragraphes pour « conclure » par un « il faut une image et un texte de 25 lignes car personne ne lit les docs ».

3. on continue. L’intérêt de l’écriture de docs ? Se forcer à communiquer les besoins du client de manière claire (mais tout seul hein, faut pas déconner, à 2 ca marche pas). Chez toi, y’a qu’une personne qui voit le client et qui essaye de comprendre ce qu’il faut faire ? Je frémis .

4. tu finis par la mise en avant de Word, qui est pour moi la meilleure façon de faire n’importe quoi. En phase de réflexion, des outils de mindmaps (ou autre type de graphe), dashboard, post it… permettent de réfléchir bien mieux avec le client ou en interne. Un traitement de texte, c’est fait pour écrire au kilomètre, pas pour réfléchir ou collaborer. Comme dit en commentaire, un wiki est déjà bien meilleur.

Bref, je n’adhère pas du tout à tes arguments. Par contre je partage une idée qui est en filigramme dans ton post : il faut réfléchir avant de commencer à coder tête baissé. Il faut bien discuter avec le client, partager avec les utilisateurs finaux, échanger… et c’est bien plus que faire une doc Word.

Désolé pour ma réponse rapide et surement pas trés construite. Si j’ai pas compris tes propos alors je te devrais une bière au prochain ParisJUG .

Bon devoxx

Etant donné que ces specs resteront entre développeurs, un wiki permet de faire évoluer rapidement les spécs avec le code.

Par contre le traitement de texte ne devrait être réservé qu’aux projets obscurs profondément enfouis dans la soute. Dés qu’un projet requiert une interaction utilisateur les specs doivent être faites sous forme de maquettes. Une description textuelle n’aura jamais la puissance descriptive d’une maquette. Un dessin vaut mieux qu’un long discours.

C’est pour ça que je fais mes specs sous Balsamiq et que j’utilise une présentation pour coller le tout ensemble. 1 slide 1 fonctionnalité avec une image et un texte court. Si ça ne tient pas la fonctionnalité est trop compliquée et il faut la découper.

Pourquoi ne pas citer openoffice.org qui en plus possède une jolie fonction qui permet de faire à tout moment du versionning de document (du vrai versionning, je ne parle pas de suivi de correction, ce que c’est faire tout logiciel bureautique.)

Et de très facilement mettre à disposition des relecteurs un pdf en un clic.