Quão comum é a programação de pares no local de trabalho?

Sempre fiquei intrigado com a programação em pares, mas em 12 anos de desenvolvimento nunca trabalhei em um local onde eles empregaram essa prática, por isso sempre fui cético em relação à maneira como as pessoas a veem.

Gostaria de saber se isso é por causa de dinheiro / tempo (chefe de cabelos pontudos avistando duas pessoas em um computador trabalhando no mesmo código !!!! como se atrevem!) Ou por outros motivos?

Eu tenho o mesmo show há 15 anos e recentemente (últimos 12 a 18 meses) começamos a adotar técnicas Agile. Onde a programação de pares é usada, a história / recurso resultante foi implementada no tempo sem defeitos. Ainda não acho que tenha sido empregado com bastante frequência.

Antes da adoção do Agile, um outro desenvolvedor e eu compartilhamos o teclado periodicamente ao longo dos anos com pouca frequência (talvez uma vez a cada 3-4 meses). Nossa equipe de gerenciamento parecia relutante, mas sempre estava satisfeita com nosso emparelhamento informal, pois geralmente realizava algumas das seguintes ações:

• silos reduzidos no time (grande vitória quando o time tem 6-8 desenvolvedores)
• código produzido com menos defeitos
• cada desenvolvedor normalmente adquiria habilidades com isso

Eu diria que a gerência é relutante, mas se você pode dar pequenos passos e demonstrar que o recurso é melhor posteriormente (economia de custos) e / ou cada (ou um) desenvolvedor adquiriu algumas habilidades (pagando antecipadamente), poderá ganhar força se você acha que é uma prática que combina com você ou sua equipe.

Meu palpite é que provavelmente haveria muitas resistências dos desenvolvedores. Você se lembra de ter sido forçado a trabalhar com pessoas que talvez não fossem as pessoas mais motivadas do mundo durante a faculdade ou mesmo o ensino médio? Essas pessoas ainda existem. A menos que você tenha uma equipe composta por todas as pessoas "de primeira linha", esse tipo de configuração causará alguma animosidade no grupo.

Ainda não fiz isso oficialmente, mas sempre que estou emperrado, ligo para um desenvolvedor e vamos trabalhar juntos em uma solução. É uma ótima maneira de trocar idéias, deixe uma pessoa pensar enquanto a outra implementa, para que você não perca sua linha de pensamento porque está digitando.

Gostaria que fosse feito mais.

Eu não ligo para isso:

1 - Gosto de ouvir minha música durante a codificação. Nem todo mundo quer ouvir Slayer explodindo em seus ouvidos.

2 - Fui criado pensando em olhar por cima dos ombros das pessoas muito rude e ficar muito desconfortável quando as pessoas fazem isso.

3 - Penso muito rápido e quando estou em um segmento de solução, quando começo a encontrar uma resposta, ser interrompido é a última coisa que preciso.

4 - Não posso fazer intervalos ocasionais para ler fóruns e grupos de notícias. Alguns podem achar inadequado de qualquer maneira, mas acho muito importante para minha melhoria contínua. Ocasionalmente, fico muito distraído, mas geralmente o benefício para o meu conhecimento aumentado supera qualquer impacto na minha produtividade.

Suponho que possa ser diferente em outras equipes, mas nas poucas vezes em que estou realmente perplexo com alguma coisa e PRECISO de ajuda, quase sempre sou o único que acaba apresentando a solução de qualquer maneira. Sou muito bom no que faço, mas acho que pode haver mais coisas acontecendo ... não tenho certeza, de qualquer forma, acho que estou melhor apenas resolvendo os problemas difíceis e, geralmente, melhor sozinho. Pode parecer arrogante, mas isso não a torna falsa.

Eu considerei que isso poderia realmente ajudar outras pessoas a aprender algumas das minhas técnicas, mas, levando em consideração o número 3, elas dificilmente poderiam fazer perguntas sem interromper minha linha de pensamento.

Tudo isso dito, eu tentei de vez em quando. Às vezes, traz benefícios menores, mas certamente não consigo vê-lo como algo consistente. O sistema de lobo solitário funciona para mim e parece funcionar para a equipe.

A programação em pares é uma ótima maneira de começar ou fazer algo não trivial e difícil. Mais tarefas rotineiras e simples são melhor executadas sozinhas.

Participei de várias sessões de programação em pares, tanto em empresas iniciantes quanto em grandes empresas. Invariavelmente, acontecia apenas quando algo novo e difícil estava sendo aceito, ou seja, duas vezes por ano, na melhor das hipóteses, por algumas semanas. Com que frequência isso acontece na sua empresa?

Nós nunca chamamos assim, mas antigamente, era assim que sempre atacávamos novos problemas. Emparelhávamos para começar uma solução, mas, em seguida, geralmente começávamos a finalizar / limpar os detalhes individualmente. Não tanto mais. Parece se tornar cada vez mais raro.

Não é muito comum. Em todas as lojas em que estive nos últimos 10 anos, já vi uma vez. Na loja mais lenta e menos eficiente. Parece criar um ambiente barulhento e estressante. Uma pessoa acaba dirigindo e fala constantemente, impedindo a outra de pensar.

Reúna a equipe para revisões de código, seja em grupos ou em pares, e dê aos desenvolvedores seu próprio espaço. A longo prazo, será melhor do que buscar a última moda do Agile.