Modèle de framework de priorisation de la dette technique

TL; DR : Critères de priorisation

• Connaissance du code. Dans quelle mesure connaissez-vous le code ?

• Sévérité. Comment cela affecte-t-il les fonctionnalités ou les performances du logiciel ?

• Dépendance et échelle. Combien de composants dépendent de cette partie du code ? L'échelle de l'architecture logicielle impactée.

• Coût de correction. Combien de story points cela coûterait-il pour corriger le problème de dette technique ?

Score total = (Connaissance + Sévérité + Dépendance) – 3 * Coût

Lire également 5 conseils pour prioriser la dette technique.

• TL; DR : Critères de priorisation
• Qu'est-ce que la dette technique ?
• Exemples de dette technique
• Le problème de la dette technique
• Critères de priorisation de la dette technique
  • Connaissance du code
  • Sévérité
  • Dépendance et échelle du système
  • Coût de correction
• Personnaliser les descriptions des critères
• Critères inappropriés pour l'évaluation de la dette technique
  • Ne pas utiliser : Valeur métier ou expérience utilisateur
  • Ne pas utiliser : Occurrence
  • Ne pas utiliser : Âge du problème
• Calcul du score de priorité pour les problèmes de dette technique
• Collecter les problèmes pour le backlog de dette technique
  • Conseil 1. Créer une section dédiée dans votre gestionnaire de tâches
  • Conseil 2. Utiliser un format cohérent
  • Conseil 3. Fournir une description claire
  • Conseil 4 : Utiliser la fréquence de modification du code pour collecter la dette technique découverte
  • Conseil 5 : Analyser automatiquement votre code pour les lenteurs et les vulnérabilités
• Conclusion

Qu'est-ce que la dette technique ?

La dette technique est un terme métaphorique utilisé dans le développement logiciel pour décrire le travail de développement supplémentaire qui résulte du choix d'une solution facile à implémenter à court terme plutôt que d'options plus robustes ou évolutives qui peuvent prendre plus de temps. Elle fait référence au coût de la prise de raccourcis ou de l'écriture de code non optimisé pour la maintenabilité, l'extensibilité ou la fiabilité à long terme.

Les exemples de dette technique incluent l'écriture de code spaghetti difficile à lire et à comprendre, l'utilisation de bibliothèques ou de frameworks obsolètes qui ne sont plus supportés, l'absence de documentation du code ou des tests, et le fait de négliger d'effectuer une maintenance ou des mises à jour régulières.

Exemples de dette technique

Problèmes typiques de dette technique :

1. Utilisation de technologies obsolètes ou dépréciées : L'utilisation de technologies anciennes ou non supportées peut entraîner des problèmes de compatibilité et des vulnérabilités de sécurité.

2. Mauvaise qualité du code : Le code difficile à lire, à comprendre et à maintenir peut entraîner des bugs, une productivité réduite et un temps de développement accru.

3. Manque de documentation : Ne pas documenter le code, les processus et les exigences peut rendre difficile pour les futurs développeurs de comprendre le logiciel, ce qui entraîne un temps de développement accru et des coûts plus élevés.

4. Tests insuffisants : Sauter ou retarder les tests peut entraîner des bugs non détectés, des vulnérabilités de sécurité et l'insatisfaction des utilisateurs.

5. Défauts de conception de l'architecture : Concevoir un logiciel avec une architecture sous-optimale ou ne pas planifier l'évolutivité peut conduire à une dette technique car le logiciel devient plus complexe et difficile à maintenir au fil du temps.

Exemples de ce qui N'est PAS considéré comme de la dette technique :

1. Reporter délibérément un travail qui n'est pas critique pour le projet ou qui peut être complété plus tard.

2. Nous prenons des décisions éclairées pour prendre un raccourci afin de respecter une date limite ou de livrer rapidement un prototype.

3. Nous choisissons intentionnellement d'implémenter une solution moins optimale qui reste acceptable pour les objectifs du projet.

4. Nous décidons d'utiliser une technologie ou un outil spécifique même si ses limitations potentielles sont basées sur des compromis avec d'autres facteurs tels que le temps, le coût et les exigences métier.

5. Nous effectuons des tâches de maintenance routinières qui n'améliorent pas significativement le logiciel.

Le problème de la dette technique

Le principal problème de la dette technique est qu'elle peut s'accumuler au fil du temps, rendant plus difficile l'ajout de nouvelles fonctionnalités, la correction de bugs ou la maintenance de la base de code.

• Les fonctionnalités prennent plus de temps à développer

• Plus de bugs

C'est toujours un compromis entre améliorer votre code et ajouter de nouvelles fonctionnalités.

Critères de priorisation de la dette technique

En tenant compte de ces critères, vous pouvez créer un système de priorisation qui vous aide à identifier et à traiter la dette technique dans les problèmes de votre gestionnaire de tâches pour maximiser la valeur métier et minimiser les risques.

N'hésitez pas à ajouter, modifier ou réécrire le nom et la description des critères pour une meilleure compréhension par votre équipe.

Pour chaque critère, nous utilisons l'échelle d'évaluation de la séquence de Fibonacci comme la plus appropriée pour l'estimation en story points.

Tableau hi.ducalis.io avec les critères de priorisation de la dette technique

Connaissance du code

C'est la compréhension et la familiarité d'une équipe de développement avec la base de code sur laquelle elle travaille. Cela inclut la capacité à comprendre et à naviguer dans le code, ainsi que la compréhension de la structure du code, des modèles de conception et des meilleures pratiques utilisées dans le projet.

La connaissance du code est essentielle pour une équipe de développement car elle impacte directement sa capacité à écrire et à maintenir du code de haute qualité de manière efficace. Les équipes ayant plus de connaissances du code peuvent travailler plus rapidement et avec plus de précision.

En bref, la connaissance du code est un composant crucial de l'ensemble des compétences d'une équipe de développement et impacte directement la qualité et l'efficacité de leur travail.

• 1 : Auteur. J'ai écrit ce morceau de code — je peux le maintenir et l'expliquer.

• 2 : Mainteneur. J'ai travaillé avec ce code — aucune question sur son fonctionnement.

• 3 : Accessible. Je peux demander à mon coéquipier et lire la documentation à ce sujet.

• 5 : Documenté. Je n'ai pas travaillé dessus. Nous avons une documentation à ce sujet.

• 8 : Compréhensible. Je n'ai pas travaillé dessus mais j'ai appris comment cela fonctionne sans effort significatif.

• 13 : Difficile. Besoin d'un temps significatif pour comprendre comment cela fonctionne. Je n'ai pas travaillé sur ce code, mais je peux contacter quelqu'un qui a travaillé dessus ou trouver de la documentation.

• 21 : Jamais entendu parler. Personne dans votre équipe ne connaît ce code, ou ils vont bientôt partir.

Sévérité

La sévérité de l'impact : Déterminez dans quelle mesure le problème de dette technique affecte les fonctionnalités ou les performances du logiciel. La sévérité de l'impact pourrait être élevée, moyenne ou faible, et cela peut être utilisé comme critère de priorisation.

• 1 : Aucun impact du tout.

• 2 : Cosmétique : Impact superficiel sur certains composants locaux. Peut être traité ultérieurement lorsque les ressources et le temps seront disponibles.

• 3 : Mineur : Cela fonctionne bien, mais nous pouvons l'améliorer. Peut être traité ultérieurement lorsque les ressources et le temps seront disponibles.

• 5 : Ralentisseur : Ralentit la productivité, rend le code moins maintenable ou empêche l'ajout de nouvelles fonctionnalités. Peut être traité plus tard lorsque les ressources le permettent. Peut être traité plus tard

• 8 : Bloquant. Bloque les améliorations ou mises à jour futures d'un composant du logiciel. Doit être traité bientôt pour éviter que des problèmes significatifs ne surviennent.

• 13 : Majeur. Bloque et casse presque plusieurs composants logiciels. Crée des risques supplémentaires ou des retards pour le projet.

• 21 : Destructeur. Rend le logiciel inutilisable ou crée un risque élevé s'il n'est pas résolu.

Dépendance et échelle du système

Combien de composants dépendent de cette partie du code ? L'échelle de l'architecture logicielle impactée :

• 1 : Trivial. Peut être ignoré car il peut être remboursé à tout moment.

• 2 : Local mineur. Est contenu dans une seule méthode, classe ou fonction. Peut violer les principes SOLID — aucun impact significatif sur la qualité globale du logiciel.

• 3 : Local modéré : Impacte plusieurs méthodes, classes ou fonctions. Peut également être plus difficile à modifier sans causer de conséquences involontaires.

• 5 : Global. Contenu dans une seule application ou service mais implique des violations SOLID à travers les sous-systèmes dans un système plus étendu qui se propagent vers des zones apparemment non liées. Peut également inclure une inadéquation entre les couches d'abstraction, des problèmes de point d'intégration et un couplage fort. Cette dette n'impacte pas les consommateurs de l'application ou du service, mais elle est ressentie lors de la modification du service lui-même.

• 8 : Majeur global. Impact plus significatif et étendu sur la qualité du logiciel. Peut impliquer plusieurs sous-systèmes et impacter l'ensemble de l'application ou du service. Peut également être plus difficile à modifier sans causer de conséquences involontaires.

• 13 : Systémique. Se répand sur plusieurs applications, infrastructures ou équipes. Implique de nombreux services partageant une base de données, un couplage élevé entre différents contextes délimités et une inadéquation flagrante entre les implémentations techniques et la logique métier. La dette systémique est intenable à long terme et nécessite une attention immédiate.

• 21 : Critique. Pose un risque significatif pour la qualité globale du logiciel et peut impacter la stabilité et la fiabilité du système.

Coût de correction

Combien de story points cela coûterait-il pour corriger le problème de dette technique ?

• 1 : Aucun effort

• 2 : Coût faible : 10 % de la durée du sprint.

• 3 : Modéré : 20 % de la durée du sprint.

• 5 : Significatif : Demi-sprint

• 8 : Élevé : Un sprint

• 13 : Très élevé : Plus d'un sprint, mais moins de deux sprints. Recommandé de diviser en plusieurs problèmes.

• 21 : Prohibitivement coûteux. Aucune idée maintenant sur comment le gérer. Deux sprints et plus.

Personnaliser les descriptions des critères

N'oubliez pas que les meilleures descriptions de critères sont celles qui sont plus faciles à comprendre pour vos coéquipiers. Plus vous aurez des descriptions de critères et d'échelles spécifiques — mieux ce sera pour votre processus de priorisation. Spécifiez les durées de sprint, les explications des dépendances, les définitions des bloqueurs et la signification de la connaissance du code. En savoir plus sur l'édition des descriptions de critères.

Personnaliser les descriptions des critères

Critères inappropriés pour l'évaluation de la dette technique

La valeur métier, l'occurrence, l'âge et l'impact sur l'expérience utilisateur sont des critères peu fiables pour évaluer la dette technique.

Ne pas utiliser : Valeur métier ou expérience utilisateur

Des facteurs tels que la qualité du code, la documentation, la couverture de tests et l'architecture logicielle sont rarement directement corrélés avec des indicateurs métier comme les revenus. Ces facteurs affectent la capacité de l'équipe de développement à effectuer des changements efficacement et la qualité globale, la fiabilité et l'évolutivité du logiciel.

L'une des raisons les plus populaires pour ne pas maintenir la dette technique est de l'évaluer en termes de revenus potentiels.

Ne pas utiliser : Occurrence

Considérez la probabilité que le problème de dette technique se reproduise à l'avenir. La dette technique n'est pas un bug qui peut se reproduire. Ne perdez pas votre temps à prédire l'avenir.

Ne pas utiliser : Âge du problème

Cela peut sembler une idée évidente et simple de refactoriser les anciennes bibliothèques plus tôt. Mais pourquoi devriez-vous y consacrer du temps si le code fonctionne bien et ne ralentit pas ou ne crée pas de vulnérabilités ? L'âge ne devrait pas être votre critère de priorisation.

Calcul du score de priorité pour les problèmes de dette technique

Comme d'habitude, nous devons équilibrer les poids des critères pour la bonne stratégie de définition des priorités principales pour la dette technique. Par défaut, nous avons un poids de -2. Moins vous avez de ressources de développement dans votre équipe — plus le poids doit être négatif.

Configuration du poids pour le critère « Coût »

La formule finale est assez simple :

Collecter les problèmes pour le backlog de dette technique

Dans « Essential Scrum: A Practical Guide to the Most Popular Agile Process », l'auteur Ken Ruben utilise trois catégories pour définir la dette technique : la dette technique découverte, connue et ciblée.

• La dette technique découverte est une dette technique que l'équipe de développement ne savait pas exister jusqu'à ce qu'elle soit exposée lors de l'utilisation ou de la maintenance routinière du produit. Par exemple, lors de l'ajout d'une nouvelle fonctionnalité au logiciel, l'équipe peut découvrir une solution de contournement qui a été ajoutée au code il y a des années et laissée inchangée, entraînant un comportement inattendu. La dette technique découverte peut également être causée par le « bit rot », qui se produit lorsque le code se détériore au fil du temps, modifiant sa fonction et son utilisabilité.

• D'autre part, la dette technique connue est une dette technique dont l'équipe de développement est déjà consciente et peut voir dans le logiciel. Les exemples de dette technique connue incluent une mauvaise qualité du code, un manque de documentation ou des tests insuffisants.

• Enfin, la dette technique ciblée est une dette technique connue que l'équipe de développement a choisi de traiter dans un sprint ou une version spécifique. Cela pourrait impliquer la refonte du code, l'amélioration de la documentation ou l'augmentation de la couverture de tests pour réduire la dette technique et améliorer la qualité du logiciel.

En comprenant les différents types de dette technique, les équipes de développement peuvent prioriser leurs efforts et travailler à traiter la dette technique pour minimiser son impact sur la maintenabilité et la fiabilité à long terme du logiciel.

Conseil 1. Créer une section dédiée dans votre gestionnaire de tâches

Il est essentiel d'avoir une propriété pour séparer les problèmes de dette technique des autres problèmes comme les bugs ou les fonctionnalités. Utilisez une étiquette/un libellé spécial, un type de problème ou un composant. Vous devez toujours avoir la possibilité de consulter le backlog complet avec tous les problèmes et de le filtrer par type.

Conseil 2. Utiliser un format cohérent

Utilisez un format cohérent pour enregistrer les problèmes de dette technique, comme une User Story ou une tâche dans votre outil de backlog. Cela vous aidera à identifier et à prioriser facilement les problèmes de dette technique.

Conseil 3. Fournir une description claire

Fournissez une description claire du problème de dette technique, y compris son impact sur la base de code, l'effort estimé nécessaire pour le corriger et les risques ou conséquences potentiels.

Conseil 4 : Utiliser la fréquence de modification du code pour collecter la dette technique découverte

La fréquence de modification du code est la fréquence à laquelle des modifications sont apportées à la base de code d'un système logiciel.

Elle peut être utilisée pour évaluer la santé et la qualité d'un projet logiciel et identifier les problèmes et risques potentiels. Elle permet d'évaluer l'impact, d'identifier les zones à haut risque et de prendre des décisions éclairées sur les modifications de la base de code.

• Une fréquence élevée peut indiquer des mises à jour fréquentes, des améliorations, une instabilité ou des erreurs.

• Une fréquence faible peut indiquer un manque de maintenance ou d'évolution, conduisant à une dette technique et d'autres problèmes.

Fortement recommandé de regarder la conférence d'Adam Tornhill sur cette idée, «

».

Conseil 5 : Analyser automatiquement votre code pour les lenteurs et les vulnérabilités

Il existe de nombreux outils pour l'analyse de code. Essayez-les et envoyez les problèmes trouvés au backlog de votre gestionnaire de tâches.

1. Code Scene — Un outil pour visualiser, comprendre et améliorer votre logiciel en termes de code, de connaissances et de personnes qui le sous-tendent. Effectuez des améliorations basées sur des recommandations automatisées, priorisées et exploitables.

2. SonarQube : Un outil populaire qui peut détecter les vulnérabilités de sécurité, les code smells et d'autres problèmes dans votre code. Il prend en charge divers langages de programmation et s'intègre avec divers outils CI/CD.

3. OWASP ZAP : Un scanner de sécurité d'application Web open-source qui peut détecter des vulnérabilités telles que l'injection SQL, le cross-site scripting et d'autres problèmes de sécurité.

4. CodeClimate : Une plateforme basée sur le cloud qui analyse votre code et fournit des informations sur sa qualité, sa maintenabilité et sa sécurité. Elle prend en charge divers langages de programmation et s'intègre avec GitHub, Bitbucket et d'autres outils.

5. Snyk : Un outil basé sur le cloud qui analyse votre code et vos dépendances à la recherche de vulnérabilités de sécurité et fournit des conseils de remédiation. Il prend en charge divers langages de programmation et s'intègre avec divers outils CI/CD.

6. AppDynamics : Un outil qui fournit des informations en temps réel sur les performances de vos applications, y compris le temps de réponse, le taux d'erreur et d'autres indicateurs. Il vous aide à identifier les goulots d'étranglement de performance et à optimiser votre code.

7. Qodana. Évaluez l'intégrité du code que vous possédez, contractez ou achetez. Enrichissez vos pipelines CI/CD avec toutes les fonctionnalités intelligentes que vous aimez des IDE JetBrains

Conclusion

La dette technique est inévitable dans le développement logiciel, mais elle peut également être un obstacle significatif au progrès et à l'innovation. En développant un système de priorisation de la dette technique qui fonctionne pour votre équipe, vous pouvez minimiser son impact et maintenir la qualité et la fiabilité de votre logiciel au fil du temps.

N'oubliez pas que la dette technique n'est pas seulement un problème de développeur ; elle affecte l'ensemble de l'organisation. En intégrant la gestion de la dette technique dans vos processus de gestion de projet, vous pouvez vous assurer que tout le monde est conscient de son impact et travaille ensemble pour y remédier.

Enfin, il est important de se rappeler que traiter la dette technique n'est pas un événement ponctuel ; cela nécessite une attention et un effort continus. En examinant et en mettant à jour régulièrement votre backlog de dette technique, vous pouvez rester au top des problèmes potentiels et vous assurer que votre logiciel reste sain et fiable à long terme.

Lire ensuite : 5 conseils pour prioriser la dette technique