Já trabalhei em algumas lojas nas quais a gerência passou a idéia de programar em pares para mim ou para outro gerente / desenvolvedor, e não consigo ficar atrás disso. Do ponto de vista do desenvolvedor, não consigo encontrar uma razão pela qual a mudança para esse estilo de codificação seja benéfica, nem como gerente de uma equipe pequena tenho visto algum benefício.

Entendo que ele ajuda nos erros básicos de sintaxe e pode ser útil se você precisar fazer algo errado, mas os gerentes que estão fora do ciclo de programação parecem continuar vendo isso como uma maneira de impedir que seus designers acessem o Facebook ou Reddit do que como uma ferramenta de design.

Como alguém próximo à área de desenvolvimento que aparentemente não consegue entender muito bem de um livro, ou de uma página wiki sobre o assunto ... de uma posição gerencial de alto nível, quais são os benefícios da Programação em Pares ao lidar com Scrum ou Agile ambientes?

Em parte, depende de como você está fazendo a programação em pares. Em alguns casos, o driver do par está escrevendo código, enquanto o segundo membro do par está observando e discutindo os detalhes de design e implementação do sistema. Outra instância da programação em pares envolve as duas pessoas escrevendo código simultaneamente - uma pessoa está escrevendo a funcionalidade implementada e a outra está desenvolvendo e escrevendo ativamente o código de teste no nível da unidade e da integração, discutindo novamente os detalhes de design e implementação do sistema.

Independentemente do tipo de programação em pares, ele efetivamente serve como uma revisão contínua de código . Você tem o olhar de duas pessoas no código, observando os erros antes que eles escapem para um ambiente posterior de teste de sistema / aceitação ou para o campo. Você também tem duas pessoas que entendem muito bem uma parte específica do sistema, para servir como redundância para minimizar o fator de barramento . A detecção precoce de defeitos e a disseminação do conhecimento do sistema pela equipe reduzem o custo de construção de um sistema.

A difusão do conhecimento também não se limita apenas ao conhecimento técnico da equipe. Dependendo de quem é o par, ele pode permitir que as informações fluam entre um membro mais sênior da empresa para um novo membro sobre outras coisas que transcendem o projeto - estilo de codificação, cultura da empresa, expectativas e assim por diante. Também pode permitir que alguém mais familiarizado com uma tecnologia ou ferramenta compartilhe seu conhecimento nessa tecnologia ou ferramenta em um ambiente aplicado no mundo real.

Como você mencionou, também ajuda a manter os desenvolvedores focados e no fluxo . Além do fluxo, muitos indivíduos têm menos probabilidade de interromper várias pessoas trabalhando em algo do que um único indivíduo trabalhando em algo. Se você passar pela mesa de alguém e ele estiver trabalhando sozinho, mas precisar conversar com ele, poderá bater e conversar com ele. Isso é menos provável se você vir duas ou mais pessoas trabalhando em conjunto ou tendo uma discussão - você não as interromperá. Interrupções custam tempo, e gastar mais tempo significa custos mais altos. É do interesse dos negócios maximizar a produtividade dos funcionários.

No entanto, existem alguns desafios que devem ser superados para tornar a programação em pares viável. Considere coisas como conflitos de personalidade ou escolha dos pares para distribuir adequadamente o conhecimento. Também há consideração de quando exatamente girar pares. A programação em pares feita aleatoriamente provavelmente não será eficaz como a planejada. Dependendo da composição da sua equipe, pode não ser eficaz emparelhar as pessoas.

1. Menos erros no código final (eficiência)
   Não substitui completamente as análises de código, mas é altamente eficaz para corrigir as coisas desde o início. Há pesquisas por aí que apontam nessa direção.

2. Conclusão mais rápida (eficácia)
   Há várias pesquisas apontando isso. Quando se trata de recursos complexos, 2 cabeças são simplesmente mais eficazes. Experiência em emparelhamento é uma obrigação para isso.

(observação: este é o seu ponto de venda para o gerente: financeiramente uma decisão sensata porque você obtém mais eficiência através do menor número de bugs e mais efetivo com a conclusão mais rápida)

1. Ensinando juniores
   Você pode adicionar um junior diretamente a um programador mais experiente. Se você tem um grupo de iniciantes, é fácil ficar por aqui e deixá-los, em pares, entender o básico. Fique por aqui e dê conselhos. O conceito é aparentemente muito antigo e deriva de artesanato.

Resposta rápida: a maioria dos benefícios e custos são publicados na Wikipedia , no entanto, vamos ver de um ângulo um pouco diferente.

Gostaria de mencionar casos específicos de benefícios de programação em pares que se aplicam ao ambiente de desenvolvimento ágil / scrum, retirado da postagem do blog :

O sucesso ou falha do software depende de sua qualidade, e a Programação por Pares melhora diretamente a qualidade de várias maneiras. Quando dois desenvolvedores trabalham juntos, a qualidade do padrão de design melhora à medida que o par desenvolve código curto, simples e fácil de manter, com menos bugs. Os erros são uma grande preocupação de qualidade no desenvolvimento de software; com dois pares de olhos escrevendo o código, mais erros são detectados, diminuindo assim o custo do desenvolvimento. Os erros encontrados no final do processo de desenvolvimento geralmente são caros de corrigir. A descoberta precoce de defeitos de software evita e ajuda a impedir problemas difíceis no caminho. Muitas vezes surge complexidade na programação, e duas mentes trabalhando para resolver um problema juntas podem ver mais opções e tirar conclusões mais rapidamente do que uma.

Em suma:

• Promove a comunicação da equipe
• Promove a transferência eficiente de conhecimento de aplicativos
• Promove a responsabilidade na abordagem do design
• Resulta em um código melhor e fácil de manter
• Ajuda a eliminar o código de buggy em seu estágio inicial
• Aumenta a produtividade da equipe, pois os membros da equipe terão atenção total durante a codificação
• Melhora as habilidades de comunicação e colaboração dos membros da equipe
• Cria camaradagem no local de trabalho
• Torna o trabalho mais divertido

Existem alguns benefícios para a programação em pares:

• Os dois programadores são capazes de colaborar no projeto juntos, potencialmente produzindo melhor arquitetura / código - dois pares de olhos podem detectar erros
• O conhecimento da instituição é preservado melhor - se um programador deixa ou não está disponível, o outro deve poder continuar o trabalho sem muita perda de produtividade
• É uma maneira de treinar rapidamente novos desenvolvedores - associe-os a um membro experiente da equipe de desenvolvimento e eles poderão experimentar a base de código da perspectiva de um veterano da equipe
• Melhor disciplina - os programadores emparelhados provavelmente serão produtivos por um período mais longo, pois um ou outro pode assumir o controle de explosões de atividades. Tarefas potencialmente tediosas, como testes de unidade, podem ser ignoradas com menos frequência do que para desenvolvedores individuais.

A Wikipedia também possui um bom resumo dos custos e benefícios na entrada do wiki .