archivo

Archivos diarios: noviembre 20, 2012

En el artículo de ayer analicé el tratamiento de las incidencias en un enfoque iterativo incremental cuando las mismas se han detectado en el entorno de producción y se está trabajando en un sprint. En este voy a analizar el tratamiento de las incidencias que aparecen como consecuencias del trabajo que se está realizando en la iteración.

Estas incidencias pueden tener una doble naturaleza: ser resultado de actividades de la iteración (se desarrolla un componente o una pantalla y no funciona bien, se producen efectos colaterales, etc…) o bien ser el resultado de descubrir bugs no relacionados directamente con el sprint y que se han detectando haciendo tareas de testing sobre elementos del sprint.

Como en el caso anterior, resulta complicado dar una receta (no hay tallas únicas).

Mi opinión es que si las incidencias son sobre tareas de la iteración se deben corregir en la iteración, siguiendo el objetivo de que el producto resultante del sprint debería estar en disposición de ser entregado (pasarse a producción), de lo contrario no estamos terminando adecuadamente las historias de usuario y estamos huyendo hacia adelante empujando estas incidencias a futuras iteraciones.

Si las incidencias son externas a la iteración tenemos que evaluar el contexto en el que nos encontramos, es decir, ¿la resolución de la incidencia es sencilla y no impacta en el sprint?, se abordaría sin más, en caso contrario, ¿hay una línea de trabajo dedicada a resolver incidencias? Si la respuesta es afirmativa se crearía una entrada en la pila de tareas pendientes de ese equipo, ¿no existe esa línea?, ¿es crítica? el equipo tendrá que decidir (consultando al product owner) si la trata en la iteración, lo normal es que así sea, lo cual provocará probablemente que alguna tarea de las previstas para el sprint no se lleve a cabo (de ahí la necesidad de informar al responsable funcional).

Anuncios