¿Se permite el código de refactorización aleatorio en scrum?

Fondo

• Mi equipo usa scrum
• Actualmente no tengo tarea asignada
• No hay más tareas pendientes en la cartera
• Hoy es el Día del Trabajo para mi cliente.

Al no tener muchas cosas que hacer hoy, quería comenzar a refactorizar un código que sigo viendo en el proyecto en el que estoy trabajando, pero actualmente no estoy asignado a ninguna tarea de sprint para hacer una refactorización a gran escala.

¿Está bien en Scrum si comienzo a refactorizar al azar el código que tengo y no he escrito que siempre me molesta pero no tengo tiempo otros días para arreglarlo debido a las asignaciones de otros días?

¿Qué pasa con otros días que tengo tiempo libre entre sprints?

De hecho, creo y creo en la refactorización continua. Siempre lo hago en los fragmentos de código en los que estoy trabajando cuando se me asigna una historia, pero ¿qué pasa con algún otro código que veo que actualmente no está relacionado con lo que estoy trabajando en ese momento?

Realmente no pretendo atacar otras respuestas, pero ¿nadie más está escribiendo pruebas automatizadas aquí? Aquí hay una lectura divertida de Martin Fowler para cualquiera que esté haciendo Scrum sin las prácticas adecuadas de ingeniería de software. Robert C. Martin también dice mucho sobre esto aquí .

Entonces, a mi respuesta ... En resumen, es así:

Sí, el código de refactorización "al azar" está permitido en Scrum , siempre que el equipo decida que debe hacerse. (Después de todo, es autoorganizado)

Y ahora por la larga respuesta:

Es evidente que dejar más y más deuda técnica después de cada Sprint es una receta para el desastre. Pronto, todos disminuirán la velocidad a medida que el código se vuelva más desordenado; cada cambio será más difícil de realizar porque el código está tan enredado y desordenado que lleva más tiempo encontrar los lugares para cambiar que realizar el cambio real. Se vuelve aún peor si tiene que hacer un cambio en un módulo grande y desordenado del que no sabe nada, se hace imposible ganar / mantener la productividad al agregar / cambiar personas en el proyecto, y así sucesivamente.

Si un equipo desea mantener estable su velocidad, debe poder mantener limpia la base del código para incrementar continuamente el software. La refactorización es una práctica obligatoria si desea mantener su velocidad durante todo el ciclo de vida del proyecto, y si desea mitigar el riesgo de agregar / cambiar personas en el proyecto, y si desea poder realizar cambios en los módulos, no sabe nada sobre, y así sucesivamente.

Sin embargo, refactorizar es una actividad muy peligrosa. Repito, es una actividad muy peligrosa . Es decir, a menos que tenga suficiente cobertura de prueba para poder cambiar de forma segura y libre la base del código. Si puede presionar un botón para verificar si nada se rompió, la refactorización se convierte en una actividad muy segura; tan seguro, de hecho, que es parte del ciclo de TDD , que es la práctica que le permite crear dicho conjunto de pruebas en primer lugar.

Pero, como los equipos en Scrum se autoorganizan, al final su equipo debe decidir qué es lo correcto. Espero haberte dado algunos argumentos en caso de que tengas que convencer a alguien. (Preste especial atención a los enlaces en el primer párrafo, y a cualquier otro artículo al que apunten)

Scrum realmente no dice nada sobre refactorización.

Lo que Scrum dice es que si no tienes ninguna tarea dentro del sprint para trabajar, debes apoyar al resto de tu equipo para alcanzar la meta del sprint. Incluso si eso significa buscar café para ellos.
Si su equipo está de acuerdo en que refactorizar el código es la mejor manera de apoyarlos (y eso incluye contar con la infraestructura para garantizar que la refactorización no introduzca demasiados errores nuevos), entonces hágalo.

Yo diría que no, no lo es. Esto es independientemente del tipo de trabajo (refactorización, etc.).

Como mínimo, las tareas deben crearse e insertarse en su sprint actual. El propósito del seguimiento del tiempo es capturar su velocidad para poder trazar efectivamente sprints futuros. Si está trabajando en cosas sin rastrearlas, tendrá un impacto en la velocidad y no mejorará con el tiempo como se pretende con un seguimiento adecuado (es probable que regularmente no tenga suficiente trabajo porque su velocidad proyectada es menor que su velocidad real )

En cuanto a la refactorización del trabajo en sí mismo, puedo hablar de eso, pero no lo haré, ya que no creo que sea la pregunta central que estás tratando de responder.

Voy a decir que no también. Re-factorizar a menudo conduce a errores no intencionados si no se maneja de la manera correcta.

Como gerente general, periódicamente pondría a todos en otro proyecto y pasaría una semana haciendo revisiones de código / refactorización / cambio de nombre y aplicación de convenciones en un proyecto. Estos sprints de refactorización casi siempre serían de naturaleza cosmética. Cualquier refactorización funcional se planificaría con anticipación e involucraría al desarrollador original.

La refactorización funcional siempre debe planificarse y coordinarse como parte del proceso scrum para que se pueda realizar un seguimiento del tiempo y todos los miembros del equipo necesarios estén disponibles para validar el proceso. Un desarrollador no debería cambiar el código escrito por otro fuera de pista porque lo más probable es que solo arruine el sprint actual para todos. Especialmente cuando se trata del tiempo de fusión de código.

Si se trata de un proyecto del cual usted es el único responsable y es su propio tiempo libre, puede ser diferente suponiendo que tome medidas para asegurarse de no causar retrasos innecesarios en su sprint actual.

En caso de duda, consulte a su gerente.

EDITAR: También quiero mencionar que un determinado código que no le gusta puede tener un determinado objetivo de rendimiento asociado. Puede que no te guste, pero puede ser más rápido que cualquier cosa que puedas construir que se adapte a cómo quieres usarlo. Solo otra razón por la cual la refactorización funcional siempre debe ser un proceso administrado.

Scrum no dice nada sobre la refactorización (ver una conferencia de Robert C. Martin, "La tierra que se olvidó de scrum").

En Scrum, las tareas están dirigidas a las funciones de su software especificadas por el cliente, no a las deudas técnicas para pagar mediante refactorización. Estos son niveles de abstracción totalmente diferentes. El cliente en su mayoría no puede evaluar la necesidad.

Scrum es gestión estadística de proyectos. Para obtener medidas significativas de "cuánto tiempo lleva", debe conocer el rendimiento (salida por sprint). Se compara la estimación y la duración real de una característica durante al menos más de 1 sprint para entrar en la estadística. Recomiendo 5 sprints. Pero eso depende de tu equipo.

Lo principal es mantener las medidas significativas y comparables para hacer posible cualquier pronóstico. Ese no será el caso si el rendimiento está disminuyendo debido a deudas técnicas.

Si todavía piensa en refactorizar tareas, tiene dos problemas: 1. Un cliente, que no comprende, por qué tiene que aceptar una tarea que no producirá una nueva característica 2. Distorsiona totalmente sus estadísticas y, por lo tanto, su capacidad para pronosticar a medida que cambia repentinamente una variable diferente que no se consideró en sprints anteriores

En ambos casos, compromete la idea de scrum ya que desea hablar sobre las características con el cliente Y hacer pronósticos confiables para "¿Cuánto tiempo lleva?" de manera estadística. Para estar seguro, debe mantener su base de código en una calidad constante (tal vez alta).

La refactorización es la mayoría de las veces una tarea subterránea. Las refactorizaciones "geniales" significan que las refactorizaciones "pequeñas" no se han procesado en el pasado.

Una última nota: si realiza refactorizaciones, asegúrese de tener el componente bajo prueba que está refactorizando. Ohh, no tienes pruebas? Haz una tarea para escribir pruebas. Su cliente estará feliz de saber que el software que está utilizando actualmente no tiene suficiente cobertura de prueba ...

Mantenga las cosas técnicas lejos del cliente y haga su trabajo como desarrollador profesional.

Aquí hay un enfoque: ¡haz las dos cosas!

La refactorización a menudo es propensa a errores o consume más tiempo de lo que originalmente se estimó como señala @misterbiscuit.

Por lo tanto, considere un intento de hacerlo un borrador o un pico. No necesita buscar aprobación o anunciarse si en esta etapa.

Luego, busque incluirlo a través de uno de los dos canales:

• un boleto existente que toca el mismo código / funcionalidad donde puede envolverlo razonablemente. Razonablemente según lo acordado con otros miembros del equipo.
• un boleto completo para su revisión en la próxima preparación del boleto (o reunión semanal, etc. si es una cascada). En ese momento puedes justificarlo.

Una vez que obtenga la aceptación real, puede buscar aplicar o rehacer su pico y hacer que el código real se fusione con la rama de la línea principal (maestra, etc.).

Esto tendrá varias ventajas:

• Todos sus códigos de código a través del mismo proceso, se prueban, QA, en la tubería de lanzamiento, etc.
• Obtiene una aceptación formal, incluso por parte del gerente de producto, de que la refactorización es parte del oficio y no es algo que deba ser 'infiltrado' en vacaciones. Pregúntese por qué no se está "infiltrando" en una característica real que puede ayudar a la perspectiva.
• Puede solicitar emparejamiento, revisión de código, qa, devops y todo el soporte que pueda necesitar para el cambio de código de factoring. Todo será oficial, de acuerdo con la Política y el Procedimiento y por encima del tablero.
• Si es una empresa que cotiza en bolsa y cumple con SOX, es probable que desee / necesite hacer este tipo de proceso formal (es decir, documentarlo y luego seguirlo).
• Obtiene una mejor reputación tanto con el gerente de producto (el cambio se realizó rápidamente) como con el equipo de desarrollo (se mejoró la base de código).
• La organización busca preocuparse por la calidad del código, lo cual es bueno para la productividad, la moral, la retención de los empleados y muchas otras razones.
• El efecto sobre la velocidad del proyecto puede rastrearse más fácilmente cuando se incluye todo el trabajo. Puede estar bien no designar ningún punto, ya que la presencia misma puede usarse para afectar la velocidad.
• Es probable que los desarrolladores vean herramientas que fomenten revisiones de código más fáciles como Fisheye, Github, etc.
• Es más probable que los desarrolladores vean algunos estándares básicos (a veces documentados, a veces no) que hacen que el código compartido y, por lo tanto, la refactorización sea más fácil. A veces, una gran parte de la refactorización es elegir un estilo y luego aplicarlo ampliamente (reemplazando una mezcla de enfoques por uno).

Un comentario final: evite que el gerente de producto escuche la palabra 'aleatorio'. Pueden responder de manera más favorable con la actualización de código 'dirigida, estratégica, que mejora el rendimiento'. O paquete de servicio de aplicaciones. O cualquier idioma que te brinde cobertura.

La refactorización aleatoria no tiene sentido. Lo que tiene sentido es la refactorización de un código que introducirá la mayoría de los beneficios. Eso significa :

• arreglar un problema de diseño o arquitectura
• mejorando la implementación

¿Está bien en Scrum si comienzo a refactorizar al azar el código que tengo y no he escrito que siempre me molesta pero no tengo tiempo otros días para arreglarlo debido a las asignaciones de otros días?

De esta respuesta :

Mantener el código mantenible debe ser un elemento en su lista de grabación (si usa un Scrum). Es tan importante como el nuevo desarrollo. Si bien puede no parecer algo que sea "visible para el usuario", ignorarlo aumenta su deuda técnica. En el futuro, cuando la deuda técnica se acumule lo suficiente como para que la falta de mantenimiento de su código ralentice el desarrollo, los retrasos en el desarrollo de nuevas características serán visibles para los clientes.

En mi trabajo anterior, teníamos algún tipo de scrum, con sprints más grandes (2-3 meses). Como tuvimos algunos retrasos entre sprints (1 mes), utilizamos este tiempo para analizar el software y refactorizar el código.