Desarrollo de software. Sprints e implicación

No es lo mismo hacer sprints sobre productos consolidados o basado en modificaciones leves o moderadas sobre funcionalidades ya implementadas, que los primeros sprints relacionados con el desarrollo del sistema, con el desarrollo de una nuevo subsistema o con modificaciones sensibles de su funcionalidad.

La diferencia es el esfuerzo que hay que dedicar para preparar el siguiente sprint, para tener esa materia prima necesaria para que la maquinaria no pare.

Ese esfuerzo se realiza en paralelo con el sprint en curso por lo que es necesario tener en cuenta ese aspecto a la hora de estimar la velocidad de desarrollo si hay personas del equipo que participan en la obtención de la materia prima, ya que no se debería contabilizar una dedicación del 100% de las mismas al sprint.

De lo contrario estas personas tendrán una dedicación superior al 100% en la iteración y la consecuencia de esto es el overtime y la imposibilidad material en determinadas circunstancias de atender a demandar ya sea del propio desarrollo o de la preparación del siguiente sprint.

Trabajar con sprints requiere una gran implicación porque se trata de una maquinaria que no para: termina un sprint y empieza el siguiente, se trabaja en un sprint mientras se prepara el siguiente. Estas condiciones no la aguantan todos los responsables funcionales (el equipo de proyecto, como comentaba antes, sí que puede si modula bien los esfuerzos) y es una de las circunstancias que hacen complicada la puesta en marcha de este tipo de enfoques.

Si el responsable funcional, product owner o como lo queramos llamar no se implica, no entiende esta dinámica de trabajo o sencillamente no puede dedicar el tiempo necesario a esto se rompen las reglas del juego y obligará a enfocar el proyecto de otra manera.

¿Por qué? No tendremos la materia prima necesaria para el siguiente sprint, ¿alternativas? parar el desarrollo por sprints o reducirlo a lo que se pueda abordar con la materia prima disponible y pactar con el responsable funcional un tiempo para seguir definiendo funcionalidades del sistema, ¿es esto volver a lo de antes?, ¿es esto volver al enfoque clásico?, no es así exactamente ya que el enfoque sigue siendo iterativo incremental, lo que sucede es que se pierde el ritmo de desarrollo que tienen los sprints y como consecuencia se disminuye la velocidad con que se agrega valor al producto y la capacidad de adaptación al cambio.

Anuncios

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: