La Dette technique. Un frein inévitable !
Comment on est arrivé là ?
Quand on commence généralement à concevoir un produit on part d’une feuille blanche. On part aussi avec une volonté d’écrire soigneusement sur cette feuille blanche, et sans ratures. On part avec l’ambition de préserver la propreté de notre code, notre conception, nos idées, ce qui nous garantira une longue vie, et une maintenabilité de notre produit, ainsi qu’une réponse favorable aux exigences du marché, et de nos clients.
Il est clair que la qualité est l’un des piliers d’un développement agile basé sur un swarming implacable de la part de l’agile team. Sauf que dans la réalité plus les besoins métiers, plus on développe, plus on arrive à un niveau de saturation. Le moindre pas, le moindre choix d’implémentation doit être bien réfléchi, pour éviter à l’équipe des besoins de refactoring fréquent qui impacteront par la suite leur vélocité, et leur débit de production puisque cette dette deviendra un vrai FREIN !Plus dangereux que cela une dette systémique suite à des choix d’architectures précipités peut causer une démotivation des développeurs, et un risque d’anomalies très élevé qui peut coûter cher à une entreprise, voir devoir réécrira le code de fond en comble, et stopper la production de valeur puisqu'il faudra rembourser la Dette.
Il est clair que la qualité est l’un des piliers d’un développement agile basé sur un swarming implacable de la part de l’agile team. Sauf que dans la réalité plus les besoins métiers, plus on développe, plus on arrive à un niveau de saturation. Le moindre pas, le moindre choix d’implémentation doit être bien réfléchi, pour éviter à l’équipe des besoins de refactoring fréquent qui impacteront par la suite leur vélocité, et leur débit de production puisque cette dette deviendra un vrai FREIN !Plus dangereux que cela une dette systémique suite à des choix d’architectures précipités peut causer une démotivation des développeurs, et un risque d’anomalies très élevé qui peut coûter cher à une entreprise, voir devoir réécrira le code de fond en comble, et stopper la production de valeur puisqu'il faudra rembourser la Dette.
Quelles sont les raisons qui peuvent provoquer cette dette ?
Dès les premiers développements cette dette commence a naître et cela pour plusieurs raisons parmi ces raisons:
- Une course acharnée pour livrer sans tester (Non intentionnelle)
- Aucun respect des bonnes pratique de code et d’implémentation (Exemple: SOLID) (Intentionnelle)
- Aucun Alignement avec le besoin métier (Non intentionnelle)
- Une course acharnée pour livrer sans tester (Non intentionnelle)
- Aucun respect des bonnes pratique de code et d’implémentation (Exemple: SOLID) (Intentionnelle)
- Aucun Alignement avec le besoin métier (Non intentionnelle)
Quel est l'impact sur la vie du produit produit ?
Vélocité : On burn moins de story point par sprint à cause de la dette
Qualité: On livre des incréments de produits avec plus d’anomalies que d’habitude
Confort: L’équipe est stressé, et n’arrive plus à suivre les demandes d’évolutions métiers.
Productivité: Des anomalies corrigées reviennent souvent
Comment recenser la dette d'un produit?
La
dette peut être divisées en trois catégories, qu’on pourra représenter à l’aide
de l’arbre produit:
Le tronc: La dette à rembourser rapidement,
et qui frein de développement.
Les branches: La dette qu’on pourra vivre avec
mais qui représente un vrai obstacle.
Les feuilles: la dette qu’on pourra vivre avec,
et qui sera bien un jour de la rembourser.
Comment sensibiliser le PO à la dette technique ?
Commentaires
Enregistrer un commentaire