lunes, 14 de marzo de 2011

Una Solución pre-Scrumban (II) / A pre-Scrumban Solution (II)



Como mencioné en el anterior post, voy a hablar un poco más del método pre-SCRUMBAN que he utilizado en proyectos anteriores.

Una variación era la de tener solamente 1 o 2 miembros de equipo con tareas Must y Should. Es decir, tener sólo a máximo un par de miembros como responsables de solucionar las incidencias de producción y otros problemas durante un Sprint. Normalmente, en nuestro equipo teníamos para ello a un perfil de desarrollador y a otro de testeador. A estos perfiles les llamábamos "Production Incidents Champion". Con el nombre, resaltábamos que sólo se solucionaban problemas de producción; es decir, el tipo de problemas en los que el tiempo de respuesta no puede ser de un Sprint y pico. El tiempo que se podía pasar en estas incidencias, como expliqué en el anterior post, venía predefinido con el número de story points de desarrollo que poníamos como Should.

Algunas ventajas de hacerlo así eran:
  • Seguíamos con la filosofía SCRUM de tener equipos multidisciplinares, pues durante el Sprint al que le tocaba ser "Champion" debía solucionar las incidencias del producto, hablando con quien fuese necesario si no tenía los conocimientos suficientes.
  • No "quemábamos" al equipo. Según mi experiencia, a la gente no le gusta mucho el rol de "Production Incidents Champion". Algo bastante lógico, por otra parte: generalmente ¡significa pelearse con problemas de solución difícil y urgencia muy alta! Rotando la figura entre los miembros del equipo, la carga se hacía más llevadera.
  • Se distraía menos la dinámica de desarrollo del grupo en general. La mayoría continuaban trabajando en nuevos desarrollos "olvidándose" de los incidentes de producción durante los Sprints en los que no estaban nominados como "Production Incidents Champion".
Otro "refinamiento" del método consistía, después de varios Sprints utilizándolo, medir el tiempo real que se pasó resolviendo incidencias, hacer estadísticas y después ajustar con ellas el tiempo de soporte que se acordaba para un Sprint.

Idealmente, el tiempo medio debía ser menor al tiempo máximo que se había destinado = el número de story points marcados como Should. Se habían dado algunos casos de incidencias muy peliagudas, de difícil resolución, que se habían "comido" algunas horas de Must, pero en general el "Production Incidents Champion" realizaba todos sus Must (su Commitment), algunos Shoulds y resolvía alguna incidencia.

Finalmente, otra variación con la que jugamos era la de introducir Coulds. Las tareas Could eran una alternativa a "tomar las siguientes en el Product Backlog", por si algún miembro del equipo acababa su trabajo antes de la finalización del Sprint. No suponían una gran ventaja respecto al método tradicional, solamente que ya las estimábamos y asignábamos de antemano (planning poker).

No hay comentarios:

Publicar un comentario