blog de OBS Business School

Diagramas Gantt en Agile… ¿una buena combinación?

Blog |

El tema de los diagramas de Gantt en el contexto del desarrollo de software ágil ha sido una cuestión muy debatida… Para situarnos, el diagrama de Gantt es una herramienta gráfica cuyo objetivo es exponer el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. Por tanto, se utiliza principalmente en proyectos predictivos, donde a partir de unos requisitos iniciales, se hace una estimación del tiempo y dependencias de las tareas.

Entonces… ¿tiene sentido usarlo en proyectos ágiles, donde trabajamos por sprints y los requisitos (backlog) van siendo modificados? De hecho, Jeff Sutherland “prohibió” los gráficos de Gantt cuando implementó Scrum por primera vez en 1993, y ha afirmado incluso más de una década después que no veía muchas razones para cambiar esto.

Es cierto que los gráficos de Gantt son de uso limitado en el sentido clásico del desarrollo ágil. El propósito principal de usar Agile es permitir que los desarrolladores reaccionen a los requisitos cambiantes más rápido. A medida que cambian los requisitos, el esfuerzo y el tiempo necesarios para abordarlos también cambian. Por lo tanto, para representar y visualizar adecuadamente la cantidad total de trabajo restante, los diagramas de Gantt tendrían que actualizarse casi continuamente. Obviamente, esto sería una carga innecesaria y poco realista para el equipo de desarrollo.

Aun así, un número creciente de empresas parece estar utilizando estos diagramas, y estamos viendo que cada vez más proveedores de herramientas de desarrollo implementan una versión de los diagramas de Gantt en sus aplicaciones. ¿Por qué?

 

https://almworks.com/blog/introducing-agile-gantt-the-evolution-of-a-manifesto.html

Hay quien dice Agile 100% verdadero, sin restricciones de límites de tiempo ni de coste, ni número de sprints, raramente se da. En su lugar, la mayoría de las empresas confían en algún tipo de proceso híbrido personalizado, que podría beneficiarse de la transparencia que diagramas de Gantt pueden aportar. Al fin y al cabo, Agile es colaborar, radiar información, ser transparente. Además, quizá el "verdadero” Agile se trata de usar lo que funcione; si los diagramas de Gantt parecen funcionar para ti, continúa y utilízalos como mejor te parezca. ¿Estás de acuerdo...?

En definitiva, los diagramas de Gantt pueden ayudan a visualizar las fechas de inicio y finalización de cualquier proceso. En el contexto del desarrollo de software ágil, estos gráficos se podrían utilizar para ilustrar lanzamientos o sprints.

Como simples representaciones visuales del progreso realizado con respecto a las estimaciones de cualquier actividad, proceso o proyecto, los diagramas de Gantt pueden facilitar enormemente la comunicación al unir las diferencias culturales o geográficas. Dado que estos diagramas son fáciles de entender por todas las partes, independientemente del idioma o la experiencia en las prácticas de desarrollo de software ágil, son herramientas útiles cuando se trata de colaborar o informar sobre su progreso a varios equipos en distintas regiones.

Una parte creciente de los proyectos son mucho más complicados que un solo equipo Scrum... Se trata de varios equipos dispersos geográficamente que participan en el desarrollo de arquitecturas de sistemas complejos de N niveles. En el caso del desarrollo de productos IoT, por ejemplo, los responsables tratarán de orquestar los ciclos de vida de desarrollo paralelo de hardware, software y componentes de servicio. Algunos de estos usarán Agile, mientras que otros deberán basar su método pensando en deadlines y compromisos de entrega.

Los Burndown charts se consideran la solución a nivel de equipo. Pero los diagramas de Gantt podrían ser herramientas ágiles legítimas desde el punto de vista de la gestión de proyectos a nivel empresa, y podrían ayudar enormemente a los inversores a comprender y supervisar el progreso realizado en comparación con las estimaciones.

Veamos algunas otras situaciones susceptibles de usarlos:

  1. Product Roadmap Gantt Chart

En el contexto del desarrollo ágil a escala empresarial, la planificación abarca períodos largos y múltiples equipos que utilizan diferentes metodologías para colaborar en un producto final complejo de "sistema de sistemas". Los diagramas de Gantt pueden soportar en gran medida dicha planificación de nivel superior, al visualizar cómo cada flujo de desarrollo se relaciona con los demás en el tiempo y, en cierta medida, incluso pueden representar relaciones entre ellos.

Desde el punto de vista de la gestión de programas, el uso de diagramas de Gantt en el sistema de desarrollo de sistemas tiene mucho sentido. Incluso si el gráfico se actualiza con baja frecuencia, en lugar de actualizarse continuamente, ayuda a proporcionar información sobre el progreso del proyecto a los inversores.

https://slidebazaar.com/items/product-roadmap-gantt-chart-powerpoint-template/

  1. Equipos escalados

Muchas organizaciones tienen equipos grandes... Van desde un par de equipos scrum hasta 50 equipos, todos trabajando en el mismo producto. A veces son equipos de desarrollo de software, pero en muchos casos, también hay equipos que desarrollan hardware para el producto. En una organización de desarrollo tan grande y mixta, podríamos estar de acuerdo en que se requieren ciertas cosas para el éxito. En resumen, necesitamos:

  • Una visión compartida para todo el producto, que abarca todos los equipos.
  • Una comprensión compartida de la hoja de ruta de productos de alto nivel.
  • Formas alineadas de trabajo, con libertad para la variación local.

Una buena combinación de programación Gantt en un contexto ágil puede ayudar a cumplir los objetivos anteriores.

  1. Metodologías híbridas: Ejemplos

A menudo en nuestros desarrollos es necesario completar una serie de otras actividades antes del lanzamiento del producto, independientemente del conjunto de características entregadas en el lanzamiento. Dichas actividades obligatorias, o entregables, se dividen en dos categorías:

Actividades relacionadas con el producto que deben realizarse antes del lanzamiento. Ejemplos incluyen:

  • Pruebas destructivas costosas (de hardware) realizadas una vez.
  • Capacitación de equipos de ventas y soporte para estar listos para el lanzamiento del producto.
  • Actividades de marketing y lanzamiento de productos.
  • Cambios en los sistemas de soporte empresarial para facilitar la implementación del nuevo producto.

Actividades relacionadas con el proceso que se deben a procesos de calidad obligatorios, cumplimiento normativo, etc. Los ejemplos incluyen:

  • Documentación que debe ser completada en un proceso prescrito.
  • Verificación formal que por alguna razón no se puede realizar de forma continua durante el desarrollo.

Ejemplo 1: Equipos ágiles múltiples, un release

En el blog de Perforce nos muestran un par de ejemplos interesantes (3). En la figura vemos que con un Gantt indicamos las dependencias entre los planes de sprint de alto nivel entre los diferentes equipos. Se indica la secuencia y las dependencias de trabajo necesarias para el lanzamiento del producto que quedan fuera del alcance de los equipos scrum.

Ejemplo 2: Procesos obligatorios

En la siguiente figura se muestra cómo se cumple con un proceso obligatorio (regulaciones), y cómo el trabajo de los equipos ágiles se ajusta al proceso general. En la parte superior de la figura hay un conjunto de gates definidas (Seleccionar, Hacer, Producir, Vender). Después de eso, vemos actividades obligatorias típicas junto con cómo se relacionan con las gates. Las actividades obligatorias se pueden detallar y hacer más específicas como se muestra con la actividad "Ejecutar pruebas de campo".

Debajo de eso, encontramos elementos relacionados con el desarrollo ágil del software del producto. En la parte inferior, vemos algunos sprints que resultan en la Característica A y la Característica B, como lo indican los hitos de la característica sobre los sprints. Se ven también cómo las tareas de “prueba de campo” en la parte superior de la figura dependen de estos hitos.

Para concluir, pues, vemos que son herramientas con mucho potencial en multitud de situaciones… Comentar también que otra crítica habitual a estos diagramas es que son pesados y cuestan de mantener… Sin embargo, desde el punto de vista de la usabilidad, hoy en día hay herramientas de “scheduling” con Gantt charts que no solo proporcionan estadísticas y una excelente visión general del progreso, sino que también permiten editar los lanzamientos directamente desde el diagrama a través de una funcionalidad fácil de arrastrar y soltar. Cualquier cambio realizado en el gráfico tendrá efecto automáticamente en las versiones o sprints afectados.

¿Qué opinas de todo ello? ¡Esperamos comentarios!

Referencias:

  1. “Should You Use Gantt Charts in Agile Project Management?”, https://content.intland.com/blog/project-management-en/should-you-use-gantt-charts-in-agile-project-management
  2. “Introducing Agile Gantt - The Evolution of a Manifesto”, https://almworks.com/blog/introducing-agile-gantt-the-evolution-of-a-manifesto.html
  3. “How to Mix Gantt Charts With Agile Project Planning (With Examples)”, https://www.perforce.com/blog/hns/how-mix-gantt-charts-agile-project-planning-examples 
  4. Agile Sprint Planning and Gantt Chart Method, https://instagantt.com/blog/sprint-planning-gantt-chart
  5. Gantt chart with Agile - why and how, https://www.linkedin.com/pulse/gantt-chart-agile-why-how-jakub-dobies
  6. Imagen 1: Fuente: Image licensed under the Creative Commons Attribution-ShareAlike 3.0 License.