3 Coisas Boas e Ruins Sobre Programar em Par

Programar em par é uma prática muito contraditória e que sempre gera discussões de amor e ódio. É difícil construir argumentos pois, assim como quase tudo em Engenharia de Software, é impossível reconstruir o mesmo cenário. Por exemplo, não dá pra comparar uma estória feita por uma pessoa e por um par e dizer qual foi melhor.

Mas, depois de alguns anos num ritmo de pareamento quase 100% do tempo, eu consegui observar alguns pontos que se repetem, tanto positivos quanto negativos.

O que funciona bem

Melhora no Foco

A qualidade do código geralmente é o tópico mais falado quando se fala sobre as vantagens de programar em par, mas eu acho que vai muito além disso. Geralmente o foco de um par é maior e isso se reflete também na comunicação com outras pessoas, seja por email ou em reuniões. E isso fica mais evidente ainda quando o par precisa se comunicar em outra língua. Fica mais fácil ir para uma reunião sabendo que tem outra pessoa para conversar depois e ter certeza de que você entendeu o que precisa ser feito.

Ter outra pessoa do seu lado, esperando por você, dificulta parar para “ler emails”. Mas ter uma pessoa do seu lado também ajuda a trocar ideias e geralmente simplifica a solução. Várias vezes eu estava pareando (com pessoas menos e mais experientes que eu) e a solução final ficou bem mais simples do que o que eu pensava. É cansativo parear, mas, achando o ritmo certo, os benefícios são bons.

Menos defeitos

Sempre que eu precisei trabalhar sozinho eu gastava uma boa parte do tempo pedindo ajuda para revisar o código e ver se eu não tinha feito nenhuma besteira. E algumas vezes eu fiz besteiras grandes – ou seja em produção – por estar só e não ter ninguém pra me lembrar de fazer aquela pequena mudança.

Dificilmente problemas como esquecer um break point ou uma mensagem de log passam desapercebidos por um par. Falhas na captura de requisitos ou em casos inesperados são encontradas mais facilmente, pois pessoas diferentes tem um maior conhecimento em partes diferentes do sistema.

Continuidade de Contexto

Um problema bem comum é quando alguém que tem muito contexto em uma parte específica do sistema sai de férias, está doente ou sai do projeto. Em alguns casos a empresa tenta “prender” a pessoa pois sabe que se ela sair ninguém mais consegue dar manutenção no sistema.

Quando a equipe programa em par isso dificilmente acontece, pois a pessoa está o tempo todo passando contexto para o seu par. Assim, mesmo que ela tenha muito mais contexto que os outros, geralmente uma ou duas pessoas tem mais contexto que a maioria e conseguem descobrir o que fazer, mesmo que demore um pouco mais. Esse ponto por si já é convincente o suficiente para que uma equipe adote programação em par.

Os desafios de programar em par

Infraestrutura

Pra mim este é o problema mais óbvio com programação em par. OS, teclado, editor de texto e outros similares são os tópicos que mais geram discussões entre desenvolvedores. O que eu vi que melhor resolve esse problema é ter uma estação de trabalho comum a todos, assim cada um continua com suas próprias configurações em seus laptops. Assim o time concorda com um conjunto de ferramentas e configurações sem abrir mão das suas pessoais.

Claro que essa solução possui um custo elevado, mas outras ferramentas podem facilitar o compartilhamento do código e diminuir a dor, como por exemplo criar máquinas virtuais para desenvolvimento. Assim as aplicações e versões serão as mesmas para todos, mas cada um pode editar o código da maneira que preferir.

Fadiga

A melhora no foco do par vem com um preço, as vezes bem alto. É comum ouvir pessoas dizendo que ficam exaustas depois de parear, e infelizmente não existe muito o que fazer sobre isso, a não ser não parear. Entretanto, algo que se pode tentar é estabelecer horários para sessões de pareamento, assim cada um continua com um tempo solitário para descansar um pouco.

Outra alternativa é fazer paradas durante o dia, como sugerido pelo Pomodoro, ou estabelecendo metas e descansando entre elas. Muitas pessoas simplesmente não abrem mão de trabalhar só, então para esses casos é melhor não utilizar programação em par e tentar ganhar seus benefícios de outra forma.

Ego

Esse é ponto bem polêmico. Quando se está pareando é muito importante se manter humilde e aberto para escutar as opiniões do seu par. Muitas vezes eu já vi um par que estava discutindo sobre a solução, ao invés de conversar e apresentar argumentos. Algumas vezes chega ao ponto de que parear fica tão chato que ninguém mais quer fazer.

Essa situação é bem complicada e as vezes é melhor aceitar que é difícil parear, seja com uma pessoa específica ou com a equipe em geral, e procurar outras maneiras de colher os benefícios citados acima.

Vale a pena ou não?

No final tudo depende. O melhor é ter uma conversa com a equipe e chegar a uma conclusão juntos. Com certeza os benefícios são muito bons, mas também é preciso ficar de olho no sentimento geral da equipe para evitar que os problemas sejam maiores que os benefícios.

As melhores sessões de pareamento que já fiz a solução final foi algo que eu não conseguiria fazer, mas que ainda assim sentia que era meu código.

Em breve vou publicar outro texto com uma atividade que fiz com a equipe para discutir maneiras de melhorar o pareamento. Mas essa atividade também pode ser feita para iniciar uma discussão sobre se a equipe quer tentar ou não começar a parear.

Anúncios

2 comentários sobre “3 Coisas Boas e Ruins Sobre Programar em Par

  1. Mandou bem sobre o assunto. Parabéns.

  2. Oi Marcos, legal a materia.
    Tem um erro bobo, “estória” -> História.
    Valeu!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s