Tres repositorios, un objetivo con fecha: iniciativas y productos en un caso real

Hay una pregunta que tarde o temprano se hace cualquier equipo con más de un repositorio: ¿dónde creo esta tarea? Si la creas en el proyecto de la API, quien sigue el objetivo no la ve. Si la creas en el proyecto del objetivo, quien mantiene la API no la tiene en su tablero. Y si toca los dos, la creas dos veces y rezas para que nadie cierre una sin la otra.

Para eso hemos añadido a Hilbana los tipos de proyecto: iniciativas y productos. Este artículo lo cuenta con un caso completo, de la configuración al día a día, con pantallazos de cada paso y un vídeo corto en los momentos clave.

El caso: un equipo, tres repositorios

Acme hace software de reservas para clínicas. Son pocos: Lucía lleva el producto, hay dos agentes de IA trabajando sobre el código y la web la mantiene un estudio externo. El código vive en tres repositorios, cada uno con su ritmo:

• API de reservas (acme/api), con sus versiones: la v2.3 sale a finales de mes.
• Web pública (acme/web), que publica la v1.4.
• App móvil (acme/app), camino de la v3.0.

Cada repositorio tiene su trabajo de siempre: actualizar dependencias, un pie de página que se descoloca en Safari, el modo oscuro de la app. Eso no se acaba nunca.

Este trimestre, además, hay un objetivo con fecha: Reservas online, que los pacientes reserven y paguen la cita desde la web y la app sin llamar al centro. Tiene dos fases y toca los tres repositorios. Y otro más pequeño, Recordatorios: avisos antes de la cita para que la gente no falte.

Lo que fallaba

Con un proyecto por repositorio, nadie podía decir cuánto le faltaba a Reservas online: sus tareas estaban repartidas entre tres tableros. Con un proyecto «Reservas online», la API no veía en su tablero el endpoint de pagos que tenía que hacer, y su versión v2.3 no lo contaba. Las etiquetas lo arreglaban a medias, hasta que alguien olvidaba ponerlas.

Y había dos problemas nuevos. El agente que trabaja en la web cogía el formulario de pago antes de que existiera el endpoint del que depende. Y para que el estudio de la web viera sus tareas, había que darle acceso a todo el objetivo, incluidas las tareas de la API y de la app.

La idea: el trabajo vive en la iniciativa y se entrega al producto

Hilbana distingue dos tipos de proyecto:

• Iniciativa: un objetivo con principio y fin. Reservas online, Recordatorios.
• Producto: un repositorio (o un producto) que no se cierra nunca. La API, la web, la app.

Cada tarea vive en la iniciativa, que es donde se decide qué hay que hacer, y se entrega al producto donde se implementa. Desde la iniciativa se sigue el objetivo. Desde el producto, lo que hay que programar. La tarea es una sola y conserva su identificador, así que la rama y el PR se enlazan igual que siempre.

Si tu equipo trabaja con un solo repositorio, no tienes que hacer nada: un proyecto sin tipo funciona como hasta ahora.

1. Pon el tipo a cada proyecto

Con clic derecho sobre el proyecto en la barra lateral, el menú tiene Tipo de proyecto: Iniciativa o Producto.

Antes de aplicarlo, Hilbana te avisa de que el tipo es definitivo: no se puede cambiar ni quitar. Es así porque de él dependen las entregas; un producto que dejara de serlo dejaría sin sitio las tareas que le han entregado. Antes de elegir, piensa si ese proyecto es un objetivo que terminará o un repositorio que seguirá ahí.

Acme marca la API, la web y la app como productos, y Reservas online y Recordatorios como iniciativas. En la barra lateral, cada iniciativa lleva una diana y cada producto, una caja.

2. Declara el repositorio de cada producto

En la ficha de cada producto, la fila Repos dice qué repositorios de GitHub o Bitbucket le pertenecen. La API declara acme/api, la web acme/web y la app acme/app. Un repositorio solo puede estar en un producto. Más abajo verás para qué sirve.

Fíjate en los milestones de la API: v2.3 va por 2 de 4 tareas. Dos de ellas no se crearon en la API: le llegaron de Reservas online.

3. Entrega cada tarea a su producto

En una tarea de una iniciativa aparece el campo Producto, que se elige en dos pasos. Primero, el producto donde se implementa:

Después, si ese producto tiene milestones, en cuál entra. Son los del producto, no los de la iniciativa:

El campo muestra los dos juntos. La tarea sigue en su fase de la iniciativa (Fase 2) y, a la vez, en la versión del producto (v2.4). Cuenta en los dos milestones.

Si la tarea ya sabes dónde va al crearla, el formulario rápido del listado de la iniciativa tiene su propio selector de producto.

4. Si toca dos repositorios, pártela

«Cancelar una reserva desde el correo» toca la API (el enlace con su token) y la web (la página de cancelación). Una tarea se entrega a un solo producto, así que esta se parte: el botón Partir por repositorio de su ficha pregunta a qué productos afecta.

Crea una sub-tarea por producto, ya entregada al suyo, bajo la tarea original. La original queda como paraguas en la iniciativa; cada parte la programa quien tiene ese repositorio.

5. El producto ve lo suyo y lo que le llega

En el tablero de la API conviven sus tareas de mantenimiento y las que le entregan las iniciativas. Estas llevan la marca de origen, «desde Reservas online» o «desde Recordatorios», y conservan su identificador (RES-23, REC-32).

El filtro Todas / Propias / Entregadas separa una cosa de la otra. Con «Entregadas», la API ve de un vistazo todo lo que le piden las iniciativas:

Y la versión del producto cuenta las dos cosas. La v2.3 de la API incluye la actualización de dependencias (propia) y el endpoint de pagos (de Reservas online). El progreso, el consumo de tokens y el resumen con IA de la versión salen de todas.

6. Dependencias entre repositorios, también para los agentes

El formulario de pago (web) necesita el endpoint de pagos (API). En la iniciativa se relacionan con bloquea: la tarea de la web queda «Bloqueada por RES-23».

Hasta aquí, nada nuevo para una persona. La diferencia está en los agentes. El endpoint lo tiene entre manos el agente de la API:

El agente de la web pide trabajo de su producto por el MCP y la cola no le da el formulario, aunque esté marcado como listo para agente. Si lo pide por su nombre, Hilbana se lo niega y le dice por qué:

next_ready_issue { "projectId": "<Web pública>" }
→ null

claim_issue { "id": "RES-24" }
→ 409: la issue está bloqueada por RES-23 (In Progress): no se puede
  reclamar hasta que estén terminadas o canceladas

En cuanto el agente de la API pasa el endpoint a Done, el formulario entra en la cola de la web. Nadie tiene que avisar a nadie.

7. El estudio externo solo ve la web

Marcos trabaja en un estudio de diseño que mantiene la web. En Hilbana es invitado con acceso a un solo proyecto: Web pública. En su barra lateral no hay nada más.

Aun así, en el listado de la web ve las tareas que le ha entregado Reservas online:

Ve esas tareas, no la iniciativa entera. En la ficha, Reservas online aparece por su nombre, sin enlace, y el milestone de la iniciativa no se le muestra. Puede cambiar el estado, comentar e imputar horas, porque es quien la implementa, pero no reescribir la tarea. Eso es cosa de quien lleva la iniciativa.

8. Que el PR entregue la tarea solo

«Correo de confirmación de la reserva» se creó en la iniciativa sin decidir dónde se haría. Lucía no tiene que volver a ella: en cuanto alguien abre un PR desde acme/api con la rama de la tarea, Hilbana ve que ese repositorio es de la API y se la entrega a la API, la pasa a en curso y adjunta el PR.

Si la tarea ya iba a otro producto, no se cambia: queda un comentario para que alguien lo revise.

9. Y la iniciativa, de un vistazo

Volvamos a la pregunta del principio: ¿cuánto le falta a Reservas online? Ahora tiene respuesta en un solo sitio. El resumen de la iniciativa suma todas sus tareas, se implementen donde se implementen. Fase 1 va por 1 de 6, y con 70 días por delante y un 10 % hecho, Hilbana la marca en riesgo.

El listado de la iniciativa enseña el objetivo entero: las tareas de la API, de la web y de la app, y también las que no son de código, como la política de cancelación. La columna Producto dice a qué repositorio va cada una y en qué versión entra; las que aún no lo tienen decidido se ven enseguida. En el tablero de la iniciativa, cada tarjeta lleva la misma marca.

En resumen

• Iniciativa para lo que termina; producto para lo que no.
• La tarea vive en la iniciativa y se entrega a un producto, con su versión. Cuenta en los dos sitios.
• Una tarea, un repositorio: si toca dos, pártela.
• Los bloqueos valen entre repositorios, y los agentes los respetan.
• Quien solo tiene el producto ve lo que le llega, no el resto de la iniciativa.
• Declara los repositorios y el PR entrega la tarea solo.

Todos los detalles, incluidos los permisos y el MCP, están en la documentación de iniciativas y productos.

Crea tu espacio gratis en app.hilbana.com/signup y prueba a partir tu próximo objetivo por repositorios.