Que doit connaître un PM du refactoring ?
Référence : Maestrix - le refactoring : que faut-il connaitre en tant que PM ?
Il est important pour le PM ou le PO d’avoir de bonnes notions du métier des équipes avec lesquelles il travaille, par exemple :
- connaître les langages (sans forcément savoir coder),
- avoir des notions d’architecture logicielle, des design patterns, etc.
- etc.
Et donc comprendre les problématiques de dette technique.
Dette technique : refactoring et refonte
- Refactoring : changer le design du code sans changer son comportement.
- Refonte : normalement la même chose (juste une traduction en français), mais d’un point de vue direction technique, il s’agit d’un refactoring plus important, notamment quand on accumule de la dette technique avec impact fonctionnel (typiquement sur la performance).
- dette technique : retard de mise à jour des composants, d’optimisation du code, etc. qui n’ont pas été traités au fil de l’eau pour aller au plus vite dans l’implémentation des fonctionnalités.
En principe, on va régulièrement faire du refactoring, pour éviter d’avoir à faire une grosse refonte avec un impact sur le travail de l’équipe.
Quand aborder le refactoring ou la refonte ?
En discovery, nous ne sommes pas sensé toucher au code (ou alors pour faire des PoC, et donc du code qui ne sera pas conservé).
Par contre, impliquer au plus tôt les équipes techniques dans le processus de discovery leur permet d’anticiper la meilleure approche pour l’implémentation, et les éventuelles tâches de refactoring à privilégier pour faciliter le développement de la nouvelle fonctionnalité.
Le refactoring ne doit pas être négligé par les PMs et les autres parties prenantes, car l’accumulation de la technique aura immaquablement des conséquences sur les performances du produit et de l’équipe technique, dans la mesure où les développeurs doivent subir les conséquences d’un code difficile à maintenir si, les problèmes s’accumulent…
Approches :
- en continue : par exemple par le TDD (donc écrire le test, faire fonctionner le test, puis refactoriser le code pour l’optimiser);
- inclure des User Stories de factorisation : temps sanctuarisé pour traiter les problèmes de dette technique et répartir la charge du sprint entre les nouvelles fonctionnalités et l’améliorations du code);
- sprint de refactoring : SAFe propose d’intégrer un sprint de refactorisation dans un ensemble de sprints (en général tout les 5 sprints).
Le sprint de refactoring a tendance à être négligé pour ne pas perdre de temps sur les fonctionnalités. Le traitement en continu est l’idéal, mais les US de factorisation permettent de reprendre du temps sur ce qui se serait quand même pu s’accumuler au fil du temps.
Comment le PM doit-il gérer la dette technique ?
Au final, le PM est garant de la qualité du produit livré aux clients. Il doit donc prendre en compte le besoin de traiter la dette technique, car elle finira tôt ou tard par impacter la qualité du produit.
le PM devrait, dans l’idéal, laisser les équipes techniques autonomes dans leur gestion de la dette technique.
Néanmoins, il doit s’organiser avec l’équipe (ou le tech lead) pour prévoir le temps nécessaire à la gestion de cette dette technique.
Le PM peut également argumenter auprès des responsables du besoin de traiter cette dette technique, notamment en jouant sur son impact financier. Dans cette démarche, il pourra se faire aider du tech lead, qui a l’expérience nécessaire pour argumenter.
Le PM disposera également d’outils permettant de rendre compte de la qualité du code, et avec l’équipe technique, prévoir des KPI de qualité à maintenir sur le code. Cela permet de la garder bien en vue dans les objectifs de chaque sprint, malgré les sujets produit à traiter en parallèle.
Par rapport au TDD
Le PM peut également fournir des tests sous la forme de scénarii, et si possible avec des données représentatives de ce qui est manipulé en production (emails, identifiants fictifs, etc.).
Le PM pourra également penser aux cas d’erreur, dans la rédaction de ses scénarii de tests.
Ces scénarii seront ainsi la base des tests fonctionnels (et de plus haut niveau) exécutés pour valider les fonctionnatlités du produit.