mecânica de emparelhamento
O trabalho em pares consiste em dois programadores trabalhando em uma mesma 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 "conduz" concentra-se no código em questão: a sintaxe, a semântica e o algoritmo. O "navegador" concentra-se menos nisso e mais em um nível de abstração superior: o teste que está tentando passar, a próxima tarefa técnica a ser entregue, o tempo decorrido desde a execução de todos os testes, o tempo decorrido desde o último commit no repositório e a qualidade do projeto como um todo. A teoria é que o trabalho em pares resulta em projetos melhores, menos bugs e uma disseminação de conhecimento muito melhor em toda a equipe de desenvolvimento e, portanto, mais funcionalidade por unidade de tempo, medida a longo prazo.
Disseminar conhecimento
Sem dúvida, como mecanismo de mentoria, o trabalho em pares é difícil de superar. Se os pares se revezarem regularmente (como deveriam), o trabalho em pares dissemina diversos tipos de conhecimento por toda a equipe com grande eficiência: conhecimento da base de código, conhecimento de design e arquitetura, conhecimento do domínio de funcionalidades e problemas, conhecimento da linguagem, conhecimento da plataforma de desenvolvimento, conhecimento de frameworks e ferramentas. conhecimento de refatoraçãoe conhecimento de testes. Não há muita discussão sobre o fato de que o trabalho em pares dissemina esses tipos de conhecimento melhor do que as revisões de código tradicionais e métodos menos formais. Então, qual é a perda de produtividade, se houver, por disseminar o conhecimento tão bem?
Emparelhamento e produtividade
Resultados de pesquisas e relatos informais parecem mostrar que a produtividade a curto prazo pode diminuir modestamente (cerca de 15%), mas, como o código produzido é muito melhor, a produtividade a longo prazo aumenta. E, certamente, isso depende de como você mede a produtividade e em que período. Em um contexto ágil, a produtividade é frequentemente medida em funcionalidades em execução e testadas, efetivamente entregues por iteração e por versão. Se uma equipe mede a produtividade em linhas de código por semana, pode de fato descobrir que o trabalho em pares faz com que esse número caia (e se isso significar menos linhas de código por funcionalidade em execução e testada, isso é uma coisa boa!).
Produtividade e rotatividade de pessoal
Os defensores do pareamento argumentam que, se a produtividade for medida em um período suficientemente longo para incluir a contratação e a saída de funcionários, o pareamento demonstra ainda mais valor. Em muitos projetos convencionais, a expertise tende a se acumular em "ilhas de conhecimento". Programadores individuais tendem a saber muitas coisas importantes que os outros programadores não sabem tão bem. Se alguma dessas ilhas deixar a equipe, o projeto pode sofrer atrasos significativos ou até mesmo piorar a situação. Parte da teoria do pareamento é que, ao disseminar diversos tipos de conhecimento amplamente dentro da equipe, a gestão reduz sua exposição a essa ameaça constante de rotatividade de pessoal. Na programação extrema (XP), fala-se do "número do caminhão": o número de membros da equipe que precisariam ser atropelados por um caminhão para acabar com o projeto. Os projetos XP se esforçam para manter o "número do caminhão" 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 todos sabem mais sobre tudo o que está acontecendo. Se a produtividade for medida em termos de funcionalidades entregues ao longo de várias versões por uma equipe desse tipo, ela deverá ser maior do que se o pareamento não fosse utilizado.
estratégias de emparelhamento
Na metodologia XP tradicional, todo o código de produção é escrito em pares. Muitas equipes Agile que não seguem o XP não utilizam programação em pares. Mas existe um meio-termo entre a ausência total de programação em pares e a programação em pares constante. Experimente usar a programação em pares ao orientar novos funcionários, em tarefas de altíssimo risco, no início de um novo projeto quando o design é inovador, ao adotar uma nova tecnologia ou em um sistema de rodízio mensal ou semanal. Programadores que preferem trabalhar em pares podem optar por fazê-lo, enquanto aqueles que não preferem podem optar por não fazê-lo. A decisão de usar revisões de código em vez de qualquer tipo de programação em pares é popular, mas não vemos nenhum motivo para não experimentar a programação em pares. Não há evidências razoáveis de que ela prejudique uma equipe ou um projeto, e há cada vez mais evidências de que é uma prática recomendada e benéfica.
