Dans plusieurs projets agiles, on entend souvent parler de la "Dette Technique", des conflits entre la partie managériale et le client sur le coût nécessaire pour la corriger, les obstacles et les freins qui bloquent les développeurs pour continuer à créer du code cohérent de qualité et respecter l'engagement de chaque Sprint (Augmentation de la charge de travail). C'est quoi alors cette dette technique? Et comment la maîtriser voire la minimiser ?
Il existe deux cas de figure, soit l'équipe de développement va travailler sur un produit ou application construite en partant de rien ou autrement dit "From Scratch", soit sur un existant ou tout simplement du "Legacy".
Chaque application ou produit a son propre code source qu'il faut le maintenir et le mettre à jour en respectant des règles du codage, du standard du code, et des normes exigées par les technologies déployées, ce qui n'est pas toujours facile et applicable par la plupart des équipes de développement, du coup la qualité du code diminue, se dégrade, et se détériore avec le temps, c'est ce qu'on appelle tout simplement la "Dette Technique". Par conséquent on perd beaucoup en terme de performance, qualité, cohérence, et efficacité, et le remboursement de cette dette devient éligible par les équipes, et impacte directement leurs engagements et vélocités.
L'impact est majeur qu'on les développeurs travaillent sur du code existant ou "Legacy" car la dette technique existe déjà depuis un certain temps, et ça se cumule au fur et à mesure, par contre pour une application "From Scratch", on peut la contrôler dès le départ et minimiser les dégâts le maximum possible.
Toute équipe agile doit avoir des très bons réflexes permettant d'éviter et de minimiser la dette technique sur leur projet, en mettant un place un nombre d'actions adéquates, en occurrence :
Concevoir et choisir la bonne conception, et l'architecture technique associée au projet en question.
Mettre en place des normes de codage et de nommage associées aux technologies déployées.
Organiser les composants techniques réutilisables et les fichiers du code source.
Exiger une documentation technique et le commentaire dans chaque code créé.
Inclure la Revue de code dans la D.o.D, ainsi que les tests de performances.
Inclure le remaniement du code dans la D.o.D.
Minimiser les outils et technologies à déployer sur le projet (Se focaliser sur les outils éprouvés sur le marché).
Utiliser des bonnes pratiques comme "TDD", "BDD", et la programmation en paire "Pair Programming".
Pour les applications "Legacy", il est fortement et vivement recommandé de faire une analyse globale de l'ensemble des composants techniques, ainsi que mettre en place une bonne stratégie pour attaquer la dette existante, et tout cela en étroite collaboration avec le Product Owner / Client afin de réserver à chaque fois un pourcentage de la capacité de l'équipe pour faire ce travail et pas produire que de la valeur métier à 100% dans un Sprint.
Conclusion :
En cas général, la dette technique fait partie toujours de la vie des développeurs tout au long de la vie d'un projet, il est quasiment impossible de l'éviter à 100%, mais il est obligatoire de la contrôler et la minimiser toujours.
La transparence et la collaboration doivent se réunir et se présenter toujours dans les projets agile, ainsi que le traitement de la dette technique qui doit être prévu , contrôlé, anticipé, et budgétisé,et surtout visible par le client et pas seulement l'équipe de développement.
Comments