Tu sais ce que c'est. Placer tout ce dont vous avez besoin dans le sprint est déjà très difficile, mais vous devez toujours trouver ailleurs 20 à 20% du temps des développeurs pour rembourser la dette technique . Si vous avez déjà défendu la nécessité de prendre du temps pour cela, alors vous savez que cela ressemble à une croisade aux proportions épiques.
Mais vous pouvez le faire, et dans ce guide, nous découvrirons exactement comment.
J'ai vu trop de réunions où exactement cette question a été passée trop de temps. Les arguments sont généralement sans fondement et les émotions peuvent être élevées - et celui qui a la voix la plus forte dans la pièce l'emporte.
Le dilemme est le suivant: si la pression commerciale prend le dessus, votre entreprise court le risque de s'endetter trop - et ensuite les développeurs perdent leur motivation, l'entreprise fait faillite technique et vos concurrents vous battent. Si vous surmontez la pression des développeurs , l'entreprise court le risque de prendre trop peu de dettes techniques, puis vos concurrents seront en mesure de fournir des produits et des fonctionnalités plus rapidement, de conquérir le marché et d'utiliser plus tard les bénéfices reçus afin de rembourser leur dette technique. Vous perdez encore.
Le bon sens suggère que les équipes de développement devraient développer une compréhension intuitive de la base de code, où se cache la dette technique, ainsi que ses conséquences pour l'entreprise, renforçant ainsi la confiance au sein de l'organisation. Si votre architecte et fondateur principal dit que vous devez faire du refactoring dès maintenant, vous (généralement) le prenez et le faites.
Il est logique d'essayer de fidéliser vos développeurs afin de créer une culture de connaissance, d'échange et de confiance. Mais cela prendra des années de dur labeur, et, après avoir terminé la refactorisation, nous n'avons encore presque aucune idée si nous avons perdu notre temps. Peut-être que nous venons de gagner quelques jours du temps de développement futur? Ou pourrions-nous attendre un peu plus tard pour rembourser la dette technique et ajouter à la place de nouvelles fonctionnalités? Nous ne savons jamais avec certitude et attribuons notre ignorance au fait que le développement de produits est plus un art qu'une science.
Eh bien, il est temps d'ajouter un peu de science au processus.
Quelles sont la fiabilité similaire du site et le budget de la dette technique
Une dette technique correctement gérée et soigneusement planifiée peut être un outil précieux. Réalisant ce que nous faisons, nous pouvons l'utiliser tout comme nous utilisons la dette financière comme levier. Mais si nous, sans le soupçonner, en prenons trop - par exemple, nous ne comprenons pas pleinement les termes de la transaction (c'est-à-dire l'impact que la dette technique a sur notre base de code, nos clients, notre équipe et nos activités) - l'entreprise peut se terminer par l'effondrement de notre entreprise.
Les meilleures équipes de gestion de la fiabilité du site fonctionnent avec leur budget de fiabilité du site en termes de dette technique gérée. La fiabilité du site est un concept popularisé par Google; elle est chargée de maintenir le logiciel dans un état «opérationnel», mais, fait intéressant, des entreprises comme Google ne visent pas à porter le temps de disponibilité à 100%. La raison en est qu'un temps de disponibilité de 99,99% est suffisant pour que les produits Google soient exceptionnellement fiables pour les vrais utilisateurs. Et ce dernier 0,01% est exponentiellement difficile à atteindre, et il est tout simplement inutile de lutter pour cela.
Par conséquent, si cela donne un total de 52 minutes de temps d'arrêt par an, Google essaiera de se rapprocher le plus possible de ce chiffre; mais tout ce qui dure moins de 52 minutes par an est une occasion manquée de prendre des risques supplémentaires et de fournir rapidement toutes les fonctionnalités prometteuses à ses clients.
Considérez votre budget de dette technique comme un budget pour la fiabilité du site. À condition que vous contractiez une dette technique raisonnable et que vous restiez en dessous du montant maximal que vous pouvez vous permettre avant qu'il ne commence à affecter vos clients et votre entreprise, vous devez augmenter le montant de la dette afin de prendre plus de risques et de gagner leurs concurrents.
Si votre dette technique est dans la zone rouge, vous devez la rembourser partiellement. S'il est dans la zone verte, vous pouvez prendre plus de risques et plus de dettes. Votre objectif est de maintenir en permanence le montant de la dette aussi proche que possible de l'idéal. En d'autres termes, si vous êtes au sommet de la partie rouge du graphique, le budget idéal pour la dette technique est A ⇒ B.Si vous êtes dans la dépression de la partie verte du graphique, alors le budget idéal est C ⇒ B.Rappelez-vous seulement que A ⇒ C est un budget trop important pour la dette technique .
Étant donné que la dette technique peut être mesurée (nous avons écrit à ce sujet dans un autre article ), ce n'est plus seulement un concept - il répond pleinement aux besoins pratiques.
Comment tirer le meilleur parti de votre budget de dette technique
Vous devez vous efforcer d'avoir un budget de dette technique qui vous ramène à la hausse ou à la baisse, au montant maximum de dette technique que vous pouvez vous permettre. Pour déterminer ce budget, définissez dans votre code de base les zones où la dette technique doit être remboursée immédiatement, c'est-à-dire les dettes qui empêcheront votre entreprise d'atteindre ses objectifs actuels. Il n'est pas conseillé de rembourser trop peu ou trop de dettes.
Andreas Klinger , coordinateur d'équipe à distance chez AngelList, le décrit bien dans son article Refactoring Large Bases of Inherited Code :
Tout n'a pas besoin d'être refactorisé. Si ce n'est pas une partie critique, ou si personne n'a besoin d'améliorer cette fonctionnalité dans les prochains mois, ou si c'est trop compliqué, pensez à reconnaître cet endroit comme une dette technique.
En termes simples, votre objectif est de trouver où deux choses se chevauchent: ce sur quoi vous travaillerez au cours du sprint, du mois ou du trimestre en cours, et les parties de votre base de code qui contiennent des dettes techniques. Remboursez la dette dans la zone de cette intersection, mais pas au-delà.
Et c'est ici que la science complète l'art. Vous pouvez utiliser les données pour identifier les domaines dans lesquels vous devez rembourser votre dette technique dans un avenir proche:
- Mettez en surbrillance les fichiers à faible propriété dans votre base de code, car la propriété du code est un indicateur avancé du bien-être de votre base de code. Plus d'informations à ce sujet dans notre article «Une caractéristique de la culture d'entreprise nécessaire au bien-être de la base de code» .
- Mesurez la cohésion et le couplage de ces fichiers et ne laissez dans la liste que les fichiers à faible propriété, faible connectivité et vitesse élevée. Vous pouvez en savoir plus sur chacun de ces indicateurs dans notre article «Utiliser les études des leaders de l'industrie pour mesurer la dette technique» .
- Calculez l'activité récurrente (churn) pour chacun de ces fichiers pour déterminer un sous-ensemble des fichiers problématiques. Selon une étude de Microsoft , les fichiers en cours de modification ne représentent que 2 à 8% du total des fichiers du système, mais ils représentent 20 à 40% de tous les changements et sont responsables de 60 à 90% de tous les bogues.
- Reliez la liste de fichiers résultante à vos plans trimestriels. L'une des fonctionnalités répertoriées dans vos plans vous obligera-t-elle à travailler sur un sous-ensemble des fichiers de problème que vous avez décrits? Si oui, définissez des objectifs liés à la refactorisation de ces fichiers, évaluez la quantité de travail nécessaire et attribuez des tâches à des développeurs spécifiques, de préférence ceux qui possèdent les fichiers correspondants. Incluez ce travail dans vos plans.
Pour commencer, jetez un œil à notre extension VSCode gratuite - elle vous aidera à surveiller et à payer en permanence les dettes techniques les plus urgentes.
Entrer dans une relation à long terme avec la dette technique
Nous avons mis en œuvre cette approche basée sur les données dans Stepsize, ainsi que dans de nombreuses sociétés de logiciels de classe mondiale. Non seulement le sujet de la dette technique est devenu beaucoup plus clair, mais nous savons également combien nous sommes prêts à contracter et quand / comment la rembourser. Nous pensons tous rarement si nous avons correctement choisi un compromis entre les nouvelles fonctionnalités et la dette technique. Nous avons réussi à éliminer une partie importante de la conjecture, ainsi que de nombreuses peurs et angoisses qui accompagnaient ce choix.
Clarifions encore: ce n'est pas une solution miracle qui peut être utilisée une fois par an, puis oubliée. Vous devez mieux connaître votre devoir technique. Suivez vos progrès sur tous les indicateurs de chaque sprint et continuez à améliorer l'ensemble du processus pour atteindre le bien-être technique .
Nous avons écrit sur plusieurs façons de le faire, afin de créer la bonne motivation, lisez comment cultiver une culture de développement basée sur la propriété et honorer les développeurs qui remboursent la dette technique .