{"id":2162,"date":"2014-10-27T16:47:55","date_gmt":"2014-10-27T15:47:55","guid":{"rendered":"http:\/\/qualilogy.com\/fr\/?p=2162"},"modified":"2014-10-28T17:56:23","modified_gmt":"2014-10-28T16:56:23","slug":"application-legacy-dette-technique-roi-refactoring","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/application-legacy-dette-technique-roi-refactoring\/","title":{"rendered":"Application Legacy \u2013 Dette technique et ROI d&rsquo;un refactoring"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2163\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRefactoringROI.jpg\" alt=\"Application Legacy - Techncal Debt et le ROI d'un Refactoring\" width=\"261\" height=\"315\" srcset=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRefactoringROI.jpg 261w, http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/10\/LegacyTechDebtRefactoringROI-248x300.jpg 248w\" sizes=\"(max-width: 261px) 100vw, 261px\" \/><\/a>En mati\u00e8re de ROI, je ne me complique pas la vie : je pose l\u2019hypoth\u00e8se que nous allons r\u00e9duire les co\u00fbts de maintenance dans une proportion \u00e9gale \u00e0 la r\u00e9duction de la dette technique.<\/p>\n<p>C\u2019est une hypoth\u00e8se que l\u2019on peut trouver simpliste et donc discutable, mais notre ambition ne r\u00e9side pas dans une pr\u00e9cision absolue et exacte des chiffres que nous avan\u00e7ons \u2013 ce serait pr\u00e9tentieux et irr\u00e9aliste \u2013 sinon \u00e0 fournir au management des \u00e9l\u00e9ments qui facilitent sa prise de d\u00e9cision.<br \/>\nEt je pense que le management pr\u00e9f\u00e8re une hypoth\u00e8se de travail simple et claire, m\u00eame si moins pr\u00e9cise, plut\u00f4t qu\u2019une formule complexe qui ne sera pas forc\u00e9ment plus r\u00e9aliste. <!--more--><\/p>\n<p>Pour avoir effectu\u00e9 cet exercice de calcul et de pr\u00e9sentation de ROI dans mon ancienne vie au sein d\u2019\u00e9diteurs logiciels (d&rsquo;analyse de code et de qualit\u00e9 des applications), je peux vous faire une confidence :<\/p>\n<p style=\"text-align: center\"><strong><em>Le ROI est directement proportionnel \u00e0 la complexit\u00e9 de sa formule :<br \/>\nplus le calcul du ROI sera compliqu\u00e9, plus le retour sur investissement sera \u00e9lev\u00e9.<\/em><\/strong><\/p>\n<h2>Le ROI des \u00e9diteurs logiciels<\/h2>\n<p>Dans les faits, un vendeur de software tentera d\u2019\u00e9viter ce calcul s\u2019il le peut, mais c\u2019est tr\u00e8s variable selon les pays. C\u2019est un exercice quasiment incontournable aux EU, o\u00f9 le CIO ou tout autre d\u00e9cideur peut se faire virer du jour au lendemain, et donc il est absolument indispensable de pouvoir justifier tout achat logiciel afin d\u2019\u00e9viter toute cause de licenciement. Dans nos pays latins (je veux dire en France, en Espagne, en Italie, \u2026), la dimension financi\u00e8re ne rev\u00eat pas la m\u00eame importance lors d\u2019un achat logiciel, et le processus de d\u00e9cision sera globalement plus simple. Le CIO va v\u00e9rifier que :<\/p>\n<ul>\n<li>La valeur et les b\u00e9n\u00e9fices attendus du software justifient un prix consid\u00e9r\u00e9 comme raisonnable et non exhorbitant.<\/li>\n<li>Le co\u00fbt de mise en \u0153uvre et d\u2019exploitation sera acceptable.<\/li>\n<li>Il dispose d\u2019un budget pour cet investissement.<\/li>\n<\/ul>\n<p>Mais dans l\u2019hypoth\u00e8se o\u00f9 le CIO demande une estimation de ROI, vous pouvez \u00eatre certains que la formule de calcul sera compliqu\u00e9e. Pourquoi ?<br \/>\nParce que le logiciel que l\u2019on tente de vous vendre aura une formule \u00e9galement compliqu\u00e9e pour calculer la dette technique, avec pour seul objectif d\u2019\u00e9lever celle-ci de mani\u00e8re \u00e0 <a title=\"Dette technique \u2013 D\u00e9veloppeurs vs. marketeux\" href=\"http:\/\/qualilogy.com\/fr\/dette-technique-developpeurs-vs-marketeux\/\" target=\"_blank\">effrayer le CIO ou tout autre d\u00e9cideur<\/a>.<\/p>\n<p>Evidemment, plus la dette technique sera \u00e9lev\u00e9e, plus le retour sur investissement sera important.<br \/>\nCe qui am\u00e8ne d\u2019ailleurs \u00e0 une question int\u00e9ressante, et jamais abord\u00e9e \u00e0 ma connaissance : la dette technique imputable aux vendeurs de software.<\/p>\n<p>Combien de temps perdez-vous dans la gestion des bugs rencontr\u00e9s dans ces softwares, et le retard des projets bloqu\u00e9s ou frein\u00e9s par ces bugs ? Combien d\u00e9pensez-vous en upgrades obligatoires, pour ne pas dire forc\u00e9s ? Si vous installez chaque nouvelle version ou chaque patch, cela repr\u00e9sente un co\u00fbt d\u2019upgrade r\u00e9gulier. Mais si vous tentez d\u2019y \u00e9chapper en \u2018sautant\u2019 de temps en temps une version nouvelle, vous pouvez \u00eatre certain que le prochain upgrade que vous tenterez sera plus compliqu\u00e9, n\u00e9cessitant m\u00eame parfois de passer par une ou plusieurs versions interm\u00e9diaires, ce qui sera encore plus co\u00fbteux.<\/p>\n<p>Combien d\u00e9pensez vous en upgrade de votre environnement (hardware, OS, version de base de donn\u00e9es, etc.) ou parce la nouvelle version n\u2019est plus compatible avec telle ou telle version d\u2019Unix, de Windows, de JDK, etc. ? Quel est le co\u00fbt pour vous lorsque le vendeur d\u00e9cide de stopper la maintenance sur ce software ?<\/p>\n<p>Ce ne sont pas seulement les applications que vous g\u00e9rez qui viennent avec une dette technique, mais \u00e9galement le software dans lequel vous investissez. Est-ce que les vendeurs de software incorporent cette dette technique dans leur formule de ROI ?<\/p>\n<h2>Le ROI de notre refactoring<\/h2>\n<p>Mais revenons-en \u00e0 notre formule de calcul. Je souhaite que celle-ci reste simple et, dans le cas o\u00f9 je rencontrerais des objections, alors j\u2019ajouterai certains \u00e9l\u00e9ments dont je laisserai l\u2019appr\u00e9ciation aux d\u00e9cideurs. Je pr\u00e9f\u00e8re proc\u00e9der ainsi plut\u00f4t que d\u2019incorporer ces \u00e9l\u00e9ments dans une formule complexe, et qui ne sera pas forc\u00e9ment plus pr\u00e9cise car tout \u00e9cart dans l\u2019estimation de chacun de ces \u00e9l\u00e9ments se traduira par une d\u00e9viation dans l\u2019estimation finale du ROI.<\/p>\n<p>Notre dette technique totale est de 1 283 jours. Un effort de 291 jours pour <a title=\"Application Legacy \u2013 Refactoring avec le plugin SQALE (II)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-plugin-sqale-2\/\" target=\"_blank\">ramener cette dette technique \u00e0 un rating SQALE de niveau &lsquo;A&rsquo;<\/a> aura pour effet r\u00e9duire celle-ci \u00e0 992 jours, soit une diminution de cette dette technique de 22.7%.<\/p>\n<p>A raison de 18.5 jours par mois ou 225 jours par an par personne, et une \u00e9quipe de 5 personnes, la charge globale annuelle pour cette \u00e9quipe est de 225 jours x 5 personnes = 1 125 jours\/homme.<\/p>\n<p>Un effort de refactoring de 291 jours sur une ann\u00e9e repr\u00e9sente un co\u00fbt de 291 jours \/ 1 125 jours\/homme, soit 25.9% du co\u00fbt de cette \u00e9quipe sur 12 mois, et donc du co\u00fbt de maintenance annuelle, soit l\u00e9g\u00e8rement plus que notre gain de maintenabilit\u00e9 \u00e9gal \u00e0 22.7%.<\/p>\n<p>Disons que globalement, le retour sur notre investissement de refactoring se produit au bout d\u2019un petit peu plus d\u20191 an, sur la base de notre hypoth\u00e8se de r\u00e9duction des co\u00fbts de maintenance dans une proportion \u00e9quivalente \u00e0 la diminution de la dette technique.<\/p>\n<p>Evidemment, cette hypoth\u00e8se reste relative: si je divise par deux la dette technique ou si je r\u00e9duis celle-ci \u00e0 n\u00e9ant, je ne vais pas diviser par deux le budget de maintenance ou r\u00e9duire celui-ci \u00e0 z\u00e9ro. Mais elle reste cr\u00e9dible pour les proportions (moins de 25%) que nous avons calcul\u00e9es.<br \/>\nEt m\u00eame si ce calcul n\u2019est pas forc\u00e9ment tr\u00e8s exact, ce dont a besoin un CIO est un ordre de grandeur (6 mois, 10 mois, 1 an, 18 mois, etc.). Si le chiffre d\u00e9passe les limites du raisonnable, un projet de refactoring ne sera pas examin\u00e9 plus avant. S\u2019il est acceptable, vous pouvez lui vendre les b\u00e9n\u00e9fices qu\u2019il pourra en obtenir.<\/p>\n<h2>Vendre le ROI<\/h2>\n<p>Lorsque je discute avec des d\u00e9veloppeurs sur des notions telle que la dette technique et comment l\u2019utiliser afin de convaincre le management qu\u2019un refactoring est n\u00e9cessaire, la plupart montre un d\u00e9couragement et une d\u00e9motivation extr\u00eame.<\/p>\n<p>\u00ab Mon boss n\u2019est pas int\u00e9ress\u00e9 quand je lui parle de corriger les d\u00e9fauts existants, l\u2019impact sur le moral de l\u2019\u00e9quipe est terrible. \u00bb<\/p>\n<p>\u00ab Le management raisonne uniquement \u00e0 court terme : si cela prend une heure pour impl\u00e9menter une nouvelle fonctionnalit\u00e9, c\u2019est un b\u00e9n\u00e9fice imm\u00e9diat. Si tu dis que cela va prendre une journ\u00e9e parce que tu veux en profiter pour am\u00e9liorer le code, il commence \u00e0 te regarder de mani\u00e8re suspicieuse. Comme si j\u2019\u00e9tais une diva qui veut se faire plaisir. \u00bb<\/p>\n<p>Les techniciens, et les d\u00e9veloppeurs d\u2019une mani\u00e8re g\u00e9n\u00e9rale, ont du mal \u00e0 trouver une justification qui leur permette de vendre l\u2019id\u00e9e d\u2019<a title=\"Application Legacy \u2013 Refactoring avec le plugin SQALE (II)\" href=\"http:\/\/qualilogy.com\/fr\/application-legacy-refactoring-plugin-sqale-2\/\" target=\"_blank\">un refactoring ponctuel ou au fil de l\u2019eau<\/a>, parce que la qualit\u00e9 logicielle n\u2019est pas un but en soi pour des managers.<\/p>\n<p>Imaginons que vous restaurez une vieille voiture pour quelqu&rsquo;un qui esp\u00e8re la revendre un bon prix, une fois vos r\u00e9parations effectu\u00e9es. Si vous proposez de mettre de nouvelles jantes plus ch\u00e8res et des nouveaux pneux plus larges, bien s\u00fbr qu&rsquo;il va croire que vous voulez vous faire plaisir en customisant son v\u00e9hicule. Sauf si vous lui d\u00e9montrez qu&rsquo;il peut en tirer un b\u00e9n\u00e9fice.<\/p>\n<p>L&rsquo;objectif principal du management : la business value d\u2019un investissement. Comment leur vendre le ROI d\u2019un projet de refactoring ? R\u00e9ponse : par une \u00e9valuation correcte des impacts sur le business.<\/p>\n<p>Notre plan : supprimer les d\u00e9fauts critiques (et Blockers), ramener la dette technique \u00e0 un niveau acceptable et veiller \u00e0 ce qu\u2019elle n\u2019augmente pas.<\/p>\n<p>Ce plan d\u2019actions porte quasi exclusivement sur une r\u00e9duction des d\u00e9fauts qui impactent d\u2019abord la Reliability, donc la robustesse de l\u2019application pour une meilleure satisfaction des utilisateurs, et non pas des d\u00e9fauts en mati\u00e8re de Maintainability dont on pourrait esp\u00e9rer une r\u00e9duction des co\u00fbts de maintenance. Cependant, moins de risques de bugs signifie \u00e9galement moins de co\u00fbts de corrections de bugs, et un gain encore plus important en maintenance. On sait \u00e9galement que plus un d\u00e9faut est constat\u00e9 tard lors du cycle de d\u00e9veloppement applicatif (en production par exemple), plus il co\u00fbtera cher.<\/p>\n<p>S\u2019il vous en co\u00fbte simplement 2 heures pour corriger un d\u00e9faut, et que vous \u00e9conomisez ainsi 2 ou 3 jours de d\u00e9tection et de correction d\u2019un bug, non seulement votre ROI devient beaucoup plus int\u00e9ressant d\u2019un point de vue financier, mais d\u2019un point de vue qualitatif, vous am\u00e9liorez grandement la satisfaction des utilisateurs et l\u2019image de votre d\u00e9partement. Et cela n\u2019a pas de prix.<\/p>\n<p>Les autres points que l\u2019on peut mettre en avant, mais sans forc\u00e9ment les chiffrer afin de ne pas tomber dans le travers d\u2019une formule compliqu\u00e9e :<\/p>\n<ul>\n<li>Une QA plus efficace : chaque fois qu\u2019un bug est constat\u00e9 en QA, le code revient chez le d\u00e9veloppeur qui doit le corriger, puis retourne en QA pour de nouveaux tests. Moins vous avez de d\u00e9fauts, moins vous avez d\u2019allers-retours, plus la phase de tests sera rapide. Donc co\u00fbts moindres, respect des budgets et des plannings. Et un planning tenu signifie un utilisateur heureux !<\/li>\n<li>Business value : un bug en production peut avoir pour cons\u00e9quence une moindre performance, voire l\u2019interruption du syst\u00e8me, donc des op\u00e9rations plus longues et une charge de travail plus importante pour les utilisateurs, donc des utilisateurs \u2013 voire des clients \u2013 m\u00e9contents. Tout cela peut impacter les ventes, ainsi bien s\u00fbr que l\u2019efficacit\u00e9 des d\u00e9partements marketing, commerciaux, logistiques, etc.<\/li>\n<li>Business value : moins vous d\u00e9pensez en maintenance, plus vous pouvez investir dans de nouvelles applications et supporter de nouveaux business et la croissance de l\u2019entreprise sur de nouveaux march\u00e9s.<\/li>\n<li>Une meilleure productivit\u00e9 des d\u00e9veloppeurs : certaines violations aux bonnes pratiques de programmation impactent les temps de d\u00e9veloppement. Par exemple, un code dupliqu\u00e9 signifie une moindre r\u00e9utilisabilit\u00e9, donc plus de temps pass\u00e9 \u00e0 d\u00e9velopper du code \u2026 qui existe d\u00e9j\u00e0.<\/li>\n<li>Meilleur contr\u00f4le des outsourcers : si vous faites un audit tous les 6 mois, votre outsourcer ne se souciera de la qualit\u00e9 de vos applications et de la d\u00e9rive de la dette technique qu\u2019une fois tous les 6 mois. Lorsqu\u2019il sera trop tard. Si vous mettez en place un outil comme SonarQube avec le plugin SQALE, vous pouvez effectuer ces contr\u00f4les automatiquement chaque semaine. C\u2019est ce qu\u2019on appelle l\u2019effet radar : s\u2019il sait qu\u2019il peut \u00eatre \u2018flash\u00e9\u2019 \u00e0 tout instant, votre outsourcer sera beaucoup plus prudent.<\/li>\n<\/ul>\n<p>Ce sont diff\u00e9rents points qui sont compr\u00e9hensibles intuitivement par le management, pour la valeur que cela repr\u00e9sente pour l\u2019entreprise, le business, et le d\u00e9partement IT. Apr\u00e8s, si l\u2019on veut r\u00e9ellement constituer un ROI pr\u00e9cis qui prenne en compte ces diff\u00e9rents b\u00e9n\u00e9fices, il faut alors soit effectuer des hypoth\u00e8ses (nombre de bugs trouv\u00e9s en production, en QA, etc.), soit se baser sur des chiffres fournis par des instituts de recherche. Le r\u00e9sultat ne sera pas forc\u00e9ment plus exact ou pr\u00e9cis que notre simple estimation bas\u00e9e sur la r\u00e9duction de la dette technique.<\/p>\n<p>Nous reparlerons probablement de ROI lorsque nous \u00e9tudierons notre dernier sc\u00e9nario : le r\u00e9-engineering de notre application Legacy. Prochainement.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En mati\u00e8re de ROI, je ne me complique pas la vie : je pose l\u2019hypoth\u00e8se que nous allons r\u00e9duire les co\u00fbts de maintenance dans une proportion \u00e9gale \u00e0 la r\u00e9duction de la dette technique. C\u2019est une hypoth\u00e8se que l\u2019on peut trouver simpliste et donc discutable, mais notre ambition ne r\u00e9side pas dans une pr\u00e9cision absolue [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-2162","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2162"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=2162"}],"version-history":[{"count":23,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2162\/revisions"}],"predecessor-version":[{"id":2186,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/2162\/revisions\/2186"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=2162"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=2162"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=2162"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}