¿El desarrollo ágil considera la necesidad de mantener características?

Si por mantenimiento te refieres a la corrección de errores, entonces no es diferente a la planificación de otras funciones en Sprint. Puede considerar el error como una característica y planificarlo en el siguiente Sprint. Así es como la planificación de Sprint debe hacerse idealmente.

Sin embargo, el mundo está lejos de ser ideal. Si está hablando de la situación en la que cualquier error debe tratarse con prioridad y eso afecta su Sprint planificado. Entonces no estás solo.

En este caso, puedo sugerirle una metodología alternativa, Kanban. Lee sobre ello. De hecho, algunos equipos implementan con éxito un enfoque Scrumban, que es una combinación de Scrum y Kanban.

El mayor beneficio de Kanban es que limita el trabajo en progreso (WIP) para evitar cuellos de botella. Y, a diferencia de Scrum, no hay un ciclo de sprint en caja de tiempo , por lo tanto, un flujo continuo. Las características / errores en la parte superior del trabajo atrasado del equipo se manejan tan pronto como un recurso está disponible, suponiendo que no se haya alcanzado WIP.

Funciona de maravilla para mantener a todos felices, incluidos Team y PO.

Verifique Kanban y Scrum: aproveche al máximo un minibook disponible de forma gratuita en PDF. Ofrece una excelente visión general de ambas metodologías.

En el “tiempo anterior”, el mantenimiento era algo que hacía debido a un cambio que no emanaba del cliente. Los ejemplos típicos de cosas que causan mantenimiento pueden incluir el trabajo que emana de un sistema operativo o actualización de utilidad, una actualización de una plataforma integrada o algo por el estilo. Generalmente se considera “valor neutral” porque se trata más de prevenir una degradación del valor del producto, en lugar de un aumento del valor del producto.

A menudo, el mantenimiento se realizaba en un “expediente” o “lista de tickets” que estaba separado del cronograma de lanzamiento de entrega orientado al “proyecto” principal. Los equipos ágiles, al definir pequeñas características o historias, han hecho que la entrega funcional se parezca más a esto, y no al revés, por lo que el mantenimiento no necesita un “tiempo” especial para adaptarse a la otra actividad.

Lo que los equipos ágiles han hecho normalmente es incorporar sus “historias de mantenimiento” en una versión, que puede estar en una rama separada o en un equipo separado o en una versión separada de las “características”. Esto a menudo es necesario debido al lugar de donde proviene el mantenimiento: otro equipo, otro proyecto, otro cliente. Sin embargo, desde una perspectiva de planificación, no importa. El mantenimiento aún funciona, todavía cambia la base del código y las actividades requeridas siguen siendo las mismas.

Otras cosas que parecen mantenimiento son cosas que ahora generalmente están automatizadas, como la actualización de los índices de la base de datos y la actividad de archivo / purga, o la limpieza de archivos de registro antiguos, que una vez fueron realizados por los desarrolladores, pero ahora generalmente se realizan mediante scripts y herramientas. Incluso he observado algunos equipos que utilizan arneses de prueba en entornos de producción para activar algunas de estas actividades.

Mi conclusión es que a la planificación le importa menos de dónde proviene el trabajo que quién lo hace, cuándo debe hacerse y cómo afecta a otro trabajo en progreso o en el plan. El mantenimiento es solo otro tipo de trabajo que debe ser secuenciado y dotado de recursos.

“mantenimiento de características” puede considerarse evolución de características; Una característica evoluciona en 2 aspectos:

1. Se agrega más profundidad, opciones o máscaras mejoradas (o se eliminan por simplicidad)
2. errores o problemas corregidos

y ambos son esencialmente más historias que se pueden procesar en cualquier iteración o sprint posterior; y se discuten, priorizan, estiman, cortan y planifican.