Tópicos
A programação em pares é uma disciplina de programação na qual todo código de produção é escrito por pares de programadores. Cada par trabalha junto em uma única estação de trabalho. Eles compartilham o teclado, o mouse e o monitor.
Os dois programadores trabalham em estreita colaboração. O teclado se move frequentemente de um lado para o outro entre eles. Todos os olhos estão travados na tela. Ambas as mentes estão imersas no código. O código é o produto de ambas as mentes, e não de apenas uma. Ambos os programadores estão igualmente empenhados em escrever o código, e não podem reivindicar a autoria.
As parcerias duram pouco. Quatro horas é um bom tempo para uma parceria. Às vezes uma parceria pode durar um dia. Muito raramente, pode durar uma semana. Ao invés disso, as parcerias se formam por algumas horas e, então, se desfazem e recriam-se com parceiros diferentes.
Durante a reunião de planejamento da iteração, cada programador compromete-se com as tarefas que completará até o final da iteração. O programador fica responsável por essas tarefas. Metade de seu trabalho em parceria ele dedica a essas tarefas, e a outra metade ele trabalha nas tarefas dos outros.
A programação em pares é uma forma de revisão de código contínua e, geralmente, substitui a prática de revisão e inspeção de código. A idéia é que se as revisões de código são uma coisa boa, então a revisão contínua é melhor.
Mesmo que cada tarefa seja da responsabilidade de um único programador, muitos outros programadores irão trabalhar nessa tarefa com o programador responsável. Sendo assim, o conhecimento sobre o sistema se espalha pela equipe, e nenhum programador pode reivindicar a propriedade de qualquer parte do código. É provável que qualquer programador na equipe seja capaz de trabalhar em qualquer módulo do sistema.
Às vezes você fica preso a uma ideia que não consegue se desvencilhar. Muitas vezes, o seu parceiro poderá proporcionar o motivo necessário para que você tenha outro ponto de vista.
Quando novas pessoas entram na equipe, elas aprendem através das parcerias. Ao longo de uma iteração, eles irão fazer parcerias com todos na equipe e verão todas as partes do sistema que estão atualmente sendo construídas. Esta é uma excelente forma de treinar um novo membro da equipe.
Você começa a trabalhar de manhã e participa da reunião diária. Então você se dirige a alguém e pergunta se ele pode ajudá-lo. Ou talvez alguém se dirija a você e lhe peça para ajudá-lo. A regra é: quando solicitado, você tem que dizer sim. Entretanto, você pode negociar o horário.
Os pares se formam naturalmente. Os gestores não se envolver na seleção dos pares. A criação dos pares não é cronogramada ou controlada, de qualquer maneira formal. O treinador, outro membro da equipe ou a equipe como um todo podem notar que alguns membros da equipe adotaram atividades de parceria patológica e podem intervir.
- Quando você estiver cansado do seu parceiro atual.
- Quando você achar que o seu parceiro atual está demasiadamente cansado ou distraído para lhe ajudar.
- Quando vocês dois ficarem empacados em um conceito.
- Hora do almoço.
- Hora de ir embora.
- Ou geralmente, sempre que lhe apetecer.
Claro que sim. Você só não pode fazer check-in do código de produção que você tenha escrito sozinho.
Muitas vezes temos que nos esconder em algum lugar para pensar sobre algumas coisas sem que alguém fique grudado no nosso pescoço ou nos distraia falando sobre a hipoglicemia da sua cunhada. É perfeitamente normal ficar sozinho, e cada programador deve ter um lugar privativo para usar.
Quando sozinho, é perfeitamente normal que escreva algum código para lhe ajudar a pensar em um programa. Entretanto, em uma equipe XP, você não tem permissão para fazer check-in desse código no ambiente de produção. Ao invés disso, você pode levar esse código para a sua próxima sessão de programação em pares e inspecioná-lo com o seu parceiro. O seu parceiro deverá ter todo o direito de modificar, apagar ou refatorar o código. Você deve ajudar o seu parceiro a ficar confortável com o código e manter a mente aberta para qualquer refatoração.
Muitas vezes a melhor abordagem é que os dois revisem o código que você escreveu e, então, re-escrevam-no como um par. Lembre-se, o valor de um pedaço de código não está realmente no código. Mas está nos neurônios e sinapses dos programadores. É sempre muito mais fácil escrever um módulo pela segunda vez, e o resultado é sempre melhor. Portanto, se você programar sozinho, pense no código como um esboço que você irá jogar fora e rescrever com seu parceiro.
Aparentemente não. As equipes que trabalham em pares não apresentam uma perda significativa de produtividade. Na verdade, tendem a demonstrar que são mais produtivos do que quando trabalhavam sozinhos.
Esta evidência anedótica é apoiada por algumas pesquisas. Alguns desses estudos podem ser encontrados em www.pairprogramming.com.
Estes resultados podem ser explicados ao vermos os programadores como dois corredores que se ajudam. Quando um fica cansado ou desfocado, o outro fornece a motivação e inspiração para continuar. Também, o par gasta menos tempo em relação aos impasses e bloqueios de ideias.
Uma coisa parece clara. A digitação não é o elemento crítico. Se fosse, então a programação em pares certamente iria diminuir a produtividade pela metade. pode ser que a programação em pares permita que os parceiros pensem duas vezes mais rápido.
As questões de higiene e etiqueta são mau hálito, odor corporal, escorrimento nasal, constipações, ruídos altos, gases, bocas nervosas, viciados em telefone, hipocondríacos, etc. Os seres humanos são uma espécie porca. Por incrível que pareça, nós geralmente somos capazes de conviver com as idiossincrasias pouco desagradáveis dos outros, mas há momentos em que uma pessoa tem certos hábitos que vão além do limite. Como trabalhar em pares com essa pessoa?
- Sorria e suporte, isso só vai durar algumas horas.
- Use balas refrescantes.
- Coloque um desodorante ou uma colônia na mesa dela.
- Escreva cartas anônimas ao infrator.
- Desligue o telefone.
- Queixe-se com o seu chefe.
- Mas, com certeza, o melhor caminho é falar para o seu parceiro o que lhe incomoda.
- Usuários canhotos versus os que usam o mouse com a mão direita.
- Algumas pessoas precisam de teclados especiais para trabalhar.
- Algumas pessoas usam Teclados Dvorak.
- Algumas pessoas precisam de telas especiais para poder ver.
- Algumas pessoas preferem um trackball de que um mouse.
Problemas como esses são muito fáceis de resolver. Configure determinadas estações de trabalho com dois teclados, dois mouses, dois monitores, etc. Os pares não têm que trabalhar no mesmo teclado, mouse ou monitor.
Na verdade, os pares não precisam realmente usar a mesma estação de trabalho. Eles podem usar duas estações de trabalho completamente independentes sentando-se próximos um do outro, conectados com o NetMeeting ou algum outro tipo de software de colaboração.
No mínimo, a programação em pares distantes geograficamente é difícil. A melhor abordagem é dividir o projeto em subprojetos que possam ser feitos separadamente em cada localização geográfica, de forma que os programadores, em cada local, possam trabalhar em pares e não tenham que interagir muito com os programadores remotos.
Às vezes o projeto não pode ser facilmente dividido por todos os sítios geográficos. Nesse caso, você pode usar o NetMeeting ou outro software colaborativo para facilitar a criação de parcerias remotas. A parceria remota é possível, mas não tão eficaz como a parceria local. Quando você faz parcerias localmente, você tem a vantagem da linguagem corporal, contato visual e todas as outras nuances da comunicação pessoal para ajudá-lo. Quando você faz parcerias remotamente, você é forçado a usar um canal de comunicação não tão eficiente.
- Talvez você esteja atropelando ele. Tente ir um pouco mais lento e faça-o engajar-se.
- Talvez ele esteja com problemas pessoais que estão lhe distraindo. Sugira que este pode não ser o melhor momento para trabalhar em pares.
- Talvez ele ache que você não está ouvindo as ideias dele. Certifique-se de conversar com ele sobre todas as ideias, e certifique-se que ele tenha a oportunidade de testar a mesma quantidade de ideias que você também testou.
- Talvez ele ache que você tem se apoderado do teclado. Empurre o teclado na direção dele e peça-o para conduzir.
- Talvez ele não queira sempre programar em pares, independente de qualquer coisa. No momento, o melhor que você pode fazer é dissolver a parceria e escolher outro parceiro. Se o comportamento continuar, a equipe terá que decidir o que fazer sobre isso. Talvez a equipe peça para ele escrever scripts de configuração ou qualquer coisa parecida.
- Pergunte-lhe gentilmente se você pode dirigir por algum tempo.
- Peça-lhe gentilmente para descrever o que ele está fazendo.
- Talvez ele precise de um tempo sozinho para pensar. Sugira-lhe isso e dissolva a parceria.
- Talvez ele não possa programar em pares. Dissolva a parceria e escolha outro parceiro. Se o comportamento continuar, a equipe terá que descobrir o que fazer.
Sua única opção é desacelerar e se esforçar para se comunicar. Você pode se entender melhor com ele, escrevendo notas estratégicas do que falando. Esforce-se em ajudá-lo com a pronúncia e a gramática. Esforce-se para entender o seu sotaque e uso das palavras. Vai levar tempo, mas a situação vai melhorar. Não desista!
Algumas pessoas chegam cedo e outras ficam até tarde. Como você pode encontrar parceiros se todos têm um horário diferente de trabalho?
Crie parcerias para durar apenas algumas horas. Tudo o que você precisa é o tempo suficiente para formar parcerias e trabalhar de forma eficaz. A maioria dos horários de trabalho permite isso.
Os membros da equipe têm que ser criativos para que todos se acomodem com seus horários de trabalho. Algumas pessoas podem ter que mudar os seus horários para permitir que outras pessoas tenham oportunidade de participar das parcerias. Por exemplo, se o Beto só puder trabalhar à noite, a equipe poderá decidir adotar um horário rotativo para que os outros possam chegar mais tarde um dia e fazer parceria com ele.
Lembre-se que as parcerias se dissolvem e refazem-se com frequência. A pessoa que ficar de fora não terá que esperar muito tempo até que alguém fique disponível para fazer parceria com ela. Neste período, ela pode ler seu e-mail, o jornal ou algum trecho de código que não esteja familiarizada.
- Grudadas pelo quadril. Às vezes duas pessoas decidem fazer parcerias exclusivas. Esta não é uma boa ideia. Elas estão perdendo a oportunidade de conhecer toda a equipe e estão ficando isoladas em uma parte do sistema. A equipe deve interrompê-las, sugerindo que façam parceria com os outros.
- Um cego guiando outro cego. Não é uma boa ideia que os novos membros da equipe façam parcerias frequentes com outros membros novos. Os novatos devem fazer parcerias, a maior parte das vezes, com os membros mais antigos da equipe.
|