Dans un contexte où les cycles de développement des logiciels s’accélèrent, les équipes de développement cherchent des moyens efficaces pour améliorer la qualité de leurs solutions dès la première itération. La notion de Less Rework aide à se concentrer ainsi sur l’identification et l’élimination des sources de refactoring, ces étapes coûteuses et chronophages qui freinent la progression des projets et développent les insatisfactions. En comprenant ce concept, les équipes IT peuvent non seulement accroître leur efficacité opérationnelle, mais aussi renforcer la satisfaction de leurs clients grâce à des logiciels plus fiables et performants.
Geoffrey Graveaud, Coach DevOps et Craft chez Inside, nous dévoile les principes fondamentaux du concept Less Rework, ses avantages concrets pour les équipes de développement, et nous donne ses conseils pour la mettre en œuvre avec efficience.
Peux tu nous donner ta vision de la notion de less rework ?
L’un des éléments les plus frustrants aujourd’hui pour les organisations qui produisent du logiciel est de retravailler des tâches pour lesquelles ils ont déjà passé du temps. Concrètement, il peut s’agir de nouvelles fonctionnalités mal implémentées pour différentes raisons, comme la pression pour aller plus vite. Cela entraîne de la précipitation et un certain nombre de bonnes pratiques qui ne sont pas respectées. De fait, la mise en production de ces nouvelles fonctions qui ne sont pas à l’état de l’art va soit « casser » quelque chose dans la production (dans ce cas il faut réinvestir du temps et de l’énergie sur cette tâche qui devrait pourtant être déjà terminée), soit participer à un cumul de défaillances, et ainsi creuser la dette technique. Et à terme, les concurrents vont creuser l’écart !
Dans ce contexte, le concept de less rework part du principe que chaque personne qui développe, chaque équipe ou organisation, doit réussir « au mieux » une tâche du premier coup. C’est n’est donc pas un principe « stricte », car il ne doit pas amener de pression supplémentaire, mais une démarche d’amélioration continue vers laquelle il faut tendre.
Quels sont les liens entre les démarches Less Rework, Accelerate et Craftsmanship ?
Parmi les 24 bonnes pratiques mentionnées dans Accelerate qui permettent d’améliorer les performances des organisations qui produisent du logiciel, il y a les « outcomes ». C’est-à-dire les résultats attendus visant des objectifs spécifiques d’un projet. Et parmi ces outcomes, il y a le Less Rework. Celui-ci tant à montrer que l’alliance de la qualité et de la rapidité permet de libérer du temps aux équipes de développement (puisqu’elles ont moins besoin de faire du réalignement logiciel), temps qui peut être réinvesti dans de l’innovation ou de nouvelles tâches business (par exemple). Ce qui permet également de baisser le coût d’un projet et d’accélérer son time to market. Concrètement, les équipes vont passer de moins en moins de temps à débuguer, il y aura donc moins de support client, et moins de refactoring (faire lien vers article refactoring). Accelerate a ainsi mesuré que les organisations sensibles à ce concept pouvaient dégager en moyenne 20% de temps aux équipes. Soit un gain significatif rapporté à une journée de 8 heures !
Il existe un second lien avec Accelerate, qui correspond à la sixième et nouvelle métrique apparue en 2024, qui est le « taux de Rework » ou Rework rate en anglais. C’est-à-dire le pourcentage du nombre de tâches pour lesquelles il y a de retravaille : du concept est né une mesure. Et pour aller plus loin, nous pouvons également faire le lien avec la démarche Craftsmanship qui correspond à la standardisation des bonnes pratiques de développement, permettant de maîtriser le volume de défaillances dans un code et de faciliter son intégration. Grâce à ces standards (qui embarquent de nombreux tests), il devient plus facile de repérer les défaillances, et de les corriger. De fait, le travail est sécurisé par l’application de bonnes pratiques dans tout le cycle de développement, et le taux de Less Rework est plus bas. Selon moi, la démarche Craftsmanship est donc un élément clé pour le Less Rework, soutenue par Accelerate.
Comment initier cette démarche et connaître son taux de Rework ?
Le taux de Rework étant un pourcentage, il est basé sur un calcul qui va dépendre du contexte des organisations, et de leur capacité à mettre en place l’automatisation de ce calcul. Mais il n’existe pas de solution universelle. Je préconise de commencer de la façon suivante : réfléchir à comment je peux savoir que je n’ai pas retravailler sur une nouvelle tâche, et qu’est-ce qu’une tâche refaite ? C’est de cette façon qu’il est possible d’aborder la question des métriques. Ce qui peut prendre la forme d’un suivi des statuts de tickets par exemple, ou encore d’une automatisation de tags ou de labels (si un tag réapparaît, c’est que la tâche a été retravaillée). Il est alors tant de se poser la question suivante : comment je peux industrialiser cette démarche ?
Il existe également une autre stratégie, plus indirecte. En effet, le Rework rate est corrélé avec l’une des 4 KPIs historiques d’Accelerate : le CFR (Pour Change Failure Rate). Ici, le CFR, en mesurant le pourcentage d’incidents ou des problèmes en production nécessitant une correction, peut donner une représentation macro du pourcentage de Less Rework.
Quels sont les bénéfices attendus de cette démarche ?
Premièrement, l’organisation va être de plus en plus souvent capable de livrer des features en production et sur le marché, parfaitement utilisables et du premier coup. L’impact est donc très fort sur la satisfaction du client et les promesses commerciales.
Deuxièmement, avec un taux bas de Rework, il est possible de dégager du temps aux équipes. Et je conseille de ne pas réinvestir ce temps que pour de nouvelles tâches business, mais également pour de l’apprentissage, la recherche de nouveaux outils plus performants, des expérimentations IA ou la création de POC. Et ainsi de se différencier de la concurrence !
Troisièmement, un taux bas de Rework joue sur la pénibilité du travail, qui va diminuer avec le temps. Elle se traduit avec Accelerate par une diminution observée du burn out de -15%, et favorise la productivité et la qualité. Car il faut toujours garder à l’esprit, et Accelerate le montre très bien, que le bien-être et la satisfaction au travail sont les prédicteurs majeurs de la performance d’une organisation.
Quels sont tes conseils et comment Inside accompagne ses clients sur cet enjeu ?
Je conseille de commencer par faire un audit et des interviews des équipes opérationnelles via des ateliers, des formulaires… Le but est de réunir un maximum d’éléments factuels avant d’initier une réflexion sur le Less Rework. Parallèlement, il faut être vigilant à la qualité même du code et à sa maintenance (qui est l’un des leviers de performance d’Accelerate depuis 2020), ce sont des éléments clé dans ce contexte. Inside propose d’ailleurs une formation Clean Code réalisée par nos coachs Software Craftsmanship. Un code de qualité, bien documenté et lisible est plus facilement testable et impacte positivement le Less Rework.
Inside propose également différentes offres et formations autour du Craftsmanship, comme le coaching ou des ateliers de sensibilisation via notre serious game Refactoring Explorer, afin de mieux maîtriser les contraintes de qualité.
Enfin, j’ai également développé un tout nouvel atelier basé sur mon serious game Accelerate 2 (version 2024), toujours dans le but de sensibiliser nos clients sur les liens de causalité entre les bonnes pratiques d’Accelerate, du Craftsmanchip et le taux de Less Rework !
Echangeons sur les avantages de la démarche less rework !