¿Cómo manejo la refactorización que toma más de un sprint?

Si tiene el lujo de retrasar la refactorización, sugiero enfocar las próximas iteraciones en agregar pruebas unitarias y pruebas de integración automatizadas hasta el punto en que pueda refactorizar cómodamente la base de código, y luego refactorizar en un solo sprint.

Mi sugerencia:

1. crear una rama
2. Combine diariamente desde el tronco a su rama y resuelva los conflictos.
3. Trabaja hasta que esté hecho. Su sucursal puede estar fuera del desarrollo del núcleo para varios sprints.
4. Combinar de nuevo al tronco.

No hay forma de evitar el hecho de que probablemente se pondrá feo. No te envidio. En mi experiencia, cuando cambias drásticamente un proyecto, es más fácil fusionar el desarrollo continuo con el nuevo paradigma en lugar de fusionar el nuevo paradigma en un tronco ahora cambiado después de que todo haya terminado. Aún así, va a doler.

No todas las tareas se pueden realizar en un sprint de 2 semanas (artificial), por lo que se requiere el sentido común. Si ya no se puede desglosar, y debe hacerse, solo sigue y hazlo. El proceso no es más importante que el resultado final, y debe verse como una guía en lugar de una ley que nunca se rompe.

Solo haz un sprint de 3, 4 o 5 semanas. ¿A quien le importa? Obviamente estás convencido de que no se puede hacer nada en un plazo más corto, así que deja de luchar contra él.

Simplemente no le digas a tus compañeros de la Royal Society of Blind Agile Adherance.

Recomiendo comenzar con el libro Trabajo eficaz con el código heredado , de Michael Feathers. Cubre una variedad de técnicas para reducir el alcance de los cambios de estilo de refactorización.

En nuestra tienda, cuando tenemos grandes tareas de refactorización o reescritura que no se pueden completar en una ventana de lanzamiento, dejamos la funcionalidad como está en el sistema. Pero, comenzamos con las nuevas funciones de bloques lego refactorizadas según lo permita el tiempo. Finalmente, llegamos a un estado en el que tenemos suficientes bloques de lego, que un sprint proporciona tiempo suficiente para conectar los bloques de lego en la aplicación y activarlo para los usuarios.

Más concisamente, dividimos o volvemos a trabajar funciones grandes con nombres nuevos. Luego, al final, usamos nuestro trabajo renombrado y refaccionado en lugar del viejo código desagradable.

Dedique un sprint para descubrir cómo mantener el código funcionando correctamente a mitad del refactor. Esto puede tomar la forma de métodos y clases obsoletos, envoltorios, adaptadores y similares. Su refactorización puede ensuciar el código por un corto tiempo para que sea más limpio a largo plazo; está bien. Ahora mismo estás diciendo que no se puede hacer. No creo que sea correcto. Piense en cómo sería su proceso si pudiera realizarse, piense en los pasos que puede tomar para lograrlo. Luego sumérgete.

+1 en la respuesta de Corbin March, eso es exactamente lo que estaba pensando. Parece que su código base es un poco feo y va a tomar más de un ciclo de sprint para limpiarlo.
Así que, como dijo Corbin,

1. ramifíquelo en un "proyecto de refactorización"
2. prueba el cambio de tu rama
3. promocione a su entorno de prueba para pruebas de control de calidad
4. fusionarlo de manera incremental en el tronco hasta que se complete la refactorización.

Estoy seguro de que no tendrías ningún problema en venderle esto a tu administrador de desarrollo, si a tus PM les resulta difícil verlos, entonces explícales que Roma no se construyó en un día y limpió toda la basura. arrojados a las calles de Roma tampoco se va a hacer en un día. La refactorización tomará un tiempo, pero valdrá la pena al final en términos de mantenimiento más fácil, lanzamientos de mejoras más rápidos, menos tickets de producción y un SLA más completo.

Aunque el rediseño que realmente desea hacer es una tarea grande, ¿sería posible refactorizar piezas más pequeñas para romper / desacoplar dependencias individuales? Ya sabes, en caso de duda, añade indirección. Cada uno de estos desacoplamientos debe ser una tarea más pequeña que la gigantesca que no puede completar.

Una vez que se eliminan las dependencias, debería poder dividir las tareas de refactorización restantes que se pueden obtener dentro de los sprints.

En el proyecto en el que estoy trabajando en este momento, estamos usando sprints de 4 semanas. Y a veces no podemos terminar una historia de usuario y simplemente la reiniciamos durante el siguiente sprint.

Sin embargo, en mi humilde opinión, debería ser posible dividir una refactorización en historias más pequeñas que se ajusten a un sprint de 4 semanas. Si no puede llevar el código a un estado coherente dentro de las 4 semanas, tengo la sensación de que está reescribiendo su aplicación en lugar de refactorizarla.

Recomiendo que cuando ciertas tareas tomen más tiempo que el ciclo de sprint de 2 semanas, la tarea se programe para otro momento. Su equipo ha identificado la necesidad de refactorización y eso es importante. A veces, no hay otra opción ... y, sí, eso apesta.

Cuando llegue el momento de comenzar la refactorización, simplemente suspenderás los sprints normales. No tienes elección. Utilice el control de versión inteligente: ramificación, refactorización, prueba, combinación. Siempre hay un momento en el que la refactorización de algunos proyectos grandes tiene prioridad sobre las características. Si es posible, también intentaría separar las preocupaciones para una mejor flexibilidad.

Habiendo pasado recientemente por el mismo problema con una parte de nuestro código base (que también es un poco más grande), espero poder compartir algunas ideas con usted. En mi situación, la base de código había sido desarrollada por otro equipo, por lo que nadie de los desarrolladores originales participó en esta refactorización. Mi experiencia con el código base fue de aproximadamente 1 año, y otro desarrollador se encargó de ello durante 2 años.

Permítame dos pequeñas notas con respecto a las otras respuestas aquí:

• Las ramificaciones te ayudarán a establecer un área de juegos para ti mismo, pero nunca fusiones tus cambios en el tronco en un gran conjunto de cambios. Te meterás en serios problemas con el resto del equipo.
• Debe hacerlo de forma incremental, y se puede hacer. No hay excusas. Lea la cubierta de Cómo trabajar eficientemente con el código heredado para cubrir. Léelo de nuevo.
• Pensar que puedes hacerlo un gran paso es una falacia. Aunque parece más trabajo, hacerlo de manera incremental es mucho más fácil de administrar.

Ir aparentemente "fuera de reserva" durante dos semanas o más no pasará inadvertido. Debe asegurarse de estar respaldado por la gestión de proyectos y, lo que es más importante, del equipo. Si el equipo no está comprometido con esta refactorización (y esto significa, hazlo ahora, no en un futuro lejano), tendrás problemas.

No lo hagas solo, usa la programación en pares. Esto no significa estrictamente que deba sentarse frente al mismo teclado todo el tiempo, pero puede manejar tareas pequeñas y limitadas (por ejemplo, escribir pruebas que capturen el comportamiento de esta clase) individualmente.

Haz un Refactoring de Scratch y trátalo como tal. (¡Una especie de refactorización "desechable", la parte "desechable" es importante!) Sinceramente, es poco probable que sepa todas las implicaciones que tendrá su refactorización. Una refactorización del rasguño te ayudará en ciertos aspectos:

• Descubrirá partes del sistema que nunca supo que existían.
• Tendrás una mejor visión de cómo se interconectan los módulos
• Descubrirá una nueva forma de agrupar su sistema en módulos, probablemente muy diferente de su comprensión actual. Discute las ideas con tu pareja. Intenta destilar tu nueva vista. Escriba un documento técnico de arquitectura breve (o dibuje un diagrama) que diga dónde están las cosas actualmente y dónde deben pertenecer lógicamente.

Cuando hayas hecho tu refactorización de scratch, espero que descubras que no puedes simplemente ir y cambiar todo. Te sentirás mal, es solo un gran desastre y no puedes simplemente apretar un interruptor y hacerlo funcionar. Esto es lo que me sucedió, podría ser diferente en tu situación.

Sin embargo, mi socio y yo entendimos mucho mejor nuestro sistema. Ahora pudimos identificar refactorizaciones / rediseños individuales, más pequeños (aunque aún grandes). Capturamos nuestra visión del sistema en un diagrama y lo compartimos con el equipo, junto con los elementos de la cartera de pedidos que creamos para implementar esa visión. Gracias al consenso común, decidimos qué elementos implementaríamos en el transcurso de la próxima iteración.

Una última cosa que nos ayudó fue usar una pizarra grande. Hay demasiadas cosas para tener en tu cabeza. Es de suma importancia mantener notas. Escriba una nota informativa al final del día, capturando lo que ha hecho hoy y lo que quiere hacer mañana. Ayuda a relajarse grandes momentos, y necesita un tiempo relajado si desea continuar con la tarea. Buena suerte!

Inicia una ventana de mantenimiento durante la cual no se realiza ningún desarrollo adicional. Realizar el rediseño, luego reanudar los sprints de desarrollo.

Tenemos dos tipos de trabajos en nuestras manos:

1. Trabajos de hora hombre
2. obras de genio

La refactorización generalmente consiste en el primer tipo de trabajo, ya que ya se conocen muchos métodos para desarrolladores como DRY , SRP , OCP , DI , etc. Así, cuando un proyecto demora dos meses en ser refaccionado, simplemente lleva dos meses , no hay manera de evitarlo. Por lo tanto, mi sugerencia sería no refactorizar el proyecto original y dejar que funcione en su situación actual. Deje de recibir nuevas solicitudes y requisitos de los interesados y del propietario del producto . Luego, deje que el equipo trabaje en el proyecto hasta que sea refactorizado y listo para funcionar.

Una sugerencia que puede ayudar: si tiene un código no probado como el que no tiene tiempo suficiente para refactorizar y vuelva a realizar la prueba dentro del sprint de dos semanas, considere primero realizar algún otro cambio pequeño no relacionado ( s) al código para que pueda concentrarse en escribir pruebas para el primer sprint o dos. Quizás pueda identificar varios clientes no probados del código que desea refactorizar; elija un cliente y realice algunos otros cambios de algún uso para el negocio que lo forzarán a escribir pruebas para ese cliente. Una vez que esté más familiarizado con el código, trabaje con él y tenga más pruebas, y posiblemente haya logrado algunas refactorizaciones contribuyentes menores, estará en una posición mucho mejor para realizar la refactorización y la (ahora más fácil ) probando ambos en una iteración.

Otro enfoque es hacer una copia del código ofensivo, refactorizarlo y luego mover a los clientes uno a uno al nuevo código. Este trabajo se puede dividir en iteraciones.

Y no se rinda: no acepte simplemente que una refactorización grande no se puede dividir en pasos más pequeños. El enfoque más fácil / más rápido / mejor puede llevar más tiempo que una iteración. Pero eso no significa que no haya forma de hacer fragmentos de tamaño de iteración.