Gantt y Jira: cómo mantener alineados el plan y la ejecución

En muchas empresas el proyecto existe dos veces. El plan, con fases, dependencias y fechas de entrega, está en un diagrama de Gantt preparado por el jefe de proyecto. El trabajo, con tickets, sprints y asignaciones, está en Jira. Mientras ambos sigan separados, alguien tiene que copiar a mano el avance de un lado a otro, y las fechas del plan se quedan obsoletas enseguida.

Este artículo explica por qué Jira por sí solo no basta para el cronograma, cómo funciona la sincronización bidireccional entre Planitude y Jira Cloud y qué límites conviene conocer antes de activarla.

Dos herramientas, dos preguntas distintas#

Jira responde a la pregunta ¿en qué está trabajando el equipo ahora mismo? Los backlogs, los tableros y los sprints están pensados para eso. Un cronograma responde a otra pregunta: ¿cuándo terminamos y qué tareas no pueden permitirse un retraso?

Para responder a la segunda hacen falta duraciones, dependencias con adelantos y retrasos, calendarios con festivos, restricciones y un cálculo que propague cada cambio a las tareas siguientes. Si la instalación del nuevo servidor se retrasa tres días, las pruebas, la formación y la puesta en marcha tienen que moverse solas, y el jefe de proyecto debe saber al instante si la fecha de entrega sigue en pie.

Lo que le falta a Jira para el cronograma#

Jira no carece de herramientas de planificación. La cronología muestra las dependencias entre elementos enlazados con el tipo de enlace «Blocks» y, cuando las fechas de dos elementos enlazados se solapan, la línea de la dependencia se vuelve roja para señalar un posible retraso^[1]. Según la página de precios de Atlassian, las dependencias se gestionan dentro de un mismo proyecto en los planes Free y Standard, y entre proyectos en Premium^[2].

Una advertencia, sin embargo, no es un recálculo: las fechas siguen siendo las introducidas y la ruta crítica no figura entre las funciones descritas. El resultado es que el plan vive en otro sitio, en un archivo o en otra herramienta, y se desalinea. Para una comparación completa entre ambas herramientas está el artículo Planitude vs Jira.

Cómo funciona la sincronización bidireccional#

La integración conecta un proyecto de Planitude con un proyecto de Jira Cloud. El acceso se hace con OAuth 2.0 de Atlassian: Planitude no conoce tu contraseña, guarda los tokens cifrados y los renueva con los tokens de actualización rotatorios de Atlassian, que caducan tras 90 días de inactividad^[3].

La primera vez eliges la alineación inicial:

1. Enviar el plan a Jira: se crea una incidencia por cada tarea y un enlace «Blocks» por cada dependencia;
2. Importar desde Jira: cada incidencia existente se convierte en una tarea al final del plan, con fecha de inicio, duración, avance y responsable;
3. Ambos: primero la importación y después el envío de las tareas que aún no están en Jira.

A partir de ahí los cambios viajan en ambos sentidos. De Planitude a Jira, cada cambio del plan se detecta y se envía en pocos segundos, venga de donde venga: la tabla, el Gantt, una importación o el asistente de IA. De Jira a Planitude, los cambios llegan mediante los webhooks que registra la integración, que Planitude renueva antes de la caducidad de 30 días prevista por Atlassian^[4], y una comprobación cada cinco minutos recupera los eventos perdidos.

Las tareas de resumen pueden quedarse solo en Planitude o convertirse en Epics, con las tareas que contienen como incidencias hijas.

Quién decide qué: la regla de los campos#

Una sincronización fiable necesita una regla sencilla para cada campo. En Planitude es esta:

La lógica refleja el trabajo real: el plan decide cuándo, el equipo decide en qué punto está una tarea y quién se encarga. El estado se traduce a porcentaje con un mapa editable: por categoría, pendiente es 0 %, en curso es 50 %, terminada es 100 %. Si una tarea ya está al 30 % y su incidencia pasa a «En curso», el avance no se sobrescribe con un 50 % fijo.

Las personas se emparejan automáticamente por correo cuando el usuario de Jira lo hace visible; si no, el emparejamiento se elige a mano en la página de la integración.

Dependencias, conflictos y borrados#

Dependencias. Los vínculos fin-inicio se convierten en enlaces «Blocks»: el predecesor bloquea al sucesor. Los vínculos inicio-inicio, fin-fin e inicio-fin no tienen equivalente en Jira y se quedan solo en Planitude. Los enlaces «Blocks» añadidos a mano en Jira no se importan ni se borran.

Fechas cambiadas en Jira. Como las fechas las calcula el plan, una fecha modificada en Jira vuelve al valor del plan y el cambio rechazado aparece en el registro de la integración. Para mover una tarea se mueve en el plan: el motor recalcula también todas las que dependen de ella.

Conflictos. Para cada campo Planitude compara tres valores: el último valor acordado, el valor actual en el plan y el valor actual en Jira. Si solo ha cambiado un lado, el cambio pasa al otro. Si han cambiado los dos con valores distintos, gana quien decide ese campo y el conflicto se anota con ambos valores. La regla depende solo de los datos, no de los relojes de los dos servidores.

Borrados. Ninguna de las dos partes borra nada en la otra. Una tarea eliminada en Planitude deja la incidencia en Jira con la etiqueta planitude-unlinked; una incidencia eliminada en Jira deja la tarea en el plan, y la página ofrece dos acciones: volver a crearla en Jira o dejar de sincronizarla.

Conectar Jira paso a paso#

1. Abre el proyecto en Planitude y elige ⋯ › Integraciones › Jira.
2. Pulsa Conectar Jira y concede el acceso en la pantalla de consentimiento de Atlassian.
3. Si tu cuenta ve varios sitios, elige el correcto y después el proyecto de Jira.
4. Revisa las opciones: tipo de incidencia predeterminado, tareas de resumen como Epics o no, campo de la fecha de inicio y etiqueta de las incidencias creadas por Planitude.
5. Elige la alineación inicial: envío, importación o ambos.
6. Revisa la sección Personas y completa los emparejamientos que no se encontraron por correo.

Planitude escribe en Jira con la identidad de quien conectó el proyecto, que necesita en Jira los permisos para explorar el proyecto, crear, editar, asignar y enlazar incidencias y ejecutar transiciones. El propietario y los editores del proyecto de Planitude pueden configurar la integración; quien tiene acceso de solo lectura solo ve su estado. Las demás integraciones disponibles se describen en la página Integraciones.

Límites conocidos#

• Solo Jira Cloud: Jira Data Center y Server no son compatibles.
• Solo dependencias fin-inicio; un único responsable por incidencia (la persona con más unidades en la tarea).
• Fechas con precisión de día: las horas se quedan en Planitude.
• Atlassian permite a una app OAuth 5 webhooks por usuario y sitio^[4]: a partir del sexto proyecto conectado por la misma persona en el mismo sitio, los cambios de Jira llegan con la comprobación cada cinco minutos.
• Con la opción «solo tareas hoja», una tarea que pasa a ser de resumen se trata como eliminada y su incidencia recibe la etiqueta planitude-unlinked.

Preguntas frecuentes#