Nous sommes devenus une société de débiteurs, dans nos vies comme dans nos projets informatiques !
Technical Debt : No penalty for early payment posté Par Jon sur le blog de Cast Software
Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
Derek remarque aussi que tout comme toute dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre : Elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement l’équipe de support technique ou quelqu’un d’autre en aval.
Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui jetterait les dés pour décider de votre taux d’intérêt. Alors, si vous n’êtes pas obligés de prendre ce risque, ne le prenez pas.
Mais la dette technique est-elle vraiment une proposition de type tout ou rien, blanc ou noir ?
Combien est assez ?
Quand elle considère la Dette Technique, une société doit déterminer combien devrait être investit pour y remédier. La meilleure façon de le faire est en donnant une valeur monétaire à la dette technique pour allouer une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques à rembourser cette dette par rapport aux pertes potentielles coté business en raison d’un échec qui n’était pas envisageable avant de contracter cette dette.
Le but de monétiser la dette technique est de limiter le nombre de violations de la qualité structurelle, ou ce qui est plus important, le coût de les réparer, bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.
Un plan d’action pour la Dette Technique
Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.
La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite de devoir payer plein d’intérêts.
De plus, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.
Alors, profitez de cette période un peu plus calme pour entamer ces travaux de remboursement…
DantotsuPM.com 