metodologia - scrum sprint

scrum y refactorización (6)

Si todo en Scrum se trata de cosas funcionales que un usuario puede ver (...)

Cualquier proyecto y metodología debe ser sobre la generación de valor comercial , rara vez se hacen las cosas solo por diversión en un entorno empresarial. Dicho esto, veo la calidad en Scrum (y otros métodos ágiles) como una forma de no matar tu velocidad a largo plazo y, en última instancia, para lograr la productividad hiperactiva. Por lo tanto, creo que una "Definición de Hecho" típica debería incluir algo como "no aumentar la deuda técnica" (ponga sus estándares de calidad allí). Si cree que una nueva característica afectará el código existente que debe ser refactorizado, incluya este costo en la estimación (o cree un artículo de refactorización en su Registro de productos) y explíquelo a su Propietario del producto. Porque al final, depende del Propietario del producto el dar prioridad a los elementos y decidir si la calidad se puede sacrificar temporalmente (si su empresa se muere porque no lanza una característica, ¿cuál es el punto de refactorizar el código existente?). Pero debe ser consciente de que esta no puede ser una estrategia a largo plazo o matará la velocidad del equipo.

Si todo en scrum tiene que ver con cosas funcionales que un usuario puede ver, ¿existe realmente un lugar para refactorizar el código que no esté relacionado con los nuevos requisitos funcionales?

bta: Independientemente de si un proyecto usa Scrum o no, a muchos gerentes de proyectos no les gusta que los desarrolladores dediquen tiempo a cosas "innecesarias", como la refactorización de códigos o la reestructuración, que no avanza directamente a uno de los requisitos funcionales pendientes.

Definitivamente una observación digna de mención; Mi solución a esto sería la siguiente:

Realizar revisiones regulares de código. Cada revisión de código debe recomendar acciones para mejorar las deficiencias en el código.
Ahora hay un requisito para los trabajos que mejoran la calidad del código. Incorpore estos en el sprint y sígalos de la misma manera que en cualquier otro trabajo.

Si su administrador necesita algo más convincente, emita "el mantenedor" como usuario, y describa algunas historias de usuario para ellos, y luego las "características" son cosas como "el código está completamente comentado con comentarios de doc XML" y "el código no producir cualquier advertencia de ReSharper ''

Creo que hay razones justificadas para justificar la refactorización de la deuda cuando el impacto del esfuerzo / costo de mantener el código es tan alto o incluso más alto que el costo de refactorizarlo para mejorar la calidad o trabajar mejor / adecuadamente, específicamente para otorgar préstamos Es un mayor grado de mantenibilidad.

por ejemplo: si el software es tan problemático que está perdiendo clientes o dinero, actuaría rápido para solucionarlo. Algunos podrían argumentar que esto es un requisito comercial propio, pero a menudo no se coloca al frente y al centro de pequeño a medio proyectos de desarrollo de gran tamaño, que en su lugar se centran en los aspectos técnicos de la creación de aplicaciones en lugar del impacto de la calidad de la aplicación en el resultado final.

Creo que probablemente está hablando de refactorización a gran escala en lugar de refactorización continua que haría durante todo el ciclo de refactor rojo-verde.

Mi enfoque sería algo como esto, si reafirmar una característica antigua hace que sea más fácil agregar una nueva característica, entonces siga adelante y hágalo. Pero de alguna manera, tiene razón, si no hay presión sobre una unidad en particular para cambiar (es decir, está completamente terminada y nunca volverá a cambiar y nunca impactará en otros módulos), entonces no hay necesidad práctica de refactorizar. Sin embargo, rara vez encuentro un módulo que esté tan finalizado.

No creo que esto tenga tanto que ver con Scrum como con la filosofía de gestión de proyectos.

Independientemente de si un proyecto usa Scrum o no, a muchos gerentes de proyectos no les gusta que los desarrolladores dediquen tiempo a cosas "innecesarias", como la refactorización de códigos o la reestructuración, que no hacen avanzar directamente uno de los requisitos funcionales más destacados. No es el "trabajo que produce resultados" como el desarrollo normal, es el "trabajo que evita el retraso de los resultados más adelante". Dados los plazos típicamente cortos utilizados para los Sprints, el beneficio es a menudo difícil de ver y casi imposible de cuantificar.

Mantener el código mantenible debe ser un elemento de su lista de quemados (si utiliza un Scrum). Es tan importante como el nuevo desarrollo. Si bien puede que no parezca 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.

Todo es cuestión de gestión / filosofía. En lugar de considerar las mejoras de refactorización y mantenibilidad como un trabajo "adicional" que no afecta a los clientes, debe considerarse como una inversión de tiempo para evitar retrasos visibles (y también posibles errores) en el futuro. Los desarrolladores a veces pueden ver estos beneficios más claramente que los gerentes; Si su administrador no comprende las desventajas de descuidar la capacidad de mantenimiento, es posible que desee tomar otros desarrolladores y conversar con su administrador.

Si puede justificarlo como parte del proceso de completar otras tareas identificando problemas / riesgos con los conjuntos actuales de código, y es un mejor resultado final, hágalo. Pero no se entusiasme demasiado y arruine las líneas de tiempo / presupuesto.