Évaluation de la dette technique pour les équipes d'ingénierie

Identifiez où la dette technique ralentit votre équipe et vérifiez si vous la remboursez.

Essayez ce bilan de santé en direct

Que mesure une évaluation de la dette technique ?

Ward Cunningham a inventé la métaphore de la dette technique dans son retour d'expérience présenté à OOPSLA en 1992. Il y écrivait que « livrer du code écrit pour la première fois, c'est comme s'endetter ». Un peu de dette peut vous faire gagner du temps. Les ennuis commencent quand elle n'est pas remboursée : chaque heure passée à contourner du code pas tout à fait correct devient alors un intérêt à payer. Les outils d'analyse mesurent le code. Cette évaluation mesure ce que l'équipe vit au quotidien : si vous voyez la dette, à quel point elle ralentit la livraison, l'état ressenti du code et des systèmes, et si vous la remboursez. Chacun note chaque affirmation individuellement, puis vous reprenez les scores les plus bas en rétrospective pour décider ensemble de ce qu'il faut corriger en priorité.

Dimensions

Visibilité

Mesure si l'équipe sait où se trouve sa dette et la traite comme un travail à part entière.

  • Points sensibles identifiés

    Nous savons quelles parties de notre système concentrent le plus de dette.

  • Suivie avec le reste du travail

    La dette est suivie dans le même backlog que les fonctionnalités et les bugs.

  • Coût connu

    Nous savons expliquer ce que nos plus grosses dettes nous coûtent en temps ou en risque.

Impact sur la livraison

À quel point la dette ralentit le travail que l'équipe cherche à livrer.

  • Rythme des fonctionnalités

    La dette ralentit rarement les fonctionnalités que nous développons.

  • Modifications sans risque

    Modifier une partie de notre système casse rarement une partie qui n'a rien à voir.

  • Builds rapides et fiables

    Nos builds et nos tests sont rapides et fiables.

Santé du code et des systèmes

À quel point il est facile aujourd'hui de travailler avec le code, les systèmes et les dépendances.

  • Facile à modifier

    La majeure partie de notre code est facile à comprendre et à modifier.

  • Dépendances à jour

    Nos dépendances et nos plateformes sont raisonnablement à jour.

  • Des tests qui permettent de refactorer

    Nos tests nous donnent la confiance nécessaire pour refactorer.

Remboursement de la dette

Mesure si l'équipe progresse de façon régulière et concertée dans la réduction de la dette.

  • Temps réservé

    Nous réservons régulièrement du temps pour rembourser la dette.

  • Dette volontaire consignée

    Quand nous contractons de la dette volontairement, nous la consignons avec un plan de remboursement.

  • Priorités partagées

    Le produit et l'ingénierie s'accordent sur la répartition du temps entre fonctionnalités et dette.

Quand utiliser ce bilan de santé

  • Quand les fonctionnalités prennent plus de temps que prévu et que l'équipe met sans cesse en cause la base de code.
  • Avant la planification trimestrielle ou celle de la roadmap, pour décider du temps consacré au remboursement de la dette.
  • Après un gros rush ou une échéance serrée, pour consigner les raccourcis pris avant qu'ils ne tombent dans l'oubli.

Conseils et astuces

  • Commencez par le groupe le moins bien noté. Une faible visibilité signifie qu'il vous faut d'abord une liste des dettes. Une bonne visibilité associée à un faible remboursement révèle un problème de planification, pas un problème de code.
  • Associez votre product manager à la discussion, même si seuls les ingénieurs notent. La répartition du temps entre fonctionnalités et dette est une décision commune.
  • Croisez les scores avec les données dont vous disposez déjà : durée des builds, nombre de tests instables ou causes d'incidents. L'évaluation montre où ça fait mal, les données montrent à quel point.
  • Menez-la en parallèle de l'autoévaluation des métriques DORA, de l'évaluation de la maturité DevOps ou du modèle de maturité de l'excellence en ingénierie pour voir le lien entre la dette, la livraison et les pratiques d'ingénierie.
  • Répétez-la chaque trimestre. Une hausse du score sur les affirmations du groupe Remboursement de la dette est le premier signe que votre plan fonctionne.

Foire aux questions

Comment mesurer la dette technique ?
Il n'existe pas d'indicateur unique. Les équipes combinent des métriques de code, comme la complexité, le taux de modification (churn) et la couverture de tests, avec des signaux de livraison tels que la durée des builds, les changements en échec et le temps nécessaire pour livrer une fonctionnalité. Une évaluation d'équipe comme celle-ci apporte ce que les outils ne voient pas : les endroits où la dette ralentit réellement les gens. Suivez les mêmes indicateurs dans la durée plutôt que de chercher un chiffre parfait.
Quels sont les quatre types de dette technique ?
La classification la plus connue est le quadrant de la dette technique de Martin Fowler. Il classe la dette selon deux questions : a-t-elle été contractée volontairement ou par inadvertance, et le choix était-il prudent ou imprudent ? Une dette prudente et volontaire est un compromis assumé, assorti d'un plan de remboursement, alors que la dette imprudente a tendance à s'accumuler sans que personne ne s'en aperçoive.
Combien de temps faut-il consacrer à la dette technique ?
Il n'y a pas de réponse standard. Certaines équipes réservent une part fixe de chaque sprint, d'autres planifient des sessions de nettoyage régulières, d'autres encore corrigent la dette dans le code qu'elles modifient déjà. Choisissez une proportion, rendez-la visible lors de la planification et menez cette évaluation chaque trimestre pour vérifier si elle suffit.
Comment expliquer la dette technique aux product managers ?
Parlez des intérêts, pas du code. Montrez comment la dette ralentit des fonctionnalités précises, provoque des incidents ou rend les estimations moins fiables, et ce que sa correction permettrait de libérer. Mener cette évaluation en présence du produit aide beaucoup : les deux parties voient les mêmes scores et peuvent s'accorder sur ce qu'il faut corriger en priorité.
Quel est un exemple de dette technique ?
Une équipe duplique un module pour tenir une échéance et prévoit de fusionner les copies plus tard. Des mois après, chaque correction doit être faite deux fois et les copies ont divergé. Parmi les autres exemples courants, on trouve les dépendances obsolètes, l'absence de tests autour du code critique et un build lent que tout le monde contourne.
Qui a inventé le terme dette technique ?
Ward Cunningham a introduit la métaphore en 1992, dans un retour d'expérience présenté à OOPSLA sur le système de gestion de portefeuille WyCash. Il y écrivait que « livrer du code écrit pour la première fois, c'est comme s'endetter » et que le danger survient quand la dette n'est pas remboursée. TeamRetro n'est pas affilié à Ward Cunningham.

Based on Ward Cunningham, 'The WyCash Portfolio Management System,' OOPSLA '92 Experience Report (1992).

Examens médicaux associés