Olá pessoal 👋, sou Axel Berle, e hoje gostaria de compartilhar com vocês um pouco sobre Pair Programming e como foram minhas experiências com essa técnica ao longo de alguns anos de tentativas e erros.

Um pouco de contexto

Estou na indústria de TI há mais de 25 anos como programador e sempre amei essa profissão. Atualmente atuo como treinador e coach Scrum, e ao olhar para trás, vejo que o maior empecilho para o meu crescimento profissional como programador, pasmem, foi o fato de trabalhar como “hired gun”. Essa expressão é geralmente usada no inglês para definir alguém que oferece seus serviços a quem pague mais. Logo mais explicarei como isso afetou meu desenvolvimento profissional.

O meu primeiro contato com algo semelhante ao que vou apresentar hoje foi há alguns anos. Lembro que naquela época eu era um estudante de Informática na Universidade de Koblenz e morava junto do meu irmão que já cursava há quase um ano. Eu estava perdido, tentando resolver um problema (bem básico) no computador e então pedi ajuda ao meu irmão. Em seguida nos sentamos e poucos minutos depois, pum a briga começou. A cada pergunta que eu fazia a meu irmão ele se tornava mais impaciente e irritado. O pior de tudo era que, fazendo isso, eu me sentia burro e o sentimento de humilhação constante tornava as coisas ainda mais difíceis. Após esse episódio eu desejei nunca mais passar por aquilo novamente.

Durante anos, eu estive trabalhando como programador em grandes empresas, que pagavam caro por hora. E sempre me perguntava, “será que Pair Programming faz sentido?”. Imagina só, um computador, um teclado, mas duas pessoas. Duas pessoas que custam caro por hora! Do ponto de vista financeiro, parece não fazer sentido. Imagine contratar dois pedreiros, só que os dois têm que compartilhar a mesma pá. Durante essas experiências, essa possibilidade nunca surgiu, pois em equipes tradicionais o gerente ou team-lead vão te dizer exatamente o que fazer.

Sessão de Programação em Par (Pair Programming)

Em outra experiência, desta vez trabalhando em Franca - São Paulo, em uma das maiores empresas de varejo do Brasil. A empresa tinha começado a sua jornada rumo à agilidade. Comecei a trabalhar em times estáveis onde tínhamos um maior grau de liberdade para nos auto organizar. Fiz uma nova tentativa de Pair Programming: perguntei a um colega (que era especializado em DevOps) se a gente poderia fazer uma tarefa juntos. “Claro!” disse ele! Sentei do lado dele e ele começou… teclando que nem um louco no teclado, resmungando algumas palavras vez ou outra. E enquanto eu fazia perguntas lembrei do episódio que ocorreu com meu irmão. A maioria das perguntas ele ignorava, ou resumia o que estava fazendo, por alto. Para mim, foi uma perda de tempo! Claramente isso não iria funcionar, pensei!

O que é necessário para Isso funcionar?

Comecei a ver o verdadeiro valor do Pair Programming quando comecei a trabalhar com uma abordagem ágil. Hoje em dia, no nosso time Scrum, praticamos Pair Programming e inclusive Mob Programming (uma modalidade onde mais de duas pessoas programam juntos), talvez mais de 50% do tempo!

Sessão de Programação em Grupo (Mob Programming)

1º Tenha um objetivo claro em mente!

O que fazemos diferente se comparado com os episódios narrados acima? Em primeiro lugar, sabemos o porquê de fazer Pair Programming! Buscamos maior qualidade? Queremos menos bugs? Código mais coeso? Melhor entendimento? Mais aprendizagem? No nosso time, Pair Programming é uma prática que garante qualidade e agilidade: qualidade porque acreditamos que soluções criadas em colaboração são melhores. E agilidade porque acreditamos que quanto mais o conhecimento é compartilhado, mais o time inteiro é capaz de se ajudar e colaborar.

2º É preciso ter confiança!

Os especialistas chamam isso de “segurança psicológica”. Pense no seu time atual, os seus colegas confiam uns nos outros? Admitem quando erram, ao invés de buscarem desculpas? Falam quando estão perdidos, ou ficam horas e horas tentando buscar respostas para não precisarem perguntar? Pedem ajuda quando não sabem como fazer algo? Se você respondeu “sim” para alguma dessas perguntas, fazer Pair Programming em times com falta de confiança talvez (ainda) não funcione bem. Pode ser visto como perigoso demais: o medo de se expor e de se sentir humilhado (assim como no episódio com o meu irmão).

3º É preciso ter coragem! Toda jornada começa com o primeiro passo!

O que aprendi ao longo do tempo ensinando tais técnicas em meus treinamentos é que muitos profissionais (inclusive muito experientes) de fato nunca tentaram Pair Programming e as razões são muito similares às minhas: o medo de se expor. Quando se faz isso em um treinamento, as pessoas em geral não sentem esse medo, pois estão colaborando com quem nunca viram antes. Por isso, todos os nossos exercícios de programação são feitos em formato de Pair Programming. Para muitos alunos, essa experiência foi reveladora.