Olá a todos, aqui é Dima Vdovin novamente. Em meu artigo anterior sobre a integração de Juns em uma equipe, mencionei brevemente a programação em pares como uma prática eficaz de ensino e aprendizagem. Agora, gostaria de falar com mais detalhes sobre a prática da programação em pares em equipes. Eu tentei várias variações deles em diferentes projetos, e hoje eu gostaria apenas de compartilhar o que vejo nisso como as vantagens dessa abordagem.
Programação em pares
Parece-me que, para explicar simplesmente como funciona a programação em pares, podemos usar o exemplo das corridas de rally. Existe um motorista (motorista) e um navegador (navegador). O motorista está focado diretamente na direção. O navegador controla para onde estamos indo e informa ao piloto sobre as próximas curvas e saltos.
O mesmo ocorre na programação em par.
O driver se concentra em escrever código, aqui e agora. Nesse momento, o navegador segura toda a imagem à sua frente, verifica se o motorista não comete erros e diz onde e como seguir em frente.
A única grande diferença das corridas de rally é que na programação em pares, o piloto e o co-piloto devem trocar de lugar periodicamente. A distribuição de funções coincide quase completamente.
É a inclusão total de ambos os participantes na programação em pares no processo que distingue este método de outros métodos de aprendizagem e controle. Por um lado, não permitimos que o driver escreva o código de forma totalmente independente e não fornecemos o “produto” finalizado para revisão pelo navegador condicional. Ao mesmo tempo, o driver está focado não apenas em linhas específicas de código, mas deve ver a área que ele cria em uma perspectiva ampla. O mesmo se aplica ao nosso navegador.
Além desse esquema clássico de programação em pares, várias abordagens mais eficazes foram criadas ao longo dos anos de existência da indústria. Por exemplo, a abordagem de pingue-pongue ou navegador de banco traseiro é popular. Algumas pessoas geralmente praticam a mistura de técnicas diferentes. Isto é normal. A eficácia deste ou daquele método depende dos objetivos e da composição dos participantes: quem participa na dupla, o que pretendem alcançar, quão experientes são os dois codificadores. A propósito, a programação em pares é bastante aplicável não apenas em um par mentor-júnior, de que falei no último artigo, mas também em um par de dois programadores experientes do mesmo nível.
A seguir, vamos discutir as opções de configuração do driver + navegador de forma mais ampla, dependendo dos objetivos da programação em pares.
Treinamento iniciante
A programação em pares é ótima para ensinar iniciantes e costuma ser usada apenas para isso. No entanto, ao usar esse método de treinamento do jun, você deve entender que está sacrificando a velocidade de desenvolvimento do recurso imediato se o desenvolvimento ocorrer em um pedaço real de código. Ao mesmo tempo, a equipe vence seriamente a longo prazo: a programação em pares com um colega experiente aumenta muito a velocidade de integração e aprendizagem de um junho.
Mas, no contexto do caso do "treinamento de iniciante", junho nem sempre aparece. Por exemplo, a programação em par pode ser usada para integrar um meio condicional recém-contratado que precisa ser rapidamente integrado a um projeto. Nesse caso, a velocidade não cai tanto e o mentor pode ser um colega comparável a um recém-chegado ao projeto em termos de nível de habilidade. Aqui já falamos de transferência de experiência e conhecimento não em programação, mas nomeadamente conhecimento sobre um projeto específico.
Por outro lado, codificar em um par de dois médios é um pouco mais arriscado do que em um par junho + meio ou junho + signor. O líder em um par de dois médios deve abordar o processo com grande responsabilidade, mas se todas as condições forem atendidas, os benefícios para toda a equipe são bastante tangíveis.
Compartilhamento de conhecimento e liquidação da "Torre"
Um problema comum para muitas equipes é a disponibilidade de especialistas insubstituíveis. Isso geralmente se aplica a start-ups ou a pequenos grupos isolados de desenvolvedores que silenciosamente viram alguns recursos ou um projeto separado. Um especialista insubstituível é aquele que entende completa e individualmente uma seção específica do código / projeto ou somente ele tem um entendimento completo de como tudo funciona. O conjunto de conhecimentos sobre o projeto de tal especialista também é denominado "Torre do Conhecimento".
Um especialista insubstituível ou "Torre" é um gargalo perigoso que deve ser evitado por qualquer meio. Porque uma licença médica banal durante a integração de novos recursos na parte de combate do projeto (ou durante a mudança, ou em outra fase grave) - e o trabalho da equipe fica paralisado. Sem mencionar a demissão de tais desenvolvedores.
Para eliminar esse gargalo, especialistas indispensáveis devem compartilhar seu conhecimento com outros desenvolvedores.
Como já está claro, a programação em pares é novamente ótima para compartilhar conhecimento. Somente neste caso não recebemos treinamento avançado e onboarding de um iniciante, mas sim a transferência de conhecimento sobre aspectos do projeto dentro da própria equipe. Se você fizer um recurso em uma dupla, então pelo menos duas pessoas já saberão sobre isso, e, no processo de escrita, o background de um dos membros da dupla será mais estreito.
A liquidação da "Torre do Conhecimento" tem mais uma vantagem que não é óbvia para muitos. Além de descentralizar o conhecimento sobre características e áreas específicas do projeto, também reduzimos a carga sobre o desenvolvedor, em torno do qual essa “Torre” foi originalmente construída. Na verdade, na maioria das vezes, se a equipe tem um especialista insubstituível, ele muitas vezes tem que trabalhar em um estado de desgaste, com horas extras, sete dias por semana durante os lançamentos e, em geral, estar disponível 24 horas por dia, 7 dias por semana. Toda essa pressão constante, mais cedo ou mais tarde, leva ao esgotamento profissional ou, na melhor das hipóteses, ao desejo de encontrar um emprego mais tranquilo.
Usar a programação em pares de forma proativa também é uma ótima maneira de evitar a construção de torres de conhecimento do nada. A circulação constante de conhecimentos sobre funcionalidades e diferentes partes do projeto dentro da equipe é um processo normal, que, infelizmente, começa a se organizar apenas no momento da demissão de um funcionário-chave. É verdade que a programação em pares não é a única maneira de lidar com "Torres" e aumentar o nível de compreensão do projeto dentro da equipe, mas esta é uma história completamente diferente.
Resolvendo problemas complexos
A programação em pares pode ser usada como uma ferramenta local de brainstorming, ou seja, aplicando literalmente o ditado "uma cabeça é boa, duas é melhor". A programação em pares é ótima para os casos em que você precisa implementar um recurso ou lógica complexa de acordo com os requisitos de negócios do projeto. Aqui não estamos mais falando em transferência de conhecimento do líder para o seguidor, mas estamos criando um sistema de dois desenvolvedores, iguais em experiência e compreensão do projeto, que combinam seus esforços.
Alguns desenvolvedores podem argumentar que se sentem mais confortáveis trabalhando apenas em áreas complexas, mas a prática mostra que dois codificadores fortes em um par têm mais probabilidade de produzir código de alta qualidade do que trabalhar separadamente.
Os pontos fortes da programação em pares nessas situações estão fora do processo de codificação. Em vez disso, o ganho é obtido por meio da capacidade de discutir ativamente e em pé de igualdade possíveis maneiras de resolver o problema - o processo de escrever código em tal caso está em segundo plano e não é um problema. Mas como e o que exatamente deve ser escrito é o problema. A possibilidade de comunicação direta, discussão e disputa fundamentada entre dois especialistas tem efeito positivo na qualidade das decisões tomadas. O tempo necessário para encontrar uma solução bem-sucedida para o nosso problema também é reduzido.
Tarefas mistas
O último caso é uma equipe de todos os casos descritos acima. Aqui temos dois desenvolvedores experientes com diferentes áreas de especialização, que estão unindo forças para trabalhar em uma tarefa. Talvez um deles seja bom em escrever códigos e o outro esteja totalmente familiarizado com os requisitos do projeto. E não é necessário que fossem dois programadores. Eles podem ser pares de codificador e engenheiro de QA ou codificador e analista.
Aqui temos uma situação de ganho mútuo puro: no caso de problemas mistos, cada membro do par complementa o outro. É assim que aproveitamos ao máximo o potencial de ambos os especialistas, eliminando seus pontos fracos e utilizando apenas seus pontos fortes.
Ao mesmo tempo, a solução de problemas mistos abrange todos os casos descritos anteriormente: tanto onboarding, se se trata de conhecimento insuficiente dos requisitos do projeto, como liquidação da "Torre", e resolução de um caso complexo.
Total
É importante entender que a programação em pares não é uma solução mágica e a resposta para qualquer problema e desafio de desenvolvimento. Em quase todos os casos, esse método leva a uma diminuição na velocidade de desenvolvimento, portanto, vale a pena usar essa abordagem com cuidado.
Além disso, não devemos esquecer o fator humano: se estamos falando em ensinar um junho, então um mentor em uma dupla deve ser capaz de interagir com um iniciante no nível adequado para que o processo de aprendizagem não se transforme em espancamento e ridículo. Se estamos tentando liquidar a "Torre", então a composição do par deve ser combinada de acordo para que a transferência de conhecimento ocorra na direção certa. O mesmo se aplica a problemas complexos e mistos: você não pode colocar dois desenvolvedores aleatórios em um computador e esperar, eles lhe fornecerão uma solução pronta em N horas.
Mas mesmo com as dificuldades expressas, a programação em pares é uma ótima prática que não só resolve o problema de integração e ensino de novatos, mas também permite preencher as lacunas de conhecimento no projeto de outros membros da equipe ou resolver efetivamente um problema complexo.