lunes, 24 de abril de 2017

Buffer de Capacidad para proyectos ágiles

En un contexto de proyecto con rigidez en los tres elementos del triángulo de hierro: alcance, plazo y costo, surge la necesidad de una planificación y seguimiento (más) cuantitativo. El enfoque ágil muchas veces es descartado en estos contextos por la creencia errónea que la planificación y el seguimiento ágil no generarán dicha información cuantitativa. Un enfoque ágil, impregnado de la filosofía Lean, evitará todos los elementos prescindibles en el proceso, con lo cual podría prescindirse de la recolección y el procesamiento de información cuantitativa, pero solo cuando ésta no se aproveche adecuadamente. Muchas veces se somete a los equipos a un registro y reporte de datos que no es rentabilizado ni por el equipo ni por los niveles de supervisión.

¿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):
  1. 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.
  2. Usar el Esfuerzo Restante establecido directamente (NO como la diferencia entre Estimación y Esfuerzo Invertido) y Capacidad. 
  3. 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).
  4. Usar Estimación, Esfuerzo Invertido y Capacidad del equipo usando Horas Ideales (horas de trabajo ininterrumpido, NO horas de contrato).
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 horas ideales de programación y va a abordar un proyecto cuyo esfuerzo total está estimado en 800 horas ideales de programación. Podríamos afirmar que a día de hoy (y respecto de las horas de programación) 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 horas ideales de programación. Si la Capacidad del equipo sigue siendo 200 horas ideales de programación 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 que puede estudiarse junto con la anterior es que en los requisitos más "grandes" se pueda 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 condsiderados 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 horas ideales de programación, con lo cual tendríamos un margen de 200 horas ideales de programación. Es decir, un proyecto que teóricamente podríamos terminar en 4 menos lo hemos planificado para 5 meses.

La siguiente figura ilustra la reducción ideal del esfuerzo restante durante un proyecto, la cual convergería a 0 al obtener la versión resultante del quinto Sprint. Como se observa en la figura más abajo (en la línea amarilla) si abordamos un alcance de proyecto equivalente a 800 horas ideales de programación con nuestra de 200 horas ideales de programación deberíamos terminar al final del cuarto Sprint.


Sin embargo, lo normal es que después de cada Sprint los cambios que surjan provocarán un repunte del esfuerzo restante. Si disponemos de un buffer de un tamaño adecuado podríamos asumir dichos cambios sin tener que cambiar los plazos ni renunciar a requisitos o cambios imprescindibles. La siguiente figura ilustra cómo con el buffer, y abordando los cambios que se detectan al final de cada Sprint, aun el proyecto llegaría a completarse en el tiempo previsto.

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, 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.

Otras lecturas relacionadas:




Patricio Letelier

No hay comentarios:

Publicar un comentario