Equipos de software: errores, historias y una puerta de lanzamiento
Un cambio de software en Tasked no es una tarjeta de color. Los errores incluyen gravedad y pasos para reproducirlos, las historias incluyen criterios de aceptación, las épicas contienen historias y el paquete de software finaliza con una aprobación de lanzamiento de la que el motor no dejará salir el trabajo sin una decisión registrada. La revisión de código puede devolver el elemento a en progreso con la etiqueta de cambios solicitados. QA puede retenerlo hasta que se realice la comprobación de aceptación. Nada de eso es un plugin.
Los tipos que un equipo de software realmente rellena
Un error solicita la gravedad (bloqueante, grave, leve o estético), los pasos para reproducirlo y dónde se ha encontrado. Una historia solicita criterios de aceptación y puntos de historia. Una épica solicita un objetivo y una fecha objetivo. Los campos personalizados amplían cualquiera de ellos cuando el equipo necesita más.
La jerarquía está integrada: una épica contiene historias y una historia contiene tareas. Esto se muestra en la interfaz, no se deja como una mera convención de nomenclatura.
- Error: gravedad, pasos para reproducir, encontrado en
- Historia: criterios de aceptación, puntos de historia
- Épica: objetivo, fecha objetivo
Cuatro paquetes, un solo motor
El paquete de software ejecuta la recepción, el triaje, en progreso, la revisión de código, QA y la aprobación de lanzamiento, y luego finalizado. La recepción y el triaje tienen un plazo de 24 horas cada uno. En progreso tiene 72 horas. La revisión de código es una fase de revisión de 24 horas. QA es trabajo de 48 horas. La aprobación de lanzamiento es una fase de aprobación de 24 horas, propiedad de producto, con en progreso como fase de corrección.
El paquete de sprint ejecuta backlog, seleccionado, en progreso, revisión de código, QA y finalizado, y un sprint también es un objeto en el proyecto: un nombre, un objetivo, un inicio y un fin, con solo uno activo a la vez. No hay ninguna puerta de aprobación en ese paquete, y es a propósito: un sprint que se cierra en finalizado tiene una forma diferente a la de un cambio que debe aprobarse formalmente. El paquete de corrección de errores ejecuta triaje, reproducir, corregir, verificar y lanzado. El paquete de lanzamiento ejecuta corte, staging, firma, producción y notas, con la firma como aprobación.
Transiciones que se deniegan
Una tarjeta no puede salir de recepción o triaje hasta que se haya completado su lista de comprobación. La revisión de código tiene una ruta de retorno a en progreso etiquetada como cambios solicitados. QA no puede pasar a aprobación de lanzamiento hasta que se realice la comprobación de aceptación. La aprobación de lanzamiento no puede pasar a finalizado hasta que se registre la decisión. Una solicitud de cambios en esa puerta devuelve el elemento a en progreso.
Esa es la diferencia entre un tablero donde cualquiera puede arrastrar una tarjeta a Finalizado y un flujo de trabajo donde se permite pasar a Finalizado.
Carencias honestas para compradores de software
Cuatro de las carencias que solía enumerar esta sección ya se han solucionado. Un sprint es un objeto con un nombre, un objetivo, un inicio y un fin (uno activo por proyecto) y un backlog con todo lo que queda fuera de él; al cerrar un sprint, los elementos inacabados se trasladan al siguiente o se devuelven al backlog, y se registra cuál de las dos opciones se ha elegido. Las etiquetas se asignan al elemento y filtran cada vista. El tiempo se registra como entradas escritas asociadas a un elemento el día en que se realizó el trabajo, y se suma a una semana personal y a un total del proyecto frente a las estimaciones. El enlace entre dos incidencias está tipificado: se relaciona, duplica o clona, dejando el bloqueo a la dependencia que el flujo de trabajo ya detecta.
Lo que todavía falta es el alojamiento de código. Un revisor puede marcar líneas en un diff o un parche que alguien suba, y la nota aparecerá junto a sus propias líneas. No hay un panel de código: nada en Tasked muestra un repositorio, una rama, una pull request o un commit, y GitHub no está integrado. Tampoco hay un diagrama de Gantt con flechas de dependencia. Tasked admite un subconjunto limitado de consultas compatibles con JQL sobre campos de tareas registrados. Las vistas guardadas siguen utilizando árboles de filtros validados, y el producto no implementa la gramática ni las funciones completas de Jira.
La API pública utiliza claves con ámbito. Los webhooks incluyen un registro de entrega. OpenAPI y una página para desarrolladores describen la interfaz. Estas funciones están disponibles en el plan Business.
Preguntas frecuentes
- ¿Existe un objeto de sprint?
- Sí. Un sprint tiene un nombre, un objetivo, un inicio y un fin, de los cuales solo uno está activo por proyecto a la vez, y todo lo que queda fuera de un sprint se encuentra en el backlog del proyecto. Al cerrar un sprint, los elementos inacabados se trasladan al siguiente o se devuelven al backlog, y se registra cuál de las dos opciones se ha elegido.
- ¿Bloquea la transición la puerta de lanzamiento?
- Sí. Una fase de aprobación abre la aprobación al entrar y deniega la salida hasta que se registre una decisión.
- ¿Puede una historia contener tareas?
- Sí. Una épica contiene historias y una historia contiene tareas. Esa jerarquía está integrada en los tipos de elementos de trabajo.
- ¿Hay JQL?
- Tasked admite un subconjunto limitado de consultas compatibles con JQL sobre campos de tareas registrados. No es el JQL completo de Jira; las vistas guardadas siguen almacenando árboles de filtros validados, y la búsqueda en lenguaje natural funciona en tareas, proyectos, comentarios y archivos.
- ¿Se puede revisar código en Tasked?
- Se puede revisar, línea por línea, un diff o un parche que alguien suba: la nota se ancla a las líneas en las que se escribió y aparece junto a ellas. No hay conexión con un alojamiento de código, por lo que no hay repositorio, rama, pull request ni commit.