Cuando llega el día de informar a la dirección de proyectos sobre el estado de un proyecto Ágil (Scrum).
En el transcurso de mi experiencia en la gestión de proyectos de desarrollo de software utilizando metodologías Ágiles (11 meses hasta la publicación de este artículo usando Scrum y Kanban) tengo que indicar que muchas veces nos centramos tanto en el trabajo diario con nuestro equipo de desarrollo que nos olvidamos que tarde o temprano tendremos que informar a la dirección sobre el estado de nuestro proyecto.
Antes de iniciar el proyecto, hay que tener en cuenta que necesitaremos una serie de métricas claras y medibles, de tal forma que luego no nos llevemos una sorpresa a la hora de generar los informes y tengamos que estar realizando el último día la engorrosa tarea de hacer «minería de datos» tal y como nos ha pasado a la gran mayoría. Mi recomendación es que utilicemos si es posible una herramienta, tanto para realizar el seguimiento de nuestro proyecto Scrum como para sacar las métricas necesarias, esto nos ayudará de forma muy significativa en la medición y en la posterior generación de los informes necesarios (podemos utilizar por ejemplo JIRA + Greenhopper de Atlassian que es una herramienta que yo he utilizado y que da muy buenos resultados)
Hay tres puntos claves según mi experiencia sobre los que tendremos que informar: Valor ganado (ya sea a nivel económico o a nivel de historias de usuario), el esfuerzo realizado/necesario para cumplir la fecha de fin de proyecto marcada y la realización de una Extrapolación (para ver donde apunta la finalización de nuestro proyecto).
- Valor ganado (Ev): porque nos va a indicar el avance actual del proyecto y si estamos por encima o por debajo de la línea optima de avance marcada.
- Esfuerzo, yo aquí lo divido en dos:
- Esfuerzo realizado hasta el momento, desglosado por periodos, puede ser por sprints, meses, etc… dependiendo del tamaño del proyecto.
- Y el esfuerzo necesario para alcanzar el objetivo de fecha fin de proyecto marcada.
- Extrapolación: a partir del valor ganado vamos a poder hacer una extrapolación en base al esfuerzo realizado y ver donde apunta la fecha de finalización de nuestro proyecto para ver si hay desviaciones.
Estos tres puntos para mí son claves para que de un vistazo podamos ver de una forma clara y simple el estado real del proyecto y lo más importante de todo, ver hacia donde estamos dirigiéndonos y poder tomar las decisiones necesarias lo antes posible.
Y como una imagen vale más que mil palabras,todos estos datos los represento utilizando dos gráficos: burn-up para representar el valor ganado junto con la extrapolación y un gráfico de barras para indicar el esfuerzo realizado/necesario.
A modo de ejemplo, aquí os dejo una muestra con los dos gráficos que utilizo:
Gráfico de Burn-Up. La línea morada representa el número de funcionalidades (historias de usuario) que tiene el proyecto. En este caso vemos que el número de Funcionalidades va cambiando conforme avanza el proyecto por lo que la fecha fin prevista va variando en función de las Funcionalidades que van entrando o saliendo del mismo. Esto es porque se trabaja cambiando a la vez que creamos, en un proyecto típico, el numero de historias de usuario generalmente siempre será el mismo. La línea verde representa el discurrir ideal, optimo del proyecto, es decir, alcanzaría el total de Funcionalidades realizadas en diciembre de este año, pero sin embargo, la realidad es distinta y la línea azul que representa lo que está desarrollado e instalado en producción, nos indica que nos hará falta parte del año que viene para terminar el proyecto ya que apuntamos a tener 158 historias de usuario en producción al final de año. En Octubre vemos que tenemos un Valor Ganado de 132. Basándonos en la velocidad de avance actual, al menos hasta Marzo del año siguiente no finalizaríamos el proyecto.
Gráfico con la velocidad de subida del proyecto (Esfuerzo). En azul se muestra el esfuerzo realizado mes a mes, en verde se muestra la línea que nos indica el ritmo óptimo y en Naranja se indica el esfuerzo que habría que realizar en los meses restantes para alcanzar el objetivo de finalizar el proyecto en diciembre.
Basándonos en los datos de los dos gráficos anteriores vemos que tenemos que tomar una serie de medidas si queremos que nuestro proyecto termine en la fecha indicada ya que todo apunta a que se va a producir una desviación importante en el mismo.
Para terminar este artículo, me gustaría indicar que este es mi pequeño grano de arena al uso de metodologías Ágiles en los proyectos, ni mucho menos he pretendido que sea una guía, sino que únicamente he querido contar mi experiencia en este mundo de las metodologías o marcos de trabajo Ágiles y que esto pueda servir a otras personas que como yo nos hemos introducido en este mundo de la gestión de proyectos ágiles.
Me gustaría recomendar a todas aquellas personas interesadas en aprender más sobre este tipo de metodologías y que además quieran conocer a gente interesante, que asistieran a la próxima convocatoria del encuentro CAS2012.
Para mí, tengo que decir, que fue todo un descubrimiento mi asistencia a la pasada reunión de la CAS2011 en Castellón donde me pude empapar aún más de este gran mundo de las metodologías ágiles.
Por supuesto cualquier crítica o petición de aclaración sobre cualquier parte del artículo será bienvenida.
Muy buen artículo, creo que esos indicadores son los más importantes con respecto a informes de avances. Gracias.
hola en cuanto al tutorial excelente tengo una pregunta has manejado epf eclipse
Hola buenas, este articulo es antiguo, pero la verdad necesito una orientación debo hacer unos gráficos de scrum tipo metodología agil, donde se refleja el esfuerzo del desarrollador respecto al tiempo que se toma para realizar los issues en el gitlab. Pero no me sale el gráfico…Alguien podría ayudarme.