Développement piloté par les tests (TDD) et Scrum : un guide pratique

Le cycle TDD comporte trois étapes répétées continuellement : écrire un test qui échoue (rouge), écrire le code minimal pour le faire passer (vert), refactoriser sans changer le comportement. Le TDD soutient la Définition du Done de Scrum en rendant les tests inséparables du développement : un développeur qui écrit le test en premier ne peut pas terminer une unité de travail sans y associer son test. Les équipes qui séparent développement et tests accumulent une dette de test qui rend progressivement plus difficile la livraison d'un incrément vraiment terminé à chaque Sprint.

Objections courantes et comment les traiter

« Le TDD prend trop de temps » : la bonne comparaison est TDD versus écrire du code puis le tester. Le coût en temps des tests est réel à court terme et compensé à moyen terme par moins de débogage et moins de cycles de régression. « C'est difficile à ajouter après coup » : vrai pour le code patrimonial. L'approche pragmatique est d'appliquer TDD au nouveau code et à tout code patrimonial qui doit être modifié. « Notre équipe ne l'a jamais fait » : la meilleure introduction passe par la pratique facilitée — un kata de codage ou une session de mob programming — et l'inscription explicite dans la Définition du Done.

Si votre équipe Scrum peine à livrer systématiquement un incrément vraiment terminé à chaque Sprint — qu'il s'agisse de dette de test, de régressions ou d'une Définition du Done peu claire — le conseil en exécution de programmes et de projets de XNM peut aider à diagnostiquer les problèmes sous-jacents du modèle de réalisation et à concevoir une voie vers une livraison Sprint durable et de haute qualité.