No es nueva la necesidad de controlar de algún modo visual la evolución de nuestros proyectos. Desde tiempos inmemoriales se asume que una de las herramientas más interesantes son los diagramas, que nos permiten abstraer y sintetizar la marcha de un proyecto, subproyecto, …
El diagrama de Gantt, según la Wikipedia, es una herramienta gráfica cuyo objetivo es el de mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posición de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias. Es un diagrama hasta cierto punto ‘estandar’ y raro es el jefe de proyecto que lo desconoce por completo, con lo que tiene la ventaja de su integración con la mayorÃa de herramientas opensource y comerciales de gestión de proyectos.
El diagrama de Gantt muestra el origen y el final de las diferentes unidades mÃnimas de trabajo y los grupos de tareas (llamados summary elements en la imagen) o las dependencias entre unidades mÃnimas de trabajo.
Tienen una pinta similar a esta, aunque podemos encontrarlo en multitud de posiciones, colores, …:
Hasta aquà todo normal.
En las metodologÃas ágiles lo común es usar diagramas de burn-down asociados a los sprints para gestionar la marcha positiva o negativa de ese sprint (que por término medio dura unas tres semanas según los más puristas). Es posiblemente el diagrama por excelencia de las metodoloÃgas ágiles, aunque la realidad es que puede ser realmente poca información si se está acostumbrado a otros modelos de desarrollo o no se conocen las herramientas complementarias que se usan en desarrollos Scrum.
Un ejemplo de diagrama burn-down podrÃa ser el siguiente:
El punto que quizás me faltaba para engranar como gestionar el proyecto a largo plazo lo encontré en Navegapolis, a través del diagrama burn-up. Este diagrama, en mi opinión menos popular en las metodologÃas ágiles, está más indicado a gestionar el proyecto a largo plazo que a corto, y más orientado al cliente que al equipo de desarrollo.
El eje X representa el tiempo de desarrollo con las fechas de los sprints previstos.
En el área del gráfico se proyecta la lÃnea que representa la velocidad de desarrollo del equipo.
La intersección de los hitos en Y del esfuerzo previsto para una versión, con la lÃnea de velocidad prevista, proyecta sobre X la fecha en la que previsiblemente estarán desarrolla la versión.
Si las estimaciones se realizan considerando valores optimistas y pesimistas de velocidad, o de esfuerzo necesario, se obtienen rangos de fechas de probabilidad.
Nunca viene mal conocer nuevas herramientas para aplicar, aunque en mi caso siempre tengo la inminente necesidad de buscar soluciones hÃbridas que intenten extraer lo que me gusta de cada sistema o modo de trabajo.
Eso si, no debemos perder el norte, la gestión es simplemente un punto más en el desarrollo de un proyecto …
