Mecânica de emparelhamento
O emparelhamento envolve ter dois programadores trabalhando em uma única estação de trabalho. Um programador “conduz”, operando o teclado, enquanto o outro “navega”, observando, aprendendo, perguntando, conversando e fazendo sugestões. Em teoria, o driver se concentra no código em questão: a sintaxe, a semântica e o algoritmo. O navegador se concentra menos nisso e mais em um nível de abstração mais alto: o teste que está tentando passar, a tarefa técnica a ser entregue a seguir, o tempo decorrido desde que todos os testes foram executados, o tempo decorrido desde a última confirmação do repositório e a qualidade do design geral. A teoria é que o emparelhamento resulta em designs melhores, menos bugs e uma distribuição muito melhor do conhecimento em uma equipe de desenvolvimento e, portanto, mais funcionalidade por unidade de tempo, medida a longo prazo.
Espalhando conhecimento
Certamente, como um mecanismo de orientação, o emparelhamento é difícil de superar. Se os pares se desligarem regularmente (como deveriam), o emparelhamento espalha vários tipos de conhecimento pela equipe com grande eficiência: conhecimento de base de código, conhecimento de design e arquitetura, conhecimento de domínio de recursos e problemas, conhecimento de linguagem, conhecimento de plataforma de desenvolvimento, conhecimento de estrutura e ferramenta, conhecimento de refatoração, e testando o conhecimento. Não há muito debate de que o emparelhamento espalha esses tipos de conhecimento melhor do que revisões de código tradicionais e métodos menos formais. Então, qual penalidade de produtividade, se houver, você paga por espalhar o conhecimento tão bem?
Emparelhamento e produtividade
Os resultados da pesquisa e relatórios anedóticos parecem mostrar que a produtividade de curto prazo pode diminuir modestamente (cerca de 15%), mas como o código produzido é muito melhor, a produtividade de longo prazo aumenta. E certamente depende de como você mede a produtividade e em que prazo. Em um contexto ágil, a produtividade geralmente é medida em execução, recursos testados realmente entregues por iteração e por release. Se uma equipe medir a produtividade em linhas de código por semana, eles podem realmente descobrir que o emparelhamento faz com que isso caia (e se isso significa menos linhas de código por execução, recurso testado, isso é bom!).
Produtividade e rotatividade de pessoal
Os defensores do emparelhamento afirmam que, se você medir a produtividade por um período longo o suficiente para incluir a contratação e a saída de funcionários, o emparelhamento começa a mostrar ainda mais valor. Em muitos projetos convencionais, a expertise tende a se acumular em “ilhas de conhecimento”. Os programadores individuais tendem a saber muitas coisas importantes que os outros programadores também não sabem. Se alguma dessas ilhas deixar a equipe, o projeto pode atrasar muito ou pior. Parte da teoria do emparelhamento é que, ao disseminar muitos tipos de conhecimento tão amplamente dentro de uma equipe, a administração reduz sua exposição a essa ameaça constante de rotatividade de pessoal. Na programação extrema (XP), eles falam do número do caminhão: o número de membros da equipe que precisariam ser atropelados por um caminhão para matar o projeto. Os projetos XP se esforçam para manter o número de caminhões o mais próximo possível do tamanho total da equipe. Se alguém sai, geralmente há vários outros para ocupar seu lugar. Não é que não haja especialização, mas certamente todo mundo sabe mais sobre tudo o que está acontecendo. Se você medir a produtividade em termos de recursos entregues em vários releases por tal equipe, deve ser maior do que se o emparelhamento não ocorrer.
Estratégias de emparelhamento
No XP de acordo com as regras, todo o código de produção é escrito por pares. Muitas equipes Agile não XP não usam emparelhamento. Mas há muito meio-termo entre nenhum emparelhamento e todos emparelhando o tempo todo. Tente usar o emparelhamento ao orientar novos contratados, para tarefas de risco extremamente alto, no início de um novo projeto quando o design é novo, ao adotar uma nova tecnologia ou em uma rotação mensal ou semanal. Os programadores que preferem emparelhar podem ter permissão para fazê-lo, enquanto aqueles que não preferem não podem fazê-lo. A decisão de usar revisões de código em vez de qualquer emparelhamento é popular, mas não sabemos de nenhum motivo para não pelo menos experimentar o emparelhamento. Não há evidências razoáveis de que prejudique uma equipe ou um projeto, e há evidências crescentes de que é uma prática recomendada útil.
