Savez-vous ce qu’est un registre de « Dette Technique » et comment bien l’utiliser dans les méthodes itératives #Agile ?

« Dettes et mensonges sont ordinairement ensemble ralliés » Rabelais dans Pantagruel.

Using a « Technical Debt Register » in Scrum

https://www.scrum.org/resources/blog/using-technical-debt-register-scrum par Ian Mitchell

En vieillissant, je me métamorphose en l’un de ces types nostalgiques et ennuyeux qui vit trop dans le passé. Les choses étaient mieux avant, mon enfant. Nous avions des standards et il y avait moins de « sur-simplification ».

Mais parfois au crépuscule, comme je me lève de mon fauteuil à bascule sous le porche et me penche en avant pour soulager mon dos, je reconnais qu’il y a une chose qui est en réalité meilleure maintenant qu’au début des années 2000 : De nos jours, un homme peut parler de la « dette technique » sans que les gens le prennent pour un fou.

La dette technique peut être définie comme les conséquences à long terme de faibles décisions de conception. À l’origine décrit comme une métaphore par la Ward Cunningham, à peu près tout le monde accepte maintenant que la dette technique est un risque réel qui peut réellement être encouru. Cette identification est bonne. Critiquer Java et en damner les conséquences n’est pas vraiment « Agile », c’est juste jouer au cow-boy. Mais la vérité est que pendant des années, cela n’a pas été compris, pas avant que les dettes de certains imbéciles soient si importantes qu’elles ne puissent perdurer.

Cela vaut cependant la peine de garder à l’esprit que pas tous les défauts et bugs ne constituent de la dette technique.

Écopez un peu de votre dette avant qu’elle ne vous noie.

C’est parce qu’ils ne reflètent pas toujours « des décisions de conception ». Ce sont souvent juste des erreurs, peu importe à quel point ils pourraient être irresponsables ou indignes. Ainsi quand une décision ne met pas directement en péril la qualité de produit, ce n’est pas de la dette technique. Une équipe peut souhaiter un nouvel environnement ou un module d’extension, mais ne pas les fournir n’est pas de la  » dette technique », puisque cela ne met pas en danger la qualité du produit lui-même. Cela pourrait très bien réduire la vitesse de développement, parce qu’ils doivent boitiller en utilisant une vieille plate-forme de développement, mais c’est un problème différent.

Dans Scrum, l’attente consiste en ce qu’une définition de DONE (fait) devrait être suffisamment robuste pour que des niveaux ingérables de dette ne puissent pas s’accumuler. De là, si on sait que la dette technique va augmenter, la définition de DONE devrait être revisitée. Il est essentiel de découvrir pourquoi la dette est encourue et comment cela peut être évité.

Il y a certain nombre d’autres contrôles qui peuvent être utilisés pour limiter la dette.

Par exemple, une équipe devrait tenir compte du « refactoring » (et bien d’autres tâches) en décidant de combien de travail ils peuvent embarquer dans un Arriéré de Sprint sans mettre en péril la qualité à long terme. Mais en dehors de ces contrôles et recherches d’équilibre, il n’y a aucune prescription sur comment la dette technique devrait être traitée une fois que vous l’avez. Ce n’est pas une inadvertance, puisque Scrum est délibérément aussi non-normative que possible. C’est une structure de travail qui laissent aux équipes la décision de comment elles la mettent en œuvre.

finiNotez cependant que mettre en œuvre « des sprints spéciaux » pour nettoyer la dette technique n’est pas une option. Des sprints techniques de dettes, aussi mentionnés comme des sprints de solidification ou renforcement, sont essentiellement un anti-modèle. Chaque Sprint doit apporter un incrément de valeur véritable. C’est pourquoi la Définition de DONE est le rempart primaire contre l’accroissement de la dette en premier lieu.

Ce que font certaines équipes est de maintenir un registre de dettes techniques

Dans ce registre les décisions de conception qui mènent à de la dette peuvent être rationalisées. Vous pouvez penser à ce registre comme un registre RAID (Risques, Assomptions, Issues & problèmes, et Dépendances) qui est sous le contrôle de l’équipe. L’équipe y détaille les conséquences techniques de décisions prises de manières opportunes sur la qualité de mise en œuvre du produit, souvent en termes de probabilité, d’impact et de remédiations envisagées. Il peut être possible de recommander de l’adresser pendant un Sprint, si l’équipe a une compréhension suffisante de l’Arriéré de Produit. Suppositions et dépendances peuvent aussi entrer dans le registre et bien sûr quelques risques peuvent finalement transformer en douloureux problèmes.

Un registre technique de dettes peut aider à informer des équipes de comment la dette encourue devrait être gérée. Ils peuvent prendre des décisions réfléchies et informées sur quand vraiment ajouter de la dette et quand au contraire la rembourser. L’utilisation d’un tel registre ne fait pas partie de Scrum, mais néanmoins cette technique peut aider une équipe à prendre en main la dette technique qu’ils décident d’accepter. Parfois, par exemple, la dette technique peut être réglée en mettant en œuvre des histoires de l’arriéré de produit. Dans d’autres cas pas, et la dette doit alors être adressée séparément.

Que faire ?

Certains cas de dette peuvent devoir être exposés au Propriétaire de Produit pour leur prise en considération et d’autres pas. Dans les cas sévères, de la dette technique peut avoir été accumulée qui excède la valeur du projet lui-même, probablement même de multiples fois. Dans de tels cas extrêmes, l’approche la plus pragmatique peut être de tuer le projet et repartir de zéro. Inutile de le dire, cette variation de « échouer maintenant plutôt que plus tard » nécessite un courage extrême.

remboursez graduellement votre dette

Une autre option quand on fait face à une dette technique substantielle est de la réduire graduellement, Sprint après Sprint. L’équipe peut devoir s’entendre avec le Propriétaire de Produit pour livrer quelque chose, à chaque itération, qui fournisse tout de même une valeur suffisante aux parties prenantes. Clairement ce n’est pas une excellente option. Elle peut se terminer en marchandages, où la magnitude et la propriété du problème de la dette ne sont pas reconnues ni rendues visibles des parties prenantes. La dette technique devient alors plus d’un cas de problème technique. Les parties affectées pourraient être encouragées à fermer les yeux tant qu’elles obtiennent quelque chose de valeur immédiate pour le business en retour, mais aucun de ceci n’est bon pour la franchise, la confiance ni la transparence.

Maintenant, bien qu’ayant comparé un registre technique de dettes à un registre RAID, je ne suggère pas qu’il doive prendre la forme « documentée » habituelle de celui-ci. Selon mon expérience, il est généralement meilleur d’utiliser un « Information Radiator ». Parfois, cela peut être aussi rudimentaire qu’une feuille de papier scotchée au dos de la chaise du ScrumMaster, mais je préfère proposer aux équipes d’utiliser un mur de cartes dédié à cette fin. Les statuts typiques sont : A faire, En cours, Fait et A escalader. Les articles sont Faits quand ils sont ou atténués ou acceptés.

Incidemment, cela marche aussi pour les registres RAID conventionnels au niveau du projet et du programme. L’escalade depuis un Registre de Dettes Techniques impliquerait sa promotion à un tel niveau. Les managers sont ainsi encouragés à prendre un intérêt actif dans ces registres et questionner tout problème non remonté qui semblent bloqué.

Cela peut être une excellente façon d’encourager le « gemba » chez les managers, où ils sortent du bureau, s’y promènent, mettent leurs liens hiérarchiques et filtres de côté et voient la réalité des choses par eux-mêmes.

CertYou est partenaire de DantotsuPM

Pour aller plus loin, relisez ces précédents billets sur ce sujet

 

19 Juillet – Montréal #PMI® – Comment gérer la dette technique ?

Les bonnes pratiques de l’Agile Alliance

Ward Cunningham, un des auteurs du manifeste agile, a comparé l’ensemble des problèmes dans le code à une dette financière, et l’a appelé dette technique.

Qu’est que la dette technique ? Comment l’évaluer ? Comment prendre des décisions rationnelles et comment gérer la dette technique ? Il y a-t-il d’autres types de dette à prendre en compte ?

L’initiative “Technical Debt” de l’Agile Alliance a été lancée pour répondre à ces questions. La présence à Montréal des membres de ce programme est l’occasion de présenter des bonnes pratiques, le modèle A2DAM et d’organiser une session du jeu “Dice of Debt”.

Pour cette session, seront présents :

  • le livre de Chris Sterling

    Declan Whelan, un des membres à l’origine de cette initiative. Il est coach agile et membre du board de l’Agile Alliance.

  • Jean-Louis Letouzey, leader de l’initiative, il est l’auteur de la méthode SQALE pour manager la dette technique.
  • Tom Grant, auteur du jeu “Dice of Debt game” a été le directeur de la pratique agile du Cutter Consortium. Il a participé à l’Analyst Panel d’Agile 2015 – En plus de son expertise agile, il est expert en serious games.
  • Jean-Pierre Fayolle est consultant en qualité des logiciels. Il est l’animateur du blog “Qualilogy”
  • Dan Sturtevant, chercheur étudiant la qualité des logiciels  et son impact financier à la Harvard University, et CEO de Silverthread, Inc.
  • Thierry Coq, consultant principal et directeur de projet pour les systèmes industriels, pétrole et gaz et maritimes chez DNVGL

réservation

PMI is a registered mark of Project Management Institute, Inc.

Les enregistrements des ScrumPulse Webcasts sont accessibles gratuitement pour aider les débutants #Scrum et permettre aux plus expérimentés de s’améliorer !

Les initiateurs, experts et formateurs sur la méthode Scrum et surtout sur les attitudes Agile y partagent leurs expériences.

En sus de ces webcasts, le site Scrum.org vous permet de visionner des vidéos et lire des papiers d’étude et articles de blog sur l’agilité et plus spécifiquement sur Scrum.

Scrum and Upcoming Agile Webcasts
Scrum and Upcoming Agile Webcasts

#22 – Management 3.0 & Scrum:  How to Become a Next Generation Leader

#21 – Women in Agile: Empowering the next Generation of Influencers

#20 – Software Craftmanship in Professional Scrum

#19 – Role of a Scrum Master (Special Spanish Edition)

#18 – Software Ethics Panel Discussion

#17 – Transforming a 25,000+ Person Consulting Company to Become More Agile

#16 – Multicultural Scrum the Impact of Culture on Living the Scrum Values

#15 – Myths, Misconception & Mysteries of Product Ownership

#14 – Scrum Guide Refresh July 2016

#13 – Scaling Professional Scrum with Visual Studio Team Services

#12 – Cage Fight:  Product Owner vs. Product Manager

#11 – The Core Protocols

#10 – We’re Moving to Agile:  What Are Our Testers Going to Do?

#9 – Organizational Improvement: Using a Framework to Guide Your Change

#8 – Challenges in the Development Team

#7 – How to Ship Your Software with Confidence and Speed

#6 – Psychological Models in Scrum

#5 – Agile Metrics

#4 – Self Managing Teams: 4 Building Blocks and an Evidence Based Approach

#3 – Scaling Scrum and Agility

#2 – Transparency in the Trenches

#1 – Dealing with Technical Debt

CertYou est partenaire de DantotsuPM
CertYou est partenaire de DantotsuPM

Enregistrer

bonne résolution de fin d’année: remboursez votre « dette technique » !

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

empty pocketsNous 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. »

bonhom-boulet
Le boulet de la dette technique peut vous empêcher d’avancer.

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 ?

bonhom-calculator-business
Calculez le coût de votre dette technique

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.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

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.

Bill Curtis
Bill Curtis

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.

technical-debt-software-qualityUne 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.

bonhom-travaux-roadworks
Le remboursement de la dette technique demande parfois des travaux importants

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…

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Le rapport CRASH de CAST Software révèle les réels impacts du développement Agile

impact objectif des méthodes agiles, de l’externalisation et de l’offshoring: des évidences mais aussi de l’inattendu !

Rassemblant les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises, cette étude de CAST sur la qualité logicielle des applications (CRASH), présente l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.

Télécharger le rapport CRASH

L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.

Crash Report 2015

Les principales conclusions sont pour certaines évidentes, d’autres bien plus surprenantes.

  • l’intégrité architecturale d’une application affecte sa sécurité,
  • les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
  • la maturité des processus (niveau CMM) affecte la qualité générale du code,
  • les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
  • les équipes internes et externalisées fournissent la même qualité de code,
  • l’offshoring impacte la robustesse et l’évolutivité des applications.
Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Précédentes éditions:

ne vous précipitez pas sur la dette (technique) par Jeff Ball

Bien faire ou faire vite? Il y a parfois un prix à payer quand on “fait vite”. C’est ce qu’on appelle la Dette Technique.

facturesMS-DOS est probablement l’exemple le plus connu de Dette Technique. En 1981, IBM demanda à Bill Gates de développer un système opératif pour son nouveau PC. Pour respecter les délais, il prit le QDOS (Quick and Dirty Operating System, Système Opératif Vite fait Mal fait) et le renomma MS-DOS. Bâclé et grossier, MS-DOS a été alourdi par une dette dès sa conception, il était doté d’un ensemble de commandes qui laissaient à désirer et de caractéristiques limitées.

Dans le monde de la gestion de projet, le respect des délais est un point clé pour mesurer la réussite de la plupart des projets. En vous pressant pour respecter les délais, il se peut que vous accumuliez une dette sans vous en rendre compte, silencieusement… mais de manière constante.

La Dette Technique peut prendre les formes suivantes:

  • developer womanDocumentation ou manuel d’utilisation inexistants
  • Programmation de mauvaise qualité (non structurée, avec peu de commentaires, codage en dur)
  • Bases de données mal structurées (données redondantes, erreurs de données)
  • Mauvaise conception (mauvaise architecture, non modulable)
  • Mauvais processus (inefficaces, entraînant une perte de temps, sujets à erreurs)

Habituellement, on parle de dette pour des projets de développement de logiciels, mais elle ne s’applique pas uniquement au software – toutes sortes de projets peuvent générer une dette.

Souvent, la Dette Technique est issue de la pression exercée pour respecter les délais, mais ce n’est pas seulement une question de précipitation.

Plusieurs facteurs peuvent être source de dette :

  • Image courtesy of ambro / FreeDigitalPhotos.net
    Image courtesy of ambro / FreeDigitalPhotos.net

    La vitesse: la précipitation est probablement la première cause de Dette Technique

  • Vision à court terme: rapiéçage et raccommodage. Solutions dénuées d’architectures
  • Contre-la-montre: efforts concentrés sur le retard accumulé (au lieu de penser au futur)
  • Innovation de pointe : apprentissage sur le tas
  • Manque de compétences: assignation de personnel n’ayant pas les bonnes compétences (ou pas de compétences du tout) à des tâches complexes.

Pourquoi s’en inquiéter?

La Dette Technique est comme la dette financière… vous pouvez l’ignorer pendant un temps, mais l’accumulation de dette reviendra vous hanter. En présence de dette, le résultat final sera chaotique – un patchwork ou un sac de nœuds difficile à comprendre ou à changer.

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Ce sera une surcharge potentielle pour tout ce qui sera entrepris par la suite – la Dette Technique peut ralentir et compliquer des projets futurs. Elle peut aussi engendrer un vieillissement prématuré – l’accumulation de dette peut raccourcir la durée de vie de votre solution.

Ne vous précipitez pas sur la dette.

le livre de Chris Sterling
le livre de Chris Sterling

La principale source de dette est la précipitation. Certaines méthodes de gestion de projet se basent sur la rapidité ; c’est le cas de la plupart des variantes légères d’Agile. Ces dernières, comme Scrum, généreront nécessairement une dette si l’on se focalise trop sur la rapidité. Les délais seront peut-être respectés, mais si c’est au prix d’autres facteurs de bonnes pratiques, tels que le design, la planification ou la qualité, alors il se peut que vous accumuliez une dette.

Il existe deux façons de contourner ce problème pour les projets Agile : essayer de rendre cette méthode légère plus robuste (comme décrit dans le livre « Managing Software Debt » de Chris Sterling) ou utiliser une solution Agile.

Pourquoi utiliser Agile?

APMG-AgilePMLes méthodes Agile telles que DSDM Atern (parfois appelée AgilePM) permettent de combiner agilité avec architecture et design. Atern possède également un ensemble d’outils assurant une approche à long terme (plans, étude de rentabilité, etc.) – qui aident aussi à établir le compromis entre rapidité et dette (et par conséquent à éliminer ou réduire la dette).

Quelle que soit la solution que vous choisissiez, que vous utilisiez Agile ou non, vous devez garder cette notion de dette à l’esprit.

Jeff Ball
Jeff Ball

Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :

  1. Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
  2. Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
  3. Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
Institut International de Conseil et de Formation Accrédité aux Bonnes Pratiques PRINCE2® (Gestion de Projet), ITIL® (Gouvernance du SI), P3O® (Management d'un PMO) et MSP® (Management de Programme).
Partenaire de DantotsuPM

© Copyright QRP International 2011. Reproduction in full or part is prohibited without prior consent from QRP International

Pour aller plus loin:

10 Octobre – Paris – Matinée CIO de CAST avec le CRASH Report 2014

Dans l’étude 2014 de CAST sur la qualité logicielle des applications (CRASH), les résultats de l’analyse de 1300 applications développées par plus de 200 entreprises montrent l’impact objectif des méthodes agiles, de l’externalisation et de l’offshoring.

Cast 10 Octobre 2014
Enregistrez-vous

L’étude montre notamment que:

  • Téléchargez le rapport
    Téléchargez le rapport

    l’intégrité architecturale d’une application affecte sa sécurité,

  • les applications servant plus d’utilisateurs ont tendance à être de meilleure qualité,
  • la maturité des processus (niveau CMM) affecte la qualité générale du code,
  • les méthodes hybrides Agile/Waterfall produisent de meilleurs résultats que les méthodes agiles pures,
  • les équipes internes et externalisées fournissent la même qualité de code,
  • l’offshoring impacte la robustesse et l’évolutivité des applications.

L’étude traite de la dette technique, des langages de programmation, des tendances en méthodes de développement et de sourcing, et de leur impact sur la qualité de vos applications métiers critiques.

Pour télécharger les principaux résultats de l’étude (en anglais), cliquez ici.

Les résultats de cette étude seront également présentés lors de la Matinée CIO de CAST le 10 octobre prochain, parmi d’autres interventions de DSI et d’experts.
— Programme détaillé et inscription —

Les Quatre Catégories De Dette Technique

The Four Grades of Technical Debt

http://madebymany.com/blog/the-four-grades-of-technical-debt par James Higgs

Presque toutes les communications entre les développeurs et collègues non techniques ou clients sont composées d’un jeu de métaphores. Certaines d’entre elles (la métaphore du bâtiment, par exemple) sont activement nuisibles, mais d’autres sont potentiellement très utiles.

L’idée de Dette technique est l’une de celles-ci, mais, comme avec toute métaphore, il est important de comprendre où se trouvent les limites de son applicabilité. Pour que ces métaphores soient utiles, elles doivent être utilisées avec précision.

Il y a une tendance prononcée à s’approprier des termes techniques et ensuite les utiliser de façon inexacte (‘ le système d’exploitation ‘ est la locution du jour), vraisemblablement pour apparaître mieux informé sur la technique, mais, à quelqu’un qui connaît ce que ces choses signifient vraiment, l’effet est de faire apparaître l’utilisateur de cette métaphore comme un baratineur.

Abusé de cette façon, des termes utiles deviennent progressivement dépouillés de leur sens et des remplaçants doivent être trouvés. Je m’inquiète que ceci puisse arriver avec ‘ la dette technique ‘. J’espère que ce billet aidera à clarifier sa signification.

Ward Cunningham
Ward Cunningham

Selon Wikipedia, Dette Technique est « La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. Il s’inspire du concept existant de dette dans le contexte du financement des entreprises et l’applique au domaine du développement logiciel ». Comme avec la dette financière, ceci est souvent inévitable et les résultats peuvent finalement être paralysants si non correctement identifiés et a traités.

Tous les projets encourent de la dette technique et ce n’est pas une mauvaise chose. Un projet sans dette avance trop précautionneusement et génère certainement des pertes. Dans un projet Lean, tout particulièrement, ce serait une erreur de produire le code sans dette tout le temps. Une approche plus raisonnable serait de tester une hypothèse en l’exécutant aussi rapidement que possible et apprenant de son utilisation dans la vraie vie. C’est seulement si les utilisateurs aiment la nouvelle fonctionnalité que cela a du sens de rembourser la dette.

Paul et moi-même en discutions l’autre jour et j’ai inventé ce que je décris comme quatre ‘catégories’ de dette.

Catégorie Une : dette accumulée au fil du temps en raison de changements de structure

facturesSi vous développez du logiciel de façon raisonnable, vous construirez sur le travail d’autres en utilisant des structures prédéfinies – comme « Ruby on Rails » – qui sont largement comprises et supportées. Une des caractéristiques de telles structures est qu’elles évoluent, parce que la seule alternative serait l’atrophie.

Dans une structure saine, ces changements rendent les choses plus simples, plus sécurisées, plus rapides, plus faciles à maintenir, plus flexibles et plus riches en fonctionnalités. Le compromis est qu’elles n’assurent souvent pas la compatibilité-arrière. Aussi, à moins que votre équipe de développement ne fasse l’effort d’adopter les nouvelles caractéristiques, vous encourrez progressivement de la dette technique. Pourquoi ?

Il est presque inévitable qu’une structure s’améliore au point que vous vouliez adopter les versions plus récentes, même s’il s’agit simplement d’appliquer un patch de sécurité. Si vous ne gardez pas un œil attentif sur ces changements dans les fondations et ne maintenez pas votre code de base relativement à jour, il deviendra de plus en plus difficile d’adopter les versions plus récentes. Peut-être quelqu’un sortira-t-il un nouveau plug-in, ou intégrera un nouveau service social auquel vous tenez. Mais qui va prendre le temps d’écrire le code pour le supporter sur les versions antérieures ?

Cette sorte de dette est la moins destructrice et peut facilement être évitée en adoptant une bonne stratégie de mise à jour. Il ne suffit pourtant pas de simplement mettre à jour la plate-forme sous-jacente. Vous devez aussi prendre le temps de vous assurer que votre système adopte les nouveaux principes de la structure qui a changé pour qu’il puisse tirer le plein avantage des nouvelles fonctionnalités.

Catégorie Deux : les développeurs cherchant à se senti plus à l’aise

developer womanUne des compétences que vous devez acquérir pour être un excellent développeur de logiciels est la capacité de travailler avec du code écrit par quelqu’un d’autre. Quelqu’un peut venir et récrire un système à partir de zéro, mais seulement d’excellents développeurs peuvent vraiment faire un bon travail de maintenance du code de quelqu’un d’autre.

Beaucoup de développeurs n’aiment pas le faire et vous les entendrez souvent dire « Le code de base a trop de dette technique et doit être récrit ». C’est un peu comme dire que les fenêtres dans votre maison sont sales et donc le bâtiment doit être démoli et reconstruit.

Selon mon expérience, au moins 99 % du temps, quand on vous dit que quelque chose doit être récrit à partir de zéro, on vous dit juste que le développeur est trop paresseux pour se donner la peine de comprendre le code de quelqu’un d’autre.

Vous feriez mieux d’ignorer un tel conseil et vous trouver simplement de meilleurs développeurs. Concentrez-vous plutôt sur les trois autres catégories de dette.

La catégorie deux de dette est presque toujours de la dette fantôme.

Catégorie Trois : l’héritage du pragmatisme

ça sent mauvais...La réalité du développement logiciel de manière professionnelle consiste en ce qu’il n’y a jamais assez de temps pour faire un travail parfait. Tôt ou tard, vous devrez vous boucher le nez et implémenter quelque chose d’une façon bien moins qu’idéale afin de terminer dans les délais et le budget.

Comme toute dette raisonnable dans le monde réel, ceci n’est pas toxique. Souvent vous pouvez vous permettre d’accepter un compromis sur la qualité, mais savoir quand est une caractéristique que seuls possèdent les bons développeurs.

Voici la chose clé de la saine dette de catégorie Trois: le coût d’implémenter une fonctionnalité d’une façon sous-optimale est le coût de faire de ceci Deux fois ! Une fois pour terminer dans les délais et une fois à la ré-implémenter de façon plus durable.

Si vous échouez à rembourser la dette dans une période raisonnable, alors vous a fait l’équivalent de mettre votre carte de crédit dans le rouge. Et, tôt ou tard, vous finirez avec de la Catégorie dette numéro Quatre.

Catégorie Quatre : Impossible d’avancer

La Catégorie Quatre est le prêt hypothécaire à haut risque de la dette technique.

leg ironsAccumulez assez de dettes de Catégories Un ou Trois et vous constaterez qu’il devient presque impossible d’ajouter de nouvelles fonctionnalités à un système existant d’une façon opportune. Vous constaterez probablement aussi que vous avez beaucoup plus de bogues dans votre système qu’il est acceptable et vous dépenserez aussi davantage sur la maintenance opérationnel. Avant cette étape, vos utilisateurs auront probablement commencé à remarquer des erreurs, des failles de sécurité ou des problèmes de performance.

Ces choses sont le coût d’entretien de la dette qui ressemble aux intérêts sur vos achats à crédit et que vous devez encore trouver une façon de rembourser.

Évidemment, ceci est une situation que vous devriez vous efforcer d’éviter, mais elle est trop courante. C’est que les gens oublient de compter le coût de remboursement de la dette qu’ils ont accumulée au fil du temps. On se sent bien quand on ajoute des fonctionnalités, comme on se sent bien quand on va faire du shopping, mais, tout comme avec vos finances domestiques, la discipline est sa propre récompense à long terme. Vous pourrez vous permettre de dépenser plus de votre argent sur de nouvelles fonctionnalités au fil du temps si vous réglez vos dettes de façon raisonnable. Seulement, vous ne pourrez pas le faire immédiatement.

Si vous vous trouvez dans cette situation, il peut être tentant parfois de vous demander si cela vaut la peine de recommencer à partir de zéro, mais c’est une réaction extrême au problème, l’équivalent se déclarer en faillite personnelle. Mieux vaut de créer un plan structuré pour rembourser la dette sur une période de temps raisonnable.

Si méticuleusement géré, le résultat peut être une amélioration générale du système, qui devient moins cher à supporter et améliorer et des utilisateurs plus heureux.

Pour mieux comprendre la dette technique tant côté business que technique, je vous propose de suivre ce webinar en anglais. Steve McConnell y explique en détail les types différents de dette technique, quand les organisations devraient et ne devraient pas les contracter et les bonnes pratiques de management, suivi et remboursement de la dette. Vous gagnerez en perspicacité dans la façon d’utiliser la dette technique stratégiquement et aussi comment garder le personnel technique et business impliqué dans le processus.

une stratégie simple pour gérer la dette technique

A simple strategy for managing technical debt

http://madebymany.com/blog/a-simple-strategy-for-managing-technical-debt par James Higgs

Auparavant, j’ai essayé d’expliquer le concept de dette technique. Aujourd’hui, j’essayerai de suggérer une façon pratique de la suivre à la trace et de la traiter dans votre projet.

dettes techniquesComme avec une dette dans le monde réel, le truc avec la dette technique est de suivre vos dettes à la trace et de vous assurer que vous avez un plan pour les régler. Autoriser les dettes à croître sans réfléchir à ce que vous faites est une façon épouvantable de diriger vos finances personnelles comme votre projet de développement logiciel.

Tant que vous prenez des décisions informées et délibérées sur quand encourir de la dette et quand la rembourser, vous n’avez pas nécessairement besoin d’un plan pour éliminer totalement votre dette. Vous devriez plutôt aspirer à la garder à un niveau acceptable pour que vous puissiez ajouter de nouvelles fonctionnalités à votre produit relativement facilement et sans trop d’effets secondaires.

tenir un registre

Mon conseil numéro un avec la dette technique est de tenir un registre dans un format simple dans votre bibliothèque de code source et avec celui-ci. Un document « Markdown » est une façon simple et facilement compréhensible de faire ceci.

ajouter les nouvelles dettes

Assurez-vous que chaque développeur de l’équipe connaît et comprend ce registre. Chaque fois que vous ajoutez à la dette, ajoutez une ligne correspondante dans votre registre dans le même « commit » que le code en cause.

Parfois vous réalisez que vous ayez contracté une dette seulement après coup, peut-être parce qu’une bibliothèque que vous utilisez n’est pas aussi puissante que vous l’aviez pensé, ou parce que les besoins changent inopinément (ce que nous appelons ici ‘un changement explosif ‘). C’est OK, ces choses arrivent dans les projets logiciels. La chose importante est d’acquérir une bonne idée de la taille de la dette aussitôt que vous le pouvez et de vous assurer que vous la saisissez dans le registre.

retirer les dettes remboursées

Quand vous réglez à nouveau la dette, enlevez l’entrée correspondante du registre et replacez le registre dans la bibliothèque de code.

Faites une routine de conduire des revues régulières  du registre de dettes et de vous assurer que vous avez un plan actif pour adresser chaque ligne. Une fois par itération est probablement une fréquence raisonnable pour faire cette passe.

paiementPartagez le registre avec votre client et assurez-vous qu’il comprend la raison pour encourir toute nouvelle dette et la taille du remboursement probable. Cela signifie que vous devez les aider à comprendre la motivation d’une mise en œuvre sous-optimale, les effets secondaires qui vont probablement produire, aussi bien que le coût prévu pour perfectionner la solution mise en œuvre quand la dette sera réglée.

Vous le devez à vos clients pour les aider à comprendre l’impact de votre prise de décision collective sur un projet. Pas assez de personnes le comprennent. Tous les systèmes sont une collection de compromis et la dette technique est une des expressions de telles prises de décision. Ceci peut souvent être une conversation difficile si le concept de dette technique est nouveau pour votre client, mais votre honnêteté paiera sur long terme.

La chose la plus importante à comprendre pour des clients est qu’ils doivent avoir un budget pour le développement continu de leur projet. Trop de projets sortent et sont ensuite autorisés à se dégrader et dans des nombreux cas le client n’aura pas été mis au courant des conséquences d’une telle approche. Donc, ils peuvent s’attendre à ce que vous puissiez tout simplement reprendre là où vous vous étiez arrêtés, peu importe combien de temps a passé. Les aider à comprendre comment fonctionne le développement logiciel fait partie de votre travail si vous êtes technique.

« Grade Two debt: Developers making themselves feel more comfortable »

faire la somme des dépensesSi vous traitez avec de la dette de Catégorie 2, une dette de « confort », quand vos développeurs vous disent que vous devez récrire votre système, la meilleure chose à faire pour désamorcer les émotions inhérentes est de leur faire créer un registre de dettes pour vous. Chaque entrée dans le registre devrait être clairement compréhensible par des développeurs et des personnes non techniques également et elles devraient toutes être actionnables.

Demandez-leur d’évaluer l’effort impliqué dans la résolution de chaque ligne du registre dans un jeu de planification et comparez ce coût au coût de reconstruire en repartant de zéro. N’oubliez pas que si vous les laissez reconstruire le système, ils construiront un système qui inclut aussi une nouvelle dette car le système sans dette n’existe pas. Alors, factorisez aussi cela dans le coût de remboursement.

Il est presque certain que vous constaterez qu’il est plus efficace financièrement de modifier le système existant que de le reconstruire.

pour conclure

La dette technique judicieusement encourue et bien gérée peut faire partie d’une approche raisonnable du développement logiciel. Simplement, n’oubliez pas d’avoir un plan de remboursement de la dette avant que les gros bras récupérateurs de créances ne viennent vous voir avec leurs barres de fer et portent in intérêt tout particulier à vos genoux.