A simple strategy for managing technical debt
http://madebymany.com/blog/a-simple-strategy-for-managing-technical-debt par James Higgs
Auparavant, j’ai essayé d’expliquer le concept de dette technique. Aujourd’hui, j’essayerai de suggérer une façon pratique de la suivre à la trace et de la traiter dans votre projet.
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.
DantotsuPM.com 