Quel petit vélo à guidon chromé... ?
- J'ai appris que tu travailles sur le nouveau projet XXL qui vient de démarrer. Félicitations ! Comment ça va ? - Pas trop mal. On a quelques difficultés de démarrage, mais rien de bien méchant. - Quel genre de difficultés ? - Intégrer les nouveaux frameworks, et quelques bugs par ci par là. - Des bugs. Vous avez des tests ? - C'est le Product Owner qui teste pour l'instant… - Non, je veux parler de tests unitaires, des tests automatisés, écrits par les développeurs, sur leur code. Tu sais, ce que je t'avais montré sur le projet XL. - Ah oui, les TUs. Oui j'en ai parlé à l'équipe, mais pour l'instant ils n'ont pas le temps, parce qu'il doivent livrer. - Oh là là. Stop. - Quoi ? - Ils t'ont dit: "on a pas le temps d'écrire des TUs parce qu'on doit livrer". - Oui. - C'est une blague ? - Je te jure que non. Qu'est-ce tu en penses ? - Ton équipe ne connaît pas les tests dont je te parle. Si c'était le cas, elle écrirait ses tests dès maintenant au lieu de les remettre à plus tard. Pour l'instant on dirait qu'elle est tombée dans le piège des développeurs débutants. - Le piège des développeurs débutants ? C'est quoi ? - "On améliorera la qualité plus tard quand on aura le temps" - En quoi c'est un piège ? - Ça n'arrivera pas. - Comment tu le sais ? - Aujourd'hui vous avez des problèmes de qualité. - Oui. Quelques petits problèmes, rien d'insurmontable. - C'était prévu dans votre planning ? - Pas vraiment. - Par conséquent vous avez déjà plus de travail que prévu. - D'où l'idée de remettre les tests à plus tard, tu comprends… - Plus tard vous aurez moins de travail ? - Peut-être… - Juste pour en être certain : demain vous direz donc à votre Product Owner : "certes on a passé un peu de temps non prévu à corriger des bugs, on est un peu en retard sur le planning, mais on a livré. Maintenant, ce qu'on voudrait c'est produire un peu moins de fonctionnalités, et prendre du temps pour améliorer la qualité". - Évidemment, présenté comme ça… - Il n'y a pas trente six manière de le présenter, si tu veux mon avis.. - OK, OK. Mais aujourd'hui, l'équipe a besoin de montrer des résultats. - Bien sûr. C'est essentiel. Et elle a aussi besoin d'apprendre. - Qu'est-ce que tu veux dire ? - Ton équipe dit: "les TUs on en fera plus tard, parce que pour l'instant on doit livrer". J'en conclus que les développeurs qui sont dans ton équipe ne connaissent pas les TUs, et ont besoin de se former. - Et pourquoi des tests unitaires ? Pourquoi ne pas s'appuyer sur les tests de recette en fin d'itération ? - Tu vois bien que ça ne suffit pas. Vous avez déjà des bugs. - Eh bien on va demander au Product Owner de faire plus de tests de recette. - Ne faites pas ça. C'est du gâchis. - En quoi c'est du gâchis ? - Les tests de recette demanderont plus d'effort, et pour trouver moins de bugs que vous n'en trouveriez avec vos tests unitaires. - Comment peux tu en être certain ? - Primo, le PO valide le produit que vous faites, mais il ne peut pas valider votre code pour vous. - Certes… - Secundo, même s'il validait tout le code à la fin de chaque itération, ce serait un retour d'information trop volumineux pour être efficace. Franchement, vous vous voyez corriger tout le code produit dans la semaine chaque vendredi après midi ? - Arrête, l'équipe a déjà du mal à réconcilier les versions de deux postes de travail… - Tertio, même si c'était un délai de retour d'information acceptable, une fois les défauts constatés et corrigés, vous chercheriez sûrement un moyen d'éviter de produire des défauts du même genre à l'avenir. - Sûrement ! - Pour détecter les défauts dans le code de manière efficace, il faut une approche systématique: écrire les tests unitaires au plus près du code qu'on est en train d'écrire. - Au plus près, c'est à dire ? - Le plus tôt possible, au moment où on écrit le code, et dans l'environnement de développement. Rappelle toi ce que je t'ai montré sur le projet XL. - Tu veux dire Test Driven Development ? - TDD, ou bien tout autre technique permettant de créer des tests au plus près du code. - Il faudrait que j'en parle à l'équipe. - Si j'étais toi, je n'attendrais pas trop longtemps. Les développeurs dans ton équipe ont tout ce qu'il faut pour faire du code de bonne qualité : jUnit, et un cerveau en état de marche, comme dit Michel. - Oui, mais tu sais ce que c'est, les tests c'est un peu vécu comme la corvée… - C'est la première chose qui doit changer. C'est parce que ton équipe n'est pas formée. - Hmm. - Tu te souviens de l'époque où tu as appris à faire du vélo ? Moi je me souviens. J'avais un vélo tout neuf, splendide ! Comme je ne savais pas en faire, je marchais en tenant le vélo sur le côté. C'était marrant au début, mais c'est devenu très vite frustrant, y compris pour les autres, parce qu'ils étaient obligés de m'attendre. Ma sœur m'a donc expliqué que l'idée du vélo, c'est de monter dessus. Ça roule bien plus vite. C'est le vélo qui te porte, et pas l'inverse. - Et qu'est-ce que s'est passé ? - Je me suis cassé la g… évidemment. Ça ne marchait pas. Alors ma sœur, qui devait être fatiguée de m'entendre me plaindre, est descendue de son vélo, et m'a expliqué comment faire, et elle m'a aidé en tenant mon vélo par la selle et en marchant à côté, et quand elle commençait à devoir courir pour me suivre, je savais faire du vélo. Voilà. - Mais quel rapport avec TDD ? - TDD, c'est comme le vélo: ça permet d'aller plus vite, à condition d'investir un peu de temps pour apprendre à s'en servir. Votre approche des tests, "plus tard, en recette, si on a le temps", vous ralentit, en fait. C'est comme si vous marchiez à côté de vos vélos. - Qu'est-ce que tu recommandes ? - Essayez! Il faut trois jours pour se former, trois semaines pour prendre l'habitude, et dans quelques mois vous maîtriserez complètement l'approche. - Oui mais là, on n'a pas le temps… - Ça y est, ça recommence… - Je plaisante ! Merci du conseil. Je vais en parler à l'équipe !