¿Cómo incluye el soporte en su Sprint?

Nuestra compañía se mudó a Scrum recientemente con un producto que fue casi codificado por una sola persona (Joe). Tenemos apoyo para hacer con nuestros clientes existentes que intentamos integrar en nuestro proceso.

Por ahora probamos el siguiente enfoque:

• Hacemos una rotación con una persona a cargo cada semana.
• La persona a cargo de la semana puede pasar hasta 8 horas en soporte.

Pero no logramos que funcione:

• Joe siempre hace el soporte porque conoce mejor el código, y siempre es más rápido para él que explicarlo.
• Nosotros (el resto de nosotros) tendemos a centrarnos en lo que está en el tablero de Sprint, también conocido como nuevas historias, en lugar de tareas de soporte.
• Joe tiene demasiado trabajo, no puede manejar todo el apoyo solo porque tiene que hacer cosas fuera del Sprint también.

¿Ya te has enfrentado a una situación similar? ¿Cómo lograste salir de eso?

Nota: No podemos dedicar una sola persona al soporte en este momento. Esperamos que en el futuro.

Adoptamos un enfoque muy similar al designar un "Programador de soporte" que rotaba entre los desarrolladores más jóvenes (o más nuevos) del equipo. Se les alentó a intentar realmente resolver el problema antes de preguntar a los otros desarrolladores, incluso si sería más rápido echarlo al desarrollador que mejor conocía el código. De esta manera, se vieron obligados a aprender la base de código y evitó noquear a la gente de "la zona" y destruir la productividad. Además, debe incorporar algún mecanismo para evitar que las personas hagan un cambio a los programadores que no son de soporte para que esto funcione.

Un punto clave es que el equipo necesita comprender que lo que puede ser la forma más rápida de cerrar los problemas de soporte no siempre es el uso más eficiente del tiempo del equipo. Asegúrese de que todo el equipo sepa que el objetivo de esta estructura es minimizar las interrupciones a las personas que están en ese modo productivo a toda costa.

Dicho esto, el programador de soporte no estaba 100% dedicado a las llamadas de soporte. Trabajaron en casos en el sprint, pero se suponía que debían trabajar en los elementos de menor prioridad para que si se quedaban atrapados en muchos problemas de soporte, el hecho de que no terminaron sus casos no sería una preocupación tan importante. .

¿Cómo incluye ir al baño en su Sprint? ¿Cómo incluye el tiempo que los desarrolladores pasan en casa jugando con sus hijos? ¿Qué hay de incluir el tiempo para dormir?

Estoy siendo sarcástico, por supuesto, la respuesta es que en mi humilde opinión, no debe incluir el tiempo de soporte en su planificación de sprint. El único momento que debe incluirse en su planificación de sprint son tareas directamente asociadas con los entregables de sprint.

Si un recurso va a dedicar tanto tiempo al soporte, entonces tiene menos horas de recursos disponibles de ese desarrollador, ese sprint. El conjunto de características incluido en ese sprint debe reflejar este hecho.

Creo que lo más simple es agregar sus actividades de soporte directamente a la lista de elementos incluidos en su sprint. Si estas actividades de soporte son correcciones de errores, se priorizarán en su cartera de pedidos de la misma manera que lo hace para las mejoras. Si se basan en el tiempo (como ejecutar informes de fin de mes), estos también se pueden programar fácilmente. Esto es lo que hacemos y funciona bien.

En mi opinión, hay dos tipos diferentes de trabajo de "apoyo". El primer tipo es una emergencia que debe arreglarse AHORA. Es realmente más trabajo de tipo operativo, cosas de lucha contra incendios que realmente no se pueden planificar y estimar como parte de un sprint. El segundo tipo es un informe de error, que se estima, prioriza y planifica en un sprint. Se trata como cualquier otra historia. A menudo, el primer tipo dará como resultado el segundo tipo; apagará el fuego y creará un informe de error para hacer una solución real para que no vuelva a suceder. Para el resto de esta publicación, estoy hablando de lo primero: trabajo de emergencia no planificado que debe hacerse AHORA.

Dedicar tiempo al equipo para hacer trabajo de apoyo reduce la velocidad del equipo. Deberías usar tu velocidad histórica para determinar tu capacidad para el próximo sprint. El cambio de contexto requerido para pasar del trabajo de lanzamiento al trabajo de soporte significa que hay algo de sobrecarga, pero dado que el trabajo que realiza para un sprint debe tener en cuenta la cantidad de trabajo que históricamente realiza en un sprint, la cantidad de tiempo típica pones en soporte, y la sobrecarga de cambio de contexto, debe tenerse en cuenta automáticamente.

No considero que esto sea trabajo de sprint. Está separado y debe priorizarse por encima del trabajo de sprint. Por lo tanto, se come la velocidad del equipo y se "planifica" al usar esa velocidad reducida al decidir cuánto trabajo se puede hacer durante el próximo sprint.