Planificación adecuada del desarrollo de software: de los prompts a Spec Kit

La mayoría de los problemas de planificación en ingeniería no se deben a la falta de tickets.

Se deben a transiciones poco claras.

Una idea se convierte en requisito demasiado tarde. Un requisito se convierte en un plan técnico sin suficiente rigor. Un plan técnico se convierte en trabajo de implementación antes de que el equipo haya acordado los riesgos, las restricciones, las pruebas o los responsables. Luego se culpa a la implementación por problemas que ya estaban presentes en los artefactos de planificación.

Esta investigación parte de una pregunta práctica:

¿Qué debe conocerse, documentarse, aclararse, evaluarse, aprobarse y probarse antes de que comience el desarrollo?

La respuesta no es «escribir más documentos».

La respuesta es:

• crear el conjunto mínimo de artefactos necesario para hacer explícitas las decisiones
• preservar la trazabilidad desde la intención de negocio hasta la evidencia de las pruebas
• separar los requisitos de producto del diseño técnico
• exigir que las dudas se aclaren antes de la implementación
• hacer que la descomposición en tareas pueda revisarse antes de empezar a programar
• usar prompts como un sistema operativo manual cuando aún no se cuenta con herramientas
• usar un flujo de trabajo estructurado cuando se necesita velocidad, consistencia y repetibilidad

El 29 de abril de 2026, revisé fuentes vigentes de GitHub, NIST, The Scrum Guide, Agile Alliance, el manual de ingeniería de sistemas de NASA, SWEBOK y el repositorio de GitHub Spec Kit. Los enlaces a las fuentes aparecen al final.

TL;DR

• La planificación adecuada del desarrollo de software necesita una cadena clara que vaya del problema a los requisitos, al análisis, al plan, a las tareas, a la implementación y a la evidencia de las pruebas.
• Los documentos principales son:
  • principios del proyecto
  • caso de negocio o descripción del problema
  • especificación de la funcionalidad
  • registro de aclaraciones
  • documento de requisitos
  • criterios de aceptación
  • plan técnico
  • evaluación de riesgos y dependencias
  • estrategia de pruebas
  • lista de tareas de implementación
  • plan de lanzamiento y reversión
  • registro de decisiones
• Puedes llevar a cabo todo el proceso manualmente con prompts, pero debes ser disciplinado con los artefactos y los puntos de aprobación.
• El proceso manual basado solo en prompts funciona mejor cuando cada prompt produce un artefacto y una decisión.
• Spec Kit mejora el flujo de trabajo al dar a esa misma secuencia de planificación una estructura de comandos repetible: constitution, specify, clarify, plan, tasks, analyze, implement y listas de verificación de apoyo.

Qué significa «planificar adecuadamente»

Planificar adecuadamente no es prometer que el plan nunca cambiará.

Significa que el equipo puede responder estas preguntas antes de la implementación:

• ¿Qué problema estamos resolviendo?
• ¿A quién afecta?
• ¿Qué resultado buscamos cambiar?
• ¿Qué está explícitamente dentro del alcance?
• ¿Qué está explícitamente fuera del alcance?
• ¿Qué requisitos son funcionales?
• ¿Qué requisitos son no funcionales?
• ¿Qué supuestos siguen sin resolverse?
• ¿Qué restricciones técnicas ya se conocen?
• ¿Qué riesgos podrían cambiar el enfoque de implementación?
• ¿Qué pruebas demuestran que el trabajo está terminado?
• ¿Qué documentación o aprobaciones se requieren antes del lanzamiento?

Esto coincide con un principio de larga data en la ingeniería de requisitos: los requisitos deben identificarse, analizarse, especificarse, validarse y gestionarse. SWEBOK describe el trabajo con requisitos como algo más que escribir una lista; incluye la identificación, el análisis, la especificación, la validación y consideraciones prácticas como el proceso y las herramientas.

En términos más sencillos de entrega:

la planificación es adecuada cuando produce decisiones sobre las que los ingenieros pueden construir con confianza.

El conjunto de artefactos que necesita todo trabajo de desarrollo

No todos los proyectos necesitan un paquete enorme de documentos.

Pero todo trabajo de desarrollo serio necesita alguna versión de estos artefactos.

1. Principios del proyecto

Este es el documento breve que establece las reglas generales.

Debe definir:

• prioridades de producto
• estándares de ingeniería
• principios de arquitectura
• expectativas de seguridad
• expectativas de pruebas
• expectativas de documentación
• reglas de revisión y aprobación

Esto evita volver a debatir las mismas preguntas para cada funcionalidad.

Ejemplos de decisiones:

• «Toda funcionalidad visible para los usuarios debe definir criterios de aceptación antes de su implementación».
• «Todo cambio que afecte la autenticación, la facturación o la exportación de datos requiere una revisión de riesgos».
• «Ninguna funcionalidad está completa sin pruebas automatizadas o una excepción de pruebas explícitamente aprobada».
• «Las rutas sensibles al rendimiento deben incluir mediciones de referencia y posteriores al cambio».

2. Descripción del problema

Este documento explica por qué existe el trabajo.

Debe incluir:

• problema actual
• usuarios afectados
• impacto de negocio u operativo
• evidencia del problema
• resultado deseado
• objetivos excluidos
• métricas de éxito

Todavía no es la especificación de la funcionalidad. Es la razón por la que la funcionalidad merece tiempo de ingeniería.

3. Especificación de la funcionalidad

Este es el contrato sobre lo que experimentará el usuario.

Debe describir:

• perfiles de usuario o actores
• recorridos de usuario
• requisitos funcionales
• requisitos no funcionales
• casos límite
• estados de error
• entradas y salidas de datos
• requisitos de accesibilidad
• expectativas de privacidad y seguridad
• necesidades de analítica u observabilidad

Las buenas especificaciones de funcionalidades evitan los detalles de implementación, a menos que la elección de implementación sea en sí misma un requisito.

4. Registro de aclaraciones

La mayoría de los equipos no documenta suficientemente la incertidumbre.

Un registro de aclaraciones recoge:

• preguntas sin responder
• decisiones tomadas
• responsable de cada decisión
• fecha de respuesta
• impacto si no se responde

Esto importa porque la ambigüedad oculta es una de las mayores fuentes de retrabajo.

5. Inventario de requisitos

Los requisitos deben estar numerados o tener un nombre para que se pueda darles seguimiento.

Ejemplo:

La clave no es el formato de tabla.

La clave es que cada requisito pueda vincularse después con una prueba o una revisión explícita.

6. Criterios de aceptación

Los criterios de aceptación definen cómo observar que el trabajo está completo.

Deben redactarse de modo que quien revise pueda determinar si se cumplen o no.

Los criterios de aceptación útiles incluyen:

• flujo principal
• límites de permisos
• entradas inválidas
• estados vacíos
• estados de fallo
• comportamiento de migración o compatibilidad con versiones anteriores
• expectativas de accesibilidad
• expectativas de analítica y registro de eventos

Agile Alliance describe INVEST como una regla mnemotécnica útil para las historias de usuario: independientes, negociables, valiosas, estimables, pequeñas y comprobables. Para la planificación, la palabra que hay que proteger es «comprobables». Si una historia no se puede probar, la implementación perderá el rumbo.

7. Plan técnico

El plan técnico convierte los requisitos en un enfoque de implementación.

Debe incluir:

• sistemas afectados
• cambios de arquitectura
• cambios en el modelo de datos
• cambios en la API
• cambios en las dependencias
• estrategia de migración
• modelo de seguridad
• consideraciones de rendimiento
• cambios de observabilidad
• estrategia de despliegue
• estrategia de reversión
• alternativas consideradas

Aquí es donde los ingenieros deben cuestionar la viabilidad antes de empezar a programar.

8. Evaluación de riesgos y dependencias

Este artefacto evita sorpresas.

Debe incluir:

• riesgos técnicos
• riesgos de producto
• riesgos de seguridad
• riesgos de privacidad
• riesgos operativos
• riesgos de dependencias
• restricciones de secuencia
• aprobaciones necesarias
• incógnitas que podrían cambiar el plan

El Secure Software Development Framework de NIST es útil aquí porque trata el desarrollo seguro como parte del proceso, no como una revisión de último momento. Incluye prácticas para definir requisitos de seguridad, proteger el software, producir software bien protegido y responder a vulnerabilidades.

9. Estrategia de pruebas

Las pruebas deben planificarse antes de la implementación porque son la evidencia de que se cumplieron los requisitos.

La estrategia de pruebas debe incluir:

• pruebas unitarias
• pruebas de integración
• pruebas de contrato
• pruebas de extremo a extremo
• verificaciones de accesibilidad
• verificaciones de seguridad
• verificaciones de rendimiento
• pruebas de regresión
• verificaciones exploratorias manuales
• requisitos de datos de prueba

El concepto de Definition of Done de The Scrum Guide es útil aquí: las expectativas de calidad deben conocerse, compartirse y aplicarse a los incrementos de trabajo. En términos de planificación, no esperes hasta el PR para decidir qué significa «terminado».

10. Lista de tareas de implementación

Las tareas deben ser lo suficientemente pequeñas para ejecutarse y revisarse.

Una lista de tareas útil incluye:

• tareas de preparación
• tareas del modelo de datos
• tareas de backend
• tareas de frontend
• tareas de pruebas
• tareas de migración
• tareas de documentación
• tareas de lanzamiento
• tareas de validación

Cada tarea debe vincularse con al menos un requisito o criterio de aceptación.

11. Plan de lanzamiento y reversión

Este documento debe responder:

• ¿Cómo se lanzará?
• ¿Se necesita un feature flag?
• ¿Cuál es el orden de despliegue?
• ¿Qué monitoreo confirma el éxito?
• ¿Qué alerta indicaría un fallo?
• ¿Cómo revertimos el cambio de forma segura?
• ¿Quién es responsable de la decisión de lanzamiento?

12. Registro de decisiones

El registro de decisiones preserva el contexto.

Debe incluir:

• decisión
• opciones consideradas
• opción elegida
• motivo
• fecha
• responsable
• consecuencias

Esto es especialmente valioso para el desarrollo asistido por IA, porque las herramientas de IA pueden generar enfoques de implementación plausibles sin saber cuáles decisiones previas son vinculantes.

Los puntos de aprobación

Los artefactos de planificación solo son útiles si establecen puntos de control.

Un proceso práctico de desarrollo de software tiene estos puntos de aprobación:

El objetivo no es crear burocracia.

El objetivo es dejar de fingir que la implementación puede corregir sin problemas las deficiencias de planificación después de los hechos.

Proceso manual basado solo en prompts

Puedes llevar a cabo todo el proceso usando solo prompts.

La clave es evitar un solo prompt gigante.

En su lugar, trata los prompts como una secuencia de generadores y revisores de artefactos.

Fase 1: Generar contexto

Objetivo:

• entender el repositorio
• entender el contexto de negocio
• identificar archivos, sistemas y restricciones relevantes

Prompt:

You are helping prepare an engineering development plan.

Review the available repository, product notes, previous issues, recent PRs, and any relevant documentation.

Produce a context brief with:
- product area
- affected users
- current system behavior
- relevant files or services
- known constraints
- existing patterns to preserve
- open questions
- risks from missing context

Do not propose implementation yet.

Resultado para aprobación:

• resumen de contexto
• lista de información faltante
• responsable de cada dato faltante

Fase 2: Aclarar el problema

Objetivo:

• pasar de una solicitud vaga a una definición específica del problema

Prompt:

Using the context brief, create a problem clarification document.

Separate:
- confirmed facts
- assumptions
- unknowns
- decisions needed
- non-goals
- success metrics

Then ask the smallest set of questions required before requirements can be written.

Resultado para aprobación:

• problema aclarado
• objetivos excluidos
• métrica de éxito
• preguntas sin responder

Fase 3: Generar requisitos

Objetivo:

• crear requisitos explícitos antes del diseño técnico

Prompt:

Create a requirements document for this development effort.

Include:
- functional requirements
- non-functional requirements
- security requirements
- accessibility requirements
- observability requirements
- data and API requirements
- edge cases
- acceptance criteria

Assign stable IDs to each requirement.
Every acceptance criterion must be testable.
Do not include implementation details unless they are strict constraints.

Resultado para aprobación:

• documento de requisitos
• criterios de aceptación
• ID de los requisitos

Fase 4: Revisar la ambigüedad de los requisitos

Objetivo:

• detectar requisitos deficientes antes de la implementación

Prompt:

Review the requirements as a skeptical engineering reviewer.

Find:
- ambiguous words
- hidden assumptions
- missing edge cases
- untestable acceptance criteria
- conflicting requirements
- missing security or privacy considerations
- missing operational requirements

For each issue, explain why it matters and suggest a precise rewrite.

Resultado para aprobación:

• requisitos revisados
• registro de aclaraciones
• conjunto de requisitos aprobados

Fase 5: Análisis técnico

Objetivo:

• convertir los requisitos aprobados en un enfoque de implementación

Prompt:

Create a technical analysis for the approved requirements.

Include:
- affected architecture
- relevant files and modules
- data model changes
- API changes
- UI changes
- integrations
- migrations
- security model
- performance considerations
- observability plan
- alternatives considered
- recommended approach

Map each technical decision back to requirement IDs.

Resultado para aprobación:

• análisis técnico
• enfoque recomendado
• alternativas consideradas

Fase 6: Evaluación de riesgos

Objetivo:

• identificar qué podría fallar, retrasar o cambiar el plan

Prompt:

Assess the technical plan for delivery risk.

Include:
- implementation risks
- dependency risks
- data migration risks
- security risks
- privacy risks
- testing risks
- rollout risks
- rollback risks
- unknowns that could invalidate the plan

For each risk, provide severity, likelihood, mitigation, and owner.

Resultado para aprobación:

• registro de riesgos
• plan de mitigación
• aprobaciones necesarias

Fase 7: Estrategia de pruebas

Objetivo:

• definir cómo se demostrará el cumplimiento antes de programar

Prompt:

Create a test strategy for the approved requirements and technical plan.

For every requirement ID, define:
- test type
- test level
- test data
- expected evidence
- automation status
- manual validation needed, if any

Include regression, security, accessibility, performance, and observability checks where relevant.

Resultado para aprobación:

• matriz de requisitos y pruebas
• plan de pruebas
• brechas de pruebas conocidas

Fase 8: Descomposición en tareas

Objetivo:

• convertir el plan en trabajo de ingeniería ejecutable

Prompt:

Create an implementation task list.

Rules:
- tasks must be independently executable where possible
- tasks must reference requirement IDs
- tasks must include test tasks
- tasks must include documentation tasks
- tasks must include release and validation tasks
- tasks must be ordered by dependency
- tasks must identify which work can happen in parallel

Do not write code yet.

Resultado para aprobación:

• lista ordenada de tareas
• oportunidades de paralelización
• notas sobre dependencias

Fase 9: Implementación

Objetivo:

• ejecutar tareas delimitadas con base en los artefactos aprobados

Prompt:

Implement the next approved task from the task list.

Before editing:
- restate the requirement IDs covered
- identify the files expected to change
- identify the tests expected to be added or updated

After editing:
- summarize the change
- list tests run
- list requirement IDs satisfied
- list any deviations from the approved plan

Resultado para aprobación:

• cambio de código
• pruebas
• registro de desviaciones

Fase 10: Validación y lanzamiento

Objetivo:

• demostrar que el trabajo cumple con los requisitos aprobados

Prompt:

Validate the completed implementation against the approved artifacts.

Check:
- every requirement ID has evidence
- every acceptance criterion passes
- tests cover expected paths
- security and privacy requirements were addressed
- rollout and rollback plans are ready
- documentation is updated
- unresolved risks are documented

Produce a release readiness report with pass, fail, or needs review for each item.

Resultado para aprobación:

• informe de validación
• lista de verificación de lanzamiento
• brechas pendientes

Fallos comunes del proceso manual

La planificación basada solo en prompts funciona, pero es frágil.

Los fallos más comunes son:

• el asistente mezcla requisitos e implementación demasiado pronto
• se omiten las preguntas de aclaración porque el primer borrador suena convincente
• los criterios de aceptación son vagos
• el análisis de riesgos se agrega después de programar en lugar de hacerlo antes
• las tareas no están vinculadas a los requisitos
• las pruebas se escriben para la implementación en lugar de para el requisito
• las aprobaciones ocurren en el chat, pero no se preservan como artefactos
• el contexto cambia sin regenerar el plan
• el prompt de implementación pierde de vista las decisiones anteriores

La solución no es un prompt más grande.

La solución es un flujo de artefactos repetible.

Dónde encaja GitHub Spec Kit

GitHub Spec Kit es valioso porque convierte el proceso manual anterior en un flujo de trabajo estructurado y guiado por especificaciones.

El repositorio de GitHub describe Spec Kit como un conjunto de herramientas para el desarrollo guiado por especificaciones. El flujo de trabajo está diseñado en torno a una secuencia de comandos y artefactos que ayudan a los equipos a pasar de la intención a la especificación, la aclaración, la planificación, la descomposición en tareas, el análisis y la implementación.

En términos prácticos, ofrece a los equipos de ingeniería una forma más rápida de ejecutar el mismo ciclo disciplinado de planificación:

Lo importante no son los nombres de los comandos.

Lo importante es que el flujo de trabajo preserva la separación entre fases.

Por qué es más rápido

Spec Kit reduce la necesidad de diseñar prompts repetidamente.

En lugar de escribir manualmente un nuevo prompt para cada fase, el equipo puede usar una secuencia conocida:

constitution
  -> specify
  -> clarify
  -> plan
  -> tasks
  -> analyze
  -> implement

Esto es más rápido porque:

• la estructura de los artefactos ya está definida
• el asistente sabe en qué fase se encuentra
• la implementación no comienza antes de que existan los artefactos de planificación
• la descomposición en tareas parte de un contexto aprobado
• el análisis puede comparar los artefactos para detectar inconsistencias
• los miembros del equipo pueden revisar archivos en lugar de reconstruir el historial del chat

Por qué es más consistente

Los prompts manuales dependen en gran medida de quién los escribe ese día.

Spec Kit hace consistente el flujo de trabajo al crear una forma de trabajo compartida:

• cada funcionalidad parte de un contexto conocido
• cada funcionalidad tiene un artefacto de especificación
• la aclaración es una fase explícita
• la planificación técnica está separada de los requisitos
• las tareas se generan a partir del plan
• la implementación se guía por la lista de tareas

Esto reduce las variaciones entre equipos, proyectos y sesiones individuales de IA.

Por qué es más sólido

El proceso de planificación se fortalece porque los artefactos pueden revisarse de forma independiente.

Por ejemplo:

• producto puede revisar la especificación antes del diseño de ingeniería
• ingeniería puede revisar el plan antes de descomponerlo en tareas
• QA puede revisar los criterios de aceptación y la estrategia de pruebas
• seguridad puede revisar las áreas de riesgo antes de que se integre el código
• los responsables del lanzamiento pueden revisar las notas de despliegue y reversión

Esta es la diferencia entre «la IA dijo que entendió» y «el equipo tiene artefactos aprobados».

Por qué es repetible

La repetibilidad importa cuando el equipo quiere escalar el desarrollo asistido por IA más allá de una sola persona.

Un proceso repetible significa que:

• los nuevos miembros del equipo saben por dónde empezar
• quienes revisan saben qué inspeccionar
• los agentes de IA reciben la misma estructura de contexto cada vez
• el trabajo puede dividirse entre ramas o worktrees con mayor seguridad
• los requisitos, planes y tareas pueden compararse entre funcionalidades
• las retrospectivas pueden mejorar el proceso en lugar de culpar a las personas

Aquí también es donde el seguimiento de issues se vuelve útil.

GitHub Issues está diseñado para dar seguimiento a ideas, comentarios, tareas y bugs. Cuando los artefactos de planificación son claros, los issues se convierten en algo más que una lista de pendientes. Se convierten en la capa de ejecución de los requisitos y las tareas aprobados.

Un flujo de trabajo híbrido recomendado

El flujo de trabajo práctico más sólido es:

1. Usa prompts manuales para explorar cuando la idea todavía no esté clara.
2. Convierte la exploración en artefactos de planificación aprobados.
3. Usa Spec Kit para formalizar el flujo de trabajo de la funcionalidad.
4. Genera tareas de implementación a partir de los requisitos aprobados y la planificación técnica.
5. Convierte las tareas en issues cuando sea necesario asignar o dar seguimiento al trabajo.
6. Implementa con base en la lista de tareas.
7. Valida contra los ID de los requisitos y los criterios de aceptación.

Esto combina el criterio humano con una estructura repetible asistida por IA.

Lista mínima de documentos

Antes de que comience la implementación, ten listos estos documentos:

• principios del proyecto o constitución de ingeniería
• descripción del problema
• especificación de la funcionalidad
• registro de aclaraciones
• inventario de requisitos
• criterios de aceptación
• plan técnico
• evaluación de riesgos y dependencias
• estrategia de pruebas
• lista de tareas de implementación
• plan de lanzamiento y reversión
• registro de decisiones

Para trabajos más pequeños, pueden ser breves.

Para trabajos de alto riesgo, deben ser explícitos y estar aprobados.

Lista mínima de aprobación

Antes de que comience la implementación, confirma que:

• producto está de acuerdo en que vale la pena resolver el problema
• los requisitos se pueden probar
• los objetivos excluidos son explícitos
• la ambigüedad crítica está resuelta
• ingeniería está de acuerdo en que el plan técnico es viable
• se evaluaron los riesgos de seguridad y privacidad
• la estrategia de pruebas está vinculada a los requisitos
• las tareas son lo suficientemente pequeñas para ejecutarse
• se entienden el despliegue y la reversión

Antes del lanzamiento, confirma que:

• cada requisito tiene evidencia
• se cumple cada criterio de aceptación
• las pruebas han pasado
• los riesgos están cerrados o aceptados
• la documentación está actualizada
• el monitoreo está listo
• es posible revertir el cambio

La idea central

La IA facilita la generación de código.

Eso aumenta el costo de una planificación poco clara.

Cuando el código es barato, el recurso escaso pasa a ser el criterio:

• decidir qué se debe construir
• decidir qué no se debe construir
• decidir qué se debe demostrar
• decidir qué riesgos son aceptables
• decidir cuándo está listo el trabajo

La planificación adecuada del desarrollo de software es la disciplina de hacer visibles esas decisiones antes de que la implementación se acelere.

Los prompts manuales pueden lograrlo.

Spec Kit lo hace más rápido, más consistente, más sólido y más repetible.

Lista de fuentes

• README de GitHub Spec Kit
• Repositorio del proyecto GitHub Spec Kit
• GitHub Docs: Acerca de los issues
• GitHub Docs: Acerca de los pull requests
• NIST SP 800-218 Secure Software Development Framework
• The Scrum Guide: Definition of Done
• Agile Alliance: INVEST
• SWEBOK: Requisitos de software
• Manual de ingeniería de sistemas de NASA