La dette technique : comment l’appréhender et la maîtriser ?


La dette technique : la responsabilité du Product Owner

En tant que responsable produit, délivrer un maximum de features dans les délais, sous la pression de ses utilisateurs (ou sponsors/membre du co-pilotage) peut souvent passer en première ligne de compte, dé priorisant parfois la structure du code. Mais vous avez à coeur de maintenir la qualité de votre produit à un haut niveau, influant directement sur votre aptitude à atteindre vos objectifs stratégiques et business.

Au milieu de tout ça, il y a : la dette technique.

FOCUS !

La dette technique : kesako ?

Comme le sujet fait débat, notamment entre les développeurs et les responsables produit, demandons à Bastien Jaillot de trancher :

En construisant un projet Web, de nombreux choix sont effectués, et ceux-ci, combinés à leurs implémentations, ont un impact sur le cycle de vie de votre projet. Cela s’appelle la dette technique: l’accumulation des risques pris lors des différentes phases techniques tout au long de la vie d’un projet.

Bastien Jaillot, La dette technique

Comment la dette technique s’installe ?

Le cycle traditionnel de développement d’un produit source de la dette technique

Lors de la conception de logiciels, la méthode traditionnelle est une approche basée sur les phases de développement des fonctionnalités :

  • Il y a tout d’abord la mise à disposition de l’alpha (souvent un prototype fonctionnel non exempt de bugs).
  • Ensuite celle de la beta (se rapprochant d’une version utilisable).
  • Puis la version finale (version stable livrée en production).