En variadas reuniones y eventos en los que conversamos sobre la problemática del desarrollo de software en el Perú, siempre observo el rostro de desconcierto de Jefes y Gerentes de Proyectos al escuchar esa afirmación. La alta dependencia de un diagrama Gantt y quizás el día a día de su intenso trabajo, probablemente no les permite explorar otras herramientas de seguimiento y control de sus proyectos que puedan ser más efectivas para este fin.
El diagrama de Gantt fue desarrollado por Henry Gantt en 1910 mientras enfocaba su trabajo en la construcción de Buques durante la Primera Guerra Mundial. Durante sus más de 100 años de existencia se han agregado pocas características a su versión original. Lo que sí es indudable es el uso masivo entre las personas que tienen que ver con la Gestión de Proyectos, convirtiéndolo casi en un estándar de facto para el seguimiento de las actividades del Proyecto.
El desarrollo de software tradicional y el sistema Push
Tradicionalmente, el desarrollo de software se ha basado en un modelo “Push” de flujo de trabajo en donde las tareas son planificadas y programadas. Esto es, tan pronto como cualquier tipo de tarea es identificada, tal como “Crear Prototipo” o “Solucionar el Bug”, es asignado a un individuo. Un Jefe de Proyectos y el equipo viven y mueren con el Gantt.
Hay algunos inconvenientes con los que uno se encuentra en el día a día trabajando con un Gantt como por ejemplo presentar un diagrama de Gantt extenso en un documento, prácticamente no se llega a notar el contenido perdiendo su valor como herramienta visual. Otra cosa que sucede frecuentemente es que no refleja la realidad del proyecto. En un proyecto de software los cambios son constantes, mantener actualizado el diagrama Gantt se vuelve tan tedioso que termina siendo obsoleto continuamente.
Un sistema “Push” también introduce conflictos. Se toma el Gantt como un contrato que fija los plazos y utilización de recursos lo cuales hay que cumplir a como dé lugar. El objetivo muchas veces no llega a ser la entrega de valor a través de un producto de software de calidad, sino el cumplimiento del cronograma Gantt. El resultado creo que todos lo conocemos: pocas veces se cumple lo establecido y el tiempo de ciclo termina siendo más largo.
Kanban y el Sistema Pull
La alternativa al Sistema Push es el Sistema Pull. En un Sistema Pull el trabajo no es planificado ni programado, el trabajo ingresa al flujo en base a la disponibilidad. Kanban es un ejemplo de un sistema Pull. Este se basa en un sistema de producción que dispara trabajo solo cuando existe capacidad para procesarlo.
Kanban permite la visualización de todo el proceso de desarrollo, mediante un tablero físico, generalmente, públicamente asequible. Esto permite, entre otras cosas, entender mejor el proceso de trabajo actual, conocer los problemas que puedan surgir y tomar decisiones, mejorar la comunicación entre todos los interesados/participantes del proyecto y hacer los futuros procesos más predecibles. Un tablero Kanban, se divide en columnas las cuales representan un proceso de trabajo.
Otra característica de Kanban es el uso de un WIP (Work in Progress o trabajo en curso) que consiste en acordar anticipadamente la cantidad de ítems que pueden abordarse por cada proceso (es decir, por columnas del tablero). El principal objetivo de establecer estos límites es el de detectar cuellos de botella los cuales representan el estancamiento de un proceso determinado que llevan a alargar los plazos de entrega.
¿Porque no uso Gantt para el seguimiento y control de mis proyectos?
Regresando a la afirmación original, en mis equipos de trabajo hemos dejado de usar diagramas de Gantt desde hace un tiempo y solo se generan cuando hay que mostrar hitos del proyecto (sprints) u otra información relevante a los interesados del proyecto.
Para el seguimiento y control del avance de requerimientos y actividades utilizamos herramientas como “Team Foundation Server” que incorpora un tablero Kanban para el seguimiento del proceso de desarrollo. Sin embargo, hay que resaltar que para que esto sea efectivo se planifican “ciclos cortos” de entrega de entre dos a tres semanas de duración, al término del cual se entrega un incremento o avance del producto de software.
El uso de prácticas agiles, así como herramientas tales como el tablero Kanban, nos ha permitido tener una mejor visibilidad y efectividad en el manejo de los ciclos de entrega del producto de software en nuestros proyectos. ¿Qué inconvenientes encuentras tú con los diagramas de Gantt ?
Fuente : http://agiland.pe/blog/por-que-no-uso-gantt-para-el-seguimiento-y-control-de-mis-proyectos/
No hay comentarios:
Publicar un comentario