Diferencia entre revisiones de «Interrupciones En Scrum»
| Línea 24: | Línea 24: | ||
*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint. | *'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint. | ||
| − | |||
====Atención de las interrupciones==== | ====Atención de las interrupciones==== | ||
Revisión del 13:44 28 ago 2008
El proceso de Scrum habla de tener un mínimo de interferencia durante el Sprint, de manera que los Miembros Del Equipo De Scrum puedan abocarse completamente al cumplimiento del objetivo del Sprint. El Scrum Master es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.
Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su Sprint, tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el Dueño Del Producto. De hecho, de poco le servirá al Dueño Del Producto que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.
Contenido
Tipos de interrupciones
Durante el proceso de Scrum pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el Sprint en curso. Estas interrupciones puede ser:
- Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
- Tareas de mantenimiento del sistema.
- Pedidos de investigación de comportamientos extraños en el sistema.
- Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
- Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.
Gestión de interrupciones
Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el Sprint?
Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.
- Usar dos Backlog: tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El Dueño Del Producto define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.
- Bugs como historias: se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El Dueño Del Producto luego las prioriza según sus necesidades, y elige acorde.
- Emergencias: son interrupciones que deben ser resueltas en forma inmediata. El Scrum Master y el Dueño Del Producto son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el Dueño Del Producto puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.
Atención de las interrupciones
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.
Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.
Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.
En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.
