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 …
Abril 16, 2008 a las 3:17 pm
No conocÃa los diagramas de gestión que se podÃan utilizar en SCRUM, y reconozco que son interesantes.
Si no interpreto mal la 1ª gráfica, el sprint representado es de 400h y está planificado en 15 dÃas, siguiendo la lÃnea de “Ideal Burndown”. Supongo es el Ideal Burndown serÃa el equivalente a un gantt, es decir, que su pendiente varÃa en función del número de personas que participan en el sprint y tiene en cuenta vacaciones, etc.
El diagrama de velocidad también resulta muy útil para conocer si la ejecución del proyecto se está “desviando” es esfuerzo/plazo. SerÃa interesante contar con otra gráfica que aporte datos de tipo económico.
Abril 16, 2008 a las 3:26 pm
Sip, varÃa en función de la planificación propia del sprint como dices: las pendientes más pronunciadas es donde deberÃas avanzar más rápido en el tiempo, pero esto depende de cómo estén divididas las tareas, las personas (vacaciones, …).
Cuando dices otra de tipo económico, ¿qué tienes en la cabeza? Quiero decir, qué tipo de gráfica serÃa, con qué ejes y queé información tendrÃa cada eje ? Es una reflexión interesante, anuque tendrÃamos que tener en cuenta y graficado el coste / unidad de trabajo de cada participante.