Tag Archives: dette technique

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

12 Juil

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.

April 5 – Webinar – Scrum Teams Don’t Think About Architecture

2 Avr

Dispelling this Myth with ScrumPulse

Upcoming Webcasts

Many groups developing software products wonder how Scrum Teams build products that don’t devolve into an architectural mess. How do we prevent the re-work that comes from teams hacking bits together all the time? How do I keep multiple teams from building the same thing in different areas that I now have to maintain? How do teams keep their architecture structurally sound when the systems are continuously evolving? How do we plan for scaling and the cloud if we don’t design our architecture up front?

Join the panel of Professional Scrum Trainers (Peter Gotz, Gary Pedretti, Fredrik Wendt and Rich Visotcky) as they discuss their real world experience and advice for building an architecture that evolves over time with purpose in its design and value creation at its core.

They’ll share patterns and tips for making your current architecture transparent with minimal investment so that Development Teams can keep the quality of their work high and stay focused on delivering valuable products to consumers.

Register

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

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 !

28 Fév

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 » !

13 Déc

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

10 Mar

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

5 Mai

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

29 Sep

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 —

August 14 – Webinar – Dealing with Technical Debt: Avoiding Technical Bankruptcy

7 Août

A free monthly webcast by Scrum.org Professional Scrum Trainers addressing common challenges faced by the software profession.

Scrum and Agile Webcasts

Scrum and Agile Webcasts

with Mark Noneman on August 14, 2014 10am-11am EST 16:00 CET/FRANCE

The phrase “technical debt” has become a commonly used phrase in software development.

technical debtTechnical debit is analogous to financial debt; build up too much and you’ll start paying more in “interest” and “principle” than you can invest in future value. This webinar will discuss what technical debt is, what causes it, and how to deal with it. Both management and engineering techniques in an agile development environment will be reviewed.

These sessions are broadcast live, completely free, and available to anyone around the world – though space in each session is limited!

SAVE MY SPOT

23-24 Mai – Paris – Agile France 2013

17 Mai

conf agile france 2013Agile France aura lieu les jeudi 23 et vendredi 24 mai 2013 au Chalet de la Porte Jaune

Le but : permettre aux praticiens avancés de se réunir et d’échanger pour apprendre en dehors des sentiers battus.

Consultez le programme.

Une petite intro vidéo de Olivier Soudieux, notre ami explorateur Agile !

Encore une fois, Agile France va marquer les mémoires. Au vu de la sélection, 2013 sera un grand cru ! N’oubliez pas de réserver vos places.

Encore une fois, Agile France va marquer les mémoires. Au vu de la sélection, 2013 sera un grand cru ! N’oubliez pas de réserver vos places.

Un avant-goût de ces sessions!!!

Jeudi 23 Mai

Un produit qui déchire, une équipe qui déchire… un leader qui déchire

David Alia

David Alia

David Alia (@davidalia)
Découvrez les principes qui permettent à un leader de créer pour son équipe un environnement propice à l’innovation, une culture d’amélioration continue et de confiance mutuelle. Comment l’aider à se mettre dans une succession permanente d’équilibres instables entre challenge et stabilité, entre enjeux et plaisir, à conserver un sens aigu de l’initiative, une motivation à toujours faire mieux, individuellement et collectivement ?

Le Respect en Action

Jonathan Scher (@jonathan_scher) et Cyrille Deruel (@CyrilleDeruel)
Vous connaissez ces équipes dans une spirale descendante : les seules phrases qui sortent viennent du désespoir. Encore un bug, ça ne marche toujours pas, je n’arrive pas…

Travaillant comme consultants, ce cas nous est arrivé plusieurs fois. Nous avons maintenant une méthode : nous remettons en place les bases du respect. En moins de 6 semaines, l’équipe est à nouveau pleine d’espoir, productive. Nous vous présenterons notre vision du modèle des trois CO – communication, considération, et coopération, ainsi que notre démarche inspirée de celle de Kotter pour sa mise en application.

Indiana Jones et le temple du Legacy Code

Mathieu Gandin (@octomga)
Selon The Economics Of Software Maintenance In The 21 Century, nous passons 80% de notre temps à maintenir du code existant et pénible à modifier. Dans cette situation nous devenons des archéologues du code, tandis que les contraintes de temps se font plus fortes. On parle alors de code Legacy.

A l’issue de cette session vous repartirez avec :

Une longue séance de livecoding pour présenter des techniques pour tester et remanier du code en profondeur
Une introduction à une démarche pour avoir une vue d’ensemble de votre gros code legacy
Une présentation de la matrice de gestion du temps de Covey pour vous organiser sur le long terme dans la reprise de votre code legacy

Clean Code Game

cleanMichel Domenjoud et Mathieu Gandin (@octomga)
Maintenir une base de code propre et bien testé est un facteur clé de succès de la réalisation d’un produit. Mais avant d’en arriver là, il convient, en tant que développeur, d’adopter une certaine discipline en terme de refactoring de code.

Pendant cet atelier de 3h nous aurons l’occasion de vous faire coder et reprendre du code existant pour en faire du beau code en suivant des principes énoncés par Robert Martin dans le livre Clean Code. Et vous verrez que plus votre code sera propre, plus vous serez productif.

Vendredi 24 mai

Communautés de pratique en pratique

Cyrille Deruel (@CyrilleDeruel)
Vous rêvez d’avoir des réunions où les développeurs échangent leurs techniques, présentent leurs dernières trouvailles, les derniers frameworks utilisés, où les testeurs partagent leurs douleurs et leurs solutions, où des personnes échangent autour de différentes problématiques ?

Ne cherchez plus : Créez des communautés de pratique.

Découvrez à travers cette session comment créer des communautés de pratique auto-organisées, quels outils j’utilise pour garantir l’auto-organisation et surtout quelles règles de communication j’utilise.

Les paradoxes du leadership

Marc Cherfi (@reporter4change) et Thomas Lissajoux
CB103557Vous êtes un manager, un coach ou un leader. En tout cas vous êtes un agent de changement et vous faites de votre mieux. Pourtant, parfois, la résistance et les frictions semblent inévitables et les résultats sont au mieux passables, quand la situation ne dégénère pas ou se verrouille.

Nous analyserons les forces en jeu et présenterons les leçons que nous en avons tiré, en essayant de proposer des pistes pour débloquer ces situations.

A l’issue de cette session, vous aurez :

  • découvert des exemples concrets de situations où rien ne semble marcher,
  • appris à identifier ce genre de situations et de comportements paradoxaux,
  • compris les forces en jeu pour prendre du recul,
  • des options à votre disposition pour essayer de les débloquer.

Des métaphores qui nous transforment

Microsoft Project

Partenaire de DantotsuPM

Christophe Thibaut (@ToF_)
Dans notre domaine il semble qu’il y ait un process pour tout, et même l’agile, en dépit des proclamations, est l’occasion d’un retour sempiternel au process, aux outils, aux recettes.

Dans cette session j’aimerais vous inviter à quitter le règne conceptuel afin de découvrir le surprenant pouvoir des métaphores. Plus qu’une simple figure de discours, la métaphore structure notre pensée et nos actions, elle définit notre réalité. En (re-)découvrant dans leur portée et leur profondeur les métaphores qui nous gouvernent, pouvons nous transformer nos projets ?

Tester autrement : Le Guide du Testeur Intergalactique

Rémy-Christophe Schermesser (@El_Picador)
Vous connaissez déjà TDD, votre couverture de code frise les 80 %, jUnit n’a plus de secret pour vous ? Mais vous sentez que vous pourriez faire plus de vos tests, que les outils que vous utilisez ont des limites. Ou alors vous en avez marre du train train assertEquals ?

Pas de panique ! Nous allons voir ensemble comment faire des tests unitaires autrement. Nous traiterons entre autres :

  • Le Mutation Testing
  • Le BDD, Behaviour Driven Development
  • Le Property Testing.

Les Quatre Catégories De Dette Technique

28 Mar

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.

%d blogueurs aiment cette page :