les compagnons du DevOps !
Après tout un tas de conversations dans mon équipe, et des échanges récents avec mes clients, j’ai finalement publié un blog sur la façon de mettre du temps de côté pour réduire la dette technique. Sur LinkedIn et aussi mon blog perso.
Il y a une technique que j’affectionne (le numéro 6).
Je dirais que pour ma part je suis dans le scénario 5 : dans chaque release, on embarque des sujets tech et on met à jour au fil de l’eau dans la mesure du possible les composants de nos produits. Cela évite de devoir faire des gros incréments.
En septembre dernier quand je suis arrivé sur le projet, y avait un sacré retard mais que l’on a quasiment fini de combler. Nous sommes une équipe de 3, j’ai principalement fait de la réduction de dette technique dans un premier temps sur la partie plateforme, les deux devs ont fait un peu de réduction de dette mais surtout de la feature pour les clients. Avec la release prévue pour juin, on est tous dans la version 5 maintenant et c’est pas plus mal
Pareil, adepte de la maintenance en continue en consacrant jusqu’à 25% d’un sprint aux opérations de refactoring, mises à jour de dépendances, montées en versions…etc.
Je n’essaye pas d’avoir un % fixe de réduction de la dette technique/refactoring pendant mes sprints de mon côté. On juge ce qui important ou non à faire, ce qui mérite vraiment d’être résolu rapidement ou ce qui peut attendre, le tout en fonction également des autres sujets en cours, mais il n’y a pas de règle fixe.
Pareil chez nous, y a pas de % fixe - juste l’idée d’entretenir le socle au fur et à mesure et de façon régulière en fonction des contraintes et objectifs du moment.