Je travaille avec une base de code de plus de 500 000 lignes de code. Il a sérieusement besoin de refactoring. Des efforts de refactorisation ont été identifiés et prendront plus de temps que le sprint normal de deux semaines. Celles-ci ne peuvent pas être divisées en tâches plus petites, comme je l'ai vu suggéré dans d'autres réponses de ce site. Le produit doit fonctionner à la fin de l'itération et une refactorisation partielle laissera le système dans un état inutilisable, car la dépendance entre les éléments est horrible. Alors, quelle serait la meilleure façon d’aborder cet obstacle? Encore une fois, je le mentionne, le décomposer en plus petits éléments n’est pas une option, cela a déjà été fait.
Mise à jour: Les gens semblent avoir besoin d'une explication sur la raison pour laquelle cela ne peut pas être intégré dans un sprint de 2 semaines. Un sprint implique plus que la simple écriture de code. Nous avons une politique de non-code sans tests. Cette politique n'existait pas toujours et une grande partie de la base de code ne les avait pas. De plus, certains de nos tests d'intégration sont toujours des tests manuels. Le problème n'est pas que le refactoring lui-même est si grand. C’est avec le fait que de petits changements ont un effet sur de nombreuses parties du système et nous devons nous assurer que ces parties fonctionnent toujours correctement.
Nous ne pouvons pas retarder ou prolonger un sprint car nous avons des correctifs mensuels. Par conséquent, cette modification qui s’étend au-delà d’un sprint ne peut pas empêcher l’autre travail d’être ajouté au correctif.
Refactoring vs Refonte: Le simple fait que notre processus de développement ne soit pas assez efficace pour gérer ce refactoring dans un cycle de deux semaines ne justifie pas de le renommer en une refonte. J'aimerais croire qu'à l'avenir, nous pourrions accomplir exactement la même tâche dans un cycle de deux semaines à mesure que notre processus s'améliorera. Le code en question ici n'a pas dû changer depuis très longtemps et est assez stable. Maintenant que la direction de la société devient de plus en plus adaptable au changement, nous souhaitons que cette partie de la base de code soit aussi adaptable que le reste. Ce qui nécessite de le refactoriser. Sur la base des réponses fournies ici, il devient évident qu’il manque un échafaudage pour que ce refactoring puisse fonctionner dans les délais impartis pour les sprints normaux.
Répondre:
Je vais faire l'approche de fusion et de succursale que Corbin March a suggérée pour la première fois afin que nous puissions en apprendre davantage sur ces problèmes et sur la façon d'identifier les tests manquants. Je pense que pour aller de l'avant, nous devrions adopter l'approche suggérée par Buhb, qui consiste à identifier les zones manquant de tests et les mettre en œuvre en premier, puis procéder à la refactorisation. Cela nous permettra de nous en tenir à notre cycle normal de sprint de deux semaines, comme beaucoup l'ont dit ici, cela devrait toujours être le cas pour la refactorisation.