Réconciliez vos clients avec les tâches techniques
Chaque projet comprend divers acteurs : les POs et les clients veulent ajouter un maximum de fonctionnalités au produit tandis que l’équipe technique les développe. De cette description simpliste, on peut rapidement voir émerger des points de vue divergents, notamment sur l’appréhension des tâches techniques et de leur priorité.
Entendons-nous sur les termes. Les tâches fonctionnelles, ou user stories, apportent ou modifient des fonctionnalités. En revanche, les tâches techniques ne changent pas le comportement de l’application. Elles peuvent permettre d’améliorer l’évolutivité du code sans toucher aux fonctionnalités ou optimiser la CI/CD. Elles n’apportent pas de valeur métier au produit mais elles ont tout de même une plus-value pour le projet. Par définition, le refactoring est une tâche technique. Ces tâches sont souvent difficiles à faire accepter au PO qui ne voit pas leur intérêt pour le projet. En tant que développeur, il nous arrive d’avoir un besoin viscéral de nettoyer du code ou d’améliorer certains processus. Pendant ce temps, le client se demande où va son argent !
Alors quelles méthodes pour corriger cette dissonance ? 🧐
Sanctuarisez la technique
Les tâches techniques étant difficiles à appréhender pour le PO, celui-ci a besoin d’être sécurisé. Vous pouvez vous mettre d’accord sur un nombre de points de complexité réservés pour les tâches techniques à chaque sprint. Ce cadre permet de rassurer autant le client (s’il a peur des abus) que l’équipe (il sanctuarise un minimum de points techniques réguliers).
L’approche SAFe propose des itérations “Innovation and Planning” : le sprint à la fin de chaque incrément est consacré seulement à l’innovation et la planification du prochain incrément. Si cela permet de sanctuariser des périodes propices au clean code, des déviances peuvent également voir le jour. L’équipe pourrait essayer de “rattraper” le retard sur l’engagement de son incrément, abandonnant les tâches techniques.
Certains projets arrivent à obtenir de temps en temps des itérations dédiées à la dette ou l’innovation. Je considère cette stratégie inadaptée, c’est courir après les problèmes plutôt que les corriger quand c’est nécessaire. L’Extrême programming recommande d’effectuer les refactoring au plus tôt pour gagner en vitesse de développement. Il parle également de simple design, qui demande de ne pas anticiper les développements futurs et de garder une architecture simple, facile à faire évoluer selon le principe YAGNI.
Parlez le langage du client pour mieux communiquer 🥳
Que ce soit le client, le PO ou le proxy PO, le plus difficile est souvent qu’ils ne voient pas l’intérêt direct des tâches techniques. Pourquoi ? Ils perdent parfois de vue que l’objectif n’est pas seulement d’ajouter des fonctionnalités. Ils ne comptent que sur la plus-value métier, valeur apportée sur le court terme, sans chercher la plus-value Produit, valeur apportée sur le long terme. En effet, si une dette technique ralentit l’ajout de valeur métier, autant la résorber rapidement ! Cela pourrait permettre une bien meilleure maintenance, pérennité ou vitesse d’évolution du produit.
Parfois, les tâches techniques sont vues comme des lubies de développeurs. Or, comme le manifeste du Software Craftsmanship l’indique, l’objectif d’une équipe est d’avancer ensemble vers les objectifs du projet en tant que professionnels. La confiance est de mise. Pour vous faire entendre, adaptez votre langage pour gagner en pertinence et pour que la plus-value transparaisse davantage.
La clé est dans le nom du ticket : il ne devra pas parler de la problématique ou de la solution technique mais plutôt du gain pour le projet. Si nécessaire, estimer le gain de temps peut être un argument de poids qui rattache à du concret.
À la place de : Ajouter plein de tests.
Le client comprendra mieux : Assurer que les cas aux limites d’une fonctionnalité sont bien testés, réduire les risques de régression.
À la place de : Améliorer une pipeline de la CI/CD.
Le client comprendra mieux : Réduire le temps d’attente des développeurs lors des déploiements, accélérer la mise en production d’évolutions et de correctifs.
Il est important de bien préparer, prioriser et chiffrer ces tâches techniques avant de les proposer en sprint planning, l’idée étant de faire accepter leur ajout régulier. Si la sanctuarisation d’un nombre de points techniques a été acceptée, les regrouper dans un backlog dédié peut grandement vous faciliter la vie.
Refactorez au bon moment
Une mauvaise pratique consiste à surchiffrer les tickets afin de s’occuper des tâches techniques pendant le temps gagné. À l’inverse, chiffrer ses tickets en y incluant le temps de faire les tests et le refactoring, c’est une bonne pratique, ça s’appelle du Test Driven Development ! 🤔 Le TDD passe par 3 étapes :
- Écrire l’ensemble des cas de test qui valident la fonctionnalité. Tant que cette dernière n’est pas développée, ceux-ci doivent échouer, voire ne pas compiler.
- Développer la fonctionnalité au plus efficace. Les tests passent ainsi au vert.
- Refactorer le code pour qu’il s’intègre parfaitement au reste du projet. Les tests doivent rester ok puisqu’aucune fonctionnalité de l’application n’a été modifiée.
C’est lors de cette dernière étape que vous pourrez modifier votre code de façon à le rendre plus pérenne et en profiter pour corriger quelques maladresses.
Il arrive que des tickets soient dépendants les uns des autres, qu’ils aient tous un prérequis commun et que leur chiffrage change en fonction de l’ordre dans lequel ils seront développés. Dans ce cas, créez un enabler. Ce type de ticket n’apporte aucune valeur métier. L’estimation du refactoring et des évolutions liées deviennent indépendantes, ce qui simplifie nettement la revue de code. Ainsi, les évolutions peuvent être priorisées à volonté. De plus, le travail ne risque pas d’être fait par plusieurs développeurs pour des évolutions différentes, évitant ainsi les conflits.
Lors d’un refactoring, l’énergie apportée pour que du code soit propre doit être proportionnelle à son potentiel d’évolution. Voyez votre projet comme un arbre : le tronc, central, se doit d’être à toute épreuve car il supporte tout le reste. Il est relu et modifié par tous, tout le temps ! De ce tronc s’étendent les branches qui ont également besoin d’attention car elles doivent soutenir élégamment l’ensemble des feuilles. Ces dernières n’ont pas besoin d’autant de rigueur car elles n’ont pas de dépendances. L’idée est donc que le tronc, le socle de l’application, soit toujours résistant tandis que le reste peut varier.
Attention, je ne dis pas de ne pas coder proprement, je dis que, si la question d’un refactoring se pose, il faut d’abord regarder quelle sera sa valeur ajoutée. Cela transparaîtra dans vos conversations avec le client, vous gagnerez en pertinence et il vous accordera plus facilement sa confiance. Comme toujours, restons pragmatiques. 😁
Conclusion
Savoir expliquer la plus-value qu’apporte une tâche technique pour ensuite la faire accepter, voici la clé d’un projet qui se veut pérenne dans le temps. Qu’on parle budget, deadlines ou dette technique, faire confiance à ses pairs est de mise car les projets sont désormais trop complexes pour être cernés en totalité. Après tout, nos différents profils sont la preuve que nous avons besoin les uns des autres. 🥰
J’espère que ces astuces vous permettront de vous améliorer !
Vous connaissez d’autres axes d’amélioration ? Vous avez un autre mode de fonctionnement ? N’hésitez pas à les proposer en commentaires !
