O Cliente Presente

XP originalmente exigia um cliente presente—um usuário real ou seu representante, fisicamente presente com a equipe.

Por que tão extremo?

O desenvolvimento de software é uma tomada de decisão constante:

• Como esse caso extremo deve se comportar?
• Qual desses dois designs é melhor para os usuários?
• Esse bug vale a pena corrigir ou é uma limitação conhecida?
• O que é mais importante: funcionalidade A ou funcionalidade B?

Se o cliente não está disponível, os desenvolvedores adivinham. Eles adivinham errado. Eles constroem a coisa errada. Ou eles esperam, bloqueando o progresso até conseguirem uma resposta.

Clientes disponíveis:

• Desbloqueiam decisões em minutos, não em dias
• Capturam mal-entendidos cedo
• Tomam decisões de prioridade no contexto
• Constroem confiança através de colaboração próxima

O papel do cliente em XP vem com direitos e responsabilidades.

Direitos do cliente:

• Conhecer o custo estimado de cada história
• Conhecer a velocidade da equipe e quando as coisas serão concluídas
• Mudar prioridades a qualquer momento (dentro dos limites da iteração)
• Cancelar o projeto e obter um sistema funcional (o que quer que tenha sido feito)
• Ver o progresso através de software funcional, não apenas relatórios

Responsabilidades do cliente:

• Estar disponível para responder perguntas rapidamente
• Tomar decisões de prioridade quando solicitado
• Fornecer critérios de aceitação para histórias
• Aceitar trade-offs quando o escopo excede a capacidade
• Dar feedback sobre o software entregue prontamente

Isso é uma parceria. O cliente não é um stakeholder distante jogando requisitos por cima do muro. Eles são um membro da equipe tomando decisões diariamente.

Na prática, o "cliente real" geralmente não está disponível. Eles têm empregos. Eles não podem sentar com desenvolvedores o dia todo.

Entre o proxy do product owner—alguém que representa o cliente:

• Gerentes de produto
• Analistas de negócios
• Product owners (terminologia Scrum)
• Especialistas internos no assunto

O modelo de proxy funciona quando:

• O proxy realmente entende as necessidades do usuário
• O proxy tem autoridade para tomar decisões
• O proxy está genuinamente disponível (não com agenda dupla)
• Clientes reais fornecem input regular (demos, sessões de feedback)

O modelo de proxy falha quando:

• O proxy não entende o domínio
• O proxy não pode tomar decisões sem escalonamento
• O proxy está ocupado demais para estar disponível
• Clientes reais nunca veem o software

Testes de aceitação são como clientes e desenvolvedores verificam que se entendem.

Para cada história, o cliente define critérios de aceitação:

• Dado [este contexto]
• Quando [esta ação acontece]
• Então [este deve ser o resultado]

Estes se tornam testes executáveis. Quando os testes passam, a história está concluída. Sem debate sobre se está "realmente concluída."

Benefícios:

• Requisitos inequívocos (se o teste passa, funciona)
• Documentação viva (testes descrevem o que o sistema faz)
• Segurança de regressão (testes capturam quando o comportamento muda)
• Engajamento do cliente (escrever critérios requer pensar)

Em XP moderno, testes de aceitação são frequentemente escritos em colaboração entre o cliente e desenvolvedores. O cliente descreve o comportamento; desenvolvedores ajudam a traduzir para forma testável.

Equipes modernas são frequentemente distribuídas. O cliente "presente" é um canal do Slack, uma chamada no Zoom ou uma mensagem assíncrona.

Fazendo funcionar remotamente:

• Supercomunique (assuma que nada é óbvio)
• Use vídeo para interação face a face quando possível
• Crie formas de baixo atrito para fazer perguntas (chat em vez de email)
• Registre decisões para que sejam encontráveis depois
• Respeite fusos horários (não espere respostas instantâneas às 3 da manhã)

Envolvimento assíncrono do cliente:

• Escreva perguntas claras com contexto
• Ofereça opções em vez de perguntas abertas
• Defina expectativas para tempo de resposta
• Use documentos para decisões complexas (mais fácil de revisar assincronamente)

O princípio permanece: minimize o tempo entre pergunta e resposta. Trabalho remoto torna isso mais difícil, mas não impossível.