Vira e mexe recebo um e-mail de alguém que experimentou fazer Programação em par e saiu frustrado ou acha que não está fazendo da melhor forma. Obviamente, não existe solução mágica para o problema e sempre é bom ter o contexto da equipe e do projeto para dar sugestões. Por isso deixo aqui sugestões que já ajudaram vários times por onde passei (mas que estão longe de ser receitas de bolo!).
O último e-mail que eu recebi sobre o assunto veio do Ayrton Araújo da FPF Tech e aproveitei para transformá-lo num post aqui no blog da K21!
Cuidado com o trabalho braçal!
Tendo contato com vários times uma coisa que se percebe é que praticamente todos têm alguns tipos de tarefas que são “braçais” demais para se fazer em dupla, exemplo:
– Queries SQL Ad-hoc para um usuário que pediu um dado em planilha, gráficos etc. (e que não são complexas de serem feitas)
– Instalação de máquinas ou deploy de uma nova release
– [Introduza aqui o trabalho braçal que você desejar :P]
Sempre é legal mapear com o time (olha a retrospectiva aí gente!!!) quais são esses tipos de tarefas para não interferir muito no pareamento como um todo. É comum ver as pessoas falarem “Parear é chato” quando estão nesse tipo de tarefa braçal.
Então, para esses casos, já fica a dica antes de qualquer coisa: Programação em par não precisa ser dogma religioso, use quando e para o que ela for produtiva!
Algumas técnicas que costumam funcionar bem
- Técnica de pomodoro: boa para aplicar durante o trabalho em par, tem vários Apps legais para celular que ajudam a marcar o tempo. Gosto bastante dos ciclos de 25 minutos que o Pomodoro sugere pois dá um bom tempo de trabalho e obriga uns minutos de descanso (café, água, banheiro, e-mail pessoal etc.)
- Dois teclados e dois mouses por dupla (se possível até dois monitores): Como a pessoa que está no teclado “manda” mais, o fato de termos dois teclados ajuda a inibir isso.
- Comece com uma tarefa bem definida antes de se sentar: A tarefa deve ser algo que ambos julgam já ter entendido o que deve ser feito. Muitos pares gostam de discutir no quadro branco ou em um papel o que vão fazer antes de começar a trabalhar.
- Começa no teclado quem conhece menos do assunto: isso garante que o novato fique motivado e por dentro do que está sendo feito.
- Regra da balinha: se um dos dois pegar uma balinha pra chupar o outro também pega, pois, sabe como é… trabalhando perto às vezes o hálito atrapalha.
- Reduza o tempo de revezamento: muitos não gostam do “engessamento de tempo” do Pomodoro e preferem experimentar revezar piloto e co-piloto em outros períodos de tempo por achar que o tempo sugerido pela técnica é muito curto. O perigo está aí! Acontece muito de times resolverem definir que uma dupla trabalhará por X dias em uma tarefa, mas ninguém se preocupa com o revezamento entre os dois. Qual a tendência? Tempos longos de revezamento, onde o “dominante” da dupla fica trabalhando enquanto o “menos dominante” fica de fora mexendo no celular, sai para uma água, fica com sono etc.
Qual o intervalo ideal? Experimente e deixe a retrospectiva de time dizer qual foi o melhor. É sempre bom lembrar que não existe um tempo-padrão-ideal porque depende muito do contexto, projeto etc. - Co-piloto é quem manda: quem está no teclado não pode digitar nada se o “co-piloto” não disser para fazer ou concordar.
Exercitando a programação em par durante um Dojo
Para ajudar nesse último item, é legal fazer Coding DOJOs com o seu time, onde o Pair-Programming vai acontecer e você vai ver na prática como as pessoas estão pareando e pode ajudá-las a se comunicarem melhor. Siga o modelo que fazemos no treinamento de testes automatizados aqui da K21 (veja a imagem abaixo), afaste fisicamente ao máximo quem está no teclado de quem está co-pilotando. Isso fará que eles tenham que falar alto para se comunicar. Todos ouvem e ficam engajados no problema!
Ah… e se você nunca fez, faça DOJOs com o seu time! É incrível como os Dojos bem facilitados e respeitando as regras são produtivos! Você verá a qualidade do trabalho em par no time melhorar consideravelmente!
Experimentação e Melhoria Contínua
Também aprendemos muito visitando outros times e vivenciando um pouco o trabalho deles. Num ambiente de experimentação e melhoria contínua, quase sempre há uma prática ou ideia diferente.
Curtiu? Conhece ou usa outras técnicas? Compartilhe seu comentário e experiência com a gente aqui no Blog.
