Le refactoring en scrum est un vrai sujet qui est souvent sous-estimé. J’ai donc décidé de faire un article pour en parler. J’ai décidé de traiter ce sujet après de nombreux échanges en commentaires avec Xavier Pigeon.
Qu’est-ce que le refactoring ?
Le refactoring consiste à modifier le code source d’une application avec pour objectif d’améliorer celui-ci, sa structure, sa lisibilité sans modifier le comportement fonctionnel de celui-ci.
Ceci peut-être le résultat de l’évolution d’un framework de développement ou tout simplement une réécriture pour améliorer l’existant.
Pourquoi améliorer son code ?
Malgré tous les efforts de l’équipe de développement, un code source applicatif n’est jamais parfait. Ceci est d’autant plus vrai quand l’équipe revient de temps en temps sur certaines parties pour travailler sur différentes demandes.
Améliorer son code a pour but de :
- donner un temps de vie supplémentaire à l’application
- le rendre plus lisible pour l’équipe
- éviter de créer de a dette technique (ou la diminuer au maximum)
- …
En effet, améliorer son code en continue n’est pas anodin et a des vertus non négligeables.
Les scrumbut à éviter
Stratégie de refactoring sur le long terme
Des équipes scrum décident de mettre en place une stratégie pour faire du refactoring sur 20% du sprint (example). Cela a pour objectif de diminuer au fur et à mesure la dette technique et améliorer le code source en général.
Le scrum ne donne aucune pratique autour du refactoring; mais nous recommandons d’éviter celle-ci.
La raison est simple : quand on avance sur des parties de codes source de mauvaise qualité, l’équipe ne fait qu’augmenter la dette technique ; alors, quand le refactoring diminue la dette technique d’un côté, nous l’augmentons de l’autre. Au final, le refactoring ne s’arrête jamais et la dette technique a plutôt tendance à augmenter sur le temps.
Solution à privilégier : faire le refactoring un bon coup avant d’avancer sur la livraison d’items ayant de la valeur (exemple: les US). Si cette méthode peut paraitre radicale, elle sera gagnante à long terme car l’avancement sur le produit sera réalisé sur de bonnes bases.
L’équipe de développement négocient le refactoring
Dans certaines équipes, l’équipe de développement partent en négociation avec le product owner pour obtenir du temps pour réaliser du refactoring. Voire dans certains cas d’insérer des items de type « refactoring ».
Cette pratique est un non-sens si nous parlons scrum. Le fait de négocier du refactoring enlève l’idée que l’équipe de développement doit livrer un increment potentiellement publiable où la qualité ne peut pas être revue à la baisse.
Solution à privilégier (1) : dans le cas où le refactoring concerne un nouveau framework de développement (ou une évolution), l’équipe scrum au complète peut prendre la décision d’y switcher ou non. Cependant, si cette évolution corrige des failles de sécurité ou améliore la stabilité du produit, l’équipe de développement ne devrait pas à avoir à négocier la mise à jour du code ; mais elle devra être transparente avec le PO pour que celui-ci puisse s’adapter à ce besoin.
Solution à privilégier (2) : si des parties du code source applicatif peuvent être améliorables, l’équipe de développement les travaillera sans même demander au product owner pendant les sprint. Cependant, elle restera vigilante à l’objectif du sprint pour perturber au minimum l’avancement du sprint.
Le refactoring en scrum, c’est automatique
Il est très important de comprendre que le refactoring fait parti de la vie d’un produit. Ne pas en faire amènera assurément le produit :
- à vieillir (obsolescence possible)
- de voir sa dette technique augmenter
- à ne plus pouvoir recruter les bons profils IT (si technos vieillissantes)
Le refactoring a un coup d’investissement quotidien bien que difficile à calculer mais les gains sont nettement plus important. Avoir un produit de qualité avec une dette technique minimisée, c’est le client et le produit qui en bénéficieront.
Comment gérer-vous le refactoring dans vos équipes scrum ?
Bonjour Judicaël,
Je ne suis pas bien sûr de comprendre votre avis quant au refactoring. J’ai cru comprendre que vous conseilliez de faire des sessions (de plusieurs semaines ?) de refactoring quitte à ne pas (ou peu) livrer de valeur pendant ce temps ? Éventuellement, en période creuse (parce que pragmatiquement ça arrive) je peux comprendre cet avis, mais dans un cycle normal, je trouve ça assez problématique. Mais j’ai peut-être mal compris.
Je vois un autre inconvénient à cette approche, c’est le faible retour sur investissement pour le client. Je n’apprends rien à personne, mais les bonnes pratiques, les frameworks, les moeurs etc. évoluent très vite et peuvent être obsolètes en 6 mois… C’est dommage d’investir plusieurs semaines de travail tous les 6 mois pour être à la page techniquement, même sur des parties de codes qui ne nécessiteront plus d’intervention de l’équipe.
À titre personnel, je pense qu’il est important que l’équipe « refactore » son code durant le sprint uniquement sur les parties sur lesquelles elles doivent ré-intervenir. Je m’explique :
Le PO (en Scrum) présente à l’équipe une évolution d’une fonctionnalité existante. L’équipe ne sait pas faire autrement que de la qualité, et pour faire de la qualité elle doit « refactorer » son code (dans notre exemple, mais ça n’est pas toujours le cas). Sa responsabilité ici est de l’annoncer et l’expliquer au PO. Lors de l’estimation de l’effort, elle doit prendre en compte cette « refacto », et cet élément de Backlog qui aurait pu sembler représenter un faible effort pour le PO représenterait en fait un effort conséquent pour l’équipe. À ce moment-là, c’est au PO d’arbitrer pour voir si cette fonctionnalité apporte suffisamment de valeur pour être ajoutée étant donné la complexité supplémentaire induite parla refacto.
En somme, je pense que le refactoring doit être justifié par un apport fonctionnel au client. Appliquer la règle du boyscoot (« Leave your code better than you found it. ») permet de limiter l’effort et de se focaliser uniquement sur les parties de code qui ont besoin d’être « refactorées » Je trouve que la « story technique » est un non-sens (si elle est réalisée, puis que la User Story associée est annulée, on a travaillé pour améliorer le produit techniquement, mais on n’a rien apporté au client, donc on a un ROI assez faible).
Voilà, ça n’est que mon humble avis 🙂
Je vous remercie pour cet article intéressant.
Hello,
Le refactoring ne devrait pas amener à de tels choix mais parfois, on a de la dette technique incroyable.
Travailler sur de la dette technique ne fait que l’augmenter ; du coût si cela a un coût de dev au développement, il en aura aussi en post-développement.
Si on peut y voir un coût pour le client le Jour J, il est de loin préférable de remettre les choses propres avant de relancer la machine.
Cela coutera beaucoup moins cher au total : dette qui aura des conséquences (bug/ano à corriger), plus de difficulté sur des devs futurs, insatisfaction cliente….
Non l’équipe n’a pas la responsabilité de dire au PO qu’elle fera du refactoring. La qualité en scrum n’est pas négociable. Elle l’informera pour raison de transparence mais n’aura pas d’aval à avoir. Le PO ne décide pas du travail de l’équipe de développement. En effet, l’estimation prend l’idée du refacto bien que parfois complexe à déterminer.
Le refacto impose parfois de tout refaire et ne peut pas se limiter à « une US ». Cette pratique ne fonctionnerait pas dans tous les cas. La façon de faire que tu dis je la propose aussi mais le choix doit se faire selon le contexte de la dette technique.
Merci pour tout commentaire complet et d’avoir amené des idées constructives 🙂