Gestionar proyectos de software con IA

¿Qué hace Gestionar proyectos de software con IA?

Convierte la entrega asistida por IA, a menudo vaga, en un sistema de ejecución controlado para un solo operador humano. Obtén el marco, consigue la aprobación consciente de la descomposición en historias, ejecuta a través de una pequeña cola de tareas enrutadas en archivos duraderos, verifica con evidencia y cierra solo después de que cada criterio de éxito pase su verificación de extremo a extremo.

Mantén el estado del proyecto duradero y neutral respecto al proveedor. Cambiar entre Codex, Claude Code u otro agente compatible no debe requerir convertir los archivos de pm/.

Inicio rápido

1. Inspecciona el espacio de trabajo. Si existe pm/, lee pm/STATE.md, luego pm/TASKS.md; repara las brechas en lugar de regenerar el sistema.
2. Si no hay un sistema de proyecto, ejecuta CP1: haz las preguntas de elicitación y redacta el marco en pm/PLAN.md.
3. Crea los cuatro archivos canónicos a partir de references/file-templates.md.
4. Impulsa el trabajo a través de CP2 descomposición, CP3 cola, el bucle de ejecución y CP4 aceptación final.

Protocolo de puntos de control del operador

Co-crea la descomposición con el operador. Registra cada aprobación con una fecha en pm/PLAN.md o pm/TASKS.md.

• CP1 — Marco. Obtén y consigue la aprobación del objetivo, los criterios de éxito, las comprobaciones finales, el alcance, las restricciones y las suposiciones estructurales.
• CP2 — Descomposición. Presenta las historias en el lenguaje del operador. Dale a cada historia criterios de aceptación y vincúlalos a los criterios de éxito a los que sirve. Resuelve las decisiones estructurales abiertas con el operador.
• CP3 — Cola. Presenta la cola de tareas ordenadas con niveles de enrutamiento antes de que comience la ejecución.
• CP4 — Aceptación final. Vuelve a ejecutar cada comprobación final de CP1 de extremo a extremo, enlaza la evidencia, presenta el informe de aceptación y obtén la aprobación. Las tareas completadas por sí solas no significan que el proyecto esté terminado.

Usa estas reglas permanentes:

• Rellena los pequeños vacíos dentro de un marco aprobado con suposiciones registradas en pm/DECISIONS.md.
• Devuelve los cambios estructurales (alcance, historias, criterios de éxito o nivel de aceptación) al punto de control correspondiente y registra la compensación.
• Pregunta en CP1: ¿Qué resultado debe existir y para quién? ¿Cómo lo verificará personalmente el operador? ¿Qué está fuera del alcance? ¿Qué restricciones son fijas? ¿Qué existe ya? ¿Qué es lo más arriesgado o poco claro? ¿Cuánta revisión desea el operador?
• En modo de rescate, reconstruye el marco y la descomposición implícitos a partir del espacio de trabajo, preséntalos para confirmación y luego reconstruye la cola.

Archivos canónicos del proyecto

Mantén cuatro archivos bajo pm/:

• pm/PLAN.md — objetivo, criterios de éxito, alcance, historias, trazabilidad, aprobaciones
• pm/TASKS.md — cola de tareas ordenadas, IDs estables, enrutamiento, verificación, evidencia
• pm/STATE.md — estado actual, notas de transferencia, registro de sesión
• pm/DECISIONS.md — decisiones, suposiciones, riesgos, problemas, registro de cambios

No crees más archivos de control por defecto. Añade pm/CONSTRAINTS.md, pm/RELEASE.md o pm/RESEARCH.md solo cuando la rama correspondiente esté activa.

Mantén el archivo de entrada específico del producto (como AGENTS.md o CLAUDE.md) corto y de navegación: apunta a pm/STATE.md, luego pm/TASKS.md, con pm/PLAN.md como alcance aprobado. Refleja la información duradera de las herramientas de planificación locales de la sesión en pm/TASKS.md y pm/STATE.md.

Enrutar el trabajo por capacidad

Asigna un nivel Route: neutral al proveedor cuando cada tarea entre en la cola:

Nivel	Úsalo para
heavy	planificación, descomposición, arquitectura, depuración ambigua, refactorizaciones transversales, revisión arriesgada, aceptación final
standard	implementación acotada, pruebas, cambios de complejidad moderada
light	búsqueda en el repositorio, resúmenes, ediciones mecánicas, documentación, clasificación de registros

Enruta cada tarea al nivel menos costoso que pueda completarla de forma fiable:

• Mantén el hilo principal suficientemente capaz para dirigir: redactar informes, enrutar trabajo, juzgar evidencia y aprobar.
• Escala un nivel después de dos intentos fallidos o un resultado de baja confianza en la misma tarea; registra la escalada.
• Exige que el nivel del revisor sea al menos el nivel del escritor. Da a los cambios arriesgados o transversales una revisión heavy con contexto nuevo. Nunca permitas que un trabajador light se auto-apruebe.
• Mantén los nombres de los modelos fuera de pm/; los alias y precios de los productos cambian mientras que los niveles de capacidad siguen siendo útiles.
• Lee references/agent-routing.md antes de configurar trabajadores para Codex, Claude Code u otro agente.

Construir contexto primero

• Extrae el objetivo real, los usuarios, el nivel de aceptación, las dependencias y las expectativas de lanzamiento.
• Trata las fechas, presupuestos, aprobaciones, horarios de proveedores o ventanas de lanzamiento como entradas de primera clase solo cuando sean explícitas.
• Busca archivos pm/, informes de tareas, backlogs, diseños, ADRs, estrategias de prueba, runbooks, registros de riesgos y archivos de instrucciones de agentes existentes antes de inventar nuevos artefactos.
• En trabajos de rescate, evalúa la claridad del objetivo, alcance, dependencias, calidad de aceptación, higiene de riesgos, legibilidad del contexto, permisos y preparación para el lanzamiento.

Elegir el modo de control más pequeño

• Por defecto, solo-operator: un operador dirigiendo agentes de IA.
• Añade external-constraint por una fecha fija real, puerta de cumplimiento, aprobación, dependencia de proveedor, cuota o ventana de lanzamiento.
• Añade feedback-heavy cuando el descubrimiento, el aprendizaje del usuario o la iteración de UX dominen.
• Añade release-safety cuando el lanzamiento requiera cambio, reversión, monitorización o notas de operación.

Dimensionar las unidades de ejecución

• Usa historias para valor visible para el usuario y aceptación. Usa hitos solo para agrupar trabajo. Ejecuta a través de tareas.
• Haz que cada tarea quepa en una ejecución enfocada del agente y una revisión rápida del operador: un subsistema, interfaz, documento o superficie de prueba y un diff revisable.
• Dale a cada tarea un ID estable, referencia a la historia, nivel de enrutamiento, alcance, dependencia, condición de finalización, verificación exacta, campo de evidencia y punto de parada explícito.
• Divide antes de la ejecución cuando una tarea abarque áreas no relacionadas o varias validaciones independientes. Mantén el historial: las tareas hijas obtienen nuevos IDs; las tareas reemplazadas se convierten en superseded.
• Después de completar una tarea, rellena su evidencia y actualiza pm/STATE.md en la misma ejecución.

Mantener la trazabilidad

• Asigna cada criterio de éxito a al menos una historia y cada historia a al menos una tarea.
• Marca una historia como hecha solo después de que todas sus tareas y criterios de aceptación estén verificados con evidencia.
• Marca el proyecto como hecho solo después de que CP4 vuelva a verificar cada criterio de éxito de extremo a extremo.

Ejecutar un bucle de calidad primero

• Define la prueba creíble más pequeña antes de la implementación: reproducción fallida, prueba automatizada, salida esperada, comparación de capturas de pantalla, comprobación de contrato o procedimiento manual exacto.
• Usa explorar -> planificar -> implementar -> verificar -> revisar -> documentar.
• Registra comandos, resultados, capturas de pantalla, métricas y notas de revisión en lugar de solo conclusiones.
• Declara presupuestos de cambio para tareas arriesgadas: archivos permitidos, interfaces estables, seguridad de datos, reversión y desencadenantes de escalada.
• Prueba cambios repetitivos o automatizados en una porción representativa estrecha antes de escalar.
• Después del mismo fallo dos veces, detente y mejora el entorno, la documentación, la regla o el validador; reinicia con contexto limpio.
• Trata los fallos repetidos del agente como retroalimentación del sistema. Mejora el proceso, no solo la respuesta actual.

Delegar de forma segura

• Delega solo trabajo acotado y listo para la autonomía. Mantén los objetivos, la descomposición, la síntesis y la aprobación en el hilo principal.
• Dale a cada trabajador un informe escrito: ID de tarea, objetivo, alcance, restricciones, comandos de verificación, evidencia esperada, punto de parada, desencadenante de escalada y nivel de enrutamiento.
• Mantén el trabajo pequeño, estrechamente acoplado o altamente interactivo en el hilo principal cuando la sobrecarga de delegación supere su beneficio.
• Prefiere validadores deterministas para reglas de tolerancia cero como pruebas requeridas, restricciones de ruta, formato o escaneo de secretos.
• Aplica el principio de mínimo privilegio, límites de confianza, reglas de manejo de secretos y aprobación explícita del operador para acciones arriesgadas.

Referencias

• Lee references/file-templates.md al crear o reparar pm/.
• Lee references/worked-example.md para un ejemplo compacto de extremo a extremo.
• Lee references/project-rulebook.md al auditar o rescatar un proyecto.
• Lee references/external-constraints.md solo para restricciones externas reales o riesgo de lanzamiento de producción.
• Lee references/ai-agent-practices.md para una guía más profunda sobre memoria duradera, contexto, delegación, evaluaciones y barreras de protección.
• Lee references/agent-routing.md al mapear niveles a las capacidades actuales de un producto.
• Lee references/source-anchors.md cuando la procedencia o la guía volátil del proveedor sea importante.
• Carga solo la referencia relevante más pequeña.

Estándares de salida

• Escribe artefactos concretos y listos para la decisión en forma imperativa.
• Reporta primero el estado del punto de control y los IDs de las tareas antes del estado en prosa.
• Formatea las tareas como: ID de tarea, Tarea, Historia, Ruta, Alcance, Depende de, Hecho cuando, Verificar con, Evidencia, Detenerse después, Estado.
• Prefiere un diff revisable por tarea.
• Mantén los nombres de los modelos fuera de los archivos duraderos del proyecto.
• No añadas planes de fechas, presupuestos, flujos de trabajo de aprobación, ceremonias recurrentes o puertas de etapa a menos que el proyecto realmente los necesite.
• Verifica las afirmaciones actuales sobre modelos, benchmarks, precios o flujos de trabajo de proveedores contra fuentes primarias antes de usarlas.