Diagramas de Gantt para planificación y seguimiento ágil. ¿Es esto un oxímoron?

El Diagrama de Gantt es quizás la técnica más conocida para planificación y seguimiento de proyectos. En muchas propuestas de proyecto el plan se ilustra usando un Diagrama de Gantt porque es una forma sencilla de visualizar el trabajo y cómo se distribuye en el tiempo. La parte cliente y la parte proveedora se sienten cómodos acordando una propuesta de proyecto si el Diagrama de Gantt se ajusta a las expectativas de plazos y presupuesto. Sin embargo, durante la ejecución del proyecto el Diagrama de Gantt puede ser poco efectivo, especialmente en proyectos del ámbito de desarrollo de software, o en general proyectos IT, donde la incertidumbre conlleva cambios a lo largo del proyecto. A continuación, comentaré algunas debilidades de esta técnica y daré mi opinión respecto de si es posible aprovecharla en un contexto de gestión ágil de proyectos.

En la siguiente imagen se presenta un Diagrama de Gantt "típico" para el desarrollo de un producto software.

En este Diagrama de Gantt se cumple el objetivo de mostrar cómo, mediante unas tareas técnicas, se conseguirá desarrollar el producto en un plazo de 4 meses. Además, las herramientas que permiten elaborar Diagramas de Gantt ofrecen funcionalidades para establecer dependencias entre tareas, asignación y balanceo de carga de "recursos" (debería decirse personas cuando de eso se trata), cálculo de holguras, etc. Aunque muchas veces la parte cliente no se preocupa de qué tareas técnicas se realizarán (o simplemente no las entiende), el proyecto puede aprobarse pues los proveedores se comprometen a hacer "todo" (especificado en un documento aparte) en el plazo que muestra el Diagrama de Gantt. Así pues, adelante!, la ejecución del proyecto puede comenzar! :-).

¿Qué debilidades tiene una planificación como la mostrada antes?

• Se ha planificado la realización de una lista de tareas técnicas de carácter general, sin una conexión explícita con el producto que se va a desarrollar. He visto plantillas de Diagrama Gantt que al aplicarlas a un proyecto, los encargados de hacerlo, simplemente quitan algunas tareas no necesarias, y acortan o alargan las duraciones de tareas, hasta coincidir con los plazos deseados :-). 
• La duración de las tareas, cuya estimación puede ya ser bastante incierta, además se enmarca en unas fechas de inicio y de fin muy específicas.
• La asignación de responsables de realizar las tareas se ha previsto al comienzo del proyecto. Cada participante sabría las fechas entre las cuales debería realizar cada tarea asignada, pero ¿es fácil acertar en esto?
• El encadenamiento de tareas (y el perfil mostrado en diagrama) delatan que se aplicará un modelo de proceso "En Cascada". En un proceso en cascada las fases y actividades técnicas son  equivalentes, por ejemplo, podríamos decir "El proyecto está en Fase de Análisis" y esto coincidiría con "El equipo solo está realizando trabajo de Análisis". Un modelo de proceso en cascada no reacciona bien ante los cambios, no considera adecuadamente el re-trabajo y asume un desarrollo monolítico del producto (todo se analiza, luego todo se diseña, luego todo se programa, etc.). Además, los defectos de mayor impacto tienden a detectarse tardíamente (especialmente al realizar pruebas de aceptación), con lo cual el re-trabajo que genera la corrección de defectos pondría en juego el cumplimiento de los plazos del proyecto. Finalmente, los primeros hitos que se establecen suelen corresponder a completar especificaciones, no a conseguir partes ejecutables del producto software. Lectura recomendada: Modelos de proceso para desarrollo ágil.
• En la medida que estas previsiones, tan específicas en cuanto a fechas y responsables asignados, no se vayan cumpliendo, la actualización del plan requerirá de bastante esfuerzo pues el desajuste también se producirá en cascada.   

Analicemos a continuación el siguiente Diagrama de Gantt, esta vez, reflejando un modelo de proceso iterativo e incremental. Podría no ser iterativo, es decir, los Sprints son una opción, pero utilizar Sprints es recomendable cuando el compromiso de entrega supera un mes de trabajo. Este nuevo Diagrama de Gantt es iterativo porque en cada uno de los 4 Sprints (de un mes cada uno) se abordan una y otra vez todas las tareas técnicas, pero sobre diferentes requisitos, y es incremental porque al terminar cada Sprint se obtiene una nueva versión ejecutable del producto.   

En este caso el modelo de proceso es diferente, el trabajo se enfoca en implementar requisitos, ahora sí que el cliente puede ver en el plan los requisitos que se implementarán. Así, el progreso se puede medir en requisitos implementados respecto de requisitos que quedan por implementar. Sin embargo, en este caso se mantienen algunos inconvenientes desde la perspectiva de un enfoque ágil:

• Dentro de cada Sprint se tiene aún que establecer fechas de inicio y fin para cada actividad técnica realizada sobre un requisito (lo cual determina las fechas de inicio y de fin de la implementación requisito dentro del Sprint).
• Asignación anticipada de responsables a las tareas técnicas. Es difícil prever quien y cuando estará disponible para realizar una tarea.
• Previsión anticipada del Sprint en el que se implementará cada requisito. Los cambios detectados (nuevos requisitos, mejoras en requisitos ya implementados y correcciones de fallos) afectarán al Sprint actual o a los Sprint posteriores, lo cual dificultará la actualización del Diagrama de Gantt.  

Veamos finalmente, un Diagrama de Gantt que para la misma situación ahora refleja un proceso iterativo e incremental de 4 Sprints de un mes cada uno, pero esta vez sin los inconvenientes vistos hasta ahora.

Este diagrama lo obtuve luchando :- ) con la herramienta pues no es natural este planteamiento, que se caracteriza por lo siguiente:

• Sigue existiendo una previsión de término del proyecto en 4 meses.
• Aparece el concepto del Backlog, una lista ordenada del los requisitos que se implementarán,  y que posteriormente también incluirá ítems asociados a mejoras y correcciones de fallos. El orden establecido debería reflejar una estrategia conveniente para el éxito del proyecto, por ejemplo, implementar primero lo que más valor aportará, o implementar primero lo que tiene mayor riesgo, o implementar primero lo esencial para tener una validación global, etc. La gestión de alcance del proyecto se efectuará en cualquier momento directamente sobre el Backlog, respondiendo a la pregunta ¿en lo que resta de proyecto tenemos capacidad suficiente para abordar lo que resta de trabajo comprometido en el Backlog?. Según esto puede que en algún momento se vea que en el Backlog hay una parte (hacia el final según el ordenamiento) que se ha acordado dejar fuera del alcance, debido a la aparición de nuevos requisitos incluidos en el proyecto, por ejemplo: solicitudes de mejoras, correcciones de fallos, subestimaciones iniciales, problemas que afecten a la capacidad del equipo, etc. Lecturas recomendadas: "Flecos" de implementación y gestión ágil de proyectos, Buffer de Capacidad para proyectos ágiles, El Backlog, el contenedor del trabajo pendiente.
• Se muestran explícitamente los requisitos que se abordarán, sin indicar en qué Sprint se implementarán. Podría, sin mayor inconveniente establecerse el contenido del Sprint 1, pero para los Sprints futuros lo recomendable es mantener el trabajo en el Backlog.
• No se ha planificado respecto de las tareas técnicas que se aplicarán a cada requisito, ni respecto de quién se encargará de llevarlas a cabo. La información asociada al estado de trabajo técnico de un requisito se debería llevar en un tablero kanban en el cual las columnas representen dicho estado (por ejemplo, columnas: Especificar Requisitos, Programar, Aplicar Pruebas de Aceptación). En dicho tablero kanban también se indicaría la persona que se ha hecho cargo de la actividad técnica (asignación que se postergaría hasta el momento de comenzar a realizar dicha actividad). Lectura recomendada: Tableros kanban. Parte II: Diseño de tablero kanban para aplicarlo con Scrum (desarrollo usando Sprints).

Según lo comentado antes, en mi opinión cuando se aplica un enfoque ágil un Diagrama Gantt solo lo usaría para visualizar los plazos del proyecto, y las fechas de inicio y fin de Sprint. No estoy seguro si vale la pena usar un Diagrama de Gantt solo para esto :-), pero está claro que usado así NO entra en conflicto con la planificación y seguimiento ágil ya que en un enfoque ágil también se establecen plazos y se lleva una estricta gestión de alcance del proyecto (aunque en algunas interpretaciones equivocadas del enfoque ágil estos aspectos parecen ignorarse).

Pero por otra parte, cuando abordamos proyectos con alta incertidumbre, establecer anticipadamente fechas de inicio y fin de implementación de requisitos, no considerar que habrá cambios, "flecos" y/o re-trabajo, asignar anticipadamente personas a tareas, etc., es decir, todo aquello a lo que nos conduce la elaboración típica de un Diagrama de Gantt, lo haría incompatible con el enfoque ágil. En este caso un Diagrama de Gantt en el enfoque ágil efectivamente sería un oxímoron :-).

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

www.tuneupprocess.com