La dette technique, c’est quoi au juste ?
Dans un projet technique, chaque choix implique des conséquences pour le reste du projet. La dette est l’accumulation des risques pris tout au long du travail. Elle ne peut être nulle, mais c’est notre rôle de la communiquer, d’expliquer nos choix et de rendre attentif notre client à cette notion. Pour éviter que celle-ci grandisse, il est nécessaire d’effectuer du *refactoring* ou repenser l’architecture.
Pourquoi vous en parler ?
Bastien Jaillot, développeur PHP, co-fondateur de JoliCode a récemment écrit un livre sur ce sujet. Concis pragmatique et agréable à lire, cet ouvrage nous rappelle cette notion qui nous tient à coeur depuis l’ouverture d’Antistatique. Une bonne occasion pour en parler et pour acheter son livre !
Qui est responsable de la dette ?
Le client, le développeur, le designer, l’architecte et le chef du projet sont responsables de la dette. Chaque décision la fait grandir ou la stabilise, une maintenance intelligente permet également de la réduire. En tant que développeur frontend, si je décide de coder mon propre système de grille CSS, la dette sera plus élevée comparée à l’utilisation d’une grille existante, maintenue et éprouvée. Une nouvelle version de navigateur sort, ma grille ne fonctionne plus, qui est responsable ? La solution est multiple et selon nous, notre engagement en fait partie.
Notre engagement
Pour éviter une augmentation de la dette technique, nous faisons tout pour augmenter la qualité de notre code. Ceci passe par un processus de validation exigeant. Les choix techniques sont pesés et expliqués aux parties prenantes du projet. Nous n’acceptons pas toute les directives visuelles ou fonctionnelles si elles impliquent une trop lourde dette. Savoir dire non à une demande et prendre le temps d’expliquer les conséquences pour le futur du projet est essentiel au bon déroulement de celui-ci.
Prévenir vaut mieux que guérir
Prévenir c’est surtout augmenter la qualité, informer des risques et mesurer pour pouvoir optimiser.
Optimiser est peut-être prématuré, mais mesurer ne l’est pas — Richard Warburto
Et Gilles, il en pense quoi ?
Voilà un type de livre que l’on télécharge sur sa tablette le vendredi, pour en parler ensuite le lundi. Parce que je ne suis pas le seul à l’avoir lu, le chapitre suivant résume les notes de Gilles:“Globalement, je n’ai pas appris grand chose, c’est un sujet dont nous sommes sensibles depuis longtemps et nous y faisons face à chacun de nos choix. Nous sommes très proches de ce que Bastien vit et des outils qu’il a mis en place à tous les niveaux (management, team spirit, best practices).”
Les points que nous pouvons facilement améliorer
- Plus Communiquer, mieux communiquer: “le responsable de projet technique se doit d’être la personne la plus communicante et non pas “la plus capable”.
- Fixer les objectifs du projet et les rappeler *souvent*
- Rendre les différents partis du projet intéressés par les résultats des mesures en place
- “Ce n’est pas parce qu’il y a une solution technique *complexe et intéressante* à mettre en œuvre qu’il faut l’implémenter. Souvent, le meilleur choix consiste à trouver une solution alternative qui prendra moins de temps à développer.”
- Équilibre Senior / Junior dans l’équipe projet.
- Valoriser le refactoring et les tests
- Augmenter la confiance réciproque avec le client
Et vous ?
Subissez-vous le poids de la dette technique dans vos projets ? Quelles solutions avez-vous mis en place pour la diminuer ?