Prácticas ágiles: técnicas de un equipo ágil día a día
Un equipo ágil no se reconoce por las herramientas que usa ni por cómo se llaman sus reuniones, sino por cómo trabaja cada día. Estas técnicas son las que hacen posible entregar software útil a menudo sin que la calidad se resienta.
Imagina una semana de trabajo (un Sprint): cada mañana, una reunión de 15 minutos (la daily); durante el día, se programa en parejas y cada persona integra su trabajo al menos una vez; al cerrar la semana, una retrospectiva para decidir qué cambiar. Y todo en un equipo pequeño, con el cliente dentro, que se organiza solo.
Resumen de las técnicas
| Técnica | Qué es | De dónde viene |
|---|---|---|
| Equipo pequeño y completo | Pocas personas que, entre todas, saben hacer todo lo necesario, con el cliente cerca | Scrum, XP |
| Daily | Reunión diaria de 15 minutos para ver cómo va el objetivo del ciclo | Scrum |
| Retrospectiva | Reunión al final de cada ciclo para mejorar la forma de trabajar | Scrum |
| Análisis progresivo | Se analiza lo justo para empezar; el resto se descubre construyendo | Manifiesto Ágil, XP |
| Tests de aceptación | Los requisitos se escriben como pruebas que el cliente entiende y la máquina ejecuta | XP (Customer Tests) |
| Programación en parejas | Dos personas escriben el código juntas en un mismo equipo | XP |
| Propiedad colectiva del código | Cualquiera puede cambiar cualquier parte del código | XP |
| Diseño en equipo | Las decisiones de arquitectura las toma el equipo, no una sola persona | Scrum (equipo autogestionado), XP |
| Integración continua | Cada persona integra sus cambios al menos una vez al día y una build automática lo prueba todo | XP, Martin Fowler |
Un equipo pequeño, con el cliente dentro
Todo el equipo trabaja unido, como una piña, y el cliente forma parte de él. En XP esto se llama Whole Team (equipo completo): según Ron Jeffries, todos se sientan juntos, incluida una persona que representa al negocio, el «cliente», que marca las prioridades y guía el proyecto. De dónde sale XP, sus valores y el resto de sus prácticas lo tienes en qué es Extreme Programming.
El equipo debe ser pequeño. El artículo original de 2018 decía «menos de 7 personas»; la Guía de Scrum vigente, de 2020, habla de un equipo de 10 personas o menos, y añade que, si crece demasiado, conviene dividirlo en varios equipos que trabajen sobre el mismo producto. La razón es sencilla: cuantas más personas, más conversaciones hacen falta para que todas sepan lo mismo.
Quién hace qué dentro de ese equipo lo explico en Roles dentro de un equipo ágil.
Reuniones cortas y frecuentes
El equipo se reúne con frecuencia, a ser posible a diario. En Scrum hay dos reuniones que todo el mundo asocia con un equipo ágil:
La daily
La Daily Scrum es una reunión de 15 minutos, cada día, para los Developers del equipo. Según la guía, sirve para revisar el avance hacia el objetivo del Sprint (el ciclo de trabajo, de un mes o menos) y ajustar el plan si hace falta.
La retrospectiva
Al final de cada Sprint, el equipo se para a revisar cómo ha trabajado: personas, interacciones, procesos, herramientas y su definición de hecho. La guía dice que su propósito es planear formas de aumentar la calidad y la efectividad. Las mejoras más útiles se abordan cuanto antes, incluso en el Sprint siguiente.
Es el momento en el que el equipo decide, por ejemplo, empezar a programar en parejas o automatizar algo que hoy se hace a mano.
Analizar lo justo y descubrir el resto construyendo
El análisis no es exhaustivo. Los «pormenores» se terminan de descubrir a medida que avanza la implementación: al ver el software funcionando, el cliente y el equipo entienden mejor qué hace falta de verdad.
Es la idea de dos valores del Manifiesto Ágil: «Software funcionando sobre documentación extensiva» y «Respuesta ante el cambio sobre seguir un plan». Lo de la derecha tiene valor; lo de la izquierda, más.
Por el mismo motivo, superar un obstáculo imprevisto tiene prioridad sobre las convenciones o reglas de trabajo preestablecidas. Las reglas están para ayudar al equipo; si en un caso concreto estorban, se cambian. Es la aplicación práctica, según la entendemos, de otro valor del manifiesto: «Individuos e interacciones sobre procesos y herramientas».
Las reglas están para ayudar al equipo, no al revés.
Tests de aceptación en lugar de documentación
El analista de negocio cambia los cientos de páginas de documentación por tests de aceptación: pruebas escritas con ejemplos que el cliente entiende y aprueba, y que la máquina ejecuta para comprobar que el software hace lo que se pidió.
En XP se llaman Customer Tests: el cliente define pruebas de aceptación automáticas para cada funcionalidad y el equipo se asegura de que, una vez pasan, sigan pasando siempre. La documentación no desaparece, pero lo que define si algo está terminado es una prueba que se puede ejecutar, no un documento que se puede interpretar.
Cómo se trabaja así paso a paso lo cuento en Desarrollo dirigido por tests de aceptación (ATDD).
El código es de todo el equipo
Propiedad colectiva del código
El código pertenece a todo el equipo y cualquier desarrollador puede modificar código escrito por otro. En XP, Collective Code Ownership significa que cualquier pareja puede mejorar cualquier parte del código en cualquier momento.
Para que esto no sea un caos hacen falta dos cosas: tests que avisen si un cambio rompe algo y un estilo de código común, para que todo parezca escrito por la misma persona.
Programación en parejas
En la programación en parejas (pair programming), dos personas trabajan juntas en un mismo ordenador. XP propone escribir así todo el código de producción: es revisión de código continua, mejora el diseño y los tests, y reparte el conocimiento. Los estilos, cómo empezar y las herramientas para hacerlo en remoto están en qué es el pair programming.
Hay dos formas habituales de repartirse el trabajo, según el artículo de Birgitta Böckeler y Nina Siessegger en martinfowler.com:
Conductor y navegante
- El conductor tiene el teclado y se centra en el paso inmediato, en voz alta
- El navegante revisa lo que se escribe y piensa en el conjunto
- Se cambian los papeles a menudo
Ping-pong
- Una persona escribe un test que falla
- La otra escribe el código que lo hace pasar
- Refactorizan y se intercambian: la segunda escribe el siguiente test
Programar en pareja cansa. Las autoras recomiendan hacer pausas regulares (por ejemplo, con bloques tipo Pomodoro de unos 25 minutos) y no pasar de unas seis horas de pairing al día.
Las decisiones de arquitectura, en equipo
Las grandes decisiones de arquitectura las toma todo el equipo, no las impone un arquitecto. La Guía de Scrum define al equipo como autogestionado: decide internamente quién hace qué, cuándo y cómo. En XP, el diseño se mejora de forma continua (refactorizando) en lugar de fijarse al principio. Para que el porqué de cada decisión no se pierda, se puede apuntar en un ADR (architecture decision record).
Integrar, probar y desplegar cada día
Los desarrolladores envían sus cambios al repositorio con frecuencia, las baterías de tests se ejecutan varias veces al día y la aplicación se construye y se despliega de forma automática.
Esto es la integración continua. Martin Fowler la define así en la revisión de 2024 de su artículo: cada miembro del equipo integra sus cambios con los de sus compañeros al menos una vez al día, y cada integración la comprueba una build automática que ejecuta los tests. Si esa build falla, se arregla en el momento: es la prioridad.
- Haz cambios pequeños e intégralos en la rama principal al menos una vez al día.
- Deja que una build automática compile y ejecute todos los tests en cada integración.
- Si la build se rompe, arréglala (o deshaz el cambio) antes de seguir con otra cosa.
- Despliega de forma automática en un entorno de pruebas, como mínimo a diario.
El artículo original hablaba de desplegar en preproducción a diario. Hoy muchos equipos van más allá: con entrega continua, cada cambio que pasa los tests queda listo para producción. La diferencia entre integración, entrega y despliegue continuos la explico en Desarrollo continuo de software.
¿Y si el equipo trabaja con agentes de IA?
Esto es criterio propio del enfoque IA Limpia, no algo que digan las fuentes de este artículo.
Un agente de IA escribe código muy deprisa, así que estas técnicas importan más, no menos:
- Tests de aceptación e integración continua son la forma de comprobar, en cada cambio, que lo que ha generado el agente hace lo que se pidió y no rompe nada.
- Cambios pequeños e integrados a menudo: un cambio enorme generado de golpe es tan difícil de revisar como uno escrito a mano.
- Propiedad colectiva: el código que propone un agente es del equipo en cuanto se integra. La persona que lo integra responde de él igual que si lo hubiera escrito.
- Retrospectiva: es buen sitio para revisar qué ha funcionado al trabajar con agentes y qué ha generado más trabajo del que ha ahorrado.
Siguiente paso
No hace falta adoptarlo todo de golpe. Elige una técnica que tu equipo no use todavía, pruébala durante un ciclo y llévala a la retrospectiva para decidir si se queda. Las dos que más rápido se notan suelen ser una daily corta centrada en el objetivo y la integración continua.
Fuentes
Comprobado en noviembre de 2026:
- Ken Schwaber y Jeff Sutherland, La Guía de Scrum, versión de noviembre de 2020, la vigente: tamaño del equipo, autogestión, Daily Scrum, Sprint Retrospective y duración del Sprint.
- Manifiesto por el Desarrollo Ágil de Software, texto oficial en español.
- Ron Jeffries, What is Extreme Programming?, versión de marzo de 2011: Whole Team, Customer Tests, Pair Programming, Collective Code Ownership, Coding Standard, Design Improvement y Continuous Integration.
- Martin Fowler, Continuous Integration, revisión del 18 de enero de 2024.
- Birgitta Böckeler y Nina Siessegger, On Pair Programming, martinfowler.com, 15 de enero de 2020.
Las relaciones entre cada técnica y los valores del manifiesto son interpretación nuestra. Este artículo no incluye código ni comandos.