Lettuce (and cucumber) is bullshit (fr)

Hou le vilain troll.

En gros, l'article revient, pour l'auteur, à dire : "je ne comprends pas l'intérêt de cucumber". Dont acte, mais pas la peine de cracher sur tout le monde pour exprimer son incompréhension.

Autant le dire tout de suite :

1°) j'adore cucumber
2°) je ne m'en suis jamais servi dans le cadre d'une startup

Lorsqu'on fait du développement agile ou tout autre forme de travail flexible, ça n'a effectivement que peu d'intérêt, ne serait-ce que parce que les specs changent en permanence et que quelqu'un qui voudrait s'intéresser au détail de l'implémentation du code n'aurait pas que ça à faire de relire l'ensemble toutes les semaines.

Cela dit, ça prend tout son sens lors de travail pour client, que ce soit des clients directs ou (surtout!) des agences.

Combien, parmi les gens qui ont travaillé en freelance ici, se sont déjà retrouvés avec une agence qui arrive avec un projet, disant qu'il est très gros, mais très urgent, mais très gros, mais très urgent, çavaprendrecombiendetemps? À cette douce entrée en matière s'ajoute irrémédiablement un cahier de charges de 70 pages où trois ou quatre sont cohérentes les unes avec les autres, et la moitié des informations manquent, voire même : où il y a des problèmes fondamentaux d'architecture.

Ce qui se passe généralement est qu'on annonce d'abord un temps d'exécution largement au dessous de ce que ça devrait prendre (parce qu'on part du principe que le cahier des charges ne peut pas être si imprécis que ça), puis le temps passe à attendre des mails et à implémenter des choses qui seront défaites par la suite, et le projet finit avec tout le monde sur les nerfs et *beaucoup* de travail gratuit.

Et bien cucumber est une solution à ça.

Je l'ai utilisé plusieurs années avec succès pour remplacer les cahiers des charges. La première chose que je faisais (je ne suis plus freelance aujourd'hui), lorsque l'agence arrivait en panique était de dire : "Non, je ne vous fait pas d'estimation de temps « à la louche », mais je peux vous facturer deux jours d'audit pour vous dire exactement le temps que ça prendra".

Je passais alors la journée à lire le cahier des charges et à écrire les user stories. Les incohérences apparaissent immédiatement quand on pense l'implémentation concrète, là où en lisant juste le cahier des charges on se dirait "ok, ça c'est un « moyen morceau », une demi journée.". À la fin de la journée, j'envoyais mes questions sur les points imprécis.

Le lendemain, une fois les réponses obtenues, je finissais les user stories. Puis je les envoyais, en disant combien de temps ça prendrait et combien ça coûterait. L'agence avait pour consigne de lire les user stories pour s'assurer que cela correspondait bien à ce qu'elle voulait et de les retourner signées : toute variation ou ajout par rapport à ce qui y était décrit engendrerait des surcoûts et des délais. Fini les "ça nous paraissait évident" et les "il faudrait juste changer un petit truc".

Un autre usage que j'en ai eu, et où cucumber brille encore plus, est celui qui concerne les clients directs. Traiter les projets d'un client qui n'a aucune expérience du web est toujours problématique. Il se représente vaguement ce qu'il veut, il veut "faire comme machin" mais en ayant son produit à lui. S'ensuit des discussions, des propositions orales de fonctionnalités, des essais de design, puis finalement un cahier des charges destiné aux développeurs, toujours rédigé au moment où il commence à être trop tard.

J'ai expérimenté avec succès une autre méthode : avant même de faire des propositions de design, pendant la discussion avec le client et en association avec un designer, nous présentions des user stories accompagnées de wireframes. Ça prend beaucoup plus de temps que de discuter vaguement de "l'idée du site", mais une fois la discussion terminée, il n'y a plus rien d'autre à faire. Le designer peut commencer le design, et le développeur peut commencer le développement. Le client sait exactement ce qu'il va avoir, il n'est pas possible d'en dévier étant donné que cela constitue les tests automatisés.

Enfin, j'en vois un dernier usage, mais je n'ai pas expérimenté celui-là. Lorsque deux cofondateurs - un CEO et un CTO - commencent à travailler sur un projet, quel CEO ne voudrait pas pouvoir suivre le détail de l'implémentation, au moins au début ?

PS: @camille, un peu de margin entre les paragraphes, ça ne ferait pas de mal ;)

:-) Super explication Olivier. Je fais un lien dessus dans l'article, pour qu'on puisse suivre la discussion sur tous les supports.
Et + 1 pour les paragraphes.
En revanches, je comprends très bien l'outil, je pense juste que c'est un investissement qui n'en vaut pas du tous les bénéfices. Je le fais avec emphase parce que c'est plus fun, mais ça ne veut pas dire que je n'ai pas réfléchie à la question ni testé le truc en situation.
Particulièrement, ce que tu décris (les deux jours d'études), est quelque chose qu'il faut faire avec ou sans cucumber, et qui sera plus rapide à écrire en pur code qu'avec du texte. De toute façon on doit faire l'interface avec le client, alors la perte de temps est minime.

@Olivier: je suis complètement en phase avec ce que tu décris au niveau des user stories. Après, cela n'entraine pas forcément l'utilisation de Cucumber, non ? Un client va vouloir tester qu'en réalisant les stories, il arrive effectivement au bon résultat. Cucumber serait surtout utile pour toi afin de savoir que tu es bon sur les stories. Qu'en penses-tu ?