Le sujet de la dette technique est vaste et a même suscité l’écriture de quelques très bons livres comme celui de Michael Feathers « Working effectively with legacy Code » qui explique comment travailler par petites étapes et surtout la nécessité d’arrêter d’augmenter systématiquement cette dette (« Stop Digging! »).
Bien souvent les équipes de réalisation sont conscientes de cette dette mais ont un réel problème pour trouver du temps pour s’en occuper. Les Technical Story spécifiques sont bien souvent repoussées dans le bas du Product Backlog par le Product Owner et l’ajout de quelques items de qualité de code dans le TERMINE (DONE) est une bonne pratique mais bien souvent insuffisante pour s’attaquer réellement à cette dette.
Alors comment faire ?
Un de mes clients a trouvé une solution sans la chercher et tout cela grâce au Kanban.
L’objectif initial de ma mission était d’améliorer le fonctionnement de l’équipe de réalisation et ses interactions avec les équipes produit. Plutôt que de mettre en place Scrum et ses cérémonies que je ne trouvais pas vraiment adapté au contexte de ce client et à son fonctionnement, j’ai préféré conseiller l’approche lean et la mise en place d’un kanban comme outil de management visuel du cycle de vie des fonctionnalités.
Depuis quelques semaines ce Kanban est en place avec une colonne par étape et les limitations de WIP (Work In Progress) bien visibles. Cet outil a fait clairement apparaître un goulot d’étranglement (« Bottleneck ») au niveau de la validation fonctionnelles des exigences (~UAT) qui est en cours de traitement, et donc les tâches en amonts ont une tendance à s’entasser devant ce goulot. L’effet induit pour l’équipe technique est qu’il n’y a plus de place vide sur le Kanban (WIP) pour démarrer les réalisations et donc, d’une certaine façon, qu’elle n’a rien à faire !
Cette opportunité a immédiatemment été utilisé par l’équipe pour s’attaquer à la dette technique (une forme de 5S), ce qui leur permet de passer du temps sur cette activité tout en sachant que cela ne pénalise pas la productivité totale puisque, par définition, la vitesse du flux de sortie est subordonnée par le goulot, donc tant que le goulot est alimenté en permanence le système est à son maximum de vitesse.
Et vous, comment trouvez vous du temps pour réduire votre dette technique ?
Excellent!
Appliquer une réflexion lean sur une organisation en place est payant, mais cela demande une certaine prise de recul, et il n’est pas évident de trouver les vraies sources d’amélioration sans se défaire de nos réflexes et schémas de pensée quotidiens.
Pour ma part, en fonctionnant en mode scrum, j’ai livré du code sans les tests unitaires implémentés (ce qui ne signifie pas qu’aucun test unitaire n’avait été effectué), pour les besoins d’une démo. Il a été accepté par le PO de faire cette première livraison, puis d’ajouter au backlog un NFR correspondant à la montée en compétence de l’équipe sur JUnit + codage des tests unitaires sur le code déjà implémenté.
L’approche lean nous a permis d’identifier que notre flux d’information était mal organisé : l’équipe en charge du développement, échange avec deux autres équipes, et rassemble les informations. Cela génère énormément d’échange, les deux équipes interlocutrices ne parlant pas entre elles. nous allons donc changer l’organisation de manière à créer un flux d’information à l’image d’une chaîne de montage, en forçant ces deux équipes à s’entendre avant de nous remonter les informations. Mais la politique reste un frein à ce genre de changements, comme d’habitude.
C’est sans doute une bonne chose pour l’équipe de développement qui a trouvé un moyen pour travailler sur sa dette technique.
En même temps je suis un peu mal à l’aise avec cette idée car cela ne résout pas le problème de fond (au contraire). En effet, un des problèmes est que la dette technique reste trop au niveau de l’équipe de développement et n’est pas assez pris en compte par la MOA et les décideurs. Le fait de « cacher » ces travaux vont faire croire qu’il n’y pas besoin d’aborder ces problèmes puisqu’ils ne seront plus visibles (ce qui n’est pas très agile d’ailleurs). Que se passe-t-il si le goulot d’étranglement revient vers l’équipe de développement ?
A mon avis le vrai enjeux est d’arriver à montrer aux MOAs le coût financier que fait porter la dette technique sur le projet. Sujet difficile à mener…
La chance qu’a ton client pour ce qui est de la dette technique est que la contrainte se situe hors du développement.
(En même temps rattraper du code qui n’est pas testé… soit on a une bonne suite de tests unitaires, soit ça peut faire très mal au 2e tour.)
Une solution apparament viable à long terme qui semble s’associer bien à Kanban, c’est de mettre en place une forme de taxe sur la capacité à la contrainte.
Un exemple : le code de cette story est catastrophique, la contrainte ne travaillera qu’à 66 % de sa capacité de façon à le remettre d’équerre. Un code propre n’aurait amené une réduction que de 5 ou 10 %.
Hors contrainte, la mise en ordre que tu décris est toujours appliquable 😉