Tá difícil parear? Converse com seu time!

Programar em par tem benefícios bem conhecidos, mas será que é sempre a melhor maneira de trabalhar? O seu time está pensando em adotar programação em par? Nesse post eu vou compartilhar minha experiência com programação em par e sugerir uma atividade que vai ajudar a melhorar os benfícios e reduzir os riscos de aplicar esta técnica.

Os Benefícios

1. Melhora no Foco: Muito se fala sobre qualidade de código, mas pra mim é bem mais que apenas o código. O foco de um par afeta também o relacionamento com os clientes, seja em uma reunião presencial ou via email. Quando se está escrevendo um email, a mensagem é revisada e erros são evitados. Em reuniões é mais difícil deixar de mencionar algo e depois o par pode conversar sobre o que foi discutido. Geralmente um par tende a se comunicar bem melhor que apenas uma pessoa.
2. Menos Defeitos: Sempre que precisei trabalhar só em um código que não me é familiar eu gastei bastante tempo pedindo para alguém revisar meu código e ter certeza que eu não esqueci nada. Além disso, algumas vezes eu faço besteira ou escrevo um código bem mais complexo que o que poderia ser. Quando estou pareando, posso dizer com certeza que o código tem bem menos defeitos e é geralmente bem mais simples. Sempre tem alguém para olhar meus erros e simplificar a solução.
3. Continuidade de Negócio: Continuidade de Negócio é muito importante em qualquer projeto e programar em par é uma prática chave para alcançá-la. Existe um fluxo constante de troca de contexto garantindo que as tarefas podem ser feitas mesmo quando uma pessoa chave não está lá.

Estes são algun dos poucos benefícios de programar em par, mas nem tudo são flores. Programar em par requer um time com determinado nível de maturidade e as pessoas precisam sentir-se confortáveis trabalhando junto com outras.

Os Desafios

1. Infraestrutura: o problema mais claro com programar em par é a configuração do time. Desde editores de textos/IDEs até o layout do teclado e o Sistema Operacional, se o seu time não tiver uma configuração comum para todos, vai ser bem difícil fazer com que as pessoas se sintam confortáveis para parear. Ter estações de trabalho dedicadas ajuda bastante, mas também é possível concordar em uma configuração comum ou ter uma maneira de compartilhar o código para que qualquer pessoa use sua própria configuração.
2. Fadiga: Eu já ouvi várias vezes pessoas dizendo que estavam muito cansadas depois de um dia ou de uma sessão de pareamento. O aumento do foco não vem tão facilmente, requer muita concentração para focar no problema, compartilhar seus pensamentos e ouvir a outra pessoa. Esquecer o mundo ao redor e não olhar o seu twitter, enquanto tem uma pessoa do seu lado esperando por você, também exige muito esforço.
3. Ego: Seja quando pareando ou até mesmo quando você pensa em parear com alguém, é importante se manter humilde e ouvir a outra pessoa. Várias vezes já vi um par discutir pela solução, ao invés de conversar. Pra mim esse é o maior problema para programar em par. Depois de algumas situações assim, parear se torna tão doloroso que ninguém mais quer, e vão até mesmo lutar contra a prática!

Tudo é relativo:

Todos os pontos que foram comentados aqui são baseados na minha experiência. Eles são todos discutíveis e bem dependentes do contexto. Cada uma das vantagens tem seus próprios custos e necessidades, eles não são garantidos. A melhor coisa que você pode fazer é falar com seu time e deixar com que eles decidam como querem trabalhar.

Existem algumas situação que o pareamento não flui e as pessoas não se sentem confortáveis. A rotação dos pares não acontece naturalmente ou talvez o time não tenha certeza se eles querem programar em par ou não. Nessas situações, eu sugiro uma atividade que pode ajudar um pouco a entender o que funciona melhor com o time.

Aquela Pessoa e Essa Pessoa

Essa atividade é na verdade uma retrospectiva postada por Paulo Caroli and Tainã Caetano (http://www.funretrospectives.com/that-guy-this-guy/), mas eu apliquei em uma conversa específica sobre pareamento e o resultado foi muito bom.

Comece criando duas sessões, "Não Seja Aquela Pessoa" (Don't be That Person) e "Essa Pessoa se Garante!" (This Person rocks!):

Na primeira sessão, escrevam exemplos de comportamentos que vocês não gostam. Não precisa ser necessariamente com o time atual, pode ser um exemplo de qualquer outra situação. Tente fazer com que cada pessoa coloque pelo menos um exemplo.

A segunda sessão deve ter exemplos do que as pessoas realmente gostam. Novamente, podem ser exemplos de qualquer situação e todos devem colocar pelo menos um exemplo.

Depois disso, leia os exemplos e deixe com que o time fale sobre cada um. O que você quer, no final da sessão, não é uma lista de o que time deve fazer ou não, mas sim uma lista de boas práticas. É por isso que é importante garantir que todo mundo fale sobre pelo menos um dos exemplos.

A conversa deve ser sobre como o time se sente sobre certos comportamentos, as pessoas concordam que isso é uma boa coisa? Em algumas situações pode ser claro, em outras talvez seja necessário uma discussão mais profunda. Evite discussões sobre certo e errado, ou situações que são muito específicas. Você precisa achar coisas que o time gosta, não regras para serem seguidas.

Busque feedback constantemente

Eu vejo essa atividade como uma boa maneira de aumentar a moral do time, ter essas conversas geralmente faz com que as pessoas fiquem mais abertas, o que gera mais conversas. Uma boa maneira de sentir a dinâmica do time é ver o quanto eles falam. Um time quieto geralmente significa que as pessoas estão desconexas e pouca informação é compartilhada.

Se o seu time está tentando programar em par, marque conversas um-a-um com algumas pessoas para sentir melhor se eles estão gostando de programar em par. Fale com a liderança para ver se eles sentem os benefícios, principalmente se foi necessário convencê-los. Métricas como a quantidade de defeitos não são muito justas, mas pode ser uma opção, apenas tenha certeza que elas não são os fatores principais para tomada de decisão.