Cliente presente, prática do Extreme programming

Equipes XP devem ser formadas não apenas por desenvolvedores, mas também por clientes e quaisquer outras pessoas que devam ser ouvidas ao longo do desenvolvimento. Um projeto bem sucedido precisa levar em conta a opinião de diversas partes, bem como incorporar diferentes pontos de vista.

por Vinícius Manhães Teles

Equipes XP devem ser formadas não apenas por desenvolvedores, mas também por clientes e quaisquer outras pessoas que devam ser ouvidas ao longo do desenvolvimento. Um projeto bem sucedido precisa levar em conta a opinião de diversas partes, bem como incorporar diferentes pontos de vista.

Embora clientes normalmente não possam passar 100% do tempo com a equipe de desenvolvimento, essa não é a proposta da prática. A idéia é que o cliente, e outras pessoas importantes no projeto, tenham disponibilidade (a maior possível) para ajudar os desenvolvedores sempre que tiverem dúvidas. A ênfase da prática é fazer com que o cliente seja acessível e compreenda a importância disso para o bom andamento do projeto.

Equipes XP se baseiam no princípio de que o resultado final de um projeto depende não apenas dos desenvolvedores, mas também do cliente e de quaisquer outras pessoas que possam ter algum tipo de contribuição para o projeto. Isso é um ponto de vista compartilhado por muitas pessoas, porém vem sendo ignorado fortemente em diversos casos, especialmente nas grandes corporações, onde é comum se criar uma distância significativa entre o cliente e a equipe de desenvolvimento.

É possível utilizar uma metáfora para ilustrar a importância dessa prática. Suponha que eu esteja acima do meu peso e decida procurar a ajuda de uma nutricionista. Depois de conversar comigo e tomar minhas medidas, ela me passa uma dieta, recomenda que eu comece a fazer exercícios e retorne em duas semanas. Na nova consulta, ela me coloca na balança e nota que eu não perdi nem 100g. Eu fico completamente aborrecido e começo a achar que aquilo é uma grande perda de tempo. Começo a cobrar explicações quando ela me pergunta:

- Você seguiu a dieta?
- Não. - respondo.
- Hummm... E você fez exercícios?
- Não. - respondo um pouco menos agitado e começando a olhar para o chão.
- Então você consegue identificar alguma causa para não ter perdido peso?
- Bem... Acho estou começando a ter uma idéia...

Na história acima, imagine que o paciente seja um cliente de desenvolvimento de software que procura um profissional (a equipe de desenvolvimento) para resolver um problema do seu negócio. Perder peso com a ajuda de uma nutricionista funciona, mas só quando ambos os lados fazem a sua parte. Por melhor que seja a nutricionista, o paciente não perde nada se não fizer a sua parte, se não tiver disciplina, se não seguir as recomendações. Por outro lado, mesmo o paciente mais disciplinado não perderá peso e poderá até ganhar se for mal orientado.

Em desenvolvimento de software acontece o mesmo. O cliente (representado pelo paciente na metáfora) tem um papel essencial que é informar o que precisa ser feito e fazer isso de forma clara. Ainda mais importante, precisa explicar qualquer mudança nas circunstâncias do projeto, as quais gerem mudanças naquilo que foi solicitado para a equipe. Essa, por melhor que seja, não tem como produzir um software que resolva o problema do cliente se este não informar adequadamente aquilo que precisa ser feito. Mas, infelizmente esse não é um trabalho que possa ser feito apenas no início do projeto ou com pouca freqüência. Trata-se de um trabalho contínuo, que precisa ser realizado ao longo de todo o projeto porque as pessoas evoluem, percebem coisas diferentes, têm dúvidas novas e é importante que o cliente esteja acessível para ajudar. O outro lado da moeda também ocorre. Por melhor e mais acessível que seja o cliente, se estiver trabalhando com uma equipe pouco capacitada, o resultado será ruim. Ambas as partes precisam trabalhar bem em conjunto.

A idéia da proximidade física entre equipe e cliente de desenvolvimento tem a ver com o valor da comunicação no XP. Existem muitas formas de se comunicar idéias, tais como diálogo presencial, telefone, email, mensagens instantâneas, entre outras. Entretanto, alguns meios de comunicação são mais ricos que outros. Normalmente, o diálogo presencial é a forma mais eficaz, porque os interlocutores têm acesso a vários elementos da comunicação, tais como as palavras verbalizadas, gestos, expressões faciais, postura, tom de voz, entre outros. No conjunto, esses elementos colaboram para que se compreenda melhor as mensagens transmitidas. Já uma comunicar por telefone, por exemplo, é menos rica porque perdem-se todas as componentes visuais. O que há de ruim nisso? Sabe quando você fala alguma coisa e a outra pessoa faz uma expressão de quem não entendeu? Pois é, trata-se de um feedback importante, porque provavelmente fará você explicar melhor o assunto. Por telefone não se consegue observar isso e talvez a pessoa decida não verbalizar sua dúvida. Assim começam as interpretações equivocadas.

A comunicação entre cliente e desenvolvedores pode se dar pessoalmente ou por email e outras ferramentas computacionais, por exemplo. Estes últimos embora também possam funcionar, são menos eficientes que o diálogo presencial. Portanto o XP procura dar preferência ao diálogo, não porque outros meios de comunicar necessariamente sejam falhos, mas porque acredita-se que dialogar será mais eficiente, gastará menos tempo e irá gerar maior compreensão. E isso é outro fator que nos leva a buscar a proximidade e a participação freqüente do cliente.