Le refactoring en Scrum : comment lui faire une place
Le refactoring améliore la structure interne du code sans modifier son comportement externe. Le problème : il n'est jamais urgent, ce qui le condamne au bas du backlog pendant que la dette technique s'accumule.
Pourquoi le refactoring est toujours sacrifié
Il est invisible pour les parties prenantes, concurrence des fonctionnalités mesurables, et n'est jamais critique. Résultat : la vélocité chute et les bugs se multiplient au fil des sprints.
Quatre stratégies efficaces
Règle du boy-scout. Laisser le code plus propre qu'on ne l'a trouvé. Améliorations incrémentielles absorbées dans le travail normal, sans ticket séparé.
Stories de refactoring dans le backlog. Pour les améliorations structurelles importantes, créer des éléments de backlog formulés en bénéfice business : réduction du temps de développement futur, baisse du risque de bugs.
Refactoring dans la Définition of Done. Si une story touche un module endetté, inclure une amélioration ciblée dans la DoD maintient le refactoring lié à la livraison.
Réserver 10 à 20 % de capacité. Protéger une fraction de chaque sprint pour la dette technique, avec l'accord du Product Owner lors du sprint planning.
Pour convaincre un Product Owner non technique, cadrez le refactoring comme un investissement dans la vitesse de livraison future. La dette structurelle finit toujours par se voir — sous forme de retards et de défauts.
Pour bâtir les disciplines d'équipe qui préservent la qualité sous pression de vélocité, la pratique de livraison de programmes et projets de XNM peut vous accompagner.