No deberían estar haciendo eso y, si lo están, deberían tener un propósito al respecto.
Comencemos desde arriba. Todo el código debe reescribirse eventualmente. La reescritura ocurre cuando los requisitos cambian y sucede a medida que cambia la tecnología. En algún lugar del mundo hay un sistema vital para la red global de control de tráfico aéreo que se escribió una vez en Fortran, se volvió a tocar alrededor de 1999 y ha estado ronroneando felizmente desde entonces. Esa cosa es una pesadilla. Todos los que lo sepan deberían mirarlo todos los días preguntándose cuándo el error no descubierto en él va a criar su fea cabeza y esperando poder encontrar a alguien que recuerde a Fortran cuando lo haga. Sistemas como ese representan una forma de deuda técnica y dejarlos funcionando, sin mantenimiento y sin tocar durante décadas es un problema.
Ok, pero eso claramente no es de lo que estamos hablando. A corto plazo, el código debe reescribirse cuando cambian los requisitos. Esto tiene sentido; el código se escribió con algún requisito y cambiar el requisito debería requerir un cambio en el código. El Principio de Responsabilidad Única sugiere que cada módulo en el código debe tener una única responsabilidad y que debe haber un único requisito que, si se modifica, puede forzar un cambio en ese código. Una reescritura es un cambio bastante significativo, pero dependiendo de qué tan desacoplado esté su código, podría ser apropiado. Si esto está sucediendo mucho, es un síntoma de problemas con el liderazgo y la priorización. Lo más probable es que sus desarrolladores estén tan molestos como las personas que pagan sus salarios y necesita hablar con el propietario de su producto.
- ¿Cómo puedo convertirme en un gurú de PHP?
- Cómo ganar contratos para el desarrollo de software y luego externalizarlo
- Como desarrollador de software, ¿cuál es el mayor desafío / disgusto / obstáculo que enfrenta cuando busca nuevas oportunidades?
- ¿Pueden los desarrolladores de Android codificar software?
- ¿Cómo funcionan las aplicaciones de múltiples mandatos como Jira?
Pero eso probablemente tampoco sea de lo que estás hablando. Parece que lo que estás diciendo es que, sin cambios en los requisitos, los desarrolladores están reescribiendo elementos del sprint N en el sprint N + 1. Eso es un problema. Sugiere que los desarrolladores no sabían cuál era la visión a largo plazo del proyecto en el sprint N o que deliberadamente asumieron una deuda técnica para aumentar las métricas en el sprint N. Por el contrario, puede significar que tienes algún tipo de desglose en el proceso de promoción y revisión de código de manera que los desarrolladores se encuentren con un código subestándar en el sprint N + 1 y se vean obligados a reescribirlo porque se promovió por error en el sprint N.
Por supuesto, hay momentos en que es apropiado asumir una deuda técnica. No siempre sabemos cómo funcionará un componente dado o es posible que queramos comenzar con los aspectos de una integración antes de que uno de los elementos base esté completo. En esos casos, el equipo debe acordar emprender una solución barata a corto plazo para llenar el vacío hasta que se realice el trabajo más sustantivo y volver a escribir más tarde para incorporar el nuevo sistema. Pero esa debería ser una tarea poco frecuente y todos los involucrados deberían estar adecuadamente motivados para sacar las cosas temporales lo más rápido posible.