▲ Desarrollo con agentes
Agente de refinamiento: criterios que un agente puede verificar.
Por César Soto · 6 min de lectura
▲ En este artículo
▲ En resumen
- Un agente de refinamiento lee el requerimiento contra el código real y le pregunta al product owner lo que falta para que el issue quede bien definido.
- El resultado es un issue con criterios de aceptación que se pueden comprobar con evidencia, y el product owner lo aprueba antes de que se construya nada.
- Esos mismos criterios son los que el agente de aceptación verifica al final, así que un criterio ambiguo se corrige al principio, donde cuesta una pregunta.
Cuando publiqué cómo un agente de aceptación revisa que cada PR cumpla sus criterios, la primera pregunta que recibí fue qué pasa si el criterio es ambiguo o está incompleto. La respuesta está un paso antes en el proceso, en un agente que refina el requerimiento con el product owner. Aquí explico cómo trabaja, con un ejemplo escrito para este artículo.
¿Qué pasa si un criterio de aceptación es ambiguo o está incompleto?
Un criterio ambiguo se corrige antes de construir, porque después ya nadie lo detecta. El agente de aceptación comprueba lo que el criterio dice. Si el criterio dice poco, el PR pasa la revisión y el hueco aparece hasta que QA o un cliente lo encuentra.
En nuestro proceso, antes de que un requerimiento llegue a construcción pasa por un agente de refinamiento. Analiza el código actual y el requerimiento, y le hace preguntas al product owner hasta dejar bien definido el issue.
Se repite hasta que no quedan huecos.
¿Qué es un agente de refinamiento?
Su trabajo termina cuando el issue se puede construir sin adivinar. La conversación que antes ocurría a mitad del sprint, cuando un desarrollador descubría la duda, ocurre ahora antes de empezar y queda escrita en el issue.
¿Por qué el agente lee el código antes de preguntar?
Porque las mejores preguntas salen del sistema real. Un requerimiento se escribe pensando en el caso principal, y el código guarda todo lo demás: los roles que existen, los filtros que ya tiene esa pantalla, el exportador que alguien construyó el año pasado.
Toma este requerimiento: los administradores deben poder exportar el reporte de ventas. Leído solo, parece completo. Leído contra el código, abre cuatro preguntas.
| Lo que el agente encuentra en el código | Lo que le pregunta al product owner |
|---|---|
| El reporte tiene filtros de fecha y sucursal | ¿La exportación respeta los filtros activos o trae todo? |
| Existen dos roles de administrador: de cuenta y de sucursal | ¿Cuál de los dos puede exportar? |
| Ya hay un exportador a CSV en el módulo de clientes | ¿Se reutiliza ese formato o hace falta Excel? |
| El reporte puede superar las 100,000 filas | ¿Qué debe pasar con un reporte grande: espera, segundo plano o límite? |
Ninguna de las cuatro es técnica. Son decisiones de producto que el requerimiento dejaba implícitas, y que de otro modo habría tomado quien construyera, sin avisar.
¿Cómo queda el issue después del refinamiento?
Queda con contexto, criterios numerados y una lista de lo que no se va a hacer. Con las respuestas del product owner, el requerimiento de una línea se convierte en esto.
Exportar el reporte de ventas a CSV
Contexto
Los administradores de cuenta necesitan llevar las ventas
a su hoja de cálculo.
Criterios de aceptación
1. El botón "Exportar" aparece solo para el rol
administrador de cuenta.
2. El archivo respeta los filtros de fecha y sucursal
que estén activos.
3. El CSV trae las mismas columnas que la tabla,
en el mismo orden.
4. Con más de 10,000 filas, la exportación corre en
segundo plano y avisa por correo al terminar.
5. Un administrador de sucursal no ve el botón y el
endpoint le responde 403.
Fuera de alcance
Formato Excel. Exportaciones programadas.
Cada criterio viene de una respuesta. La sección Fuera de alcance importa tanto como los criterios: le dice al agente que construye dónde detenerse, y al de aceptación qué no debe exigir.
¿Qué hace que un criterio sea verificable por un agente?
Un criterio es verificable cuando se puede comprobar con evidencia, en el código o ejecutando la aplicación. Si para darlo por cumplido hace falta una opinión, todavía es un deseo.
| Como llega | Como queda | Qué evidencia busca el agente de aceptación |
|---|---|---|
| La exportación debe ser rápida | Con más de 10,000 filas corre en segundo plano y avisa por correo | Un job en la cola y el envío del correo al terminar |
| Solo los administradores exportan | Un administrador de sucursal no ve el botón y el endpoint le responde 403 | La condición en la interfaz y una prueba del endpoint con ese rol |
| El archivo debe coincidir con el reporte | El CSV trae las mismas columnas que la tabla, en el mismo orden, con los filtros activos | Una prueba que compara las columnas y las filas filtradas |
¿Qué cambia para el product owner?
El product owner pasa de redactar el requerimiento completo a responder preguntas precisas y a decidir el alcance. Su criterio sigue siendo el centro del proceso: el agente señala los huecos, y solo el product owner sabe qué necesita el negocio en cada uno.
- Decide con el sistema a la vista. Las preguntas llegan con lo que ya existe en el código, así que la decisión considera los roles, los filtros y los límites reales.
- Aprueba antes de que se construya. El issue refinado pasa por su aprobación, que es el primer punto de control humano del proceso.
- Recibe lo que pidió. Los criterios que aprobó son los mismos que el agente de aceptación comprueba en el PR.
“Un criterio ambiguo cuesta una pregunta al principio y un requerimiento devuelto al final.”
¿Cómo se conecta con el agente de aceptación?
Los dos agentes trabajan sobre la misma lista. El de refinamiento deja los criterios escritos al principio y el de aceptación busca la evidencia de cada uno al final, antes de que el PR llegue a una persona. Describo ese segundo agente en qué es un harness.
Es la misma regla que uso para los agentes en producción: el agente propone y alguien con autoridad decide. Aquí el agente propone el issue y el product owner lo aprueba. El método de PeakSyn muestra dónde cae cada punto de control.
¿Por dónde empezar?
- Toma los últimos requerimientos que QA devolvió. Anota qué pregunta, hecha a tiempo, los habría evitado.
- Dale al agente el requerimiento y el código. Sin el código, sus preguntas serán las genéricas de cualquier plantilla.
- Pídele preguntas antes que una redacción. El issue se escribe después de las respuestas.
- Exige criterios numerados y una sección de fuera de alcance. Cada criterio con la evidencia que lo demostraría.
- Deja la aprobación en el product owner. Nada pasa a construcción sin ella.
Si quieres revisar cómo se vería este paso en tu equipo, puedes agendar una conversación de 30 minutos.
Preguntas frecuentes
¿El agente de refinamiento reemplaza al product owner?
No. El agente encuentra los huecos y redacta; las decisiones de alcance y prioridad son del product owner, y el issue no pasa a construcción sin su aprobación.
¿Qué pasa si el product owner no tiene la respuesta a una pregunta?
El requerimiento se queda en refinamiento hasta que la tenga, o esa parte se mueve a fuera de alcance. Las dos salidas son mejores que construir sobre una suposición.
¿Sirve el refinamiento si no tengo un agente de aceptación?
Sí. Un issue con criterios verificables le sirve igual a un desarrollador y a QA. Con un agente de aceptación el beneficio crece, porque esos criterios se comprueban en cada PR.
¿Depende de una herramienta específica?
No. Hace falta un agente que pueda leer el repositorio y un lugar donde vivan los requerimientos, que en nuestro caso es Linear. El mismo esquema funciona con otros gestores de issues.
Referencias
¿Quieres aplicarlo en tu equipo? Hablemos 30 minutos.
Sin costo, en video, con César Soto.
Agenda una conversación