Introducción: cuando tres perspectivas valen más que mil correos
En muchos equipos de desarrollo de software, la historia de usuario llega como una nota en Jira o un correo del Product Owner.
Se interpreta, se desarrolla, se prueba… y al final, el usuario dice:
“Sí, funciona, pero no era lo que necesitábamos.”
Ese “pero” representa el costo del aislamiento entre negocio, desarrollo y calidad.
El problema no es de herramientas, sino de comunicación: falta de conversación significativa antes de codificar.
Aquí entra en escena la Sesión de los Tres Amigos (Three Amigos Session), una práctica ágil y clave en la Calidad Fluida.
Tres perspectivas —la del negocio, la del desarrollador y la del tester— se sientan a conversar, a explorar ejemplos concretos y a descubrir cómo se comportará el sistema en la realidad.
En Enjisst, esta práctica se aplica dentro de procesos de consultoría en calidad de software y auditorías técnicas ágiles, como parte de su metodología PAREX: Agilidad Pragmática.
Es el puente invisible que une visión, código y validación: calidad que se diseña en equipo, no que se revisa al final.
El origen del concepto
El término “Three Amigos” fue popularizado por Dan North y Liz Keogh, pioneros del Behavior-Driven Development (BDD).
Ambos identificaron un patrón común en los proyectos fallidos: los defectos más costosos no se originaban en el código, sino en las conversaciones ausentes.
Historias poco claras, supuestos no validados y criterios de aceptación ambiguos generaban retrabajo y frustración.
La solución era simple pero poderosa: provocar las conversaciones correctas antes de escribir una sola línea de código.
En marcos modernos como Use-Case 3.0 y PAREX, esta práctica se reconoce como la base de la trazabilidad continua:
lo que el negocio visualiza se convierte en funcionalidades accionables y, finalmente, en escenarios de prueba automatizados, tal como lo promueven los servicios de aseguramiento ágil de Taqtical.
Los tres protagonistas
- El Product Owner (Negocio):
Representa la necesidad, el valor y la prioridad.
Su rol es asegurar que todos entiendan por qué esa historia existe y qué problema resuelve. - El Desarrollador (Dev):
Aporta la perspectiva técnica.
No solo estima esfuerzo, sino que cuestiona la factibilidad y anticipa riesgos. - El Tester o QA:
Encarna la visión del riesgo y la validación.
Pregunta “¿qué pasa si…?” para descubrir casos frontera y evitar fallos invisibles.
Cuando estas tres voces colaboran, surge un entendimiento compartido que ni el mejor documento puede reemplazar.
De hecho, Enjisst integra este principio en sus consultorías de aseguramiento de calidad, ayudando a los equipos a reducir retrabajo y mejorar la cobertura funcional desde la conversación inicial.
El ritual: de la historia al escenario
1. Preparación: traer la historia, no la solución
La sesión inicia con una historia de usuario bien definida, pero abierta a exploración:
“Como usuario, quiero poder agregar productos al carrito para luego comprarlos.”
El Product Owner presenta el valor esperado; el equipo evita discutir soluciones técnicas, enfocándose en comportamientos.
2. Inmersión en el valor
Antes de hablar de código o pruebas, los tres amigos se preguntan:
- ¿Qué problema resuelve esta historia?
- ¿Quién se beneficia y cómo?
- ¿Cómo sabremos si funciona?
Esta reflexión ancla la conversación al valor, no a la funcionalidad.
Según PAREX: Agilidad Pragmática, este paso asegura que los escenarios se alineen con los objetivos del negocio, garantizando que la validación posterior tenga sentido.
3. Descubrimiento de escenarios concretos
Una vez entendido el valor, comienza la exploración de ejemplos:
- Éxito: agregar un producto disponible.
- Error: intentar agregar un producto agotado.
- Frontera: agregar el máximo número permitido de unidades.
Cada escenario revela reglas, validaciones y excepciones que, si no se discuten ahora, se convertirán en errores después.
Este pensamiento por escenarios refleja los principios de Use-Case 3.0, donde se “cuenta la historia completa”, incluyendo variantes y excepciones.
4. Redacción colaborativa en lenguaje Gherkin
Los ejemplos se transforman en escenarios ejecutables escritos en Gherkin, usando lenguaje natural y entendible para todos:
Feature: Agregar productos al carrito
Scenario: Agregar un producto disponible
Given que el usuario ha iniciado sesión
When agrega un producto con stock
Then el carrito debe mostrar el artículo y el total actualizado
Estos escenarios luego alimentan pipelines de automatización de pruebas BDD, uno de los pilares de los servicios de aseguramiento de software de Taqtical.
5. Validación y priorización
El equipo revisa qué escenarios son esenciales, cuáles se automatizarán y cuáles requieren validación manual o UX.
El resultado: una especificación ejecutable y priorizada por valor.
Lo que realmente se gana con una sesión de tres amigos
- Claridad compartida: todos interpretan el requisito de la misma forma.
- Prevención de defectos: los errores se detectan antes de programar.
- Criterios de aceptación sólidos: se redactan en lenguaje observable.
- Cultura de colaboración: QA deja de auditar, y se convierte en arquitecto de validación.
- Velocidad sostenible: más tiempo al inicio, pero menos retrabajo después.
Los equipos que aplican esta práctica —acompañados por consultorías de calidad ágil como las de Enjisst— reportan una reducción significativa en tiempos de entrega y mayor confianza del negocio.
Cómo dirigir una sesión de los tres amigos efectiva
| Fase | Objetivo | Entregable |
| Comprensión | Entender el valor y propósito | Declaración de valor de la historia |
| Exploración | Descubrir comportamientos y riesgos | Lista de escenarios posibles |
| Especificación | Formalizar en Gherkin o notas de prueba | Escenarios acordados |
| Cierre | Priorizar y asignar responsables | Lista de acciones |
Consejos prácticos:
- Define un objetivo claro: una historia, no un sprint completo.
- Limita la duración (30–60 minutos).
- Usa ejemplos reales y datos del negocio.
- Garantiza participación equitativa.
- Cierra siempre con acuerdos medibles.
Ejemplo práctico
Historia: “Como usuario, quiero restablecer mi contraseña para recuperar el acceso a mi cuenta.”
Escenarios descubiertos:
- Restablecer con correo válido → éxito.
- Intentar con correo no registrado → mensaje de error.
- Solicitud repetida → bloqueo temporal.
- Link expirado → aviso y nueva solicitud.
Feature: Recuperar contraseña
Scenario: Solicitud exitosa
Given que el usuario tiene una cuenta activa
When solicita restablecer su contraseña
Then recibe un correo con el enlace de recuperación
Cada escenario representa una validación observable del comportamiento y sirve como base para la automatización de pruebas funcionales, promoviendo la trazabilidad que Enjisst fomenta en sus servicios de testing y aseguramiento de software.
Conexión con la Calidad Fluida
La Sesión de los Tres Amigos es la primera válvula del flujo de calidad.
Allí se inyecta el conocimiento que más adelante recorrerá el pipeline de automatización, validación y despliegue continuo.
En términos de PAREX, este espacio garantiza la continuidad de la trazabilidad desde el modelamiento de negocio hasta la ejecución automatizada de pruebas BDD.
El resultado es un flujo estable de valor verificable, donde cada funcionalidad tiene un propósito, un escenario y una evidencia.
Recomendaciones avanzadas
- Documenta los acuerdos o graba las sesiones; son activos de conocimiento.
- Usa herramientas colaborativas (Miro, Notion, Jira) para vincular escenarios.
- Crea mapas de escenarios (Scenario Mapping) para visualizar rutas y excepciones.
- Evita el exceso de detalle: aplica el principio Just Enough, Just in Time de Use-Case 3.0.
Estas prácticas se incluyen en los programas de consultoría y capacitación técnica de Enjisst, orientados a fortalecer la colaboración entre roles y optimizar el flujo de valor.
Cierre: la conversación como cimiento de la calidad
En una era centrada en la automatización de pruebas y la velocidad de entrega, la Sesión de los Tres Amigos nos recuerda que la conversación sigue siendo la herramienta más poderosa para construir calidad.
Antes del código, antes del pipeline, y antes de la prueba, está el diálogo que alinea propósito, factibilidad y validación.
Porque el software de calidad no empieza con una línea de código:
empieza con tres personas dispuestas a escucharse, y con organizaciones como Enjisst que convierten esas conversaciones en valor tangible.