Pair programming, vamos aprender juntos?
Em uma simples definição, pair programming são duas pessoas trabalhando juntas no mesmo código, de uma única estação de trabalho compartilhando idéias e soluções. De acordo com Martin Fowler, “Pair Programming é sobre melhorar o design e minimizar os erros”[1].
Quando duas pessoas trabalham em conjunto ganhamos em qualidade de código, pois a programação em voz alta leva a articulação mais clara das complexidades e detalhes ocultos na codificação. Já quando o quesito é transferência de conhecimentos, a programação em par é uma poderosa ferramenta para que um desenvolvedor júnior adquira técnicas ou habilidades mais amplas de membros da equipe mais experientes.
Mas para o CIO e gerente de sua empresa essa prática pode ser um desperdício. Como provar que duas pessoas trabalhando em uma mesma atividade vão produzir mais do que se cada um trabalhar em atividades separadas, sendo que o júnior pode diminuir a velocidade de um especialista ou sênior? De acordo com o economista Laurie Williams da universidade de Utah na cidade de Salt Lake, pessoas pareando são apenas 15% mais lentas do que duas pessoas trabalhando individualmente, porém produzem 15% menos bugs[2]. A IBM reportou gastos de aproximadamente $250 milhões corrigindo e refazendo correções para 30.000 problemas relatados por clientes [3]. Isto é quase $8.000 por cada problema.
Eu acredito na filosofia que duas pessoas pensam melhor que uma. Com o pair programming, podemos detectar os erros mais cedo e os problemas podem ser resolvidos de uma melhor forma, pois enquanto o “driver” está pensando no código o “navigator” foca na qualidade e em pontos em que o par pode esquecer.
Além de aplicar pair programming para se desenvolver software, descobrimos que essa técnica já é utilizada em outras áreas:
A seguir eu pontuo algumas recomendações no pair programming que fizeram sentido para mim na minha experiência como desenvolvedora,
evite:
Parar para conversar com outras pessoas;
Se estiver no comando esquecer do pair (vice-versa);
Discussões improdutivas;
Deixe de fora o Ego;
Mexer no celular;
faça:
Intercalar momentos de concentração e descontração.
Celebrar as conquistas;
Esteja disposto a aprender e a ensinar;
Silencie notificações (celular, smartwatch, computador, …)
Troque feedbacks;
Planeje as atividades, conversem antes de começar a colocar a mão na massa;
pergunte:
Você acha que isso é correto?
Você acredita que este é um teste válido?
Você tem alguma ideia melhor?
E agora?
fale:
Confie em mim.
Sugira melhores nomes para variáveis e classes.
Dê sugestões em relação a tecnologia.
Dê Feedbacks.
Na bionexo usamos o pair programming para resolver problemas que entendemos ser de alta complexidade técnica ou em novas histórias, onde nenhum dos integrantes tem total conhecimento do fluxo. Nesses casos, juntamos as forças para aprender e compartilhar os conhecimentos.
Quando um integrante está com dificuldade de realizar uma atividade, envolvemos uma pessoa que tenha mais experiência para que naquele momento o pair programming faça parte do aprendizado, assim contribuindo para a entrega da atividade e o crescimento do profissional.
Claro que muitas vezes estávamos fazendo pair programming por fazer, mas como assim, por fazer? O que eu quero dizer é que tem momentos que a atividade exige ajustes pequenos, aí seria o momento de “splitar”, mas cada dia é uma oportunidade de aprendizado e é assim que enxergamos na bionexo, nós erramos mas aprendemos com os erros.
Espero que esse conteúdo possa contribuir no dia a dia do seu time melhorando o pair programming ou até iniciando essa prática.
[1] https://martinfowler.com/bliki/PairProgrammingMisconceptions.html
[2] Williams, Laurie, A Collaborative Software Process PhD Dissertation, University of Utah, 2000.
[3] “A Discipline for software Engineering”, 1995, Humphrey, W.S.
