¿De qué información cuantitativa estamos hablando?. Esencialmente necesitamos tres elementos: la Estimación del Esfuerzo del trabajo, el Esfuerzo ya Invertido y la Capacidad del equipo que ejecuta el trabajo. Un cuarto elemento derivado de lo anterior es el Esfuerzo Restante = Estimación de Esfuerzo - Esfuerzo ya Invertido.
Dependiendo de las necesidades de gestión de una determinada línea de trabajo, desde una perspectiva ágil podría ser válido y eficaz cualquiera de los siguientes niveles de gestión (desde el más simple al más exigente):
- Centrarse solo en la generación de un buen flujo de trabajo terminado, SIN usar Estimación NI Capacidad. En esta opción probablemente no se utilizarían Sprints pues su uso conlleva de forma natural alguna de las otras opciones que se plantean a continuación.
- Usar el Esfuerzo Restante establecido directamente (NO como la diferencia entre Estimación y Esfuerzo Invertido) y Capacidad.
- Usar Estimación y Capacidad del equipo usando como unidad Puntos (u otra medida similar que represente el tamaño de las unidades de trabajo de forma global).
- Usar Estimación, Esfuerzo Invertido y Capacidad del equipo usando Horas Ideales (horas de trabajo ininterrumpido, NO horas de contrato). Al trabajar con Horas Ideales debemos indicar de la actividad que se trata, por ejemplo, Horas Ideales de Programación (HIP).
Excepto en la opción 1, en las otras tres sería posible responder cuantitativamente la pregunta ¿llegaremos a cumplir el compromiso de alcance-tiempo-costo? En 2, 3 y 4 el equipo conoce su Capacidad y puede con ello calcular a partir de cualquier día del proyecto cuánto trabajo puede abordar desde ese momento hasta el final del proyecto. Además, el equipo puede también conocer en cualquier día del proyecto cuánto es el esfuerzo necesario para abordar el trabajo restante. Por ejemplo, supongamos un equipo tiene una Capacidad mensual de 200 HIP y va a abordar un proyecto cuyo esfuerzo total está estimado en 800 HIP. Podríamos afirmar que a día de hoy (y respecto de las HIP) parece factible realizar dicho proyecto en 4 meses (4 * 200 = 800). Supongamos que más adelante, finalizando el segundo mes del proyecto comprobamos que el trabajo restante es de 500 HIP. Si la Capacidad del equipo sigue siendo 200 HIP por mes, concluiríamos que en ese momento que con esa Capacidad no podríamos terminar el proyecto en dos meses.
Haríamos un razonamiento similar al usar Puntos en lugar de Horas Ideales, es decir, comparando el Esfuerzo Restante respecto de Capacidad disponible, pero en este caso ambos datos medidos en Puntos (es una medida del tamaño de las unidades de trabajo, medida relativa a una unidad de trabajo usada como referencia).
Hasta aquí todo claro y de muy sencillo cálculo. Pero ¿qué pasa con los cambios que se presenten durante el proyecto y que conlleven un aumento del esfuerzo total asociado al proyecto?. La primera solución sería negociar oportunamente con el cliente una reducción de alcance del proyecto para conseguir una reducción de esfuerzo equivalente a los cambios que han surgido. Como no todos los requisitos son igual de importantes o esenciales, el cliente podría postergar aquellos requisitos relativamente prescindibles (dejándolos fuera del alcance del proyecto). Otra posible opción incluso más recomendable es estudiar si en los requisitos más "grandes" se puede hacer una reducción estableciendo una parte como primera versión (y dentro del alcance del proyecto) y el resto como un trabajo postergado fuera del proyecto. Sin embargo, puede que el cliente llegue a un punto en el cual ya no está dispuesto a reducir más el alcance del proyecto, y que tampoco sea factible aumentar los plazos/costos del proyecto. Para evitar esta situación límite sabemos que en proyectos en los cuales se presentarán cambios es conveniente tener una determinada holgura. A continuación veremos una forma ágil de establecer y gestionar dicha holgura.
En un proyecto gestionado de forma ágil deberían descubrirse tempranamente los cambios especialmente los de gran impacto pues en los primeros Sprints nos preocuparemos de abordar el trabajo más importante y valioso para el cliente, así como aquello que pueda conllevar mayor riesgo. Además, se asume que al revisar cada versión resultante de un Sprint se detectarán cambios, asociados a fallos o mejoras que probablemente deban ser considerados dentro del alcance del proyecto. Así pues, con las reuniones de revisión al final de cada Sprint y con las entregas frecuentes se fuerza desde el comienzo del proyecto la aparición de esos posibles cambios. Pero la solución (fácil) no siempre podrá ser quitar o reducir el alcance del proyecto.
Un buffer nos permitirá abordar los cambios sin que ello suponga reducir el alcance de un proyecto durante su ejecución (y manteniendo su costo y plazo). La idea es sencilla, al planificar el proyecto reservar un porcentaje de la Capacidad del equipo para los eventuales cambios. Por ejemplo, si reservamos un 20% de Capacidad para dicho proyecto de 4 meses lo abordaríamos como si se tratase de un proyecto de 1000 HIP, con lo cual tendríamos un margen de 200 HIP. Es decir, un proyecto que teóricamente podríamos terminar en 4 meses lo planificamos para 5 meses.
La siguiente gráfica Burndown ilustra la reducción ideal del esfuerzo restante (línea naranja) durante un proyecto. Se comienza con el esfuerzo restante total de 800 HIP y a a medida que avanza el tiempo del proyecto se esperaría que el esfuerzo restante converja a 0 al final del cuarto Sprint.
Otras lecturas relacionadas:Haríamos un razonamiento similar al usar Puntos en lugar de Horas Ideales, es decir, comparando el Esfuerzo Restante respecto de Capacidad disponible, pero en este caso ambos datos medidos en Puntos (es una medida del tamaño de las unidades de trabajo, medida relativa a una unidad de trabajo usada como referencia).
Hasta aquí todo claro y de muy sencillo cálculo. Pero ¿qué pasa con los cambios que se presenten durante el proyecto y que conlleven un aumento del esfuerzo total asociado al proyecto?. La primera solución sería negociar oportunamente con el cliente una reducción de alcance del proyecto para conseguir una reducción de esfuerzo equivalente a los cambios que han surgido. Como no todos los requisitos son igual de importantes o esenciales, el cliente podría postergar aquellos requisitos relativamente prescindibles (dejándolos fuera del alcance del proyecto). Otra posible opción incluso más recomendable es estudiar si en los requisitos más "grandes" se puede hacer una reducción estableciendo una parte como primera versión (y dentro del alcance del proyecto) y el resto como un trabajo postergado fuera del proyecto. Sin embargo, puede que el cliente llegue a un punto en el cual ya no está dispuesto a reducir más el alcance del proyecto, y que tampoco sea factible aumentar los plazos/costos del proyecto. Para evitar esta situación límite sabemos que en proyectos en los cuales se presentarán cambios es conveniente tener una determinada holgura. A continuación veremos una forma ágil de establecer y gestionar dicha holgura.
En un proyecto gestionado de forma ágil deberían descubrirse tempranamente los cambios especialmente los de gran impacto pues en los primeros Sprints nos preocuparemos de abordar el trabajo más importante y valioso para el cliente, así como aquello que pueda conllevar mayor riesgo. Además, se asume que al revisar cada versión resultante de un Sprint se detectarán cambios, asociados a fallos o mejoras que probablemente deban ser considerados dentro del alcance del proyecto. Así pues, con las reuniones de revisión al final de cada Sprint y con las entregas frecuentes se fuerza desde el comienzo del proyecto la aparición de esos posibles cambios. Pero la solución (fácil) no siempre podrá ser quitar o reducir el alcance del proyecto.
Un buffer nos permitirá abordar los cambios sin que ello suponga reducir el alcance de un proyecto durante su ejecución (y manteniendo su costo y plazo). La idea es sencilla, al planificar el proyecto reservar un porcentaje de la Capacidad del equipo para los eventuales cambios. Por ejemplo, si reservamos un 20% de Capacidad para dicho proyecto de 4 meses lo abordaríamos como si se tratase de un proyecto de 1000 HIP, con lo cual tendríamos un margen de 200 HIP. Es decir, un proyecto que teóricamente podríamos terminar en 4 meses lo planificamos para 5 meses.
La siguiente gráfica Burndown ilustra la reducción ideal del esfuerzo restante (línea naranja) durante un proyecto. Se comienza con el esfuerzo restante total de 800 HIP y a a medida que avanza el tiempo del proyecto se esperaría que el esfuerzo restante converja a 0 al final del cuarto Sprint.
Sin embargo, la línea roja ilustra una evolución más real del esfuerzo restante en un proyecto en el cual surgen cambios, particularmente detectados en las reuniones de revisión al finalizar cada Sprint. Como se observa, al final de cada Sprint es normal que aparezcan "flecos", es decir, nuevas UT que representan pequeñas mejoras e incluso fallos.
Si no contamos con holgura nos veríamos obligados a negociar constantemente con el Product Owner buscando una reducción de alcance, extensión de plazos y/o aumento de costos. Previendo esos usuales "flecos" podemos establecer un buffer de Capacidad/Tiempo que nos permita abordarlos y reservar las negociaciones para cambios que sean más significativos. Así, volviendo al ejemplo de antes, en la siguiente figura se ilustra el mismo proyecto, pero ahora planificado a 5 meses, con lo cual contamos con un buffer de Capacidad/Tiempo de un 20%, ya que conseguimos una Capacidad disponible de 1000 HIP mientras el esfuerzo inicialmente previsto es de 800 HIP.
El buffer es del proyecto como un todo, no se debería establecer un buffer para cada unidad de trabajo ya que lo usual es que las diferencias entre los esfuerzos reales invertidos y los estimados de unas y otras unidades de trabajo se anulen entre sí en cierta medida. Es decir, finalmente en algunas unidades de trabajo se requiere más esfuerzo del estimado inicialmente y en otra menos. El buffer global debería cubrir la desviación de forma más eficiente que si cada unidad de trabajo tuviese su propio buffer.
Finalmente, podría pensarse que actuando de esta forma no habría mucha diferencia con respecto a un proyecto gestionado de forma tradicional en el cual también se establezca un buffer. Pero la diferencia existe y es significativa, en un proyecto tradicional se tienen muy pocas o ninguna evidencia del consumo del buffer hasta que el proyecto está muy avanzado pues precisamente los cambios tienden a detectarse al final del proyecto, donde se concentran las actividades de pruebas.
- ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?
- "Seguimiento ágil: Dashboard global para contextos multi-proyecto".
- "7 diferencias entre una planificación tradicional y una ágil"
- "Estimación en un proyecto ágil, Parte I: Una estrategia pragmática"
- "Estimación en un proyecto ágil, Parte II: Algunas diferencias respecto de estimación tradicional"
Patricio Letelier
No hay comentarios:
Publicar un comentario