LMi-MAG26 Juillet - Flipbook - Page 55
© ATHVisions - iStock
projet agile n’est pas une coïncidence. Les méthodes de
travail agile sont souvent conçues pour la prendre en
compte et encourager les équipes à prévoir des périodes
régulières dans leur emploi du temps pour réviser le
code existant. Cela fait partie de la philosophie d’amélioration continue de ces méthodologies.
Le développement trop rapide du code crée différents
types de dettes techniques que les organisations
ne doivent pas négliger.
de paralyser l’innovation IT. Tout comme le remboursement d’un prêt sur trente ans signifie que vous avez
payé beaucoup plus que le prix de vente de votre maison
- du fait des intérêts -, le déploiement précipité d’un
produit logiciel pour être parmi les « premiers arrivés »
peut engendrer plus tard de nombreux jours-homme
consommés au sein de vos équipes de développement,
d’assurance qualité et de service client.
Trouver le bon compromis
Dans l’absolu, une dette financière n’est ni bonne ni
mauvaise, et il existe des principes, tels que la valeur
temporelle de l’argent, qui aident à déterminer si la
souscription d’un prêt spécifique est une bonne idée ou
non. De la même façon, le concept de dette technique
permet de réfléchir (et même de quantifier) les compromis nécessaires pour le développement de logiciels sous
la pression des marchés dans le monde réel.
Et, pour continuer de filer la métaphore, il existe différentes façons de traiter une dette technique, tout comme
il existe différentes façons de s’occuper de ses dettes
financières. Vous pouvez effectuer de petits paiements
réguliers gérables à court terme, mais qui finissent par
coûter cher au fil du temps, ou vous pouvez rassembler
les ressources nécessaires pour rembourser la totalité
ou la majeure partie de la dette en une seule fois. Dans le
cas d’une dette technique, cela peut signifier accepter un
travail quotidien afin de la réduire couplé à la perte d’efficacité liée à l’utilisation d’un code de mauvaise qualité ;
élaborer un plan effectif de réduction de la dette ; réécrire le code et résoudre les problèmes au fil du temps ;
ou encore, supprimer complètement le code initial et le
remplacer par une version entièrement remaniée.
Par ailleurs, le fait que l’expression « dette technique »
ait été créée par l’un des inventeurs de la gestion de
En 2009, un essai publié par Martin Fowler détaille une
façon d’envisager les différents types de dette technique.
Le développeur et auteur a popularisé le concept de
remaniement du code qui revient à traiter une grande
partie de la dette technique logicielle. Son essai propose
deux axes différents pour catégoriser celle-ci. Le premier consiste à opposer ce qui est planifié et ce qui ne
l’est pas, le second, à choisir entre témérité et prudence.
Une gestion prudente de la dette technique consiste à la
prendre en compte dès qu’elle est contractée ou évaluée
ultérieurement dans le cadre d’une stratégie spécifique,
tandis qu’une gestion téméraire consiste à la laisser
s’accumuler sans trop y penser. Les deux axes combinés créent un tableau comportant quatre approches de
la gestion de la dette.
- La gestion planifiée, mais téméraire : « Nous savons
que nous prenons beaucoup de raccourcis, mais nous
n’avons pas le temps d’y penser ou de nous en préoccuper. Passons tout simplement la ligne d’arrivée ! »
- La gestion planifiée et prudente : « Nous avons évalué
les risques de cette conception avant de la mettre en
œuvre. Nous connaissons les conséquences auxquelles
nous devrons faire face et nous avons un plan pour y
remédier. » [Lire l’intégralité de l’article sur lemondeinformatique.fr]
APPROFONDIR
ÉCOUTER EN LIGNE
Podcast
tinyurl.com/podcast-gerer-dette
LIRE EN LIGNE
Article
tinyurl.com/gerer-dette
55
