Le refactoring en scrum

refactoring en scrum
refactoring en scrum

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 ?

[ Article lu 2 fois aujourd'hui ]
A propos Judicaël Paquet 490 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.