« DetteTechnique » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (5 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Category: Martin Fowler]] | [[Category: Martin Fowler]] | ||
[[Category: Portail Equipe de développement]] | [[Category: Portail Equipe de développement]] | ||
| Ligne 5 : | Ligne 4 : | ||
Auteur : Martin Fowler ([https://twitter.com/martinfowler @martinfowler])<br /> | Auteur : Martin Fowler ([https://twitter.com/martinfowler @martinfowler])<br /> | ||
Source : [https://martinfowler.com/bliki/TechnicalDebt.html TechnicalDebt]<br /> | Source : [https://martinfowler.com/bliki/TechnicalDebt.html TechnicalDebt]<br /> | ||
Date : 21/05/2019<br /> | Date : 01/10/2003 - 21/05/2019<br /> | ||
---- | ---- | ||
Traducteur : Fabrice Aimetti<br /> | Traducteur : Fabrice Aimetti<br /> | ||
| Ligne 28 : | Ligne 27 : | ||
La métaphore de la dette est parfois utilisée pour justifier le fait de ne pas tenir compte de la qualité interne. L'argument est qu'il faut du temps et des efforts pour empêcher l'accumulation de la dette. Si de nouvelles fonctionnalités sont nécessaires de toute urgence, il est peut-être préférable d'assumer la dette, en acceptant que cette dette doive être gérée ultérieurement.<br/> | La métaphore de la dette est parfois utilisée pour justifier le fait de ne pas tenir compte de la qualité interne. L'argument est qu'il faut du temps et des efforts pour empêcher l'accumulation de la dette. Si de nouvelles fonctionnalités sont nécessaires de toute urgence, il est peut-être préférable d'assumer la dette, en acceptant que cette dette doive être gérée ultérieurement.<br/> | ||
<br/> | <br/> | ||
Le danger ici est que la plupart du temps, cette analyse n'est pas bien faite. Le code mal conçu a un impact rapide, ralentissant le développement des nouvelles fonctionnalités qui sont demandées rapidement. Les équipes qui font cela finissent par dépasser la limite de leurs cartes de crédit, mais livrent toujours plus tard qu'elles ne l'auraient fait si elles avaient fait l'effort d'améliorer la qualité interne. Ici, la métaphore conduit souvent les gens à s'égarer, car la dynamique ne correspond pas vraiment à celle des prêts financiers. S'endetter pour accélérer la livraison ne fonctionne que si l'on reste en dessous de la limite de rentabilité de [https://martinfowler.com/bliki/DesignStaminaHypothesis.html l'hypothèse de robustesse de la conception (en)], et les équipes atteignent cette limite en quelques semaines plutôt qu'en quelques mois.<br/> | Le danger ici est que la plupart du temps, cette analyse n'est pas bien faite. Le code mal conçu a un impact rapide, ralentissant le développement des nouvelles fonctionnalités qui sont demandées rapidement. Les équipes qui font cela finissent par dépasser la limite de leurs cartes de crédit, mais livrent toujours plus tard qu'elles ne l'auraient fait si elles avaient fait l'effort d'améliorer la qualité interne. Ici, la métaphore conduit souvent les gens à s'égarer, car la dynamique ne correspond pas vraiment à celle des prêts financiers. S'endetter pour accélérer la livraison ne fonctionne que si l'on reste en dessous de la limite de rentabilité de [https://martinfowler.com/bliki/DesignStaminaHypothesis.html l'hypothèse de robustesse de la conception (en)]<ref>DesignStaminaHypothesis</ref>, et les équipes atteignent cette limite en quelques semaines plutôt qu'en quelques mois.<br/> | ||
<br/> | <br/> | ||
Il y a régulièrement des débats pour savoir si les différents types de code mal conçu doivent être considérés comme de la dette ou non. J'ai trouvé utile de réfléchir à la question de savoir si la dette est acquise délibérément et si elle est prudente ou imprudente - ce qui m'a conduit au [[Quadrant de la Dette Technique (fr)]].<br/> | Il y a régulièrement des débats pour savoir si les différents types de code mal conçu doivent être considérés comme de la dette ou non. J'ai trouvé utile de réfléchir à la question de savoir si la dette est acquise délibérément et si elle est prudente ou imprudente - ce qui m'a conduit au [[Quadrant de la Dette Technique|Quadrant de la Dette Technique (fr)]].<br/> | ||
<br/> | <br/> | ||
==Lectures complémentaires== | |||
* Pour autant que je sache, Ward a introduit ce concept pour la première fois dans un retour d'expérience lors de [http://c2.com/doc/oopsla92.html OOPSLA 1992]. Il a également été discuté sur le [http://www.c2.com/cgi/wiki?ComplexityAsDebt wiki]. | |||
* Ward Cunningham a fait une [http://www.youtube.com/watch?v=pqeJFYwnkjE conférence vidéo] où il parle de cette métaphore qu'il a créée. | |||
* Dave Nicolette développe le point de vue de Ward sur la dette technique avec une [http://neopragma.com/index.php/2019/03/30/technical-debt-the-man-the-metaphor-the-message/ belle étude de cas] de ce que j'appelle [[Quadrant de la Dette Technique|la dette intentionnelle prudente (fr)]] | |||
* Quelques lecteurs ont communiqué des noms similaires. David Panariti qualifie la programmation crade de '''programmation déficiente'''. Il semble qu'il ait commencé à l'utiliser il y a quelques années, lorsqu'elle s'intégrait à la politique gouvernementale ; je suppose que c'est à nouveau à l'ordre du jour maintenant. | |||
* Scott Wood a suggéré que "'''l'inflation technique''' pourrait être considérée comme le retard pris lorsque le niveau actuel de la technologie dépasse celui des fondations de votre produit au point qu'il commence à perdre sa compatibilité avec l'industrie du logiciel. Par exemple, le retard pris dans les versions d'un langage au point où votre code n'est plus compatible avec les compilateurs du marché". | |||
* [http://www.construx.com/10x_Software_Development/Technical_Debt/ Steve McConnell] a souligné plusieurs bons points de la métaphore, en particulier la façon dont le fait de maintenir votre dette non intentionnelle à un faible niveau vous donne plus de latitude pour vous endetter intentionnellement quand il est utile de le faire. J'aime aussi son concept de paiements minimums (qui sont très élevés pour régler les problèmes liés aux systèmes embarqués par opposition aux sites web). | |||
* Aaron Erickson parle du [http://www.informit.com/articles/article.aspx?p=1401640 mode de financement Enron]. | |||
* [http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt Henrik Kniberg affirme] que c'est la vieille dette technique qui pose le plus de problèmes et qu'il est judicieux de plafonner la dette qualitative pour se permettre de la gérer. | |||
* Erik Dietrich parle du [http://www.daedtech.com/human-cost-tech-debt/ coût humain de la dette technique] : les luttes intestines au sein des équipes, les compétences atrophiées et l'épuisement. | |||
==Notes== | ==Notes== | ||
<references /> | <references /> | ||
