sinra¿Qué es una Issue?
Una issue representa un trabajo concreto: un bug que corregir, una tarea que construir, una especificación que redactar. Cada entregable en Sinra se rastrea hasta una issue.
A diferencia de los formatos tradicionales de “user story” con estructura rígida, las issues de Sinra usan nombres directos y descriptivos. “Exportación CSV de informes” es más útil que “Como usuario, quiero exportar informes para poder analizar datos.”
Tipos de Issues
| Tipo | Cuándo usarlo | Estado que lleva |
|---|---|---|
| Especificación (specification) | Dice qué habrá que verificar: el requisito, por escrito | Estado de redacción |
| Plan (plan) | Opcional. Dice cómo se construirá la especificación | Estado de redacción |
| Tarea (task) | Una unidad de trabajo de implementación | Estado de desarrollo |
| Bug (bug) | Un defecto a corregir | Estado de desarrollo |
El tipo se elige al crear la issue, desde el menú New, y no se puede cambiar después. El botón New global crea un bug.
Especificaciones, planes, tareas y bugs siguen las mismas reglas de planificación: pueden estar en una capability, una release y un ciclo. Lo que cambia es el estado que llevan, cómo cuentan en la capacidad y los vínculos que aceptan. La página Trazabilidad explica cómo se conectan.
Campos Principales
- Nombre: título conciso y descriptivo
- Cuerpo: texto enriquecido con imágenes y
@menciones - Prioridad: Baja, Media, Alta
- Tiempo estimado: en días, alimenta los cálculos de capacidad
- Labels: etiquetas personalizadas por organización
- Plataforma: Backend, Frontend, Mobile, etc.
Asignación
Las issues se pueden asignar a un usuario específico o a un equipo completo. Cuando se asigna a un equipo, cualquier miembro del equipo puede tomarla.
Un Estado por Tipo
Una issue lleva exactamente un estado, el que corresponde a su naturaleza:
| Tipo | Estado | Por qué |
|---|---|---|
| Especificación, plan | Estado de redacción (writing status) | Se redactan, se revisan y se aprueban |
| Tarea, bug | Estado de desarrollo (development status) | Se implementan, se prueban y se cierran |
El formulario, la ficha de la issue y las listas solo muestran el estado que aplica. Una nueva issue empieza en el estado inicial de su tipo.
La Realización
Una especificación o un plan nunca tiene un estado de desarrollo propio. Su realización (realization) se calcula a partir de sus tareas y se muestra junto a su estado de redacción:
| Realización | Cuándo |
|---|---|
| Not started | Ninguna tarea, o todas las tareas siguen pendientes |
| In progress | Al menos una tarea ha empezado, pero no todas están terminadas |
| Done | Al menos una tarea, y todas están terminadas |
La realización va acompañada del número de tareas terminadas sobre el total (por ejemplo 2/5). Una especificación cuenta todas sus tareas, las enlazadas directamente y las que están bajo sus planes. Nunca escribes la realización: sigue a las tareas.
“Terminada” para una especificación abarca por tanto dos preguntas distintas: ¿está redactada (estado de redacción)? y ¿está construida (realización)? Un ciclo cuenta la primera.
La Cadena de Diseño: el Vínculo Padre
Un plan o una tarea puede indicar qué issue realiza, mediante su Parent issue:
- Un plan tiene como padre una especificación.
- Una tarea tiene como padre un plan o una especificación.
- Una especificación y un bug no tienen padre.
El padre siempre es opcional, y padre e hijo siempre están en la misma capability. Elegir un padre vincula la issue a la capability del padre. Si un padre cambia de capability, sus hijos lo siguen.
La ficha de una issue muestra la cadena como un árbol: los ancestros, la issue, y luego sus planes y tareas, con tipo, nombre, estado y realización. La ficha de una especificación indica cuántas tareas están terminadas sobre el total, y una acción Add a plan o Add a task abre el formulario de creación con el padre y la capability ya rellenados.
Eliminar dentro de una Cadena
Una eliminación nunca deja huérfanas:
- Eliminar un plan cuyo padre es una especificación: sus tareas suben y se vinculan a la especificación.
- Eliminar una issue cuyos hijos no tienen adónde subir (una especificación con planes o tareas, un plan sin padre con tareas) se rechaza. El mensaje indica el número de issues vinculadas. Muévelas o elimínalas primero.
Release y Release Deseada
Una issue dentro de una capability siempre tiene la release, y la release deseada, de esa capability. Ambos campos son de solo lectura en el formulario e indican de dónde viene el valor (“Inherited from” la capability). Una issue sin capability elige su release libremente. Consulta Releases para la regla completa.
Concerns: un Vínculo para Issues Fuera de una Capability
Un bug encontrado después de la entrega no puede entrar en la capability de origen: tomaría una release ya entregada. Una issue sin capability puede, en cambio, declarar la capability que Concerns. Este vínculo es solo informativo: no cambia la release de la issue ni ninguna cifra de progreso, carga o capacidad. Desaparece en cuanto la issue se vincula a una capability.
Seguimiento del Tiempo
Registra el tiempo empleado directamente en una issue. Sinra compara el tiempo empleado con la estimación, mostrando los excesos antes de que se conviertan en sorpresas. Estas cifras alimentan el cálculo de carga del ciclo. El tiempo se guarda en cuanto sales del campo (Intro, Tab o un clic fuera) y aparece una breve confirmación. Un valor negativo se rechaza con un mensaje, y lo que escribiste permanece en el campo.
Su rol en una tarea
Una persona puede estar vinculada a una tarea de cuatro maneras: asignada a la tarea, asignada mediante su equipo, creadora de la tarea, o tester. «Mis tareas» muestra la primera por defecto y permite elegir otra.
Elegir una capability de una release pasada
El selector de capability de una tarea ofrece todas las capabilities, incluidas las de una release pasada, que van al final y llevan la marca «Release pasada: v0.9». Elegir una hace que la tarea siga esa release, como con cualquier capability.
Aviso de duplicado
Al crear una tarea, escribir un título de al menos 8 caracteres busca tareas abiertas con un título cercano, sea cual sea el orden de las palabras («Seguimiento insignia empresa» encuentra «Insignia empresa: seguimiento»). Un aviso enlaza con tres como máximo, cada una en una pestaña nueva. No bloquea nada: aún puede crear la tarea.
Comentarios y Menciones
Cada issue tiene una sección de comentarios con texto enriquecido y @menciones. Mencionar a un usuario dispara una notificación por email con todo el contexto. La discusión permanece unida al trabajo, no perdida en Slack.
Las menciones llegan a tu centro de notificaciones: el contador de la barra superior, un enlace que abre el comentario exacto y una casilla Esperar una respuesta para seguir las preguntas hasta que se respondan.
El botón Publicar envía el comentario; un comentario vacío, o solo con espacios, se rechaza con un mensaje (una @mención sola cuenta como contenido). En el menú @, Intro o Tab inserta a la persona seleccionada sin borrar lo que escribiste; los miembros desactivados no se ofrecen. Los comentarios largos se ajustan en lugar de cortarse.
El tipo de una issue se fija en la creación. Al editarla, se muestra en solo lectura.
Creada desde una acción
Una issue puede crearse desde una acción de una retrospectiva o de un postmortem (Convertir en issue). El formulario llega rellenado y totalmente editable: título, enlace al origen, tipo (una tarea desde una retro, un bug desde un postmortem), asignado, release y ciclo. La página de la issue muestra entonces «Creada desde la acción … de …» con un enlace, o «origen eliminado» si la retro o el postmortem ya no existe.
Desde ese momento la acción sigue a la issue: hecha cuando la issue termina, abandonada cuando se desactiva, de nuevo en curso cuando se reabre. Eliminar la issue devuelve a la acción su estado anterior y quita el vínculo. Una acción se convierte en una sola issue: convertirla otra vez crea la issue sin vínculo y se lo indica.