El Cliente Disponible

XP originalmente pedía un cliente en sitio—un usuario real o su representante, físicamente presente con el equipo.

¿Por qué tan extremo?

El desarrollo de software es toma de decisiones constante:

• ¿Cómo debería comportarse este caso límite?
• ¿Cuál de estos dos diseños es mejor para los usuarios?
• ¿Vale la pena corregir este bug o es una limitación conocida?
• ¿Qué es más importante: la funcionalidad A o la funcionalidad B?

Si el cliente no está disponible, los desarrolladores adivinan. Adivinan mal. Construyen lo incorrecto. O esperan, bloqueando el progreso hasta que puedan obtener una respuesta.

Clientes disponibles:

• Desbloquean decisiones en minutos, no días
• Detectan malentendidos temprano
• Toman decisiones de prioridad en contexto
• Construyen confianza a través de colaboración cercana

El rol de cliente en XP viene con derechos y responsabilidades.

Derechos del cliente:

• Conocer el costo estimado de cada historia
• Conocer la velocidad del equipo y cuándo se terminarán las cosas
• Cambiar prioridades en cualquier momento (dentro de los límites de la iteración)
• Cancelar el proyecto y obtener un sistema funcional (lo que se haya hecho)
• Ver el progreso a través de software funcional, no solo reportes

Responsabilidades del cliente:

• Estar disponible para responder preguntas rápidamente
• Tomar decisiones de prioridad cuando se le pida
• Proporcionar criterios de aceptación para las historias
• Aceptar compromisos cuando el alcance excede la capacidad
• Dar retroalimentación sobre el software entregado prontamente

Esto es una asociación. El cliente no es un stakeholder distante lanzando requisitos por encima del muro. Es un miembro del equipo tomando decisiones diariamente.

En la práctica, el "cliente real" a menudo no está disponible. Tienen trabajos. No pueden sentarse con los desarrolladores todo el día.

Entra el proxy del product owner—alguien que representa al cliente:

• Product managers
• Analistas de negocio
• Product owners (terminología de Scrum)
• Expertos internos en la materia

El modelo de proxy funciona cuando:

• El proxy realmente entiende las necesidades del usuario
• El proxy tiene autoridad para tomar decisiones
• El proxy está genuinamente disponible (no tiene doble agenda)
• Los clientes reales proporcionan retroalimentación regular (demos, sesiones de retroalimentación)

El modelo de proxy falla cuando:

• El proxy no entiende el dominio
• El proxy no puede tomar decisiones sin escalar
• El proxy está demasiado ocupado para estar disponible
• Los clientes reales nunca ven el software

Las pruebas de aceptación son cómo los clientes y desarrolladores verifican que se entienden mutuamente.

Para cada historia, el cliente define criterios de aceptación:

• Dado [este contexto]
• Cuando [esta acción ocurre]
• Entonces [este debería ser el resultado]

Estos se convierten en pruebas ejecutables. Cuando las pruebas pasan, la historia está terminada. No hay debate sobre si está "realmente terminada".

Beneficios:

• Requisitos inequívocos (si la prueba pasa, funciona)
• Documentación viva (las pruebas describen lo que hace el sistema)
• Seguridad de regresión (las pruebas detectan cuando el comportamiento cambia)
• Compromiso del cliente (escribir criterios requiere pensar)

En XP moderno, las pruebas de aceptación a menudo se escriben en colaboración entre el cliente y los desarrolladores. El cliente describe el comportamiento; los desarrolladores ayudan a traducir a forma comprobable.

Los equipos modernos a menudo están distribuidos. El cliente "en sitio" es un canal de Slack, una llamada de Zoom o un mensaje asíncrono.

Hacerlo funcionar remotamente:

• Sobrecomunicar (asumir que nada es obvio)
• Usar video para interacción cara a cara cuando sea posible
• Crear formas de baja fricción para hacer preguntas (chat sobre correo)
• Registrar decisiones para que sean encontrables después
• Respetar zonas horarias (no esperar respuestas instantáneas a las 3 AM)

Participación asíncrona del cliente:

• Escribir preguntas claras con contexto
• Ofrecer opciones en lugar de preguntas abiertas
• Establecer expectativas para el tiempo de respuesta
• Usar documentos para decisiones complejas (más fácil de revisar de forma asíncrona)

El principio permanece: minimizar el tiempo entre pregunta y respuesta. El trabajo remoto hace esto más difícil pero no imposible.