XP Rio

Na semana passada entrevistei o Kent Beck a pedido da Revista Inform. A entrevista será publicada na edição de dezembro. A entrevista segue abaixo em primeira mão para o XP Rio.

Vinícius: Como o XP se compara a abordagens tradicionais de desenvolvimento de software, tais como PSP (Personal Software Process) do SEI ou o RUP da Rational?

Kent: PSP se concentra em aprimorar habilidades individuais. RUP é uma coleção de práticas que podem ter valor para o desenvolvimento de software. Comparado a ambos, XP é muito explícito sobre a importância dos relacionamentos sociais para se desenvolver software de forma eficaz, além de forçar o lado técnico a ser mais rigoroso que o usual. XP é descrito não apenas por práticas, mas também pelos valores e princípios que motivam essas práticas.

Vinícius: XP e metodologias ágeis em geral têm uma íntima co-relação com princípios Just-in-Time criados e aprimoradas na Toyota. Você acredita que o XP terá, no longo prazo, os mesmos efeitos na indústria de software que o Just-in-Time teve na indústria automobilística?

Kent: Espero que sim, mas mudanças fundamentais como essas levam décadas para se espalhar por uma indústria, portanto, não saberemos a resposta por um tempo.

Vinícius: Você acredita que haveria vantagens para as empresas produtoras de software brasileiras se elas optassem pela adoção do XP para melhoria de qualidade, ao invés de outras abordagens, como o CMM?

Kent: Sim. As práticas do XP são descritas de forma clara, embora cada equipe deva decidir como aplicá-las. Os resultados da utilização do XP podem ser imediatos e substanciais, apesar de as equipes poderem continuar melhorando durante anos à medida que o utilizam. No XP, eu sugiro que as equipes adotem ciclos rápidos de feedback, de modo que possam avaliar rapidamente mudanças em suas práticas de desenvolvimento. Finalmente, enquanto algumas das mudanças propostas pelo XP possam ser aplicadas por um programador sozinho, algumas das práticas corolárias demandam mudanças da parte do cliente, fornecedores e executivos, além dos próprios desenvolvedores.

Vinícius: Qual é o papel dos frameworks em projetos XP e a relação deles com o valor da simplicidade?

Kent: Frameworks são arriscados quando são escritos cedo demais, pois nesse caso serão difíceis de usar. Mediocridade consistente não é um objetivo valioso. Se você estiver trabalhando no estilo XP, você primeiro constrói duas ou mais aplicações e então abstrai aquilo que é comum, fazendo com que aplicações semelhantes sejam construídas mais facilmente no futuro. Depois de muitos anos trabalhando dessa forma, as equipes terão criado frameworks poderosos, mas sem o risco de que eles sejam mais difíceis de utilizar do que o necessário.

Vinícius: Qual é o futuro do JUnit?

Kent: Estamos trabalhando ativamente no JUnit 4, que trará a primeira grande mudança na API. Nosso objetivo é fazer com que escrever testes seja ainda mais fácil e simples para os desenvolvedores. A nova versão também possui novas áreas úteis para aqueles que desejam criar plugins para o JUnit.
Além disso, os testes antigos serão executados sem modificações na nova versão e os testes baseados no novo estilo poderão ser facilmente executados em versões antigas do JUnit.

Vinícius: Quais são os seus planos com a Agitar? O que você está produzindo com eles no momento?

Kent: A Agitar Software produz ferramentas que tornam os testes dos desenvolvedores mais valiosos e mais visíveis. Acredito que o futuro do desenvolvimento de software envolva maior responsabilidade e transparência, de modo que nossos objetivos estão bem alinhados. Eu trabalho com eles planejando e revisando produtos, além de conversar com clientes e potenciais clientes.

Vinícius: Como a documentação se encaixa nas práticas do XP?

Kent: Comunicação é algo crítico para se desenvolver software de forma bem sucedida, e o meio de comunicação deve ser escolhido de modo a maximizar os benefícios e minimizar os custos. Cada equipe encontra uma forma diferente de solucionar suas necessidades de comunicação. Entretanto, uma das premissas básicas por trás do XP é que as decisões perdem valor muito rapidamente no desenvolvimento de software. Por isso, escrever documentos enormes contendo milhares de decisões de análise e design, cada uma das quais vai perdendo valor gradualmente, não é uma atividade valiosa. Equipes normalmente encontram formas de comunicação melhores que essa.

Vinícius: Quais são os pontos negativos do XP que você já tenha notado como sendo os mais nítidos?

Kent: Ele desafia as convicções de algumas pessoas. Para aplicá-lo de forma eficaz, as crenças precisam estar alinhadas com as do XP. Quando pensamentos básicos estão desalinhados com os valores do XP há interferências nos benefícios que podem ser obtidos. Para alguns, isso requer uma grande mudança na forma de pensar e de agir.

Vinícius: Você acredita que o XP possa ser aplicado a projetos que envolvam muitas pessoas? Isso impediria o sucesso da adoção do XP?

Kent: Acredito que o XP possa ser aplicado em muitas escalas diferentes. As verdades básicas sobre a natureza humana e sobre desenvolvimento de software são as mesmas para uma equipe de uma pessoa ou de mil. Grandes organizações que obtiveram sucessos isolados com desenvolvimento ao estilo do XP estão interessadas em obter os mesmos tipos de melhorias em toda a equipe. Acredito que seja positivo para o XP que as companhias queiram que todos as suas equipes mostrem resultados concretos com frequência, que tenham significativamente menos defeitos e que reduzam custos de uma forma geral.

Vinícius: O que você recomenda para empresas interessadas em começar a utilizar o XP?

Kent: Experimente. O processo mais eficaz que encontrei para a aplicação do XP é olhar para as práticas e lembrar momentos nos quais você e a sua equipe fizeram um bom trabalho. Então, aplique aquilo que você já sabe que funciona, mas veja se você consegue fazer algo ainda melhor desta vez. Gerentes têm o direito de demandar visibilidade e responsabilidade de suas equipes. XP é uma forma de prover comunicação clara sobre o projeto. Os outros processos que você mencionou no início da entrevista são outras formas de atingir esse objetivo.

Obrigado pela oportunidade de me expressar para o público brasileiro. Entrem em contato caso tenham mais questões.

Sinceramente,

Kent Beck
Diretor, Threee Rivers Institute

Este artigo foca na parte do Jogo do Planejamento (levantamento de requisitos e controle/execução de atividades)... como o próprio autor coloca:

"We’ll look at XP as a series of nested conversations. You’ll see a pattern repeated at each level: explore, plan, define a test, do the work, verify the result.

Nested Conversations in XP

Month scale
Release planning, iterations, release to users

Week scale
Iteration planning, daily work, release to customer

Day scale
Standup meeting, paired programming, release to development team

Hour/Minute scale
Test, code, refactor"

Nesta entrevista, Kent Beck fala sobre mudanças na nova edição de Extreme Programming Explained. Além do texto, você também pode escutar toda a entrevista, bem como uma descrição geral do livro apresentada por Bruce Taylor.

Extreme Programming - Visão Geral

Você colocaria grande parte do seu dinheiro em um investimento que tivesse 70% de chances de dar prejuízo? Talvez não, mas supondo que você seja suficientemente corajoso e decida fazer isso, você acompanharia o seu investimento de perto, ou só se preocuparia com ele de vez em quando?

Essas perguntas têm muito em comum com a indústria de software e talvez você se interesse por elas, se tiver a oportunidade de apreciar alguns números levantados por uma empresa americana chamada Standish Group. Há pouco mais de uma década, ela vem produzindo um relatório chamado The Chaos Report, cujo exemplar do ano 2000, que pesquisou 280 mil projetos de software nos EUA, revelou que 72% deles falham devido a um dos seguintes fatores:

a) Consomem mais recursos que o orçado
b) Consomem mais tempo que o estimado
c) Não entregam o que foi combinado
d) Todas as alternativas acima em conjunto

Infelizmente a letra d) é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que foram cancelados ("apenas" 64.400 projetos).

O Standish Group também informa que, pesquisando o grau de utilização das funcionalidades dos sistemas que são colocados em produção, foi descoberto que, tipicamente, 45% das funcionalidades nunca são utilizadas pelos seus usuários e 19% delas raramente são usadas, totalizando 64% de funcionalidades que poderiam deixar de ser produzidas. Por outro lado, o mesmo estudo revelou que 7% das funcionalidades são usadas sempre e outros 13% são usados com frequência. Assim, concluiu-se que o Princípio de Pareto também se aplica ao desenvolvimento de software, onde 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

O Manifesto Ágil

Nem todos os que trabalham na indústria de software têm conhecimento destes números, mas praticamente todos percebem, ainda que intuitivamente, que muita coisa é feita de forma errada e ineficaz, gerando problemas que não parecem ter fim. Existem inclusive piadas citando que nós estamos aqui para resolver os problemas que nós mesmos criamos.

Há alguns anos, um pequeno grupo de profissionais veteranos na área de software decidiram se reunir em uma estação de ski, nos EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre pareciam ter sido respeitados quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que são apresentados a seguir:

"Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:

- Indivíduos e interação entre eles mais que processos e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda."

O Manifesto Ágil, criado em 2001, descreve a essência de um conjunto de abordagens para desenvolvimento de software criadas ao longo da última década. A mais conhecida delas é o Extreme Programming, também conhecida pela abreviação XP, uma metodologia criada por Kent Beck no final dos anos 90. O XP é composto por um pequeno conjunto de práticas, que giram em torno de alguns valores básicos.

Valores:

- Feedback

Algumas pessoas seriam capazes de caminhar na beirada de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Elas acreditam que projetos de software são iniciativas frequentemente caras, arriscadas e com um histórico repleto de falhas, o que as leva a simples conclusão de que provavelmente o projeto em que estão envolvidas também enfrentará falhas e problemas, como é habitual na área de software.
Isso pode ser tratado de forma mais econômica e eficaz se as falhas forem detectadas rapidamente. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as consequências daquilo que pediu. Os clientes, por sua vez, procuram se manter próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que eles tenham ao longo do desenvolvimento.

- Comunicação

O cliente de um projeto de software tem um conjunto de problemas que deseja solucionar com o sistema em desenvolvimento e possui algumas idéias sobre que funcionalidades podem resolvê-los. Por sua vez, desenvolvedores possuem conhecimento sobre aspectos técnicos que influenciam a forma de solucionar o problema do cliente. Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes. Embora existam inúmeras formas de se comunicar idéias, algumas são mais eficazes que outras. Por exemplo, quando duas pessoas estabelecem um diálogo presencial, inúmeros elementos da comunicação colaboram para a compreensão do assunto, tais como gestos, expressões faciais, postura, palavras verbalizadas, tom de voz, emoções, entre outros. Quanto maior a capacidade de compreensão, maiores as chances de evitar problemas como ambiguidades, entendimento equivocados, entre outros. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

- Simplicidade

XP, assim como outras metodologias ágeis, se baseia em premissas que, frequentemente, representam o inverso do que as práticas habituais da indústria de software sugerem. Ele leva em consideração outros pontos de vista, aparentemente sem sentido, o mesmo que ocorreu há pouco mais de 50 anos quando se iniciou o desenvolvimento do Sistema de Produção da Toyota, também conhecido como Just-in-Time.
No início, o Just-in-Time foi considerado, especialmente pelos americanos, uma idéia absurda, porque se baseava no inverso das práticas as quais a indústria automobilística estava habituada a utilizar. No entanto, o avanço da indústria automobilística japonesa é bem conhecido atualmente e a Toyota é, há décadas, a montadora mais lucrativa do mundo. Parte disso tem a ver com uma filosofia que também norteia as práticas do XP: não produzir mais que o necessário.
A Toyota acredita que o maior desperdício que existe é produzir algo que ninguém irá utilizar. Se você leu atentamente os parágrafos anteriores, deve recordar que 64% das funcionalidades tipicamente produzidas não são utilizadas. Isso representa mais da metade delas e, possivelmente, bem mais da metade do tempo e dos gastos de um projeto típico de software.
O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

- Coragem

Costuma-se dizer que a única constante em um projeto de software é a mudança. Clientes mudam de idéia com frequência, mesmo quando fecham contratos nos quais, teoricamente, assumem o compromisso de não alterar o que está na especificação. Eles mudam porque aprendem durante o projeto e descobrem problemas mais prioritários a serem solucionados ou formas mais apropriadas de resolvê-los. Embora isso seja natural, acaba gerando uma preocupação para a equipe de desenvolvimento que, de tempos em tempos, precisa alterar partes do sistema que já estavam prontas, correndo o risco de se quebrar o que já vinha funcionando.
XP não tem uma solução mágica para eliminar esse risco. Ele existe em um projeto XP, como existe em qualquer outro. O que muda é a forma de lidar com ele. Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando é acontece cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção.

Práticas:

- Cliente Presente

Projetos XP procuram contar com a presença do cliente, junto à equipe de desenvolvimento, tanto quanto possível. Isso não significa que ele tenha que estar 100% de seu tempo com os desenvolvedores, mas sim que deve procurar, no mínimo, visitá-los e dialogar com eles inúmeras vezes ao longo do projeto, com a maior frequência possível. Como explicado anteriormente, XP valoriza o diálogo como forma de assegurar maior compreensão entre as partes. Portanto, a presença do cliente permite que os desenvolvedores compreendam melhor o que se espera do software, bem como permite que o cliente monitore de perto o avanço do projeto. Se alguém acha que clientes não têm tempo para dedicar aos desenvolvedores, vale lembrar que clientes de software estão lidando com um investimento arriscado, no qual as chances de prejuízo, como dito antes, são bastante elevadas.

- Jogo do Planejamento

O software é desenvolvimento de modo iterativo e incremental em projetos XP. Ou seja, uma vez por semana os desenvolvedores se reúnem com o cliente para priorizar um pequeno conjunto de funcionalidades que, no conjunto, possam ser implementadas e testadas completamente naquela semana. Terminado esse período, que é chamado de iteração, o cliente tem a oportunidade de utilizar e avaliar o que foi produzido. Com base nos resultados, reúne-se novamente com a equipe e estabelece novas prioridades de acordo com o que acabou de aprender com o software e com aquilo que já imaginava ser necessário produzir ao longo do restante do projeto. Essa reunião semanal recebe o nome de Jogo do Planejamento. Nela, o cliente tem o direito de informar as funcionalidades, também chamadas de histórias, bem como indicar a prioridade das mesmas. Os desenvolvedores, por sua vez, têm o direito de estimar e apresentar suas considerações técnicas. O objetivo do jogo do planejamento é criar um plano para uma semana de trabalho, que seja capaz de gerar (através de funcionalidades) o máximo de valor possível para o negócio do cliente, naquela semana.

- Stand Up Meeting

O stand up meeting é uma reunião rápida (em torno de 10 minutos) realizada no início de cada dia, onde os participantes normalmente ficam em pé (daí a origem do nome), cujo objetivo é atualizar todos os membros da equipe a respeito do que ocorreu no dia anterior e priorizar as atividades do dia que está começando. Ela é uma forma simples de assegurar que as pessoas obtenham feedback rápido sobre qualquer aspecto do projeto, bem como um mecanismo para planejar o que precisa ser feito primeiro, fazendo com que todos relembrem e reavaliem frequentemente o que é mais importante de se fazer a cada dia.

- Programação em Par

Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas em projetos XP. Quando é adotada, todo e qualquer código produzido no projeto é implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado. À primeira vista, a programação em par parece impensável, pois dá a impressão incorreta de que consome mais recursos ou eleva o tempo do desenvolvimento. Mas, não é o que acontece.

Companhias aéreas, por exemplo, utilizam co-pilotos, quando na prática, o piloto teria condições de realizar todo o trabalho sozinho. Elas colocam dois profissionais (exaustivamente treinados e relativamente caros) para fazer o trabalho que um só poderia fazer porque acredita-se (e as estatistísticas confirmam) que a chance de duas pessoas errarem seja significativamente menor que a probabilidade de uma única pessoa se equivocar. No caso da aviação, falhas humanas podem ter consequências drásticas. Os custos materiais podem ser elevados e o custo humano pode ser impagável. No caso de software, embora nem todas as falhas tenham o mesmo tipo de consequência que se observa na aviação, no mínimo as falhas costumam consumir tempo e dinheiro.

A programação em par é uma forma eficaz de reduzir a incidência de bugs, pois trata-se de um mecanismo de inspeção de código que opera permamentemente ao longo do projeto. Há muito tempo se pesquisa sobre técnicas de inspeção de código e já se sabe que elas são muito eficazes na redução de bugs. A programação em par nada mais é do que a incorporação da técnica de inspeção de código a tudo o que é produzido no projeto, o tempo todo. Ou seja, é apenas uma técnica comprovadamente eficaz (a inspeção de código) sendo utilizada em seu grau mais elevado, isto é, o tempo todo.

A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. Isso ocorre devido à oportunidade de dialogar, trocar idéias e explorar mais alternativas do que os desenvolvedores fariam se estivessem sozinhos. A programação em par também produz um efeito conhecido como pressão do par que faz com que os desenvolvedores tenham maior foco na atividade e faz com que isso se mantenha por mais tempo. Maior foco significa menos dispersões ao longo do dia, o que por sua vez significa que a empresa aproveita melhor o tempo que o desenvolvedor passa com ela.
Uma das características mais marcantes da programação em par é a sua capacidade de disseminação de conhecimento, que ajuda a elevar rapidamente as habilidades técnicas dos membros da equipe. Isso tem efeitos extraordinários no médio e longo prazos, porque quanto mais habilidoso um desenvolvedor é, melhores se tornam as suas soluções. Elas ficam mais claras, mais limpas, mais fáceis de compreender e se acerta mais vezes. Além disso, normalmente se consegue gerar tais soluções com maior rapidez. O efeito cumulativo de inúmeras soluções melhores e mais rápidas ao longo do projeto representa um enorme ganho de produtividade.
O conjunto de características apresentadas acima faz com que a programação em par acelere o desenvolvimento e o torne mais econômico, embora à primeira vista pareça o contrário. Em função da redução de bugs (e consequente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário e a solução tende a ser melhor.

- Desenvolvimento Orientado a Testes

Observando-se o trabalho de um desenvolvedor, nota-se que boa parte do seu tempo é dedicada à depuração de bugs. Trata-se de uma atividade frequentemente demorada que se repete inúmeras vezes à medida que o desenvolvedor produz mais código para seu projeto. Idealmente, gostaríamos que softwares nunca tivessem defeitos, mas infelizmente, em função da complexidade de cada sistema, esse objetivo dificilmente é factível, levando à necessidade de depuração. Entretanto, o tempo gasto com depuração pode ser reduzido significativamente quando se consegue assegurar que os erros sejam detectados imediatamente, assim que são introduzidos. Quando este é o caso, é mais rápido depurar e compreender o que pode ter causado o problema porque o programador tem, em sua memória, todo o contexto relativo à funcionalidade que está desenvolvendo. Não é necessário relembrar algo que foi implementado meses atrás.
É possível detectar problemas imediatamente desde que tenhamos o hábito de implementar testes automatizados antes de cada funcionalidade, de cada classe e de cada método criados no sistema. Quando isso é feito, criamos um mecanismo automatizado que aponta os problemas assim que eles são inseridos, o que reduz o tempo de depuração, além de servir como um mecanismo para testar o bom funcionamento do sistema a qualquer momento.
Equipes que trabalham com XP se preocupam em criar softwares saudáveis, que funcionem corretamente e permaneçam assim ao longo do tempo, à medida que recebem novas funcionalidades e alterações. Em se tratando de saúde, a prevenção é o melhor remédio e no caso de software não é diferente. Para tornar os sistemas saudáveis, equipes XP investem em testes automatizados, implementados antes mesmo de escrever o código das funcionalidades. Em particular, procura-se criar testes de unidade e testes de aceitação. Os primeiros, verificam se cada classe, ou seja, cada pequeno componente da aplicação, funciona como esperado. Já um teste de aceitação procura assegurar que uma determinada funcionalidade, representada pela interação de inúmeros componentes, está funcionando corretamente. Assim como a programação em par, o desenvolvimento orientado a testes ajuda a criar uma rede de proteção em torno do software, para que ele se mantenha saudável ao longo do tempo.

- Refatoração

Quando deixamos de cuidar de nossa casa, a poeira se acumula, a pia fica cheia de louça suja, as lixeiras ficam entupidas e aquilo que se costumava chamar de lar se transforma em um lugar pouco agradável. Para evitar que isso ocorra, investimos tempo frequentemente para varrer, lavar a louça, arrumar a cama, retirar o lixo, entre outras atividades. Isso nos ajuda a ter mais conforto e permite que utilizemos a nossa casa para o que desejarmos, como por exemplo, convidar amigos para assistir a um jogo conosco.
Assim como a nossa casa, sistemas também se deterioram quando não investimos continuamente na limpeza e na organização dos mesmos. A estrutura de qualquer sistema tende a se degradar ao longo do tempo, à medida em que novas funcionalidades são inseridas, alterações são feitas, erros são corrigidos e mais código é introduzido. Para evitar que a aplicação se transforme em uma casa suja, desorganizada e difícil de manter, equipes XP utilizam a prática de refatoração. Elas alteram pequenas partes do sistema, frequentemente, sempre que encontram uma oportunidade para melhorar o código, tornando-o mais limpo, mais claro e mais fácil de ser compreendido. Tais alterações não mudam o comportamento das funcionalidades, apenas melhoram a estrutura do código. Agindo assim de forma sistemática e com frequência, as equipes investem para que o software se mantenha sempre fácil de alterar, gerando a velocidade de desenvolvimento que os clientes de projetos XP costumam vivenciar e apreciar.

- Código Coletivo

Em um projeto XP, os pares se revezam, as pessoas se revezam na formação dos pares e todos têm acesso e autorização para editar qualquer parte do código da aplicação, a qualquer momento. Ou seja, a propriedade do código é coletiva e todos são igualmente responsáveis por todas as partes. Com isso, os desenvolvedores ganham tempo, pois não precisam esperar a autorização de um colega para editar uma área do código e há maior disseminação de conhecimento. Além disso, quando diversas pessoas têm a chance de olhar uma mesma área do código, torna-se mais frequente a identificação de oportunidades de melhoria, levando frequentemente à refatoração em áreas que precisam da mesma.

- Design Simples

O design de uma aplicação surge de forma incremental e evolutiva em projetos que trabalham com XP. O objetivo é criar a solução mais simples possível que seja suficiente para implementar as funcionalidades de cada iteração. Qualquer característica que possa ser implementada para dar apoio a funcionalidades futuras, só são codificadas de fato se e quando tais funcionalidades forem priorizadas para uma iteração. Assim, busca-se concentrar os esforços da equipe naquilo que se tem certeza absoluta de que será necessário hoje, por já ter sido priorizado pelo cliente para a iteração corrente. Aquilo que poderia ser útil no futuro, deixamos para resolver no futuro, quando houver certeza da necessidade. Isso levanta a preocupação de que não sejamos capazes de solucionar problemas futuros com rapidez. Entretanto, as demais práticas do XP ajudam a equipe a ter agilidade e segurança, de modo que ela possa esperar o futuro chegar com tranquilidade. Além disso, a prática regular de tentar se antecipar ao futuro não parece ser das mais adequadas quando se observa os padrões da indústria, ou seja, 64% de funcionalidades que tipicamente não são utilizadas, como mencionado antes.

- Metáfora

Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico. A lixeira, a mesa de trabalho, janelas, pastas e outros itens que estamos habituados a encontrar no computador, simulam elementos do mundo físico e seus respectivos comportamentos. XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua.

- Ritmo Sustentável

Os recorrentes problemas observados nos projetos de software levam inúmeras equipes a trabalharem longos períodos e, por exemplo, fazer horas-extras com frequência como forma de reduzir atrasos e tentar entregar o software em um prazo razoável. Entretanto, sempre que fazem isso, se esquecem de que desenvolvedores são seres humanos que, como tais, sentem fome, se cansam, ficam com sono, perdem a atenção em tais circunstâncias e introduzem bugs. Assim, é comum o tempo extra ser gasto em vão, pois o fato de trabalhar mais não significa que o projeto avançou. Para progredir, é necessário que novas funcionalidades sejam implementadas e finalizadas, sem que haja bugs esperando para serem identificados nas mãos dos usuários.
Projetos XP respeitam isso e seguem a filosofia de que o mais importante não é trabalhar mais e sim trabalhar de forma mais inteligente, em um período de tempo semanal que as pessoas sejam capazes de sustentar sem ficarem esgotadas e sem prejudicarem o trabalho com o déficit de atenção decorrente da fadiga. Existe uma distinção importante entre movimento e progresso. Uma equipe que se movimenta muita, que trabalha muitas horas, que "dá um gás" pelo projeto, mas produz várias coisas erradas não está progredindo. Está apenas consumindo energia. O importante não é se movimentar muito, é se mover na direção certa, de forma inteligente e sustentável.

- Integração Contínua

Quando inúmeros desenvolvedores trabalham juntos em um mesmo projeto, é necessário sincronizar o que estão fazendo e assegurar que o código de um se integre corretamente com o de outro. Esse processo de sincronização recebe o nome de integração contínua em XP e é executado inúmeras vezes ao dia, pois é mais fácil integrar pequenos incrementos de código do que grandes blocos de código implementados ao longo de dias. Quando há pouco a ser sincronizado em cada integração, eventuais conflitos no código são solucionados de maneira mais rápida e problemas não se acumulam uns sobre os outros.

- Releases Curtos

Com o objetivo de receber feedback rapidamente, não apenas da pessoa que atua como cliente junto à equipe de desenvolvimento, mas de toda a comunidade de usuários do sistema, projetos XP procuram criar versões pequenas do software, contendo poucas funcionalidades novas, mas que sejam colocadas em produção com frequência. Isso permite que os usuários tenham acesso ao software rapidamente, de modo que a equipe não corra o risco de investir demais em algo que não esteja correto, ou pior, em algo que não se revele necessário e valorizado pelos usuários.

Encerramento

Trabalhar com Extreme Programming equivale a encarar o desenvolvimento de software de uma forma diferente daquela a que estamos habituados. Trata-se de uma forma mais humana, onde todos - clientes, desenvolvedores e demais interessados no projeto - são identificados como pessoas que falham e que acertam. A estrutura de desenvolvimento criada pelo XP procura ajudar o projeto a explorar o que as pessoas têm de melhor e solucionar suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização para evitar que trabalhos desnecessários sejam executados. Isso ajuda a poupar tempo, recursos e permite gerar maior valor para os clientes. Extreme Programming é a arte de maximizar o trabalho que não será feito. Pois, mais importante que trabalhar muito e produzir muito, é produzir a coisa certa, aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas, fazendo isso de forma consistente, segura e rápida ao longo de todo o andamento do projeto.

Programação em par é uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming. Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.

À primeira vista, a programação em par parece ser uma prática fadada ao fracasso e ao desperdício. Afinal, embora possa haver benefícios, temos a impressão de que ela irá consumir mais recursos ou irá elevar o tempo do desenvolvimento. Entretanto, não é exatamente isso o que ocorre.

O par

Você embarcaria em um avião que não tivesse um co-piloto? Provavelmente não, porque mesmo que você não ligasse para isso, a companhia aérea se preocupa (e muito) com essa questão, de modo que ela nem cogita permitir uma coisa dessas. Mas, para que serve um co-piloto se, na prática, seria perfeitamente possível pilotar um avião com uma única pessoa? Aliás, cada vez mais, é o próprio computador de bordo quem faz a maior parte do trabalho. Então, porque as companhias aéreas fazem questão de ter piloto e co-piloto em 100% dos vôos?

O que aconteceria se o piloto tivesse uma dor de barriga exatamente na hora do pouso, por exemplo? Havendo um co-piloto, isso não seria um problema (a propósito, tomara que eles não tenham almoçado no mesmo restaurante). Acredita-se (e as estatistísticas confirmam) que a chance de duas pessoas errarem seja significativamente menor que a chance de uma única pessoa se equivocar. No caso da aviação, falhas humanas podem ter consequências drásticas. Os custos materiais podem ser elevados e o custo humano pode ser impagável. Por essa razão, entre outras, companhias aéreas colocam dois profissionais (exaustivamente treinados e relativamente caros) para fazer o trabalho que um só poderia fazer tranquilamente.

Isso não é suficiente para garantir a segurança de um vôo, outros mecanismos também são usados e representam papéis essenciais. Porém a utilização de um co-piloto é uma das práticas que colaboram para elevar a segurança dos vôos. Embora pareça inconcebível colocar dois profissionais para fazer o trabalho que apenas um poderia fazer sozinho, como a programação em par sugere, as práticas da aviação são um exemplo de que a utilização de pares também é adotada em outras áreas, nas quais são, inclusive, bastante valorizadas.

A indústria de software

O Chaos Report do ano 2000 (produzido pelo Standish Group), que pesquisou 280 mil projetos de software nos EUA, revelou que 72% dos projetos falham devido a um dos seguintes fatores:

a) Consomem mais recursos que o orçado
b) Consomem mais tempo que o estimado
c) Não entregam o que foi combinado
d) Todas as alternativas acima em conjunto

Infelizmente a letra d) é a regra geral. Além disso, os atrasos normalmente representam 63% mais tempo que o estimado, os gastos normalmente são 45% maiores que o orçado e no geral apenas 67% das funcionalidades prometidas são efetivamente entregues. Destes 280 mil projetos, 23% deles fracassaram tão vigorosamente que chegaram a ser cancelados (são "apenas" 64.400 projetos).

Estamos falando de uma indústria na qual 72% do que se produz falha! Se fôssemos fazer uma comparação grosseira com a aviação, é como se disséssemos que a cada 100 aviões que sobem, 100 descem (um tanto inevitável), porém 72 deles não levantam vôo nunca mais (só uma maneira light de dizer que você iria preferir não estar em um destes vôos). Se olharmos software como um investimento, que é exatamente o que ele representa para a empresa que decide contratar seu desenvolvimento, é como se estivéssemos olhando para uma ação na bolsa de valores que tem 72% de chances de dar prejuízo. Imagine você comprando uma ação com essa característica. Pois isso é o que uma empresa faz atualmente quando decide contratar um projeto de desenvolvimento. Feliz dela, pois só estamos nesse pé porque as coisas andam melhorando. Em 1994, a taxa de fracassos era de 84%.

No ano passado, a Revista Exame mostrou uma reportagem trazendo números do SEI na qual comentava exaustivamente sobre a enorme quantidade de erros cometidos pelos desenvolvedores e a quantidade monumental de dinheiro que as economias de todo o mundo acabam desperdiçando por conta destes erros. A reportagem trazia resultados de pesquisas que indicavam que um programador experiente normalmente insere um erro a cada 10 linhas de código. Eu costumo brincar com isso e dizer que, sendo assim, um programador mais lento é menos arriscado do que um apressadinho. Pois esse último tem uma taxa de inserção de bugs maior.

Estes números demonstram que a indústria de software poderia fazer bom uso de práticas inovadoras que possam ajudar a eliminar tais problemas de maneiras mais eficazes do que se tem observado até hoje. As metodologias ágeis surgiram há poucos anos como uma alternativa a formas mais tradicionais de desenvolvimento de software. Baseadas em práticas que se assemelham muito com as usadas nos processos Just-in-Time criados na Toyota, na década de 50, metodologias ágeis como o Extreme Programming se baseiam em um conjunto de práticas coeso que pode ser eficaz em inúmeros projetos. A programação em par é uma destas práticas e tem grande potencial para resolver diversos problemas que afetam os projetos de software, embora não todos, naturalmente. Um dos principais benefícios da programação em par é a permanente inspeção de código que ocorre durante seu uso.



Detecção de bugs

A programação em par é uma forma eficaz de reduzir a incidência de bugs em um sistema. Isso se deve em grande parte às visões complementares que atuam durante o uso dessa prática. Quando dois desenvolvedores estão programando em par, um deles está com as mãos no teclado e no mouse. O outro está sentado ao lado, olhando para a mesma tela e preocupado em resolver o mesmo problema. Ambos estão trabalhando juntos na solução, embora apenas um esteja com as mãos no teclado. Eles conversam o tempo todo e trocam idéias sobre a solução.

A pessoa que está conduzindo o teclado (condutor) tem um campo de observação diferente do seu parceiro. Quem digita normalmente está olhando sobretudo para a linha que está editando e adjacências. O navegador, por sua vez, tem uma visão mais ampla e olha não apenas a linha que está sendo editada, mas também o restante do código que aparece na tela. Ao fazer isso, ele acaba tendo uma visão complementar que frequentemente revela problemas que o condutor não percebe com a mesma rapidez. Usando uma metáfora para ilustrar essa questão, imagine que uma pessoa está dirigindo um carro, enquanto outra está no carona. A pessoa que dirige tem uma visão geral das redondezas, mas foca a maior parte do tempo no carro adiante. Existe uma preocupação constante em não deixar o carro atingir o que está à frente, e isso exige atenção constante. Já a pessoa que está no carona, também observa que há um carro adiante, mas tem menos preocupação com essa questão. Por isso, acaba olhando mais para as redondezas, vê a paisagem com mais tranquilidade e tem condições de sinalizar problemas que o motorista só detectaria mais adiante. Por exemplo, em função de sua visão complementar, o carona pode alertar o motorista para que mude para outra faixa, visto que aquela na qual se encontram está fechada algumas centenas de metros à frente e o condutor ainda não teve condições de notar isso. Essa visão complementar, quando trazida para o código, permite que o navegador atue mais como um estrategista, olhando para o código como um todo e identificando problemas que passam despercebidos para quem está mais preocupado com a linha que está sendo digitada.

Em 1971, em um livro chamado The Psychology of Computer Programming, Gerald Weinberg mostrou que o olho humano tem uma incrível capacidade de só enxergar aquilo que deseja e, naturalmente, ignorar aquilo que não quer ver. Ele diz o seguinte: "programadores, se deixados por conta própria, ignoram os erros mais gritantes, os quais qualquer pessoa seria capaz de detectar instantaneamente". Isso se deve a um princípio bastante estudado na psicologia chamado dissonância cognitiva. Temos a tendência natural, como programadores, de acreditar que aquilo que escrevemos está certo. Inclusive, somos capazes de reler uma linha de código, que contém um erro de digitação e não enxergá-lo, mesmo depois de ler a mesma linha inúmeras vezes. Trata-se de uma pequena (e desagradável) peça que o cérebro nos prega. Contudo, um pequeno erro que passe despercebido para o condutor normalmente é notado pelo navegador por ter uma visão complementar e não ser afetado pela dissonância cognitiva de seu colega.

Quem trabalha continuamente com programação em par se habitua a corrigir e ter seu trabalho corrigido dezenas de vezes ao dia. A incidência de erros identificados pelo colega costuma ser tão elevada que surpreende quem não está acostumado ao uso da técnica. Depois de um dia ou dois experimentando a programação em par, muitas pessoas se perguntam como alguém as permite trabalhar sozinhas. É o tipo de coisa que não é intuitivo, mas acontece e só é claramente perceptível quando se experimenta a técnica.

Equipes que trabalham em par conseguem reduzir drasticamente a inserção de defeitos em seus códigos. Isso é uma mensagem compartilhada e repetida por todos que estão habituados a essa técnica. Atualmente, existem diversas pesquisas demonstrando este fato, tais como a reportada no artigo "Strengthening the case for pair programming; Laurie Williams, Robert Kessler, Ward Cunningham et al.; IEEE Software, v. 17, n.4, 2000, p. 19-25". Isso isoladamente já é um ponto positivo em favor da utilização da programação em par, especialmente se levarmos em conta os números apresentados anteriormente sobre a indústria de software. Mas, essa é uma daquelas técnicas simples, porém com resultados positivos em inúmeros aspectos e a detecção de bugs é apenas um deles. Esse aspecto, inclusive, não chega a ser novidade. Há muito tempo se pesquisa sobre técnicas de inspeção de código e já se sabe que elas são muito eficazes na redução de bugs. Atualmente, isso já não é mais assunto passível de grandes discussões, pois existe material de sobra mostrando isso. Nesse sentido, a programação em par nada mais é do que a incorporação da técnica de inspeção de código a tudo o que é produzido no projeto, o tempo todo. Ou seja, é apenas uma técnica comprovadamente eficaz (a inspeção de código) que passa a ser utilizada em seu grau mais elevado, isto é, o tempo todo.

Simplicidade

A programação em par ajuda os desenvolvedores a criarem soluções mais simples, mais rápidas de implementar e mais fáceis de manter. Isso ocorre em grande parte devido à oportunidade de dialogar e trocar idéias sobre programas que estejam sendo desenvolvidos. Quando nos deparamos com um problema, buscamos uma solução usando todo e qualquer recurso que esteja a nossa disposição. E, assim que encontramos uma solução, encerramos a busca e a utilizamos. O detalhe é que existem duas grandes categorias de problemas: os convergentes e os divergentes. Os convergentes são aqueles que aceitam uma única resposta certa. Os divergentes são aqueles que aceitam várias soluções. Problemas convergentes são raros. Normalmente são vivenciados pelas crianças no jardim de infância. São fáceis de resolver porque só há uma resposta certa. Os divergentes, por sua vez, são os mais comuns e estão ao nosso redor o tempo todo. Eles aceitam inúmeras soluções, algumas mais eficazes, outras menos.

Quando tentamos resolver um problema sozinhos, normalmente adotamos a primeira solução que encontrarmos, pois isso trata-se de uma característica psicológica conhecida como "tunelamento". Uma vez identificada uma solução, é como se entrássemos em um túnel e não enxergássemos mais nada além daquele caminho. Essa característica é ruim porque a primeira solução encontrada nem sempre é a melhor, a mais eficiente, mais simples ou mais rápida de implementar. Mas, como seres humanos, somos assim e se nos deixarem sozinhos, é exatamente isso que tenderemos a fazer.

A programação em par elimina esse problema. Quando o par se depara com um problema, cada programador começa a imaginar individualmente uma solução para ele. Depois, eles começam a discutir as soluções imaginadas. A partir desse diálogo é comum surgir uma terceira alternativa contendo características das duas anteriores. A conversa continua e de repente têm-se quatro, cinco, seis caminhos diferentes a serem escolhidos. Eventualmente, um deles acaba se revelando mais simples, ou mais rápido ou mais eficiente ou tudo isso em conjunto. Isso é bastante comum quando se programa em par e o efeito é bem perceptível: o par consegue executar a atividade mais rapidamente do que se um desenvolvedor estivesse programando sozinho. Além disso, a solução frequentemente é mais simples e mais fácil de ser compreendida por outras pessoas. A programação em par explora a diversidade de idéias que é rara de ser observada quando se programa sozinho.

Pressão do par

Se um desenvolver trabalha oito horas por dia, engana-se quem pensa que ele realmente produza durante essas oito horas. De modo geral, o aproveitamento de um programador trabalhando sozinho raramente chega sequer a 50% do tempo que passa na frente do computador. Ao longo do dia, ele lida com seu programa, bem como inúmeros emails, instant messages, telefonemas, pessoas interrompendo-o para comentar sobre o jogo do dia anterior e assim por diante. Além disso, mesmo que não houvesse nenhum agente externo para tirar a sua atenção, ele normalmente se dispersa de tempos em tempos por uma razão simples. Programar é uma atividade complexa, que exige muita atenção e lida com uma grande quantidade de variáveis que, com frequência, se comportam de maneiras indesejáveis. De tempos em tempos o programador precisa descansar e refrescar o pensamento pra ser capaz de continuar. Isso por si só já seria suficiente para fazê-lo dispersar-se várias vezes ao dia. Somando-se às inúmeras interrupções por que costuma passar, o desenvolvedor acaba dedicando menos tempo do que se imagina produzindo funcionalidades. Ainda assim, uma boa dose do tempo que consegue dedicar à programação acaba sendo consumido em depuração de erros que ele próprio produziu.

A programação em par produz um efeito conhecido como pressão do par que faz com que os desenvolvedores tenham maior foco na atividade e faz com que isso se mantenha por mais tempo. Imagine que você esteja programando em par e, de repente, resolva olhar seus emails. Trata-se de uma situação embaraçosa. Primeiro, porque há uma pessoa ao seu lado que poderá acabar lendo seus emails (e dependendo do que você ande trocando por aí, isso pode ser bastante constrangedor). Segundo porque você estará interrompendo o seu trabalho e o do seu amigo. Ou seja, há uma responsabilidade compartilhada. Quando um pára, o outro também acaba sendo prejudicado. Normalmente, não gostamos de decepcionar nossos colegas, portanto, quando programamos em par procuramos manter o maior foco possível na atividade para não atrapalhar ninguém. A responsabilidade é maior e isso faz com que o foco também o seja.

Maior foco significa menos dispersões ao longo do dia, o que por sua vez significa que a empresa aproveita melhor o tempo que o desenvolvedor passa com ela. Mas, como fica a necessidade de descansar de tempos em tempos? Quando programam em par, os desenvolvedores se revezam no teclado. Normalmente, a pessoa que está digitando se cansa mais do que o navegador. Sendo assim, de tempos em tempos o teclado troca de mãos, permitindo ao programador que o estava utilizando descansar um pouco, embora continue engajado na atividade, colaborando para a construção da solução. Sendo assim, a programação em par acaba servindo como uma forma de equilibrar a necessidade de trabalhar com o maior foco possível e, ao mesmo tempo, descansar de tempos em tempos.

Recentemente conversei com o dono de uma empresa na qual iniciamos a implantação do XP há pouco mais de um ano. Lá, eles utilizam XP atualmente em todas as suas equipes, todos trabalham em par e utilizam as demais práticas do XP. O dono me disse que o que ele mais gostou no XP foi a programação em par. Quando escutei isso, achei que tivesse escutado errado e pedi que ele repetisse, afinal, não acreditei que a pessoa que estava pagando aqueles desenvolvedores também fosse a mais entusiasmada em ter dois deles "fazendo o trabalho que um só poderia fazer sozinho". Então ele me explicou que em 20 anos de empresa, jamais tinha visto as pessoas trabalhando tanto tempo focadas da forma que via agora. Ele disse que no passado, observava que raramente os desenvolvedores utilizavam mais que metade do tempo que passavam na empresa de forma útil. E isso obviamente não era das coisas que ele mais apreciava, afinal era ele quem pagava. Por outro lado, depois que as pessoas começaram a programar em par, ele passou a notar que de um modo geral as pessoas conseguiam aproveitar no mínimo 75% do tempo que estavam no trabalho de forma extremamente útil. Isso mostra que, ao contrário do que possa parecer à primeira vista, a programação em par não consome mais recursos, pelo contrário. Ela aproveita melhor as pessoas tornando-as mais produtivas.

Disseminação do conhecimento

Uma das características mais marcantes da programação em par é a sua capacidade de disseminação de conhecimento, especialmente em projetos XP, nos quais os desenvolvedores sempre trocam de pares, fazendo com que haja maior compartilhamento de informações ao longo do projeto. Além disso, os desenvolvedores também se revezam no desenvolvimento das funcionalidades. Isto é, hoje estou trabalhando em uma parte do sistema e amanhã posso vir a codificar outra parte completamente diferente, com outro par. Esse revezamento se dá de maneira simples.

Suponha que hoje iniciei o dia trabalhando com João em uma funcionalidade. Na parte da tarde, por exemplo, João vai trabalhar com outra pessoa, em outra parte do sistema. Por sua vez, Patricia vem trabalhar comigo. No início, passo de 5 a 10 minutos lhe explicando o que eu e o João havíamos iniciado. A partir daí, ela pode simplesmente me ajudar a continuar na mesma linha de ação, bem como pode notar que há uma forma mais simples de atacar o problema. Se esse for o caso, ela me explica e com isso a solução está sendo oxigenada com uma visão renovada, não viciada, que muitas vezes acaba reduzindo o tempo total de desenvolvimento. Daí por diante, passamos a tarde desenvolvendo, por exemplo, de modo que na manhã do dia seguinte eu vou trabalhar com outra pessoa e o Fábio vem trabalhar com a Patrícia. Como ela já passou a tarde do dia anterior trabalhando na funcionalidade, eu pude deixar o par tranquilamente, pois ela já conhece o problema tão bem quanto eu. Em resumo, para que o revezamento ocorra de forma adequada, é importante que sempre haja alguém no par que já esteja trabalhando há mais tempo na funcionalidade, para que possa contextualizar a pessoa que está chegando. Isso é fácil de fazer se nós garantirmos que apenas uma única pessoa do par será trocada a cada vez que o revezamento ocorrer. Isso preserva o histórico e permite rotacionar. Entretanto, é essencial que a pessoa que tenha ficado no par, necessariamente saia dele no próximo revezamento. Isso garante que todas as pessoas na equipe tenham a oportunidade de trocar de pares.

O problema mais nítido desta abordagem é o tempo que se gasta para contextualizar a pessoa que está chegando. Esse tempo pode ser grande ou pequeno, dependendo do tamanho da funcionalidade e da frequência de trocas. De modo geral, procuramos assegurar que as funcionalidades sejam sempre quebradas para que fiquem suficientemente pequenas (o que por si só já faz com que a contextualização tenda a ser rápida). Isso é conseguido aplicando certos parâmetros ao jogo do planejamento. Nós por exemplo, trabalhamos com o hábito de assegurar que qualquer história possa ser desenvolvida em par em no máximo três dias. Caso seja estimada em um tempo superior, pedimos ao cliente que quebre a história até que esteja dentro desse parâmetro. Além disso, procuramos rotacionar os pares com frequência para que o um par nunca passe tanto tempo junto, ao ponto de ter que explicar uma quantidade enorme de coisas para a próxima pessoa que estiver chegando no par. Então, de um modo geral limitamos as sessões de pareamento a uma manhã ou uma tarde, porque não se produz tanto assim neste período de tempo. Isso faz com que a quantidade de informações a serem transmitidas seja menor e diminui o tempo de contextualização.

Esse tempo, embora possa parecer um overhead, frequentemente se paga de duas formas: maior compartilhamento de conhecimento e oxigenação da funcionalidade. Cansei de presenciar situações nas quais uma pessoa ingressou no par e, com uma visão ainda não viciada, conseguiu perceber formas melhores e bem mais rápidas de solucionar o problema.

O aprendizado em par é particularmente rico porque ocorre o que é chamado de aprendizado situado. Há um problema para ser resolvido, há uma contribuição clara para o projeto caso ele seja resolvido, existe um contexto bem definido no qual aquele problema se encontra e existe uma pessoa ao seu lado que muitas vezes já conhece a solução. Quando este é o caso, o seu aprendizado é muito rico porque, primeiro, há um grande interesse seu em saber a solução. Nós sempre aprendemos melhor e com mais afinco quando temos um problema real para resolver. Especialmente quando sabemos que a resolução dele irá contribuir de alguma forma para outras pessoas. Nós gostamos de contribuir com as pessoas a nossa volta. Então, na programação em par, existe uma primeira componente fundamental que é a necessidade. E uma segunda que é o desejo de contribuir. Além disso, temos ao nosso lado uma pessoa que sabe resolver o problema e, o que é melhor, ela pode dialogar conosco e explicar. O diálogo é a forma mais rica de comunicação e ele permite que as pessoas recebam feedback facilmente. Desta forma, enquanto seu colega lhe explica algo, você pode fazer gestos ou ter expressões faciais que demonstrem que não está captando a mensagem. Seu colega instintivamente pode captar esse feedback e explicar melhor a solucão. O problema em questão pode ser técnico ou de negócio. Às vezes o seu colega entende melhor o negócio associado àquela parte do código por já ter trabalhado com ele em outro projeto. Eventualmente sabe melhor um determinado aspecto técnico porque teve aulas daquele assunto em um curso que fez e você não. Às vezes é o contrário e você é quem ensina. Na verdade, durante a programação em par, as pessoas naturalmente se revezam no papel de "professor" e "aluno".

Mesmo quando ambos não sabem resolver o problema, é mais rápido pesquisar sobre ele quando se está em par. Ambos podem, por exemplo, compartilhar idéias sobre termos a serem buscados no Google, podem lembrar de livros que têm a disposição, que possa ter a solução, podem lembrar de diferentes pessoas que talvez saibam a solução e possam ser procuradas, entre outras coisas.

A maior disseminação do conhecimento rapidamente eleva as habilidades técnicas dos membros da equipe. Isso tem efeitos extraordinários no médio e longo prazos, porque quanto mais habilidoso um desenvolvedor é, melhores se tornam as suas soluções. Elas ficam mais claras, mais limpas, mais fáceis de compreender e se acerta mais vezes. Além disso, normalmente se consegue gerar tais soluções com maior rapidez. O efeito cumulativo de inúmeras soluções melhores e mais rápidas ao longo do projeto representa um enorme ganho de produtividade. Mas, não é tudo.

Também há a disseminação de conhecimento sobre o negócio, que leva mais pessoas a saberem solucionar questões em qualquer parte do projeto, o que naturalmente aumenta a robustez da equipe. Ou seja, se alguém faltar por qualquer razão, se um desenvolvedor entrar de férias ou se uma pessoa decidir mudar de emprego, isso não impede a equipe de seguir adiante. Naturalmente há uma perda na força de trabalho, mas não há uma situação em que se perca uma pessoa sem a qual o projeto não possa sobreviver. O projeto consegue sobreviver bem a mudanças de pessoal porque muita gente sabe sobre muita coisa. É quase impossível apenas uma pessoa saber sobre um assunto do projeto a tal ponto de comprometê-lo caso não apareça mais.

Isso obviamente é bom para o projeto, mas também é excelente para os desenvolvedores, que podem tirar férias, visitar médicos ou faltar por qualquer razão que se faça necessária, com a tranquilidade de saber que a equipe não terá que importuná-lo. A equipe consegue seguir adiante com ou sem ele. Em muitas empresas, é comum os desenvolvedores terem dificuldades para tirar férias, por exemplo, tamanha é a dependência de um projeto sobre ele. E isso naturalmente é ruim para ele e péssimo para o projeto. Esse tipo de coisas não existe quando se utiliza a programação em par.

Confiança

A programação em par também é uma forma de fazer com que o desenvolvedor tenha mais confiança no código que produz. Afinal, o código foi produzido por ele e mais outra pessoa que o ajudou a revisá-lo. Quando sabemos que mais uma pessoa, ou talvez várias, já olharam para o código no qual trabalhamos e estão de acordo sobre o mesmo, temos maior confiança de que ele realmente irá funcionar. Isso significa que a programação em par reduz o estresse do desenvolvedor. Primeiro, porque várias pessoas conhecem e concordam com a solução, segundo porque nenhum erro cometido no projeto é exclusivo de uma única pessoa. Quando há um erro, não existe um culpado. A responsabilidade é da equipe como um todo, porque várias pessoas tiveram a chance de editar aquele código. Essa capacidade de deixar anônimo o responsável por uma falha, que em outras palavras, significa que toda a equipe é responsável por qualquer falha, é um dos aspectos sociais mais interessantes do XP, porque reduz a possibilidade de brigas e desentendimentos dentro da equipe, além de tornar todos mais compreensivos uns com os outros. Naturalmente o estresse reduz-se e as pessoas convivem melhor dentro do projeto.

Velocidade

O conjunto de características apresentadas acima faz com que a programação em par acelere o desenvolvimento significativamente, embora à primeira vista pareça o contrário. Em função da redução de bugs (e consequente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário. Existem pesquisas indicando que se uma atividade é feita em 8 horas por um desenvolvedor sozinho, será feita em aproximadamente 4 horas por um par. O que significa que, mesmo no curto prazo, não existem diferenças significativas de
produtividade. Pois, em ambos os caso se estão consumindo basicamente os mesmos 8 homem-hora. A Laurie Williams, por exemplo, tem diversas estudos nessa linha. Eu os respeito, mas os considero pouco significativos em relação ao que ocorre realmente nos projetos, porque os problemas solucionados durante estes experimentos são muito simples. E os problemas que os projetos reais enfrentam são bem mais complexos. Entretanto, quanto mais difícil a situação, quanto mais complexo o problema, maior é o ganho da programação em par.

Pelo que observo nos projetos, pela complexidade daquilo que se busca resolver, não me parece que a programação em par consuma a mesma quantidade de recursos. Parece-me que consome bem menos, porque é exatamente diante dos problemas complexos que a oportunidade de discutir inúmeras soluções mais agrega valor. É exatamente nestes casos que conseguimos descobrir formas mais simples que realmente economizam muito trabalho que, um programador sozinho, eventualmente não imaginaria. Quanto mais complexo o problema, mais importante a capacidade de descobrir bugs rapidamente com o processo permanente de inspeção de código. Quanto mais difícil o problema, maior é a importância da pressão do par para evitar a dispersão. Quanto mais difícil, mais importante é a disseminação do conhecimento para que mais pessoas compreendam os problemas e se tornem cada vez mais habilidosas em resolvê-los.

Programação em par não consome mais recursos, não duplica o número de desenvolvedores necessários ao projeto, nem duplica o tempo de desenvolvimento. Na verdade, por mais paradoxal e contra-intuitivo que possa parecer, a programação em par poupa recursos. Lembre-se, as pessoas erram. Se todos fossem perfeitos, a programação em par possivelmente só serviria para duplicar recursos, elevar o tempo e encarecer o projeto. Mas, a questão fundamental é perceber que as pessoas erram e erram com mais frequência do que se imagina. A programação em par ajuda a reduzir a incidência de problemas e torna os projetos mais produtivos.

Problemas

Programar em par exige que as pessoas envolvidas sejam receptivas, compreensivas umas com as outras, engajadas e, sobretudo, humildes. É necessário aceitar que somos falíveis para que possamos programar em par. Weinberg criou o termo egoless programming, ou seja, programação sem ego. É essencial que o desenvolvedor não veja o código como uma extensão de si próprio. Ele não pode achar que um erro no código significa uma falha sua como pessoa. O código é apenas uma obra que tem vida própria e não representa o caráter e a personalidade de quem o criou. Pois, se o desenvolvedor imaginar que o código representa a si próprio, dificilmente irá buscar problemas e falhas no código. Afinal, ninguém gosta de saber que tem falhas. O código precisa ser visto como algo que não representa a personalidade de seu criador. Isso é mais fácil de se obter quando se programa em par, pois neste caso, o código é a contribuição de várias pessoas e não de uma única.

Pode parecer que desenvolvedores, frequentemente introspectivos e muitas vezes pouco sociais, tenham dificuldades significativas para lidar com a programação em par. Isso realmente acontece com alguns, porém poucos. Aqueles que trabalham com programação em par observam que naturalmente há um pequeno desconforto inicial em muitos casos, mas em quase todos as pessoas se adaptam rapidamente e aprendem a valorizar bastante a programação em par à medida que percebem o benefício dela. Na minha experiência particular tenho notado isso consistentemente, tanto no mercado, quanto no nível acadêmico.

No mercado, tive a oportunidade de trabalhar com algumas dezenas de desenvolvedores com programação em par, em diversos projetos XP e, em todos os casos, os desenvolvedores se adaptaram bem a essa técnica e nenhuma das equipes pensa em voltar atrás. Todas mantém a prática de forma consistente, algumas há quase dois anos. Na UFRJ, onde ministrei curso de XP para a graduação diversas vezes, meu alunos (que de um modo geral são dos últimos períodos) não trabalhavam antes com a programação em par e sempre acabaram se adaptando bem a ela com uma ou outra exceção. As exceções existem, mas são apenas exceções.


Adoção

Apesar de tudo o que foi dito acima, se você acredita que a programação em par não funcionaria no seu caso ou no caso da sua empresa, provavelmente você está certo e não há muito mais o que eu possa fazer aqui. Em todo o caso, antes de jogar a idéia fora, a minha sugestão é que você a experimente por alguns dias. Não durante uma ou duas horas apenas. Tente utilizá-la, por exemplo, durante uma semana, apenas para fazer um pequeno experimento. Imagino o quanto o seu projeto deva ser importante e como você tem pouco tempo, mas experimentar durante alguns dias não fará um mal tão grande assim. No pior dos casos, você realmente terá perdido algum tempo. Mas, se tudo der certo, talvez você descubra uma tremenda oportunidade de melhorar seu projeto e ganhar muito tempo adiante. Tente experimentar, de mente aberta, apenas por poucos dias. Afinal, é sempre fácil dizer que algo não funciona sem experimentar, mas normalmente é muito mais recompensador e instrutivo se dar a chance de experimentar. Porque quando funciona, você ganha alguma coisa nova, mas mesmo se não funcionar, no mínimo você passa a poder dizer que não funciona e que você sabe disso, por ter experimentado. Ninguém vai poder dizer que você não tem autoridade para falar do assunto.

Programação em par é uma técnica que tem várias justificativas, porém só se percebe o seu real valor utilizando. Muitas coisas que acontecem naturalmente durante o seu uso, só são realmente percebidas enquanto se utiliza. A teoria, as justificativas, as pesquisas, os resultados estatísticos, entre outros são interessantes e têm o seu papel, mas o que realmente faz a diferença é experimentar e sentir os seus efeitos. Isso vale mais do que qualquer palavra que você tenha lido até aqui, mais do que qualquer pesquisa ou qualquer coisa que falem com você a esse respeito. E, a propósito, se for possível, experimente não apenas com outro desenvolvedor, mas com vários. Assim, você terá a exata noção do que a programação em par pode fazer por você e um gostinho de uma das partes do XP.

As informações que podem ser compartilhadas em um stand up meeting também poderiam ser transmitidas através de ferramentas. O que ocorre no XP, é que há uma preferência por canais de comunicação mais ricos, o que não significa que os outros canais sejam errados ou não funcionem. Quem trabalha com XP apenas acredita que pode avançar melhor e mais rapidamente dando preferência aos diálogos. Aliás, essa é uma palavra chave na compreensão do stand up meeting.

Trata-se de um diálogo entre todos os membros da equipe, se possível envolvendo também a presença do cliente. Em qualquer diálogo, existem pelo menos duas coisas que são compartilhadas de maneira bastante rica: informações e emoções.

Informações

Em projetos XP, cada membro da equipe tem acesso a toda e qualquer parte do código e, acima de tudo, tem o direito de alterar qualquer parte do sistema, a qualquer momento, sem ter que pedir permissão a ninguém. Essa é uma prática conhecida como Código Coletivo. A parte boa dessa prática é que o desenvolvedor consegue avançar muito rapidamente, pois nunca fica dependendo de outra pessoa, ou da autorização de alguém, para editar uma parte do código. Por outro lado, isso exige muita troca de informações, visto que tudo o que está acontecendo, em qualquer parte do sistema, interessa a todos os membros da equipe.

O diálogo diário permite que cada desenvolvedor descreva brevemente o que fez no dia anterior, eventuais problemas que detectou, soluções interessantes que foram criadas etc. Não é necessário entrar em detalhes. A idéia é que as pessoas saibam o que está acontecendo e quem fez o que. Se um desenvolvedor se interessar bastante por um assunto a respeito do qual outra pessoa trabalhou no dia anterior, ele pode, após o stand up meeting, se reunir com essa pessoa e discutir a solução com maior nível de detalhe. Pode até resolver fazer par com aquela pessoa durante o dia de trabalho que se está iniciando.

À primeira vista, o stand up meeting parece ser demorado. Afinal, se cada desenvolvedor tiver que explicar tudo o que fez no dia anterior, certamente isso pode consumir muito tempo. Entretanto, note que a idéia é fazê-lo diariamente e há várias razões importantes para ser assim. A primeira é que um dia de trabalho é um período relativamente curto. Descrever o que aconteceu em um dia é diferente de descrever os acontecimentos de uma semana, um mês ou um ano. Um dia é muito pouco tempo e normalmente não se produz uma quantidade enorme de coisas interessantes em um único dia. Sendo assim, existe a tendência de que cada desenvolvedor tenha pouco o que dizer se o stand up meeting realmente for conduzido com frequência diária. Apesar de pouco, o que ele tiver a dizer interessa a todos, porque o código é coletivo. De tempos em tempos, haverá alguma coisa realmente muito significativa que tenha sido feita por um par no dia anterior. Nestes casos, o stand up meeting pode acabar tomando mais tempo, porém o valor deste tempo é mais alto devido à utilidade da informação que se está transmitindo.

O stand up meeting é uma prática regida pelo valor da comunicação. Entretanto, é importante notar como também incorpora bem o valor do feedback. A cada dia de trabalho, podemos acertar em diversos pontos do projeto, mas também podemos errar. Equipes XP não esperam ser perfeitas e sabem que erram com frequência. Entretanto, isso não é temido, pois trata-se de um aspecto básico do ser humano: errar. O que realmente tememos é descobrir que erramos tarde demais, porque normalmente o custo de corrigir um erro cresce bastante quanto mais tempo levamos para detectá-lo e corrigi-lo. O stand up meeting é uma oportunidade para que os membros da equipe detectem e discutam problemas que tenha surgido no dia anterior, de modo que se possa priorizar ou não a correção dos mesmos e, de modo que se possam compartilhar sugestões sobre como tratá-los. Quando os problemas são apresentados a todos os desenvolvedores, é comum que surjam várias sugestões e, dessa variedade, surge frequentemente uma forma rápida e simples de solucionar a questão.

Se alguma coisa muito grave é detectada no stand up meeting, o gerente do projeto e o próprio cliente ficam sabendo com bastante rapidez. Pois qualquer problema terá sido detectado há no máximo um dia de trabalho. Assim, o gerente, o cliente e os desenvolvedores podem criar soluções enquanto esse problema ainda não deu origem a outros.

Essa reunião matinal também é uma demonstração da aplicação do valor da simplicidade. Existem muitas formas de se transmitir informações, mas convenhamos, quando as pessoas estão próximas umas das outras, nada é mais simples do que conversar. Usar ferramentas é um caminho, mas isso normalmente envolve aprender a usá-las e a conviver com seus problemas. Além disso, não é necessário passar muito tempo ligado a computadores para saber que eles falham, os sistemas operacionais falham, travam, um dia funcionam e o no outro não e assim perde-se tempo, quando existem soluções mais simples e menos propensas a erros.

O stand up meeting também é um mecanismo para expressar e treinar a coragem dos membros da equipe. Em muitas empresas, os desenvolvedores escondem problemas potenciais com medo de sofrerem uma punição do chefe, do cliente ou de qualquer pessoa com poder na organização. De fato, muitas organizações são regidas pela cultura do medo. O stand up meeting é um espaço aberto onde as pessoas são incentivadas a falar tudo o que está acontecendo e são valorizadas por fazer isso. Trata-se de um aspecto importante porque com a prática, os membros da equipe perdem o medo de revelar os problemas à medida em que percebem que são valorizados por fazer isso. Além disso, os desenvolvedores passam a se expressar mais e com frequência, o que normalmente é ótimo para treinar a habilidade de comunicação. A mesma de que ele irá necessitar, por exemplo, para se comunicar bem com o cliente. Da mesma forma que é necessário coragem para dizer o que realmente está acontecendo, o stand up meeting acaba servindo como uma forma de treinar e desenvolver essa coragem diariamente.

Finalmente, equipes XP costumam utilizar Radiadores de Informações como o Quadro de Acompanhamento Diário. Trata-se de uma tabela, desenhada em um quadro branco, contendo informações sobre todas as histórias da iteração. Nela, colocam-se as estimativas de cada história, quanto tempo foi gasto em cada uma por dia da iteração, que tarefas extras foram executadas etc. É um quadro importante porque gera muita visibilidade para todos os membros da equipe, incluindo o cliente. Com esse quadro, não há necessidade de perguntar nada para o gerente para saber o estado do projeto em um iteração. Basta
olhar para a parede. As informações estão lá. Projetos XP atualizam esse quadro diariamente, sempre nos stand up meetings. Assim, nenhum desenvolvedor precisa preencher uma folhinha dizendo quantas horas trabalhou por dia, por exemplo. Ao invés disso, ele faz algumas marcações simples em um quadro, uma vez por dia, durante o stand up meeting. Todos os desenvolvedores fazem isso durante essa reunião e leva apenas alguns segundos para cada pessoas marcar a sua informação. Quando todos o fazem em conjunto, essa prática tende a se manter de forma mais consistente do que quando realizamos uma atividade dessas sozinhos. Além disso, é um momento de socilização do qual todos participam.

Emoções

É possível transmitir informações através de ferramentas. Porém, emoções também informam e estas são muito difíceis de serem compartilhadas através de ferramentas. Durante um stand up meeting, os membros da equipe conseguem avaliar e sentir como está o clima da equipe. Olhando para cada pessoa, é possível observar se estão satisfeitas com o trabalho que está em andamento, dá para ver se estão cansadas ou energizadas, se estão entediadas ou empolgadas, se estão de acordo com os rumos do projeto etc. Muitas informações importantes jamais são verbalizadas, mas frequentemente basta você olhar para a expressão facial de uma pessoa para saber que ela discorda plenamente de alguma coisa ou para notar que ela está cansada, ou aborrecida. Nestes momentos, um bom coach (bem como qualquer membro da equipe) deve atuar pedindo à pessoa que expresse seus sentimentos. Muitas vezes vivenciei grandes viradas em projetos, viradas extremamente positivas, porque alguém notou um problema na expressão de um dos desenvolvedores.

Há pouco tempo, por exemplo, tínhamos iniciado um projeto em um dos nossos clientes e, em uma reunião dessas, um membro da equipe demonstrava pela expressão facial que não estava muito satisfeito com o rumo das coisas. Ele não disse isso, apenas pareceu insatisfeito pela expressão que fazia. Então perguntei o que o estava incomodando. Ele me explicou que tinha a sensação de que aquele projeto não deveria produzir um software para web, como estava sendo feito. Na opinião dele, pelas características do projeto, faria mais sentido que fosse uma aplicação desktop. Discutimos isso com todos e ficou bastante claro que ele estava coberto de razão. Então, decidimos reverter o que estávamos fazendo e refazer algumas coisas para direcionar o software para desktop. Hoje, passados alguns meses, percebe-se que tomamos a decisão certo. Felizmente descobrimos isso bastante cedo devido à oportunidade de fazer um stand up meeting e interpretar as emoções que estavam no ar e não apenas as palavras verbalizadas. Se tivéssemos continuado no caminho original, talvez tivéssemos chegado à mesma conclusão em algum outro momento. Mas, certamente demoraria mais e o custo de reverter o projeto para desktop acabaria sendo maior. Portanto, emoções também representam um feedback importante que precisa ser levado em conta a todo o momento.

Para finalizar, precisamos compreender que o stand up meeting é uma forma de priorizar o que será feito em cada dia de trabalho. Nós priorizamos para assegurar que estamos fazendo o que é mais importante a cada momento do projeto e isso é feito porque o maior objetivo do XP é entregar um fluxo constante de valor para o cliente. Isso só é possível quando planejamos cuidadosamente o que será feito, isto é, quando escolhemos a cada dia fazer o que mais tenha potencial de gerar valor naquele momento. Sem essa priorização diária, é fácil um desenvolvedor acabar gastando tempo com algo que pode até ser útil, mas não era a coisa mais importante naquele ponto do projeto.

Em princípio, é fácil decidir o que deve ser feito a cada dia de trabalho. Basta olhar para o mural, onde a equipe coloca os cartões contendo as histórias da iteração, e verificar que histórias ainda precisam ser finalizadas. Entretanto, às vezes surgem problemas inesperados no dia anterior. Nesses casos, a equipe usa o stand up meeting para decidir se esses problemas devem ser tratados já no dia que está sendo iniciado, se devem ser deixados para uma iteração futura etc.

A priorização em equipe só pode ser feita de forma adequada quando temos a noção do todo, isto é, quando sabemos o que está acontecendo em cada parte do projeto, com cada pessoa da equipe e não apenas conosco. Pois, algo que eu possa considerar muito sério e prioritário no momento, pode ser absolutamente irrelevante quando somos informados de um problema bem mais significativo que está acontecendo em outra parte do projeto. Nos dias em que isso acontece, talvez faça mais sentido deixar o meu problema de lado e ir ajudar outra pessoa a resolver o problema mais sério que está afetando toda a equipe. Sem stand up meeting diário, é mais difícl notar e atuar rapidamente sobre situações como essas.

Clientes normalmente não podem passar 100% do tempo com a equipe de desenvolvimento, bem como não têm condições (frequentemente) de se dedicar exclusivamente a um projeto em particular. Entretanto, não é essa a proposta da prática. Na verdade, a prática chama-se Cliente Presente e o objetivo dela não é fazer com que o cliente passe 100% do tempo com a equipe, mas sim que ele tenha disponibilidade (a maior possível) para ajudar a equipe sempre que ela tiver 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. Ontem mesmo, após fazermos o XP Game em um evento aqui no Rio, estávamos conversando sobre isso e o Luiz Esmiralha comentou que em uma grande empresa na qua trabalha ou trabalhava (Luiz, me corrija se estiver errado) os desenvolvedores eram proibidos de conversar diretamente com os clientes finais. Não podiam sequer trocar emails. Esse é o outro extremo e não é muito agradável.

Costumo 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 as 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 com a cara mais lavada.
- 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... - respondo tentando enfiar a cara no chão a qualquer custo. :-)

Perder peso com a ajuda de uma nutricionista funciona e isso eu sei de carterinha porque perdi 22kg assim. Mas, só funciona quando ambos 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 orientado por uma nutricionista incompetente. As duas partes precisam funcionar e bem.

Em desenvolvimento de software acontece o mesmo. O cliente 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 circustâncias do projeto, as quais gerem mudanças naquilo que foi solicitado para a equipe. A qual, 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 frequê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. Como mencionei antes, 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, telefone, email, instant message, entre outras. Entretanto, alguns meios de comunicação são mais ricos que outros. Normalmente, o diálogo é a forma mais eficaz de comunicar, 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 comunicação 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 ser 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. Portanto o XP procura dar preferência ao diálogo, não porque outros meios de comunicação 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 frequente do cliente.