Mi equipo de 4 personas maneja directamente la mayoría de los tickets técnicos, con un SLA de 8 horas a 24 horas de oficina , lo que significa que durante un sprint debemos agregar estos tickets en la parte superior de nuestra acumulación de sprint actual. Tenemos una persona dedicada que maneja los boletos comerciales y los problemas fáciles, sin embargo, no puede manejar preguntas/problemas específicos.
Estos tickets afectan en gran medida nuestra velocidad y desmoralizan a los miembros del equipo que no pueden medir su esfuerzo .
La mayoría de los tickets no son errores, son solo problemas relacionados con el producto, por ejemplo, recientemente desperdiciamos 3 días depurando un problema del cliente, para luego descubrir que era un módulo RAM roto.
¿Cómo puedo mantener al equipo motivado y medir la velocidad real sin romper el SLA?
Esto no es muy inusual. La mayoría de los equipos de desarrollo de software deben estar preparados para corregir los errores de producción con prioridad, si se informa alguno. También es bastante normal que los informes de errores deban evaluarse primero , aunque algunos de ellos pueden resultar no ser errores en absoluto. Sin embargo, su equipo parece tener más de ellos con SLA más estrictos.
Esto es lo que haré en tu situación:
Creo que puede encontrar interesante la lectura del siguiente artículo: Aplicación de Agile en un equipo de desarrollo de características mixtas y corrección de errores vinculado a SLA
Creo que tener un miembro del equipo dedicado que se ocupe de los tickets es una buena solución al problema del SLA. Al hacerlo, los otros tres miembros del equipo pueden mantener los sprints sin interrupciones .
A la mayoría de los desarrolladores no les gusta trabajar únicamente en problemas de soporte. Para evitar que la moral del "desarrollador de soporte" se vea afectada, ha elegido correctamente utilizar el principio de turno rotativo. Es prudente hacerlo por otra razón también. Sin rotación en esta tarea, muchos errores serán manejados solo por el mismo "desarrollador de soporte", y los desarrolladores restantes podrían comenzar a prestar menos atención a la calidad del código.
El "desarrollador de soporte" podría usar Kanban para resolver tickets de soporte y crear nuevos lanzamientos más rápido, sin tener que esperar al final de un sprint .
Ha escrito que a veces el "desarrollador de soporte" no puede manejar preguntas/problemas específicos por sí solo. Otra solución puede ser asignar tiempo para las entradas con antelación. Para saber más acerca de cómo puede reservar un porcentaje de su velocidad como un búfer de interrupción, puede echar un vistazo al patrón de Scrum conocido como " Illegitimus Non Interruptus ".
Si la velocidad de su equipo se ve afectada por los tickets, entonces es importante reflejar ese impacto en la planificación de su sprint. Hay al menos dos formas de hacerlo.
Opción uno: si no es posible asignar puntos de historia a los boletos, permita que su velocidad disminuya. No pienses en una velocidad reducida como algo malo. El propósito de la velocidad es ayudar a un equipo a comprender cuánto trabajo comprometerse dentro de un período de tiempo. Un equipo de baja velocidad que cumple con sus compromisos es preferible a un equipo de alta velocidad que es poco confiable en sus compromisos.
Opción dos: si es posible asignar puntos de historia a los boletos, cuente las finalizaciones de boletos para la velocidad del equipo. Presta atención al porcentaje de la velocidad del equipo que aportan los tickets de cierre. Al planificar un sprint (un nuevo período de trabajo), reserve una cantidad adecuada de capacidad para los tickets que el equipo espera encontrar durante el sprint. Por ejemplo, si la velocidad es 100 y los tickets aportan 40, entonces comprométase solo con 60 puntos de trabajo sin tickets. Durante el sprint, si el equipo completa el trabajo sin tickets y no recibe la cantidad esperada de trabajo con tickets, entonces el equipo puede incluir historias adicionales sin tickets en el sprint.
La opción dos es el enfoque preferible. Recuerde que el propósito de la velocidad es ayudar a los equipos, al planificar un sprint, a evitar comprometerse con más trabajo del que se puede completar durante un sprint. Una vez que se han cumplido los compromisos, siempre está bien que un equipo incorpore trabajo adicional a un sprint.
Como mencionó @Depressive_Bore, las respuestas sobre el mantenimiento del software probablemente le serán útiles.
Como se dijo anteriormente, este es un escenario general.
Dentro de nuestro equipo de 4 personas, tenemos un miembro del equipo dedicado para manejar los errores de producción. Su velocidad será cero para ese sprint (seguiremos el número de tickets que él/ella cerró). Este papel se lleva a cabo en forma de todos contra todos.
Los miembros restantes del equipo se tomarán como la velocidad para ese sprint.
Pruebas automatizadas.
Como observa, la mayoría de estos problemas no son errores y la mayor parte del tiempo trabajando en ellos es probablemente 'resolver cosas' en lugar de cambiar el código.
Aunque pueda parecer un problema de gestión de tiempo/recursos, en realidad su problema es tratar la atención al cliente como una serie de tareas técnicas que se agregarán a su sprint. ¡Los técnicos no tienden a ser los mejores chicos de atención al cliente!
Para evitar esto, necesita una prueba rápida y eficiente para decidir si el problema requiere un cambio de código para solucionarlo y, de ser así, cuáles deberían ser los requisitos de ese cambio.
Idealmente, un conjunto de pruebas automatizado determinará si el producto funciona según lo diseñado y se puede ejecutar antes y después de cada lanzamiento.
Pero también puede crear un conjunto de pruebas manuales escribiendo los pasos y el comportamiento esperado y las correcciones comunes cada vez que se informa un error. Una vez que tenga un gran conjunto de estos, se pueden entregar a un equipo de atención al cliente menos técnico para que los revise antes de escalar el problema.
Serguéi Kudryavtsev