Iniciativas y productos

Muchos equipos trabajan en dos ejes a la vez. Por un lado están los repositorios: el frontend, el backend, la API… Son permanentes, no se cierran nunca y reciben mantenimiento todo el tiempo. Por otro están los objetivos con fin: «la web de pedidos», «la migración a la nube»… Tienen principio y final, se reparten en hitos y sus tareas se implementan en uno u otro repositorio.

Si cada tarea solo puede estar en un proyecto, hay que elegir: o se sigue el objetivo («¿cuánto falta?») o se sigue el repositorio («¿qué tengo pendiente en la API?»). Con los tipos de proyecto no hace falta elegir.

¿Por qué lo hemos añadido? Lo cuenta un caso completo, con pantallazos y vídeos: un equipo con la API, la web y la app en repositorios distintos y un objetivo que los cruza a los tres. Léelo en Tres repositorios, un objetivo con fecha.

Los tipos de proyecto

• Sin tipo. Es lo que tiene todo proyecto al crearse, y funciona como siempre. Si no trabajas así, no tienes que hacer nada.
• Iniciativa. Un objetivo con fin. Sus tareas se entregan a los productos donde se implementan.
• Producto. Un proyecto de código: un repositorio (o un producto) permanente. Además de sus tareas de mantenimiento, recibe las que le entregan las iniciativas.

El tipo se pone desde el menú del proyecto en la barra lateral (clic derecho) o en la fila Tipo de la ficha del proyecto. En la barra lateral, cada iniciativa lleva una diana y cada producto, una caja.

El tipo es definitivo

Una vez puesto, no se puede cambiar ni quitar. Hilbana te lo avisa antes de confirmar. Es definitivo porque de él dependen las entregas: un producto con tareas entregadas que dejara de serlo las dejaría sin sitio. Antes de elegir, piensa si ese proyecto es un objetivo que terminará (iniciativa) o un repositorio que seguirá ahí (producto). Al proyecto General no se le pone tipo.

Entregar una tarea a un producto

En la ficha de una tarea de una iniciativa aparece el campo Producto. Se elige en dos pasos: primero el producto y, si tiene hitos, después en cuál entra. El campo muestra los dos juntos, por ejemplo «apirest · v2.3».

• La tarea sigue viviendo en la iniciativa: su identificador no cambia (por ejemplo, WEBS-12) y la rama y los PRs se siguen enlazando igual.
• Aparece también en el producto: en su listado, en su tablero y en su ficha, con la marca «desde WEBS…». Un filtro Todas / Propias / Entregadas separa lo suyo de lo que le llega.
• Cuenta en los dos hitos: el de la iniciativa (por ejemplo, «Fase 1») y el del producto («v2.3»). El progreso y el resumen con IA de cada hito la incluyen.
• Se ve también desde la iniciativa: en su listado, la columna Producto dice a qué producto y versión va cada tarea («apirest · v2.3»), y en su tablero cada tarjeta lleva la misma marca. La columna se oculta desde Columnas.

También puedes elegir el producto al crear la tarea, desde el formulario del listado de la iniciativa.

Una tarea, un repositorio

Cada tarea se entrega a un solo producto. Si una tarea toca dos repositorios (el front y el back), pártela: el botón Partir por repositorio de su ficha crea una sub-tarea por cada producto que elijas, ya entregada al suyo. Si una depende de la otra, relaciónalas con bloquea.

Quién ve y quién hace qué

Quien tiene acceso a un producto ve las tareas que le entregan, aunque no tenga acceso a la iniciativa. Ve esas tareas, no la iniciativa entera: ni sus otras tareas, ni sus hitos, ni sus documentos. En la ficha, la iniciativa aparece por su nombre, sin enlace.

Si además puede escribir en el producto, las implementa: cambia su estado, las comenta, imputa horas y las mete en un hito del producto. Lo que no puede es editar su contenido (título, descripción, prioridad, responsables…) ni cambiar a qué producto se entrega: eso es cosa de quien lleva la iniciativa.

Bloqueos entre repositorios y agentes

Cuando la tarea de back bloquea a la de front, el agente (o la persona) de front no puede empezar la suya antes de tiempo:

• La cola de agentes (next_ready_issue) no reparte una tarea bloqueada.
• claim_issue la rechaza y dice qué tarea la bloquea y en qué estado está.
• get_issue enseña cada relación con el estado de la otra tarea. Si no puede verla, solo su identificador y su estado.

En cuanto la de back pasa a terminada, la de front entra en la cola. Por el MCP, next_ready_issue y list_issues aceptan el projectId de un producto y traen también lo entregado. Más en API y MCP.

Asignación automática por el repositorio del PR

En la ficha de un producto, la fila Repos declara sus repositorios de GitHub o Bitbucket. Un repositorio solo puede estar en un producto.

Cuando llega un PR de uno de ellos enlazado a una tarea de una iniciativa que aún no tiene producto, la tarea se entrega sola a ese producto y queda un comentario que lo explica. Si la tarea ya iba a otro producto, no se cambia: se deja un comentario para que alguien lo revise.

Límites

• Todo funciona dentro del mismo workspace: una iniciativa no entrega tareas a productos de otro workspace.
• Solo las tareas de una iniciativa se entregan a un producto.