Cómo lidiar con Bugs y problemas críticos, no planeados, que ingresan en el medio del sprint o release?

Siempre es molesto cuando algo surge fuera del plan y el equipo debe arreglarlo o administrarlo dentro del Sprint. Desafortunadamente, debemos lidiar con la imprevisibilidad. Sin embargo, siempre es bueno analizar por qué tuvimos que lidiar con esas molestias.

Qué se puede considerar una molestia en esto contexto? En mi opinión, podemos considerar los errores críticos o solicitudes de cambio no planificadas, que recibimos durante el sprint o release y somos forzados a integrarlo o corregirlo dentro del sprint.

En este post, abordaremos, de manera genérica, algunas razones para esto y, si esto sucede, quién lo reportará en el backlog y qué otras medidas debemos considerar para mantener el sprint a una velocidad estable.

Qué se puede llamar molestias?

En una publicación anterior (Bug, cambio de requisitos y el dilema del PO) definí qué son errores o defectos y cuáles son las solicitudes de cambio o los requisitos de cambio.

Así que esencialmente las molestias son errores y cambio de requisitos inesperados. Los cambios de requisitos forman parte del proceso normal de evolución del producto. Se puede considerar un signo de ineficiencia si, con cierta frecuencia, observamos la introducción de cambio  de requisitos durante el sprint, nuevas user stories no planificadas para la implementación cuando el sprint ya se está ejecutando y / o el alcance de la release ya está acordado. Es aún más crítico si se refiere a cambios radicales en el diseño de la función, que probablemente impacten sobre diferentes componentes.

Esto es seguro un escenario molesto para cualquier equipo de desarrollo. Trae ineficiencias de planificación en la propiedad del producto o los niveles arquitectónicos.




Quién puede identificarlos?

Yo diría que, idealmente, los errores pueden ser identificados por los administradores de testes o test managers ejecutando múltiples técnicas de prueba. Siempre es malo cuando el usuario identifica un error por primera vez. Se muestra una mala garantía de calidad en el producto. A menudo, los errores son escritos también por usuarios clave (Key users), todo el Dev Team, incluidos Product Owner y Scrum Master, también pueden identificar e informar de errores en el backlog. Y pueden venir también de una línea de soporte al usuario. Este será un tema para una próxima publicación, el flujo de trabajo para informar y resolver un error en varios niveles de soporte de usuarios. Este tema es particularmente interesante en un contexto DevOps.

A menudo, un cambio de requisito no planificado introducido como se describe en las líneas anteriores, puede representar una solución para eludir las dependencias, dependencias que no permitiran que el producto se despliegue como se diseñó inicialmente. En esta situación, observamos al arquitecto y el equipo de desarrollo trabajando juntos para construir rápidamente una opción resumida para entregar la funcionalidad. A veces no es la solución más eficiente, pero se implementa concienzudamente como una solución que debe solucionarse tan pronto como se resuelva la dependencia.

Cómo deberíamos reportar esos errores en el backlog?

Cuando se informa de un bug en el backlog, es extremadamente importante una buena descripción: nivel de gravedad, frecuencia, cómo podemos repetir la ocurrencia, capturas de pantalla, etc. Esta descripción completa facilita el esfuerzo del test manager para reproducir el error, y se agregará a la tarea una descripción técnica completa del error con otro tipo de información, como registros del servidor, mensajes del navegador, etc. Todas estas tareas tienen un único objetivo: hacer más fácil y rápido la resolución del bug por parte del Equipo de Desarrollo.

Los cambios de requisitos funcionales son normalmente escritos por el ingeniero de usabilidad (UX – User Experience) o por el Product Owner, que resumen la voz del cliente o introducen funciones innovadoras, mejoran los flujos de trabajo para ejecutar funciones, etc. Los requisitos no funcionales, normalmente los escribe el Equipo de Desarrollo, a menudo también por el arquitecto que tiene La función explícita de buscar permanentemente mejoras arquitectónicas.

Un cambio de requisitos también puede ser un nuevo requisito de seguridad o un requisito de calidad o una obligación legal que nos obliga a adoptar cambios estructurales en el producto (por ejemplo, todas las leyes de privacidad de datos). En este caso, tenemos requisitos no funcionales y deben ser escritos por el arquitecto o por un miembro senior del equipo de desarrollo. Pero esta es la manera saludable en que los cambios de requisitos entran en el backlog! Esas no son molestias.




Cómo debe lidiar el equipo con estas molestias introducidas en el medio del sprint?

En mi opinión, aquí ingresa las habilidades de negociación del Scrum Master para proteger al equipo: si algún esfuerzo no planificado ingresa en el sprint, el esfuerzo equivalente ya planeado debe abandonar el sprint. Qué es exactamente una discusión que debe ser moderada por Scrum Master, entre el equipo y el propietario del producto.