Como você demonstra desempenho em ambientes de programação pareada?

As análises de desempenho surgiram recentemente no meu trabalho e fui colocado em uma posição interessante. Nossa equipe faz muita programação de pares, que tem a tendência de calcular a média das diferenças de habilidades entre os membros da equipe (especialmente considerando que alternamos os pares). Geralmente, ao fazer análises de desempenho, você olha para o trabalho realizado e demonstra o que realizou e como excedeu as expectativas para tentar negociar um aumento ou outros benefícios.

Como você demonstra (ou mesmo mede) o desempenho individual em um ambiente como este?

inclua o valor que você adicionou à programação de pares na revisão de desempenho - você ajudou o outro programador a aprender coisas úteis? (e vice-versa, você ouviu seus conselhos sábios e cooperou bem?)

uma revisão de desempenho não deve ser uma competição, deve ser uma avaliação de treinamento em relação aos seus objetivos pessoais (presumivelmente alinhados com os objetivos da empresa e mutuamente acordados no início do ano; caso contrário, é apenas arbitrário)

Seria difícil provar definitivamente um benefício de desempenho sobre o outro cientificamente.

Sua hipótese é que a programação em pares aumenta o desempenho do desenvolvedor e melhora a qualidade. Seu teste envolverá fornecer a um par um conjunto de requisitos restritos a uma arquitetura específica e fazer com que eles o implementem.

Seu controle, nesse caso, é que você forneça os mesmos requisitos a um único desenvolvedor de posição, habilidade e experiência iguais (conforme julgado objetivamente por seus pares) e também restrito à mesma arquitetura.

Para verificar sua hipótese de desempenho de tempo, os programadores em pares devem concluir seu trabalho em menos da metade do tempo como controle. Para verificar sua hipótese de qualidade, é necessário que o par do experimento e o código de controle sejam revisados ​​por terceiros objetivos e que um grupo de QA objetivo teste os resultados de ambos os grupos sem informar a equipe que produziu o quê. O grupo de programação em pares deve ter um código melhor e menos erros.

Não é um experimento perfeito, mas eu ficaria fascinado em saber se alguém tentou algo semelhante.

Além disso, no entanto, não vejo como você pode provar de fato que a programação em pares é superior a um único programador em um determinado recurso.

Em suas métricas de desempenho, chame separadamente 1) crescimento e desenvolvimento individual e 2) orientação e apoio de colegas. Permita que cada funcionário se auto-avalie e incorpore o feedback de seus líderes. Se fizer sentido na cultura da sua empresa, considere avaliações ou depoimentos de colegas.

Se feito corretamente, o funcionário que obtém o maior valor educacional de um emparelhamento é recompensado por sua capacidade de contribuir com a equipe a longo prazo, e o funcionário que está ajudando a acelerar a atualização é recompensado por transferir conhecimento e experiência. As pessoas que estão em algum lugar no meio (aprendendo novos domínios em vez de apenas passar do nível júnior para o sênior) são reconhecidas pelos dois extremos da equação.

Na prática, classificar o desempenho individual é complicado na melhor das hipóteses. É muito difícil fazê-lo sem criar alguns sentimentos de ressentimento ou competição. Mas se você avalia a contribuição individual da equipe e valoriza o aprendizado e o ensino, há algumas chances de fazê-la funcionar com um pouco menos de atrito.

Os pares estão mudando frequentemente? Nesse caso, você pode usar análises anônimas para criar um medidor. Por exemplo, se a pessoa A disse que B fez 60% do trabalho, a pessoa C disse que a pessoa B fez 30% do trabalho e a pessoa D disse que a pessoa B fez 90% do trabalho, você pode calcular a média para a pessoa B fazendo 60% do trabalho. Se o trabalho que a pessoa B realizou em seus pares tem um fator relativo de 100 pontos, então a pessoa B fez 60 pontos em trabalho!

No entanto, isso não é (nem perto) perfeito. É provável que as pessoas se concedam mais crédito do que concedem à outra pessoa; portanto, você pode levar isso em consideração no cálculo. Isso também pode levar a um ambiente em que os pares suspeitam um do outro. O cálculo também pode ser alterado por alguém que não gosta da pessoa com quem está trabalhando etc.

Digo que, se dois de nós trabalhamos juntos para criar o X, obtemos crédito por ter terminado e implantado. O ponto em que você pode ter um problema é quando uma parte de um par não funcionou. Nesse caso, o gerente deveria ter sido informado sobre isso o tempo todo e, portanto, deveria usar esse feedback ao preencher seu comentário para a revisão de desempenho.

Você está na situação exata em que meu professor coloca os alunos em nosso currículo de Desenvolvimento de Jogos. Somos emparelhados (2, 3 ou 4 pessoas, dependendo do tamanho da classe e do tamanho do projeto) e, no final, somos instruídos a avaliar cada membro da equipe e a nós mesmos em relação ao projeto e ao trabalho realizado, bem como os projetos das outras equipes como um todo. Uma nota é formulada com base nessas avaliações.

Durante a formulação da equipe, o professor deliberadamente colocaria um programador forte e um programador fraco juntos, esperando que eles trabalhassem um com o outro e / ou ajudassem, mas 99% das vezes o programador fraco passaria de skate e faria muito pouco trabalho para ninguém ou teria nenhuma pista do que eles estão fazendo (sendo os cursos avançados, é muito frustrante).

As avaliações devem ser privadas, mas digamos que há algumas pessoas com quem todos se recusam a trabalhar.

A programação em pares significa que uma pessoa pensa o que e como algo deve ser feito, e a outra interpreta um macaco de codificação. Então, em algum momento, eles mudam (alguém fica entediado, cansado etc.). É bom, porque ambos não são interrompidos em suas atividades.

Algumas pessoas também consideram isso como "a revisão de código em esteróides". Você recebe um código revisado, o que deve significar maior qualidade.

Boa pergunta. O importante não é apenas o que você contribui, mas como seus colegas vêem sua contribuição. Peça a eles um feedback sincero, pois é esse feedback que ajuda você a ser um 'qualquer que seja' melhor . Sério, é importante que seus colegas entendam sua contribuição e eles a entendam apenas quando tiverem um bom aprendizado enquanto estiverem em parceria com você. Feliz codificação, compartilhamento e aprendizado resultam em bons ganhos.

A desvantagem da programação em pares é que a produtividade do programador mais experiente é restrita à produtividade do programador menos experiente, a curto e médio prazo. A longo prazo, a experiência e a produtividade aumentam no desenvolvedor júnior.