Guía práctica
Roadmap de software en un diagrama de Gantt
Cómo convivir con el tablero de sprints y aun así poder responder cuándo estará lista la versión 2.0, con un ejemplo de cuatro fases listo para editar.
Atajo Abre el roadmap de ejemplo Trece tareas en cuatro fases, con backend y frontend en paralelo, QA como tarea propia e hito de publicación. Abrir el ejemplo →Un Gantt no compite con tu tablero
Si trabajas por sprints, el tablero manda en el día a día. Pero cuando alguien de fuera del equipo pregunta cuándo estará lista la versión 2.0, el tablero no responde. Un diagrama de Gantt sí: enseña las épicas como bloques, sus dependencias y una fecha defendible.
La forma útil de combinarlos es sencilla: cada tarea principal del Gantt es una épica, y las subtareas son los grandes entregables, no las historias sueltas. El detalle vive en el tablero; el calendario, aquí.
Las fases de una versión
Cómo montarlo paso a paso
- Una tarea principal por épica. Si tienes más de seis, el diagrama deja de leerse: agrupa.
- Deja QA como tarea propia, no como coletilla del desarrollo. Es lo primero que se recorta y lo que más caro sale.
- Marca la publicación como hito de cero días: es la fecha por la que te van a preguntar.
- Carga las horas por perfil con su precio por hora. El informe da el coste de la versión, que es justo lo que necesitas para justificar el roadmap.
- Revisa el diagrama al cierre de cada sprint y ajusta el avance. Con las dependencias encadenadas, un retraso se propaga solo y ves de inmediato si peligra la fecha.
Errores clásicos
- Planificar al cien por cien de capacidad. El soporte, las incidencias y las reuniones existen: cuenta con un setenta por ciento útil.
- Meter cada historia de usuario en el Gantt. Se vuelve ilegible y obliga a mantener dos sistemas.
- Olvidar la beta. El tiempo entre código terminado y versión publicada nunca es cero.
- No marcar el avance. Un Gantt sin porcentajes es una foto vieja, no una herramienta.
Preguntas frecuentes
¿Sirve un diagrama de Gantt en un equipo ágil?
Sí, para la vista de roadmap y para comunicar fechas fuera del equipo. El tablero gestiona el sprint; el Gantt responde a cuándo estará lista la versión y a qué depende de qué.
¿Qué granularidad conviene?
Épicas como tareas principales y entregables grandes como subtareas. Si acabas metiendo tickets individuales, has bajado demasiado y el diagrama se vuelve inmanejable.
¿Cómo calculo el coste de una versión?
Asignando horas estimadas y precio por hora de cada perfil a cada tarea. El informe suma el total, lo reparte por responsable y lo distribuye por meses.