En tant qu’êtres humains, nous sommes confrontés à l’incertitude et à la complexité.
Pour nous donner l’illusion de contrôle dont nous rêvons, nous établissons des règles empiriques, telles que :
Dépensez 10 % en dette technique
Mettez de côté 20 % pour l’innovation
Prévoyez 25 % pour la correction des bogues
Ces directives sont faciles à comprendre et à communiquer. Mais ce n’est pas la vraie raison pour laquelle les gens de réfèrent à ces pourcentages réconfortants.
La raison ultime de ces heuristiques est qu’elles sont facilement défendables et nous aident à nous protéger contre les réactions négatives potentielles.
« Innovons-nous assez ? » devient « Nous dépensons 20 % dans l’innovation. »
« Consacrons-nous suffisamment de temps pour s’attaquer aux problèmes existants ? » devient « Nous avons alloué 25 % à la correction des bugs. »
« Travaillons-nous à maîtriser notre dette technique ? » devient « Nous consacrons 10 % de notre temps à réparer la dette technique. »
Les règles empiriques sont claires et nettes, pratiques et donnent l’impression que nous savons ce que nous faisons.
Mais ne nous leurrons pas. Facile à comprendre n’est pas synonyme d’important ni de passer notre temps sur les bonnes choses.
Habituellement, lorsque nous utilisons des heuristiques simples comme celles-ci, nous essayons de faire abstraction de notre ignorance en l’enveloppant dans une illusion de clarté et une couche de déni plausible.
Si vous considérez de tels pourcentages comme des réponses à vos questions, alors vous devriez vous demander : Qu’est-ce que nous cachons potentiellement sous le tapis en simplifiant à l’excès la réalité de cette manière ?
Ne confondez pas simplicité avec vérité.
L’esprit aime les choses qui sont faciles à comprendre, mais ce n’est pas parce qu’elles pénètrent doucement dans notre cerveau qu’elles sont vraies.
La réalité est généralement beaucoup plus cahoteuse que ce que nous sommes capables de comprendre.
partagez ce billet avec vos amis, collègues et relations professionnelles
Manager la dette technique de votre projet et/ou produit est nécessaire et même vital, mais vous ne pouvez pas tout mettre en pause juste pour la rembourser.
Manager la dette technique, c’est comme entretenir une maison dans laquelle vous vivez : C’est nécessaire, mais vous ne pouvez pas tout mettre en pause juste pour faire des réparations. Dans cet article, nous aborderons des approches pratiques pour traiter la dette technique tout en garantissant que le développement de produits continue à toute vitesse.
Chaque ligne de code est livrée avec un choix : Aller vite ou la construire correctement. La plupart des équipes choisissent la vitesse, et pour une bonne raison : Les opportunités business n’attendent personne. La dette technique s’accumule grâce à ces décisions précipitées, ces moments « on y reviendra plus tard » qui vous ont aidé à respecter une échéance critique ou à saisir une opportunité de marché. Mais à l’instar de son homologue financier, la dette technique s’accumule. Chaque correctif rapide et solution de contournement ajoute du poids à votre base de code jusqu’à ce qu’un jour, votre équipe se retrouve à pédaler dans la mélasse alors qu’elle avait l’habitude de sprinter.
Le véritable art n’est pas d’éviter la dette technique, mais de la gérer de manière stratégique.
Les meilleures équipes produit ont appris à trouver cet équilibre, à maintenir leur vitesse tout en empêchant la dette technique d’atteindre une masse critique. Voyons comment maîtriser cet exercice d’équilibre.
Identifiez et priorisez la dette technique
Toutes les dettes techniques ne sont pas égales. Comme pour la dette financière, il y a les bonnes dettes (pensez aux prêts immobiliers qui construisent votre patrimoine) et les mauvaises dettes (comme les cartes de crédit à taux d’intérêt élevé qui échappent à tout contrôle). L’essentiel est de savoir laquelle est laquelle.
Travaillez avec votre équipe d’ingénierie pour classer votre dette technique en trois catégories :
#1 – Blocages critiques
Ce système d’authentification tient ensemble par des bouts de ficelle.
La base de données atteint 90 % de sa capacité maximale toutes les deux semaines.
Une API (application programming interface ou « interface de programmation d’application ») tierce pourrait disparaître d’un jour à l’autre.
#2 – Des inquiétudes croissantes
Testez les lacunes de couverture dans les fonctionnalités de base.
Ce monolithe qui devient de plus en plus difficile à mettre à jour.
Les problèmes de performances qui n’affectent que les utilisateurs expérimentés.
#3 – Des correctifs intéressants
Une documentation obsolète.
De la duplication mineure de code.
Le framework d’interface utilisateur qui est juste un peu en retard sur la dernière version.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
Concentrez votre énergie sur l’endroit où le retour sur investissement est le plus élevé.
Une base de code désordonnée qui fournit toujours de la valeur de manière fiable pourrait être moins urgente à revoir qu’un système d’apparence propre qui n’est qu’à un client majeur de s’effondrer.
Équilibrez la dette avec le développement de fonctionnalités.
L’éternelle lutte dans le développement de produits n’est pas de savoir s’il faut s’attaquer à la dette technique, mais quel effort lui consacrer. Dans notre exemple précédent d’entretien d’une maison dans laquelle vous vivez, vous ne pouvez pas arrêter de vivre dans la maison pour faire des réparations, mais vous ne pouvez pas non plus ignorer les signes avant-coureurs pour toujours. Le moment idéal ? De nombreuses équipes performantes le trouvent dans la « règle des 80/20 » :
Consacrez 20 % de chaque sprint à la maintenance du système tout en conservant votre moteur principal – le développement de fonctionnalités – à 80 % de sa puissance.
Il ne s’agit pas simplement de choisir un nombre arbitraire. Il s’agit de créer un rythme durable où la gestion de la dette technique devient aussi naturelle que votre stand-up quotidien. Lorsque vous intégrez la réduction de la dette dans votre flux de travail habituel plutôt que de la traiter comme un monstre distinct à combattre, vous maintenez l’élan tout en gardant votre base de code saine.
Communiquez sur la valeur commerciale de la gestion de la dette technique.
La gestion de la dette technique, c’est comme maintenir votre crédit auprès de vos parties prenantes : Vous devez parler leur langue pour obtenir leur adhésion. Alors que votre équipe d’ingénieurs s’embarrasse de code spaghetti et de dépendances vieillissantes, vos leaders se concentrent sur une chose : L’impact sur l’entreprise. La clé ? Transformez la dette technique d’un problème d’ingénierie en un récit d’entreprise.
Peignez le tableau en des termes qu’ils ne peuvent ignorer :
Ce retard de trois mois dans les fonctionnalités ? Il ne s’agissait pas seulement d’un code complexe, mais d’une perte de revenus potentiels de 200 000€.
La récente interruption de production n’a pas seulement frustré l’équipe d’ingénierie, elle vous a coûté 50 clients premium.
La capacité de mises à jour rapides de fonctionnalités de votre concurrent ne concerne pas seulement la taille de l’équipe, mais aussi une base de code plus propre et plus adaptable.
Lorsque vous formulez la dette technique en termes d’opportunités de marché manquées, de désabonnement de clients et d’avantage concurrentiel, ces sprints de re-factorisation ne ressemblent soudainement plus à de l’indulgence d’ingénierie. Ils deviennent des investissements stratégiques. Votre rôle est de faire le lien entre ces points, en montrant comment la dette technique d’aujourd’hui devient le handicap business de demain.
Créez une culture d’amélioration continue.
La santé du code, comme les bonnes habitudes, se construit quotidiennement. Il ne s’agit pas tant de sprints de nettoyage héroïques que de petits choix que votre équipe fait chaque jour : Le test unitaire supplémentaire écrit, la refonte rapide lors de la création d’une fonctionnalité, la révision de code réfléchie qui permet de détecter un futur casse-tête.
Créez un environnement où la qualité n’est pas seulement prêchée, mais célébrée.
Faites en sorte qu’il soit facile de faire ce qu’il faut.
Contrôles automatisés de la qualité du code qui détectent les problèmes à un stade précoce.
Modèles pour du code propre et cohérent.
Documentation claire et réellement tenue à jour.
Directives de révision de code qui mettent l’accent sur la maintenabilité.
Célébrez les victoires invisibles.
Citez l’ingénieur qui a nettoyé en ajoutant des fonctionnalités.
Partagez des indicateurs sur la réduction des taux de bogues et l’accélération des déploiements.
Soulignez comment un code propre a permis une réponse rapide au besoin du business.
Documentez le temps économisé grâce aux efforts de refactorisation précédents.
Pensez-y comme à une cuisine professionnelle : Les meilleurs chefs nettoient pendant qu’ils cuisinent. Ils n’attendent pas que toute la vaisselle s’empile, car ils savent qu’une cuisine propre signifie une sortie plus rapide, meilleure et plus fiable. Votre base de code mérite le même respect.
Établissez une stratégie de dette technique à long terme.
Considérez la gestion de la dette technique comme un jardin, pas comme le nettoyage du garage. Vous n’attendez pas que les mauvaises herbes prennent le dessus sur tout. Vous vous en occupez régulièrement, en l’intégrant à votre rythme quotidien plutôt qu’à une refonte saisonnière massive.
Le succès réside dans la systématisation et la mesure de la gestion de la dette.
Mettez en place des « moniteurs de santé » qui intéressent votre équipe :
Combien de temps faut-il pour intégrer un nouveau développeur ?
Quel est votre ratio entre les travaux prévus et les travaux d’urgence ?
En combien de temps pouvez-vous livrer un correctif critique ?
À quelle fréquence les mêmes zones de code se brisent-elles ?
Créez des rituels qui restent.
Examens mensuels des radars techniques avec vos responsables techniques.
« Fix it Fridays » où les équipes s’attaquent à l’endettement dans des domaines critiques.
Présentations trimestrielles sur la santé technologique aux parties prenantes
Métriques de qualité du code dans les revues de sprint.
L’objectif n’est pas la perfection, c’est le progrès durable. Lorsque la gestion des dettes devient aussi routinière que vos réunions quotidiennes, vous avez craqué le code. Votre futur moi (et votre équipe) vous remercieront lorsqu’une nouvelle opportunité de marché urgente ne sera pas entravée par des limitations techniques.
La voie à suivre.
Considérez la dette technique comme le score de crédit d’un produit : Tout le monde en a un, mais les équipes qui réussissent savent comment le maintenir au bon niveau. Il ne s’agit pas d’avoir zéro dette ; Il s’agit de faire des choix stratégiques qui maintiennent l’agilité de votre produit et la motivation de votre équipe.
La sauce secrète ? Une approche en trois volets.
Rendez la dette visible.
Suivez-la comme vous suivez les fonctionnalités.
Mesurer son impact sur la rapidité de livraison.
Célébrez lorsque vous remboursez de la dette.
Choisissez vos batailles.
Corrigez ce qui fait le plus mal.
Attaquez-vous à la dette qui bloque l’innovation.
Fusionnez les améliorations dans le travail sur les fonctionnalités.
Adoptez des habitudes saines.
Nettoyez pendant que vous codez.
Examinez rétrospectivement l’impact de la dette.
Partagez les victoires et les leçons apprises.
N’oubliez pas : L’excellence technique n’est pas une question de perfection, mais de progrès. Les meilleurs produits ne sont pas ceux qui n’ont aucune dette technique ; Ce sont ceux où les équipes choisissent consciemment quelle dette contracter et laquelle rembourser.
Tout comme un investisseur intelligent équilibre croissance et stabilité, les équipes de produits intelligentes équilibrent vitesse et durabilité. Votre futur moi vous remerciera lorsque cette demande de fonctionnalité révolutionnaire vous arrivera, et que votre équipe pourra la livrer en quelques semaines au lieu de plusieurs mois.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le paysage concurrentiel actuel est en évolution rapide, caractérisé par l’arrivée de nouveaux acteurs dans des domaines d’activité établis, l’évolution des besoins des utilisateurs et l’introduction de nouvelles technologies à un rythme très rapide. La plupart des organisations ne peuvent suivre ce rythme et l’agilité organisationnelle est une capacité essentielle pour votre réussite.
Les leaders sont souvent désireux de comprendre l’impact de l’adoption de méthodes de travail agiles et, dans cet article, nous explorons 5 indicateurs clés qui aident les leaders à suivre l’amélioration des équipes et des produits dans l’ensemble de l’organisation. Ces métriques sont d’excellents indicateurs pour ouvrir la voie à l’innovation, à la résilience et à une croissance soutenue.
#1 – Fréquence de livraison (de sortie)
Une mesure de la fréquence à laquelle une organisation délivre des mises à jour de son ou ses produits est l’un des principaux indicateurs du développement de ses capacités d’agilité business. Les approches agiles telles que Scrum aident les organisations à livrer fréquemment de la valeur aux utilisateurs. Avant même qu’un produit ne soit construit, la valeur qu’il apporte à ses utilisateurs cibles est estimée et les organisations valident les hypothèses lorsque le produit est finalement mis à la disposition du client. Une organisation dont la fréquence de sortie est plus rapide recueille potentiellement plus fréquemment les commentaires de ses utilisateurs.
L’organisation doit s’efforcer d’augmenter la fréquence de mise sur le marché de ses produits au fil du temps. Une fréquence de sortie plus élevée améliore l’agilité de l’entreprise en permettant une innovation plus rapide, une réactivité aux besoins des clients et une adaptabilité aux changements du marché.
Il y a un certain nombre de facteurs que nous pourrions prendre en compte pour augmenter la fréquence de sortie de ses produits :
Tests fonctionnels et non fonctionnels automatisés.
Amélioration des capacités de management de produits, y compris la capture et l’analyse des commentaires des utilisateurs.
Créer des équipes inter-fonctionnelles dans le cadre des efforts de conception de l’organisation.
CertYou est partenaire de DantotsuPM, allez voir les certifications AgilePM
#2 – Incidents par période
Les équipes produit sont responsables de la livraison de produits utilisables à leurs clients et les incidents, lorsqu’ils se produisent, nuisent à la convivialité de vos produits. Les incidents font référence aux temps d’arrêt du produit, aux pannes du produit et aux défauts non détectés du produit, entre autres. Les leaders doivent encourager et soutenir l’équipe produit afin de réduire le nombre d’incidents rencontrés par les utilisateurs par période. Les entreprises doivent investir dans des capacités techniques qui permettent de capturer automatiquement ce type de problèmes à partir des relevés d’incidents et, en outre, de fournir aux utilisateurs un moyen de signaler ces problèmes.
Les entreprises gagnent beaucoup de bonne volonté de la part de leurs clients si ces problèmes peuvent être détectés et corrigés avant qu’ils ne soient visibles par les utilisateurs. Pour s’assurer qu’un produit conserve sa valeur pour ses utilisateurs, le nombre d’incidents par période doit avoir tendance à diminuer au fil du temps.
Voici quelques facteurs qui pourraient contribuer à réduire le nombre d’incidents par période :
Capturez la dette technique en tant qu’éléments de premier ordre de l’arriéré de produit.
Augmentez les tests automatisés autour des fonctionnalités sujettes aux incidents.
Obtenez l’engagement de l’équipe produit à réduire la dette technique sur une période donnée.
Améliorez les capacités d’analyse des logs des utilisateurs pour repérer les problèmes potentiels.
La construction d’un produit est coûteuse et jusqu’à ce qu’un produit soit mis à la disposition de ses utilisateurs, le budget dépensé jusque-là pourrait être assimilé à un « stock d’invendus » comme dans le cas d’une entreprise traditionnelle.
Le délai d’exécution est le temps écoulé entre l’idée et le produit fonctionnel entre les mains du client.
Souvent, l’équipe produit trouve qu’il est plus facile de mesurer le temps de cycle, c’est-à-dire le temps écoulé entre le moment où une tâche est en cours et le produit entre les mains du client. Le temps de cycle peut être mesuré à la place du délai d’exécution, mais en fin de compte, l’équipe produit doit améliorer son système de management du backlog (l’arriéré de produit) pour calculer le délai d’exécution.
Il convient de souligner que l’effort visant à augmenter la fréquence de livraison devrait réduire le délai d’exécution. Cependant, la mesure et la visualisation du délai d’exécution apportent une valeur ajoutée à part entière.
Les facteurs qui améliorent les délais sont les suivants :
Réduire et, éventuellement, éliminer les temps d’attente dans le système.
Dans notre travail avec les clients, nous avons observé que les leaders n’accordent pas suffisamment d’attention à une mesure très importante : Le niveau de satisfaction des personnes qui font réellement le travail. Il semble que les leaders supposent au fil du temps que les employés qui ne montrent pas de signes visibles d’insatisfaction doivent certainement être heureux et notre travail a montré que ce n’est certainement pas le cas
Les employés qui ne sont pas satisfaits au travail et ont des niveaux de moral en baisse ne sont pas en mesure de fournir des produits de valeur que les utilisateurs adorent. Lors d’un récent engagement de transformation de l’organisation où nous avons remarqué que le moral des employés était en baisse, les leaders avaient demandé à l’équipe d’augmenter la fréquence des livraisons et de réduire le temps de cycle, mais les équipes ne pouvaient pas améliorer ces mesures sans l’adhésion des leaders à la prise de certaines décisions qui impliquaient d’investir dans l’automatisation et de restructurer les équipes. Les leaders ont également supposé qu’il était facile pour les équipes de s’améliorer. La seule façon d’obtenir l’engagement des leaders a été de mener une enquête sur la satisfaction des employés, qui a donné des résultats négatifs.
Nous avons pu cocréer un certain nombre d’initiatives avec les équipes produit, notamment :
Des méthodes de travail qui ont donné de l’autonomie et du sens aux équipes.
Le leader s’est engagé à financer des changements d’infrastructure afin de réduire la durée des cycles et d’augmenter la fréquence des livraisons.
Les employés engagés et heureux sont plus susceptibles d’accepter le changement, d’apporter des idées innovantes et de collaborer efficacement, alimentant ainsi l’agilité et le succès de votre organisation.
#5 – Satisfaction du client
Il faut beaucoup de travail pour créer des produits qui apportent continuellement de la valeur à leurs utilisateurs et les organisations capables de créer des produits de valeur peuvent s’attendre à ce que la satisfaction des clients s’améliore au fil du temps.
Les 4 indicateurs : Fréquence de livraison, Incidents par période, Délai d’exécution et Satisfaction des employés, contribuent tous à améliorer la satisfaction client.
Il existe un certain nombre de techniques qui ont été utilisées pour mesurer la satisfaction des clients, notamment le Net Promoter Score (NPS)et le taux d’attrition des clients.
L’équipe produit peut également envisager le déploiement de données de télémétrie qui fournissent des informations sur les comportements des utilisateurs au sein du produit.
Les mesures de satisfaction client fournissent des informations précieuses sur la façon dont le produit répond aux attentes des clients et va même plus loin. En écoutant activement vos clients et en adaptant vos produits, services et expériences en conséquence, votre équipe produit favorise la fidélité, établit des relations durables et garde une longueur d’avance sur un marché concurrentiel.
Sam Adesoga
Sam Adesoga
Coach Agile Principal et Formateur Principal at Valuehut, un cabinet de conseil en coaching et formation agile, qui aide les organisations à explorer les méthodes de travail agiles. Sam a beaucoup d’expérience dans le soutien aux dirigeants et à leurs équipes en matière d’agilité d’entreprise avec un objectif ambitieux :Aider les organisations à développer un état d’esprit agile nécessaire pour continuer à garder une longueur d’avance sur la concurrence et les marchés.
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
Notez 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
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.
Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.
Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser les choses les plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager un montant faible et raisonnable de dette technique peut en réalité faire avancer le projet plus rapidement et permettre d’atteindre l’objectif d’avoir un logiciel utilisable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.
Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la dette technique : « Comme toute dette dans la vie de tous les jours, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »
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 ?
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
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
La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure de calcul de la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.
Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont généré la dette technique.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
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.
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.
MS-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:
Documentation 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
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
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
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 utiliserAgile?
Les 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
Vous ne pourrez probablement pas vous en débarrasser totalement, mais vous devez appliquer ces trois règles d’or :
Commencez dès aujourd’hui à rembourser les anciennes dettes (chaque nouveau projet rectifie des erreurs et confusions passées)
Évitez de nouvelles dettes (bien faire les choses à l’avenir, équilibrer rapidité et qualité)
Si, pour un projet, vous n’avez pas d’autre choix que de générer une dette, éliminez-la le plus vite possible
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
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
Si 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
Une 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
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.
Accumulez 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme 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.
Partagez 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 »
Si 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.
partagez ce billet avec vos amis, collègues et relations professionnelles
« Quel est le pourcentage idéal à dépenser sur votre dette technique ? »
DantotsuPM.com 