jueves, 3 de noviembre de 2011

Gráficas Burndown: ¿cómo rentabilizar el esfuerzo asociado a su elaboración?


Este post es un resumen del artículo "Seguimiento ágil de proyectos de desarrollo de software utilizando Gráficas Burn Down", publicado por María Isabel Marante, Maria Company y Patricio Letelier en las JISBD 2011. Artículo completo disponible en: http://bit.ly/soy0fA

Las Gráficas Burndown han sido impulsadas por la metodología ágil Scrum, en la cual son el artefacto protagonista para el seguimiento de cada iteración. Una Gráfica Burndown muestra la evolución diaria del esfuerzo restante para finalizar el trabajo acordado con el cliente en cada iteración. Aunque esta gráfica parece a priori muy sencilla, para que su uso sea efectivo requiere superar los siguientes desafíos: estimar el trabajo, y  diariamente  recolectar y consolidar dichas estimaciones. Adicionalmente, para poder interpretar correctamente una Gráfica Burndown, es necesario contar con información complementaria respecto de eventos diarios tales como trabajo añadido o quitado del sprint, estimaciones faltantes, ajustes realizados a la estimación, etc. Las carencias en los aspectos mencionados están provocando que las Gráficas Burndown no se estén aplicando o no estén resultando tan efectivas como se espera. Este post ilustra cómo hemos integrado las Gráficas Burndown en la metodología y herramienta Tune-up, y cómo hemos superado los obstáculos antes indicados.

Tune-up ofrece una Gráfica Burndown para cada sprint de un producto o para un proyecto (un conjunto de unidades de trabajo que posiblemente se implementarán en deferentes sprints), junto con una tabla llamada Daily Events con información complementaria para la correcta interpretación de la gráfica. La siguiente figura muestra la gráfica Burndown de Tune-up (la tabla de eventos se explica en detalle más adelante).


La Gráfica Burndown de Tune-up incluye dos gráficas en una; una gráfica básica Burndown (asociada a la  línea  serpenteante descendente) y una gráfica Burn Up (asociada a la línea  ascendente  representando el esfuerzo invertido). Además, se incluye una línea  que  representa el esfuerzo estimado y una  línea  diagonal que  representa el esfuerzo restante de referencia (considerando una velocidad de proyecto constante). Al disponer en una misma gráfica los esfuerzos estimados, invertidos y restantes, se  facilita la interpretación del estado de la iteración y cómo se ha ido desarrollando. Situaciones tales como una bajada o subida pronunciada del esfuerzo restante podrían visualmente explicarse por una correspondiente bajada o subida en la línea de esfuerzo estimado, o bien en una subida o bajada en la línea de esfuerzo invertido. Sin embargo, la confirmación de estas interpretaciones, como veremos a continuación, exige contar con la información detallada de los eventos que pueden haber ocurrido entre dos puntos consecutivos de la gráfica. El esfuerzo restante de referencia corresponde a la línea que se traza desde el punto de mayor esfuerzo restante hacia el punto de esfuerzo restante 0 en el día de fin de la iteración. Además, asociada a esta línea se muestra en la parte inferior de la gráfica la velocidad requerida para conseguir la tendencia ilustrada por ese esfuerzo restante de referencia. Toda la información de la Gráfica Burn Down  puede ser filtrada por Actividad, WU (Work Unit, nombre dado al ítem de trabajo en Tune-up) y/o miembro del equipo.


La Tabla Daily Events de la figura anterior contiene los eventos diarios que permiten interpretar con precisión la Gráfica Burn Down. Haciendo clic en un punto de la Gráfica Burndown, se despliega dicha tabla con la lista de eventos ocurridos entre el día previo y el día seleccionado. Para cada evento se indica el miembro del equipo, la actividad e información de la WU donde se produce. En Tune-up se supervisan todos los eventos que pueden influir en la correcta interpretación del esfuerzo restante, dichos eventos se describen a continuación:

Eventos que invalidan la lectura del esfuerzo restante
  • Actividad con estimación sobrepasada. El esfuerzo invertido por el miembro del equipo en la actividad sobrepasa el estimado (lo cual llevaría a un esfuerzo restante negativo). El miembro del equipo asignado debería re-estimar.
  • Actividad sin estimación. La actividad no ha sido estimada, con lo cual la información global de esfuerzos está incompleta.
Eventos que provocan una variación en el esfuerzo restante observado
  • Cambios del esfuerzo invertido. El esfuerzo invertido se ha modificado. Por ejemplo, se había registrado 10 horas de trabajo pero luego se corrigieron cambiándose por 5 horas. 
  • Ajuste en Estimación. Incremento o Decremento de la estimación. Es imprescindible que cuando se prevea que la estimación no se cumplirá, inmediatamente se realice una re-estimación.
  • Introducción de estimación faltante. Indica que se ha estimado una actividad que el día anterior no tenía estimación.
  • Actividad asignada/desasignada  a/de un  miembro del equipo.  Esto es sólo  relevante cuando se trata de la Gráfica Burn Down filtrada con un miembro del equipo.
  • WU nueva. WU creada y añadida al sprint.
  • WU eliminada.
  • WU desestimada. Su esfuerzo restante se considera igual a 0
  • WU añadida. WU que se ha añadido al sprint (estaba en el backlog o en otro sprint).
  • WU quitada. WU que estaba el día anterior del sprint pero se ha llevado a otro sprint o al Backlog.
  • WU terminada. Su esfuerzo restante aunque no fue consumido del todo debe considerse igual a 0
Para ilustrar el uso de estos eventos en la interpretación de la gráfica veamos un ejemplo. La Gráfica Burn Down de la figura mostrada antes corresponde a la actividad Programación de la versión 0.2 de un determinado producto. En dicha gráfica, el día 20 de abril se observa un descenso pronunciado del esfuerzo restante. Este descenso, a priori lo podemos  asociar al descenso del esfuerzo estimado (observable en la línea verde de la gráfica). Pero cuestiones tales como: ¿por qué ha descendido el esfuerzo estimado?, ¿se ha movido, eliminado o desestimado trabajo?, ¿algún miembro del equipo ha ajustado alguna estimación?, no se pueden responder a simple vista. Para responder tales cuestiones es esencial la información de la Tabla  Daily Events. En la dicha tabla vemos los eventos asociados a la actividad Programación que ocurrieron el día 20 de abril; hubo un decremento en la estimación de la actividad Programación en 3 WUs y se han introducido 2 nuevas estimaciones que faltaban (en la tabla vemos que el día 19 de abril faltaba por estimar la actividad Programación en dichas WUs). De esta forma sabemos que el descenso del esfuerzo restante se debe a un decremento en la estimación de 3 WUs, aunque además se hayan incluido 2 nuevas estimaciones antes no consideradas.

El disponer de información detallada de lo realizado durante cada sprint, aporta información útil para reuniones de retrospectiva, pudiendo llegar a evaluar acciones de mejora en el proceso mediante la comparación de datos de diferentes sprints y su tendencia.

Pero, ¿esta forma de seguimiento detallada que pueden aportar las gráficas Burndown puede considerarse ágil?. La clave está en la automatización de su elaboración, presentación y apoyo para su interpretación. La automatización permite que el equipo se concentre en su trabajo y disponga de esta información sin tener que invertir esfuerzo adicional. Obviamente, el equipo tiene que estimar y registrar el avance del trabajo (o registrar directamente el trabajo restante). Se supone que el equipo habrá previamente evaluado la necesidad y conveniencia de llevar un seguimiento detallado, en lugar de prescindir de él y optar, por ejemplo, por solo centrarse en la generación de flujo, sin estimar ni registrar el progreso del trabajo, tal como sugiere el método Kanban. No tiene sentido pretender llevar a cabo un seguimiento detallado o incluso utilizar sprints, siendo que el contexto del producto o servicio no lo requiere o no ofrece condiciones adecuadas para poder llevarlo a cabo.


Patricio Letelier

linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com


No hay comentarios:

Publicar un comentario