domingo, 20 de mayo de 2018

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 un contexto de gestión tradicional de proyectos un Diagrama de Gantt no suele incomodar, sin embargo, cuando se aplica un enfoque ágil no parece ser lo más apropiado para planificar y realizar el seguimiento del proyecto. En muchas propuestas de proyecto se suele ilustrar el plan 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 cuando se cuenta con su Diagrama de Gantt razonablemente ajustado a las expectativas de plazos. 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 proyectos IT en general. 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 lo que podría ser 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 cuestionable, 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) y 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 exactas 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 son recomendables 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. Pero 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.  
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 un poco :- ) 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, 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 Sprint 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 serviría para visualizar los plazos del proyecto y también las fechas de inicio y fin de Sprint. Esta información NO entra en conflicto con la planificación y seguimiento ágil. Es decir, en un enfoque ágil también pueden establecerse plazos y llevar una estricta gestión de alcance del proyecto (realizada en el Backlog). Pero cuando abordamos proyectos con alta incertidumbre, el detalle y la antelación de la planificación a la que nos fuerza un Diagrama de Gantt es incompatible con el enfoque ágil.


Patricio Letelier