Desarrollo de Productos Digitales con Agentes de IA

No, y ya no emitimos la certificación de Scrum Alliance. Tampoco damos DevOps ni Integración Continua, Testing Ágil ni Arquitectura como cursos. Esos contenidos ahora se trabajan dentro de este servicio, sobre el código de tus equipos: abajo contamos cómo aplicamos hoy integración continua, arquitectura, pruebas y TDD con agentes de IA. Cuando un equipo completo necesita profundizar un tema, sumamos una capacitación in-company dentro del mismo servicio.

Primero, una red mínima de pruebas; la cobertura viene después. Sin pruebas, integrar seguido solo integra errores más rápido, y con agentes, todavía más rápido. Por eso empezamos con pruebas de caracterización (golden master): fijan cómo se comporta hoy el sistema, aunque ese comportamiento tenga errores. Con esa red, el equipo pasa a trunk-based development: cambios chicos, integrados a la rama principal varias veces al día, con el pipeline como única puerta de entrada. Lo que todavía no está listo se esconde con feature flags, no en ramas largas. Y los ambientes se definen como código (infrastructure as code), para que el equipo y los agentes los reproduzcan igual cada vez.

Una prueba rápida: ¿cuánto tarda el pipeline en decir si un cambio rompió algo? Si pasa de los 10 minutos que propone XP, el equipo lo va a esquivar, y los agentes también. Si quieres saber más: Entrega continua de software.

Por partes, con decisiones que el equipo toma y valida en el camino, sin un rediseño completo. Lo que vuelve maleable un sistema para una persona también lo vuelve maleable para un agente: pruebas que avisan rápido, módulos con límites claros y nombres que dicen qué hace el código. Así trabajamos la arquitectura:
· Atributos de calidad primero: acordamos con negocio cuáles importan (facilidad de cambio, seguridad, disponibilidad) y se priorizan como un backlog más. Monolito o microservicios se decide según esos atributos.
· Arquitectura hexagonal (puertos y adaptadores): separa el dominio de la base de datos y de los servicios externos, para cambiar y probar cada parte por separado.
· Refactoring de arquitectura en pasos chicos, con pruebas que fijan el comportamiento actual antes de mover nada: el agente propone y las pruebas verifican.
· Arquitectura en el pipeline: las métricas de calidad se miden en cada integración, así el diseño no se degrada sin que nadie lo note.

El agente acelera cada paso, sobre todo el de entender código que nadie documentó. Las decisiones de arquitectura las sigue tomando el equipo.

Escribir pruebas deja de ser el cuello de botella; decidir qué probar, no. Un agente genera cientos de pruebas en minutos, y muchas solo repiten lo que el código ya hace: pasan siempre y no protegen nada. Lo que trabajamos con el equipo:
· Cuadrantes de la prueba: qué pruebas guían el desarrollo y cuáles critican el producto, qué se automatiza y qué no.
· Pirámide de automatización: muchas pruebas unitarias rápidas y pocas de punta a punta, elegidas para los recorridos que importan. Con agentes es fácil invertirla, y el pipeline se vuelve lento y frágil.
· Pruebas end-to-end automáticas: un agente recorre la aplicación como un usuario, y hasta graba el video del recorrido; si una pantalla cambia, la prueba se rompe. Lo contamos en Esta reunión podría haber sido un video.
· ATDD: el equipo define con negocio los criterios de aceptación antes de construir, y el agente los convierte en pruebas.
· Testing exploratorio: el tiempo que libera la automatización va a lo que un agente no ve: usabilidad, casos raros, el contexto del negocio.

Una prueba rápida: rompe a propósito una línea del código (es la idea del mutation testing). Si ninguna prueba falla, esas pruebas no protegen esa parte.

El código sigue siendo del equipo, y la responsabilidad también. La propiedad colectiva (collective code ownership) dice que cualquier persona del equipo puede cambiar cualquier parte del código. Con agentes, el riesgo es el opuesto: código que nadie del equipo entiende. Lo evitamos con tres prácticas:
· Nadie integra código que no puede explicar, lo haya escrito quien lo haya escrito.
· TDD y ATDD/BDD: el equipo escribe primero la prueba o el criterio de aceptación, y el agente escribe el código que lo cumple. La intención queda en manos de personas.
· Revisión centrada en el diseño, con los estándares del equipo verificados por análisis estático, así las personas miran lo que una herramienta no ve.

Si te reconoces en alguna de estas frases, el cuello de botella está en cómo se construye:
· "Un cambio chico nos lleva semanas."
· "Nadie se anima a tocar ese módulo."
· "Cada entrega rompe algo que funcionaba."
· "Solo una o dos personas entienden el sistema."
· "Antes de cada salida, probamos todo a mano."

Cuando las frases cambian, el cuello de botella se corrió.
· "No sé en qué anda mi equipo" o "Nunca cumple con lo que se compromete": está en cómo trabaja el equipo.
· "Lo que construimos no mueve el negocio": está en qué construir y por qué.

Este frente se puede contratar solo. En el diagnóstico confirmamos por dónde conviene iniciar.