Más rápidos,

¿pero más ágiles?

​

¿Seguimos siendo ágiles si dejamos de entender lo que hacemos con equipos que desarrollan con GenAI ?

En esta charla vamos a explorar nuevas formas de deuda y su impacto en equipos ágiles, poniendo en discusión conceptos como adaptabilidad, transparencia, excelencia técnica y sostenibilidad.

Licenciado en Análisis de Sistemas, especialista en Ingeniería de Software y finalizando una Maestría en Ingeniería de Software, con experiencia en desarrollo de software, docencia e investigación.

​

Mi trayectoria combina tecnología, agilidad e inteligencia artificial, con especial interés en la mejora de equipos y procesos de desarrollo.

¿Quién soy?

Equipo A

• Entrega 8 historias por Sprint
• Escribe casi todo manualmente
• Puede explicar la arquitectura y por qué se tomaron las decisiones

Primero: Entendamos a los equipos

Equipo B

• Antes entregaba 8 historias
• Con agentes de IA ahora entrega 15
• El código funciona
• Los tests pasan

¿Cuál de los dos equipos es más ágil?

Mi pregunta fue…¿Cuál de los dos equipos es más ágil?

No fue …“¿Cuál es más productivo?”

¿Cuál tiene mayor capacidad de responder al cambio?

Productividad no es solo producir más

La verdadera pregunta es si produce más valor sostenible

​

“La IA puede movernos muy rápido hacia arriba en throughput. Pero eso no garantiza que también nos mueva hacia la derecha en capacidad de adaptación.”

​

• Productividad = cuánto podemos producir hoy
• Agilidad = qué tan bien podemos responder mañana

Productividad Aparente vs Real…

Podemos decir: “Antes entregamos 10 funcionalidades por mes y ahora entregamos 20” – Insuficiente

Se deben considerar más variables. No se trata de una fórmula matemática exacta, sino de una forma de mostrar que el volumen producido es apenas una parte del problema.

Valores

y Principios

• Desarrollo sostenible
• Excelencia técnica
• Buen diseño
• Simplicidad
• Reflexión continua

Relación entre Manifiesto Ágil y DT

Entender que los equipos tienen deudas

Martin Fowler — Ingeniero de software, autor y referente mundial en refactorización y arquitectura de código

Code Smells

• Lista larga de parámetros
• Código duplicado
• Código muerto
• Clase grande
• Método largo
• Agrupaciones de datos
• Obsesión primitiva
• Envidia de características
• Generalidad especulativa
• Campo Temporal
• Explicaciones excesivas con comentarios

Kent Beck — ingeniero de software, creador de Programación Extrema (XP), desarrollar el Desarrollo Guiado por Pruebas (TDD)

¿La DEUDA TÉCNICA es solo de Código?

​

La Deuda ya no es solamente de Código

Originalmente atribuido a W. Cunningham (1992) para comunicar el balance entre velocidad y re-trabajo en la entrega de software que funciona y con calidad

• Código
• Arquitectura
• Diseño
• Testing
• Documentación
• Infraestructura
• etc.

Ward Cunningham — es un informático y programador estadounidense, famoso por ser el inventor del primer sitio web tipo wiki (WikiWikiWeb) y pionero en el desarrollo ágil de software

Ahora aparecen otros …

Podemos tener código técnicamente correcto y, sin embargo, tener deuda.

​

Margaret-Anne Storey — Especialista en aspectos humanos y sociales de la ingeniería de software.

Deuda Cognitiva

• Le pido a un agente que implemente autenticación OAuth.
• Genera 7 archivos, configura middleware, refresh tokens, excepciones, tests y configuración.
• Funciona
• Hago merge

Deuda Cognitiva

• 3 meses después falla el refresh token en producción.
• El desarrollador que hizo el PR abre el código y tiene que preguntarle nuevamente a la IA cómo funciona

¿Quién tenía realmente el conocimiento: el equipo o la conversación con la IA?

Terminamos antes de comprender

“Antes una organización podía tener un sistema demasiado complejo para una persona.

Con GenAI podemos llegar a tener funcionalidades demasiado complejas para todo el equipo que supuestamente las desarrolló”

Analogía

Pero nadie del equipo sabe:

• ¿por dónde pasan las tuberías?
• ¿por qué una columna está en determinado lugar?
• ¿qué materiales se utilizaron?
• ¿qué decisiones estructurales tomó el robot?
• ¿dónde están los planos?

​

La capacidad de construir no es necesariamente capacidad de evolucionar

Intent Debt

Quizás venía de:

• Una regulación
• Una decisión comercial
• Una promoción temporal
• Un bug workaround
• Un requerimiento del cliente
• Una alucinación de la IA

• T1: Ocurrente, aparece la deuda con beneficios inmediatos
• T1 → T2: “Blissful ignorance” o ignorancia feliz
• T2: Conciencia, nos damos cuenta de que existe
• T1 → T3: Podemos seguir obteniendo valor
• T3: Punto Crítico. Seguimos con Beneficio obtenido > Costo de la deuda
• T3 → T4: “Suffering from debt”. Costo de la deuda > Beneficio obtenido.
• T4: Pagar la deuda

Technical Debt Timeline

No deberíamos priorizar deuda solamente por cuánto “deuda” hay, sino por cuánto está interfiriendo con nuestra capacidad de entregar valor

IA y Agilidad - Empirismo

Se modifican algunas condiciones necesarias para ser Ágiles

¿Velocidad o Agilidad?

Velocity ≠ Agility

“Más velocidad no siempre significa más agilidad”

GenAI-Induced Self-Admitted Technical Debt (GIST)

Código incorporado mientras el desarrollador manifiesta incertidumbre sobre su comportamiento o corrección.

​

Evolución de prácticas ágiles

La Definition of Done (DoD) con IA

Una DoD convencional puede tener:

• Tests pasan
• Code review realizado
• No hay vulnerabilidades críticas
• Documentación actualizada
• Desplegable

¿Nuestra DoD contempla solamente que el software funcione, o también que pueda ser sosteniblemente evolucionado?

Por ejemplo podemos tener:

• El autor puede explicar el código generado
• El equipo conoce las dependencias introducidas.
• Se verificaron supuestos generados por IA
• Existe evidencia de testing independiente de la propia IA
• El cambio puede ser mantenido sin depender del contexto original del chat

Retrospectivas con IA

En vez de solamente preguntar:

• ¿Qué salió bien?
• ¿Qué salió mal?
• ¿Que podemos mejorar?

Agregar:

• ¿Qué delegamos a la IA?
• ¿Qué aprendimos gracias a la IA?
• ¿Qué dejamos de comprender por usar la IA?

​

​

“¿La IA aumentó o disminuyó nuestra capacidad como equipo?”

Estimaciones con IA

¿Seguimos estimando esfuerzo humano o estimamos incertidumbre, complejidad y riesgo?

​

En realidad: Los Story Points suelen representar una combinación relativa de trabajo/esfuerzo, complejidad, riesgo e incertidumbre, no simplemente horas de programación.

“Si una historia era 8 puntos y ahora Copilot la implementa en una tarde, ¿pasa a ser 2 puntos?”

La IA puede reducir tiempo de ejecución, pero no necesariamente reduce incertidumbre. Incluso puede aumentarla si el equipo no comprende la solución generada.

Code Review / Review del trabajo

Ya no alcanza con revisar “qué código se escribió”, sino también:

• Qué supuestos hizo la IA
• Qué partes fueron verificadas
• Qué decisiones fueron aceptadas sin suficiente análisis.

​

La IA produce algo muy peligroso cognitivamente: respuestas plausibles

Documentación y trazabilidad

Si la IA participa en una decisión importante: ¿Queda registrado el porqué?

​

No se trata de guardar todos los prompts, sino de preservar decisiones relevantes, supuestos, restricciones, rationale y alternativas descartadas.

Pair/Mob Programming

En vez de “humano + humano”, podés pensar “equipo + IA”, pero cuidando que la IA no se convierta en la única portadora del conocimiento.

​

Práctica interesante: sería que una persona genere y otra explique o cuestione.

Testing con IA

¿Quién valida a quien generó la solución?

IA genera:

• Código
• Tests
• Casos de prueba
• Casos borde

​

¿Estamos obteniendo evidencia independiente? ¿Quién está cuestionando los supuestos originales?

Refinamiento con IA

¿Refinamos mejor o generamos más artefactos?

IA puede generar:

• Historias
• Criterios de aceptación
• Casos borde
• Preguntas
• Alternativas

Generar una historia no significa comprender el problema.

¿Qué evidencia necesitamos?

¿Funciona… pero cómo sabemos que está bien?

• Resultado correcto
• Tests
• Supuestos verificados
• Decisiones comprendidas
• Riesgos revisados

El resultado no siempre es evidencia suficiente.

Evidencia proporcional al riesgo

Jez Humble — co-autor de Continuous Delivery, referente en entrega continua, feedback rápido y evolución segura del software.

El cuello de botella se mueve

Optimizar una etapa no significa optimizar el sistema. Si medimos solo velocidad, veremos solo velocidad.

“Mejorar una actividad local no garantiza mejorar el flujo del sistema”

Lo habitual:

• Throughput
• Lead time
• Historias
• PRs

Lo que quizá falta observar:

• Retrabajo
• Defectos
• Comprensión
• Dependencia de IA
• Facilidad de cambio

Gene Kim — Investigador y autor sobre DevOps, flujo y organizaciones tecnológicas de alto desempeño

Bus Factor… ¿con IA?

• Antes: “Solo Juan sabe cómo funciona”
• Ahora: “Nadie sabe exactamente cómo funciona, pero la IA sí”

¿Reducimos el Bus Factor o simplemente movimos el conocimiento fuera del equipo?

¿El conocimiento está entrando al equipo o solamente estamos accediendo a él bajo demanda?

IA como sustituto vs. amplificador

No es cuánto usamos IA. Es cómo la usamos

• Sustituto cognitivo: “Hacelo por mí”
• Amplificador cognitivo: “Ayúdame a entender, cuestionar y decidir”

¿La IA está aumentando la capacidad del equipo o reemplazandola?

Jakob Nielsen — Referente en interacción humano-computadora y análisis del impacto de IA en el trabajo del conocimiento.

Lean: producir código también puede ser desperdicio

Cuando producir se vuelve barato, producir de más es muy fácil

GenAI ↓ costo de generación

Pero:

• Más código
• Más funcionalidades
• Más mantenimiento
• Más cosas que comprender

“Código barato de producir no significa código gratis de mantener”

Mary Poppendieck — Referente de Lean Software Development y aplicación de principios Lean al desarrollo de software

La IA puede reducir tiempo de ejecución, pero no necesariamente incertidumbre.

“En contextos complejos no eliminamos la incertidumbre planificando mejor; aprendemos interactuando con el sistema”

Debemos analizar previamente de contextos complejos donde necesitamos experimentar, observar y aprender

Dave Snowden — Creador del framework Cynefin, referente en complejidad, incertidumbre y toma de decisiones.

Muchas gracias 😄