Diagrama de Gantt de software: planifica una versión de principio a fin
Planifica un proyecto de software como diagrama de Gantt: descubrimiento, diseño, desarrollo, pruebas, despliegue, lanzamiento y revisión posterior, con flujos paralelos y puertas de decisión, junto a los sprints ágiles.
El diagrama de Gantt de un proyecto de software muestra cómo dependen entre sí los flujos de trabajo y cuándo puede salir una versión. Responde a lo que un tablero de sprint no responde: dadas las dependencias, ¿cuál es la fecha más temprana para el lanzamiento?
En resumen
- Planifica a nivel de versión: flujos, puertas y dependencias, no tickets individuales.
- Los flujos paralelos se muestran con tareas que esperan a la misma predecesora; el más largo fija la fecha.
- Los puntos de decisión, como alcance acordado y seguir o no seguir, pertenecen al gráfico como hitos.
- Un flujo de desarrollo puede dimensionarse en sprints convertidos a días laborables.
- La capacidad y el esfuerzo no se modelan; usa tu gestor de tareas para eso.
Dónde ayuda un Gantt a un equipo de software y dónde no
La mayoría de los equipos de software ya trabaja con sprints, y un tablero de sprint es el lugar adecuado para gestionar el trabajo dentro de ellos. Un diagrama de Gantt se sitúa por encima. Abarca toda la versión: qué tiene que terminar antes de que pueda empezar el diseño, qué flujos pueden ir en paralelo, dónde las pruebas deben esperar a la integración y qué decisiones condicionan el despliegue. Es una vista de la forma del proyecto, no un sustituto del backlog.
Lo que un Gantt muestra y un tablero no es el tiempo y la dependencia juntos. Un tablero te dice qué está en curso. Un Gantt te dice que frontend y backend deben terminar ambos antes de la integración, que las pruebas no pueden empezar hasta entonces y que la más larga de dos construcciones paralelas decide la fecha. Eso lo hace útil para planificar versiones, para hablar con personas ajenas al equipo y para detectar el único flujo que retiene todo lo demás.
Mantén las tareas en grueso. Planifica al nivel de descubrimiento, diseño, flujos de desarrollo, integración, pruebas, lanzamiento y revisión, en días laborables, y deja las historias y los tickets a tu gestor de tareas. Si trabajas con sprints, un flujo de desarrollo puede ser simplemente una tarea cuya duración es un número de sprints expresado en días laborables. No intentes modelar aquí el alcance de cada sprint; el gráfico queda obsoleto en cuanto se mueve el backlog.
Añade los puntos de decisión como hitos de duración cero: alcance acordado, revisión del diseño, seguir o no seguir. Ahí es donde de verdad se decide un cronograma, y ponerlos en el gráfico hace difícil eludir quién decide y cuándo. QueryChart no registra esfuerzo ni capacidad, así que el tamaño del equipo no se modela. El ejemplo siguiente es un plan de versión completo, etapa por etapa.
Una versión de software, de las entrevistas a la revisión posterior al lanzamiento
Diecisiete tareas. Abre el panel de la hoja de cálculo para ver las dependencias de cada etapa.
El descubrimiento termina en una decisión de alcance
«Entrevistas con las partes interesadas» (4 días laborables) conducen a «Redactar requisitos» (5). «Alcance acordado» es un hito de duración 0, y los dos flujos de diseño lo esperan.
Dos flujos de diseño, una revisión
«Arquitectura técnica» (4 días laborables) y «Diseño UX y prototipo» (8) empiezan ambas tras «Alcance acordado». La «Revisión del diseño» espera a las dos, de modo que el trabajo de UX, por ser el flujo más largo, decide cuándo se hace.
Flujos de desarrollo y preparación de pruebas
«Desarrollo de backend» (20 días laborables) y «Desarrollo de frontend» (18) empiezan tras la «Revisión del diseño» y confluyen en «Integración» (5). «Plan y datos de prueba» (4) también empieza tras la revisión, así que está listo mucho antes de que las pruebas lo necesiten.
Probar, decidir, lanzar, revisar
«Pruebas de sistema» espera a «Integración» y a la preparación de pruebas. La «Decisión de seguir o no» es un hito previo al «Despliegue en producción» (2 días laborables), y después vienen «Lanzamiento», «Soporte reforzado» (10) y «Revisión posterior al lanzamiento» (2).
Cómo funciona
Decide el nivel de detalle
Planifica a nivel de versión. Cada tarea debe ser un flujo o una etapa que lleve días o semanas, no un ticket. Si una tarea dura menos de un par de días, intégrala en la tarea que la contiene.
Introduce el descubrimiento y el diseño, con los hitos de decisión
Añade las tareas de descubrimiento y diseño con duraciones en días laborables, y añade hitos de duración cero para el alcance acordado y la revisión del diseño. Haz que la etapa siguiente dependa del hito, no de la última tarea.
Pon los flujos paralelos sobre la misma predecesora
Backend, frontend y la preparación de pruebas deben depender todos de la revisión del diseño. No los encadenes uno tras otro; el sentido del gráfico es mostrar qué puede solaparse.
Convierte los sprints en días laborables
Si un flujo lleva cuatro sprints de dos semanas, introduce 40 días laborables. Añade un desfase solo donde haya una espera real, como una congelación de versión.
Añade las puertas de lanzamiento
Añade seguir o no seguir como hito antes del despliegue, y da al soporte reforzado y a la revisión posterior al lanzamiento sus propias tareas para que el plan cubra las semanas posteriores al lanzamiento.
Resalta la ruta crítica y comparte
Activa Ver, Ruta crítica para ver la cadena que fija la fecha de lanzamiento, y luego comparte el gráfico como enlace o exporta un PDF para las partes interesadas.
Errores que debes evitar
Planificar a nivel de ticket
Un diagrama de Gantt con cientos de tareas pequeñas está desactualizado en un sprint. Mantenlo a nivel de flujo y deja el detalle al gestor de tareas.
Encadenar flujos paralelos
Poner el frontend después del backend porque lo hace una sola persona oculta la estructura real de dependencias. Vincula las tareas por lo que de verdad necesitan e indica las personas compartidas en el campo Personas.
Olvidar que la capacidad no se modela
Dos tareas asignadas a la misma persona pueden solaparse sin aviso. QueryChart registra responsables, pero no comprueba la carga de trabajo.
Omitir las semanas posteriores al lanzamiento
El soporte reforzado y una revisión son trabajo real. Si los omites, el plan termina el día del lanzamiento, que rara vez es cuando el equipo queda libre.
Abre la plantilla de proyecto de software
Abre el plan del proyecto de software como gráfico propio, sustituye los flujos por los tuyos y comparte el calendario de la versión.
Guías relacionadas
Preguntas frecuentes
¿Encaja un diagrama de Gantt con un equipo ágil?
Sí, a nivel de versión. Úsalo para la forma del proyecto, sus dependencias y sus puertas, y deja el alcance de los sprints en tu herramienta de backlog. Responden a preguntas distintas.
¿Qué muestra un diagrama de Gantt que no muestra un tablero?
El tiempo y la dependencia juntos: qué flujos van en paralelo, cuáles deben terminar antes de que pueda empezar el siguiente y qué cadena fija la fecha de lanzamiento.
¿Cómo planifico un sprint en el gráfico?
En general no se hace. Expresa un flujo de desarrollo como una tarea cuya duración sea su número de sprints en días laborables, y deja el alcance del sprint al tablero.
¿Puedo vincularlo a mi gestor de incidencias?
No. QueryChart no tiene integraciones con gestores de incidencias. Puedes pegar en la hoja filas de una exportación de hoja de cálculo.
¿Puedo mostrar quién trabaja en qué?
Sí, cada tarea tiene un campo Personas. No hay comprobación de carga de trabajo ni de sobrecarga.
