Desarrollo basado en especificaciones en Jira
El desarrollo basado en especificaciones significa escribir una especificación estructurada antes de que un agente haga un compilación, para que compile lo correcto en lugar de una suposición plausible. En Jira, esa especificación se encuentra en la actividad en la que ya trabajas, una vez que tiene una intención real: resultados, alcance, restricciones y criterios de aceptación. Una actividad puede contener la especificación completa de una tarea, o una parte de la especificación de una función más amplia dividida en varias actividades.
En esta guía se explica qué hace que una especificación esté lista para el agente, por qué la actividad es el inicio adecuado para ella y cómo escribir la primera. En resumen, el desarrollo basado en especificaciones en Jira te ofrece tres cosas:
Una única fuente de información en la que se basa el agente y que el revisor usar para comparar.
Criterios de aceptación que definen el estado "Finalizado" tanto para el agente como para la persona.
Menos necesidad de repetir trabajo, ya que la intención se define antes de que el agente escriba una línea de código.
¿Qué es el desarrollo basado en especificaciones?
El desarrollo basado en especificaciones es una práctica en la que escribes una especificación estructurada que define qué compilar y cómo se mide el éxito, y el agente la implementa, en lugar de adivinar a partir de un prompt de una sola línea.
La especificación se convierte en la fuente de la información. Dirige el plan, la compilación y la comprobación, y en Jira los tres tienen lugar en la misma actividad. La idea es anterior a la IA, ya que surgió del diseño de API y de la práctica de métodos formales, donde defines el comportamiento antes de la compilación.
La definición sigue cambiando a medida que las herramientas maduran, así que trátalo como una práctica, no como un formato de especificación fijo. Lo que se mantiene constante es el paso fundamental: definir la actividad antes de que el agente la cree.
La diferencia radica en cuándo se resuelve la ambigüedad. El vibe coding resuelve el problema una vez escrito el código; el desarrollo basado en especificaciones lo resuelve antes.
Vibe coding: guías al agente con prompts y aceptas lo que te devuelve, por lo que el alcance, las restricciones y los casos extremos que asume salen a la luz una vez escrito el código.
Basado en especificaciones: primero estableces la intención, las restricciones y los criterios de aceptación para que el agente cree basándose en una definición en lugar de una suposición, y la revisión se compruebe con esa misma definición en la actividad donde se encuentra.
Para el código que tiene que sobrevivir en una base de código real, un agente sin un contexto establecido puede resolver el ticket de forma demasiado literal y pasar por alto la restricción que importaba. Ahí es donde empieza la reelaboración.
Dos cosas que los prompts tienden a confundir: la especificación es lo que estás creando, el plan es cómo se crea. El desarrollo basado en especificaciones define primero el qué y luego construye el cómo a partir de ahí. Ese es el paso que el modo de planificación en las herramientas de programación con IA suele omitir: esboza el cómo directamente a partir de un prompt, por lo general sin una especificación acordada que lo respalde.
El modo Plan puede servir como una especificación ligera, pero redacta el “cómo” a partir de una prompt en el momento, no de una especificación acordada que persista en la actividad.
Por qué son importantes las especificaciones para la programación con IA
Cuando la generación de código se vuelve barata, la parte difícil ya no es escribir código. Es definir lo correcto para la compilación. Eso hace que la especificación, no el prompt, sea el artefacto de mayor impacto que produces.
Un prompt de un solo intento deja los vacíos al agente, que los llena con suposiciones y produce código que parece correcto pero resuelve el problema equivocado. Una especificación cierra esas brechas primero, de modo que el agente cree hacia una definición en lugar de una suposición. En Jira, esa especificación es la actividad que tu equipo ya planifica, asigna y revisa.
¿Qué incluye una especificación que un agente pueda usar para la compilación?
Una especificación lista para agentes responde a las preguntas que un buen ingeniero haría antes de empezar. En Jira, estas se encuentran en el resumen, la descripción, los requisitos vinculados y los criterios de aceptación de la actividad. Hay seis elementos importantes:
Resultados: lo que el cambio debería lograr, en términos que un revisor pueda comprobar.
Alcance: qué se incluye y, lo que es igual de importante, qué queda fuera.
Restricciones: los límites de arquitectura, seguridad y rendimiento que se deben respetar.
Decisiones previas: el contexto ya está establecido, por lo que el agente no vuelve a discutirlo.
Desglose de tareas: la actividad dividida en pasos lo suficientemente pequeños para verificarlos.
Criterios de aceptación: la definición de hecho comprobable hacia la que trabaja el agente y con la que se le evalúa. En Jira, residen en la actividad, y una revisión de código de IA puede verificar el cambio frente a estos antes de que llegue a una persona.
Cómo la actividad se convierte en la especificación en Jira
Una actividad bien estructurada puede servir como la especificación en la que el agente se basa para construir y revisar. Las especificaciones también pueden almacenarse en un documento vinculado, que es como funcionan muchas herramientas de SDD; Jira simplemente permite que se almacenen allí donde ya se lleva a cabo el trabajo. Se considera de grado de especificación cuando incluye los seis elementos anteriores. Una actividad de una sola línea de “solucionar el error de inicio de sesión” no.
Mantener la especificación en la actividad tiene una ventaja estructural: se encuentra donde la actividad ya reside, por lo que es más difícil de abandonar que un archivo markdown en un repositorio que nadie vuelve a abrir. Eso no significa que se mantenga por sí sola, sino que la especificación y la actividad nunca se separan.
Todo va de la mano: resumen, descripción, requisitos de Confluence vinculados y criterios de aceptación, en un solo lugar que leen tanto el agente como el revisor.
Un archivo de repositorio, por el contrario, se encuentra separado del lugar donde se realiza un seguimiento de la actividad, se revisa y se cierra, por lo que queda obsoleto en el momento en que cambia el plan.
La misma actividad se convierte en el espacio de revisión una vez que el agente ha terminado, el lugar donde tu equipo se alinea sobre los requisitos y las preguntas abiertas.
Jira define planes con requisitos, tareas y estimaciones claros e integrados.
Cómo Planificador de Jira genera una especificación estructurada
En la sección anterior se ha abordado lo básico: cómo convertir tú mismo una actividad en una especificación. Planificador de Jira es para iniciativas complejas que abarcan varios equipos, donde escribir cada especificación a mano no escala. Parte de la iniciativa y la desglosa en actividades estructuradas, cada una con su propia especificación.
Planificador de Jira es el acelerador, no la línea base. El método SDD de línea base es una actividad bien formada más los criterios de aceptación, y todos los equipos pueden hacerlo hoy. Planificador de Jira acelera la parte más difícil de esa actividad: convertir una solicitud compleja y ambigua en una especificación estructurada.
Para proyectos complejos, Planificador de Jira utiliza Teamwork Graph, incluidos tu código base, el historial de Jira y Confluence, y el contexto del equipo, para definir los requisitos y generar una especificación técnica estructurada en Confluence, lista para su compilación por parte de un desarrollador o agente de programación. Un plan, muchas audiencias: legible para una persona, útil para un agente.
Para qué sirve:
Proporciona un espacio compartido para que tú y tu equipo colaboren y se alineen previamente antes de que se ejecute un agente.
Extrae contexto de toda tu actividad para que la especificación comience a partir de lo que tu equipo ya sabe en lugar de un prompt en blanco.
Produce una especificación que una persona puede leer con claridad y un agente puede analizar sin problemas, de modo que el mismo artefacto sirve para la revisión y la ejecución.
Mantiene la especificación en Confluence, vinculada a la actividad, para que la intención y las decisiones queden registradas.
Planificador de Jira convierte las ideas preliminares en especificaciones estructuradas y listas para agentes
Planificador de Jira está en acceso anticipado; regístrate en la lista de espera
Cómo redactar tu primera especificación lista para agentes en Jira
Toma una actividad y conviértela a mano en una especificación lista para el agente con los seis elementos como tu lista de comprobación.
Empieza a partir de una actividad. Captura el resultado, los límites del alcance y las restricciones en la descripción, no solo un título.
Convierte la intención en una especificación estructurada. Esta es la verdadera actividad de SDD. Transforma el contexto previo en resultados, alcance y restricciones de la actividad para que el agente herede una definición.
Escribe criterios de aceptación evaluables. Estos son los contratos que el agente elabora y que el revisor comprueba. La mayoría de los criterios suelen requerir varias pasadas antes de que se puedan comprobar.
Asígnaselo a un agente de programación. Una actividad con nivel de especificación le da al agente lo suficiente para implementar y abrir una solicitud de extracción vinculada al elemento.
Revisa la solicitud de extracción según los criterios y luego ajústala. Ajusta la especificación donde el agente adivinó y reutiliza el patrón en la siguiente actividad.
Preguntas frecuentes sobre el desarrollo basado en especificaciones
¿Necesito Planificador de Jira para llevar a cabo un desarrollo basado en especificaciones?
No. La línea base es una actividad bien formada con criterios de aceptación que cualquier equipo puede escribir hoy. Para la actividad compleja, Planificador de Jira la acelera comenzando desde un plan de nivel superior, una iniciativa, y dividiéndola en actividades estructuradas de Jira, cada una con sus especificaciones completadas, para que no tengas que escribir cada una a mano.
¿Cuál es la diferencia entre una especificación y los criterios de aceptación?
La especificación define todo el cambio: resultados, alcance, restricciones y contexto. Los criterios de aceptación son una parte, la definición de terminado comprobable hacia la que el agente construye y contra la que el revisor verifica.
¿Es suficiente un prompt realmente bueno?
Para una actividad pequeña y reversible, a menudo sí. Para cualquier cosa compleja o difícil de deshacer, un prompt hace que el agente adivine lo que omitiste. Una especificación elimina las conjeturas.
¿La especificación debería estar en un archivo del repositorio o en una actividad de Jira?
Una actividad mantiene la especificación donde la actividad se supervisa, se revisa y se cierra. Por eso es menos probable que se desvíe que un archivo markdown en un repositorio que nadie vuelve a abrir.
¿El desarrollo basado en especificaciones ralentiza a los equipos?
Añade esfuerzo al principio y elimina la reelaboración más adelante. En la actividad compleja, ese intercambio es una ganancia neta. En correcciones triviales, omite la especificación y escribe el prompt directamente.
¿Cuándo debo redactar una especificación y cuándo puedo prescindir de ella?
Escribe una para una actividad compleja, de alto impacto o difícil de revertir, o cualquier cosa con restricciones reales de arquitectura o seguridad. No la utilices para pequeñas correcciones reversibles en las que sea más rápido usar un prompt rápido.