Tableros

Cada proyecto y cada solución tiene su tablero: el backlog convertido en trabajo del día a día.

La pantalla Tableros lista todos, con su avance, lo que está en curso y en revisión y el sprint activo, filtrable por Proyectos o Soluciones. El de un proyecto también se abre desde su ficha.

Tipos de ítem

Cada tipo tiene su familia de códigos, correlativa por tablero:

Tipo	Código	¿Es alcance?
Requerimiento funcional	RF-001	Sí
Requerimiento no funcional	RNF-01	Sí
Tarea técnica	T-01	No
Defecto	DEF-001	No
Deuda técnica	DEU-01	No
Pregunta	P-01	No

Solo los requerimientos (RF y RNF) cuentan para el avance y la estimación, y solo ellos necesitan un pedido de cambio después de la línea base. Un ítem puede tener serie de módulo: con la serie “CLI”, el código es RF-CLI-08.

El kanban

Cuatro columnas: Pendiente, En curso, En revisión y Terminado. Se mueve arrastrando la card (en el celular, con el selector de la card), y cada movimiento pasa por su regla (abajo).

La card muestra código, título, módulo, sprint, responsable, prioridad (el borde de color), si está bloqueado, criterios verificados, puntos de la Definición de Terminado, comentarios y estimación.

Filtros: búsqueda por código o título, sprint (el activo por defecto), responsable (“Lo mío” y “Sin asignar”), tipo y módulo. Quedan en la dirección, igual que el ítem abierto.

Tomar, revisar y terminar

Cada ítem tiene responsable y revisor, que tienen que ser personas distintas.

1. Tomar lo pasa a En curso a nombre de quien lo toma.
2. Pedir revisión exige un revisor y lo pasa a En revisión; al revisor le aparece en Mi trabajo.
3. Aprobar la hace alguien distinto del responsable. Pedir cambios exige el motivo y lo devuelve a En curso.
4. Terminar exige la nota de resolución (qué se hizo y cómo) y acepta los commits que lo resuelven.
5. Reabrir exige el motivo.

Hay un límite de ítems En curso por persona (2 por defecto, en Configuración → Tablero). Pasarlo pide confirmación.

Criterios de aceptación

Son una lista numerada (CA1, CA2…). Cada uno se marca verificado con su evidencia (el test que lo prueba, una demo, una captura), quién y cuándo.

Ajustar un criterio guarda la versión anterior, la nueva y el motivo, y el criterio queda pendiente de que el cliente lo valide. Con un ajuste pendiente, el ítem no se termina sin un motivo escrito.

Definición de Terminado

Cinco puntos por ítem:

1. Cumple sus criterios de aceptación.
2. Probado con pruebas funcionales.
3. Pasó revisión de código cruzada.
4. Sin errores ni deuda sin registrar.
5. Verificado en staging.

Cada punto está cumplido, pendiente a propósito (con una nota) o sin revisar. “Criterios” se cumple solo al verificarlos todos, y “Revisión”, solo cuando otra persona la aprueba. Para terminar, ninguno puede quedar sin revisar; se puede cerrar igual con un motivo, que queda escrito.

Dependencias

Un ítem depende de otros por su código. Mientras una dependencia no esté terminada, el ítem está bloqueado: la card lo muestra y tomarlo pide confirmación. No se aceptan dependencias circulares.

Comentarios y menciones

Cada ítem tiene un hilo de comentarios. Escribir @nombre le avisa a esa persona en Mi trabajo hasta que abre el ítem. La resolución, la aprobación, los cambios pedidos y la reapertura quedan en el hilo, distinguidos.

¿Qué sigo?

Propone lo próximo para tomar: pendientes sin dependencias abiertas, tuyos o sin asignar. Primero los del sprint activo, después por prioridad, con los defectos antes. Se pide por tablero o para todos.

Sprints

Un sprint tiene nombre, objetivo y fechas, y está Planificado, Activo o Cerrado. Hay a lo sumo uno activo por tablero; iniciarlo sin fechas le da dos semanas desde hoy. Al cerrarlo se guarda la foto (comprometido, completado y arrastrado) y lo no terminado pasa a otro sprint o al backlog.

Avance y métricas

• Burndown del sprint activo contra la línea ideal.
• Velocidad: días estimados completados por día hábil.
• Proyección de fin: la fecha esperada y la de 84 % de confianza.
• Por estado, por tipo, por módulo, bloqueados, tiempo de ciclo y estimado contra real.

Los días hábiles descuentan fines de semana y feriados.

El historial y git

Todo cambio queda en el historial del ítem, con quién, cuándo y por dónde (web, token o asistente de IA). Un ítem guarda vínculos a commits, ramas, PR o URLs. Un commit cuyo mensaje nombra un código (“RF-120”) se vincula solo a ese ítem.

Sincronizar con la SRS del repositorio

Si tu SRS vive en un archivo Markdown en el repositorio:

• Importar primero simula y muestra qué es nuevo, qué cambia, qué se saltea y qué está en el tablero pero no en la SRS. La SRS manda el contenido (título, módulo, descripción, prioridad y criterios); el tablero manda la ejecución (estado, responsable, sprint).
• Sincronizar devuelve la SRS con el estado de cada requerimiento igual al del tablero, sin tocar el resto del archivo.

Consejo

Lo más cómodo es hacerlo desde tu asistente de IA en el editor (Claude Code, Cursor): leé el archivo, importalo y, al terminar un requerimiento, sincronizalo. Ver Asistentes de IA.