La santé financière est une métaphore utile pour nous aider à comprendre la relation entre la qualité d’un logiciel et sa valeur réelle. Utiliser la notion de dette financière nous aide notamment à réfléchir aux conséquences de livrer un logiciel plus rapidement au détriment de sa qualité (externe ou interne).
Ward Cunnigham a introduit le terme de dette technique pour faire référence aux raccourcis techniques qu’une équipe fait afin de livrer plus tôt, par exemple pour satisfaire des contraintes de temps ou de budget. Comme l’analogie le laisse supposer, s’endetter c’est accepter de rembourser plus tard et de payer les intérêts en attendant. Et il faut bien comprendre quel est le taux d’intérêt qui s’applique !
Dans le meilleur des cas, la dette est contractée à un taux d’intérêt très faible. Dans un cas bien plus problématique, la dette s’accumule de façon inconsciente et inconsidérée sur des aspects techniques fondamentaux. Rien que le paiement des intérêts de cette dette va couter excessivement cher. Et c’est sans parler du remboursement du capital qu’il faudra entreprendre pour juguler les pertes. Le genre de situation qui mène tôt ou tard à la faillite totale suivie d’une réécriture complète et contre lequel Uncle Bob nous met en garde.
Chris Sterling propose une catégorisation de la dette logicielle qui va au delà de la dette technique. La question n’est pas de savoir si sa catégorisation est exacte, mais bien d’en avoir une qui est utile et nous permet de se doter d’une stratégie de désendettement payante. Dans le même ordre d’idée que Chris, j’utilise les axes suivants pour catégoriser la dette logicielle :
- la dette technique
- la dette de conception, qui traduit l’incapacité du logiciel à évoluer à un rythme soutenable à cause d’une conception ou d’un choix technologique inadapté
- la dette de qualité externe, qui regroupe les bogues, les tests manquants et les critères non fonctionnels non vérifiés
- la dette d’exploitation, qui augmente le coût d’exploiter le logiciel dans le futur, par exemple pour cause de logs de diagnostic ou de support manquants
- la dette de gestion de configuration, qui inclut entre autres le travail laissé de côté sur l’intégration continue et les outils de gestion de révisions
- la dette de collaboration, qui impacte la capacité de l’équipe à collaborer dans le futur, par exemple pour cause de rareté d’une compétence clé
Outre savoir catégoriser sa dette, il faut comprendre comment cette dette s’accumule en premier lieu pour éviter d’en accumuler davantage. Comme le note Martin Fowler dans sa classification de la dette dont InfoQ s’est fait le relai, une dette peut-être accumulée de façon :
- inconsciente, lorsqu’elle est inconnue de l’équipe
- délibérée, elle doit alors être gérée et accompagnée d’une stratégie de désendettement de préférence à court terme
et d’une manière :
- inconsidérée, lorsque l’équipe ne maîtrise pas suffisamment les bonnes pratiques de développement ou ne comprend pas leur importance
- prudente
Pour s’assurer de garder le logiciel en bonne santé financière, une équipe Scrum doit établir ce que signifie qualité production en considérant aussi bien qualité perçue que qualité intrinsèque. Elle doit viser une définition de « terminé » aussi proche de la qualité production que possible. Une équipe qui n’a pas une définition de « terminé » qui lui permet de livrer un logiciel de qualité production à chaque sprint laisse derrière elle ce qu’en Scrum on appelle le travail « non terminé ». Elle se doit de rendre visible au Product Owner ce travail en le portant au Product Backlog. C’est le cas par exemple d’une équipe qui n’a pas encore acquis les compétences pour automatiser certains types de tests pendant le sprint et remet à plus tard l’écriture ou l’exécution manuelle de ces tests.
Pour une équipe qui sait mener cet exercice, la dette est délibérée. Cependant, si la définition de « terminé » de l’équipe est trop réduite, l’accumulation de dette peut être inconsidérée et mener à la faillite du logiciel. Que vaut en effet une définition de « terminé » qui s’arrête aux tests unitaires, ou pire qui ne les inclue pas ?
