Desarrollo de software. Incidencias e iteraciones I

En un enfoque iterativo incremental hay diversas formas de gestionar las incidencias. Vamos a considerar dos tipos de incidencias y las analizamos por separado: las que se producen sobre la aplicación en el entorno de producción y las que aparecen en la iteración en la que estamos trabajando.

En este artículo vamos a analizar el primer caso, en el artículo de mañana, el segundo.

En función de la criticidad e impacto de cada incidencia se puede decidir incluirlas en la pila de producto para ser tratadas en iteraciones sucesivas o bien trabajar con ellas dentro de este ciclo. En este segundo caso puede impactar sobre los objetivos del sprint porque las historias de usuario y tareas sobre las que se trabaja están adaptadas a la capacidad (velocidad) del equipo de trabajo y esas tareas de más implican que el equipo debe incrementar la velocidad para cumplir los objetivos, a veces se podrá (pero cuidado con la calidad de los resultados) y otras no será suficiente e implicará que alguno de los hitos de la iteración no se puedan ejecutar, salvo que se decida prolongar la duración del sprint.

No estoy hablando de metodologías concretas sino de un enfoque iterativo incremental y que cada cual lo gestione cómo crea que conviene mejor al proyecto y es mejor. Con respecto a retrasar la fecha de finalización del sprint yo no soy partidario, aunque en determinadas situaciones puede ser la mejor opción (no tenemos que encorsetarnos, nos debemos a los proyectos no a las metodologías).

Si se decide trabajar con incidencias dentro de este ciclo existe la posibilidad de tener una persona (o un conjunto de ellas) que se dediquen a corregir las mismas, “fuera” del equipo de personas que trabajan en el sprint. Lo pongo entre comillas porque perfectamente pueden ir rotándose con personal del equipo “principal” o ser parte de hecho de ese equipo principal pero no computarse su esfuerzo en la capacidad del equipo de trabajo (la rotación podría ser incluso dentro del mismo sprint).

El resultado del trabajo de estas personas podría sincronizarse con el sprint, conformar un sprint independiente o simplemente empaquetar incidencias corregidas y decidir el mejor momento para pasar a producción (sin sincronizarse con el sprint o adoptar un enfoque iterativo).

Estas personas podrían ayudar al equipo de desarrollo del sprint en caso de que no entrase suficiente carga de trabajo como consecuencia de incidencias.

Anuncios
1 comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: