Pair programming

Assuntos Gerais Agile
#1

Olá pessoal eu participo do grupo agile-brasil e pintou um tema que eu tenho muitas duvidas quanto a pratica real e gostaria de ter a colaboração de vcs que conhecem esse tema na pratica e assim também contribuir para nossa comunidade aki…

obrigado desde já.
[caso esse topico não seje ideal para o forum, desde já deixo nas mãos dos moderadores para fecha-lo]

[quote]Olá pessoal,

gostaria de saber com o pessoal que implantou o conceito de Pair programming, com sucesso (ou não), como foi feita a implantação do conceito e se houve resistência da equipe com a mudança. No meu caso, imagino que eles irão pensar: “Pô, dividir um computador? Vou ficar sem o meu?” o que vai causar um ruído…

Flavio Steffens de Castro [/quote]

Duas respostas tiradas do grupo.

[quote]Cara, a idéia de programar em par é evitar a ociosidade. Os dois não param de produzir e ficam mais empolgados.
Em alguns lugares se utiliza um programador mais experiente que fica instruindo e o outro vai digitando e aprendendo, além de discutir também. Com o tempo eles tendem a se nivelar melhor e acelerem mais ainda os processos de fabricação de software.
Hélio Bentzen[/quote]

[quote]A programação pareada é, de fato, uma da práticas que provoca mudanças
mais radicais na cultura da equipe. (neste caso sim, radical e não
extremo). :slight_smile:

Primeiro, antes de falar para a equipe formar pares e sair
programando, é importante mostrar os benefícios da prática. No caso
vale destacar a velocidade para chegar a soluções, o aumento no número
de idéias, a motivação para evitar código feio, a revisão do código,
etc, e inclusive os aspectos sociais que esta atividade proporciona.
Para tudo isso, dá para mostrar o valor do trabalho em duplas
comparando com o a programação solo.

Especificamente para a questão que vc apontou (vou perder meu
computador). Perceba que um bom ambiente para programação pareada não
contém apenas n/2 máquinas, onde n é o número de desenvolvedores. Além
das estações de trabalho principais, é legal ter máquinas periféricas
que o pessoal pode usar para tarefas de pesquisa, exploração ou para
atividades pessoais, como ler emails. Quando se faz pair programming
não é proibido ler emails pessoais de vez em quando, mas é bom separar
isso do trabalho. Assim vc deixa o desenvolvedor ter momentos pessoais
mas não os estimula tanto, pq para realizá-los ele precisará
explicitamente parar de trabalhar com o grupo.
Abraços, Dairton
[/quote]

#2

Desculpa a ignorância mas Pair programming não eh a mesma coisa que XP ??

#3

De forma nenhuma. Programação em par está contida no XP, é uma das práticas utilizadas no ambiente de desenvolvimento.

#4

Vivendo e aprendendo :smiley: valew…

#5

A prática tem suas vantagens mas é muito difícil de aplicá-la.Quando temos equipes mistas em termos de conhecimento pode até ser facil e vantajosa para todos.E para as mais experientes?A equipe aceitaria bem isso ?
Seria realmente nescessário ?
Outra pergunta é : alguém já trabalhou ou trabalha em alguma empresa que adote essa prática do xp ?

#6

Eh? Eu tou fazendo coaching agora, e a coisa mais simples de introduzir numa equipe eh pair programming. “De hoje em diante, a gente tem metade dos micros que tinha semana passada. Em compensacao, a gente tem 2 monitores por maquina, agora - e vai todo mundo fazer pair programming ao inves de revisao de codigo offline. Digam pra mim qual o periodo ideal do dia pra gente trocar os pares!”

Nao tem muito misterio, pra falar a verdade.

Se nao aceitar, eh sinal de que existe algum outro problema cultural na empresa ou equipe. Equipes experientes deveriam se aconfortar com metodologias ageis muito mais facilmente, uma vez que tendo experiencia implica-se que elas sabem o que tao fazendo (e leem por ai).

Yeap. A ThoughtWorks foi uma das pioneiras em XP/Agile e eu nao trabalhei nenhum projeto desde que entrei aqui que nao adotasse PP.

#7

Bom, “muitas duvidas” precisam de “muitas respostas”… que tal uma de cada vez? :wink:

#8

Se me lembro bem o Ambler e o próprio Beck falavam que não dava pra trabalhar 100% do tempo em PP pois era estressante para a equipe. Sou meio adepto disso. Nos meus últimos projetos tinha uma carga grande de PP, mas não 100%. Cada um tinha sua máquina. Usava o PP mais para implementar coisas mais complexas (onde realmente ví benefício). Porém, de qualquer forma, a equipe era bem sênior. PP é pura produtividade e foco no problema (sem ficar viajando, lendo mails ou postando no GUJ, he he he).

Aliás, teve um dia que foi engraçado, só para você entender o pair programming. Chamei o Shoes no MSN e ele não respondia… só falava “peraí… peraí… espera…” (quase me mandou calar a boca). E eu fiquei lá… chamando… depois de um tempão… ele escreveu: “- Fala rodrigoy… cara, pair programming é foda…”. :lol:

(caras, faz 4 meses que estou sozinho trabalhando num projeto, sinto muito a falta de uma equipe e de pair programming)

#9

O problema é que pair programming soa como uma prática um tanto “exótica” principalmente em pessoas cujo conhecimento em metodologias de desenvolvimento se resume ao que elas leram na infoexame. Às vezes nem é culpa da equipe.

Quem aqui já não ouviu algo parecido com isso:

Até explicar que focinho de porco não é tomada…

#10

Não seu senior, e trabalho a 2anos, todos as empresas trabalhei nunca tive contato com metodologias.
Mas tenho contato sempre com pessoas experientes que como nosso gerente dinosauro abrem um enorme sorriso para falar que MA não da certo.

mas focando em pair programming gostaria de saber como fazer esse processo de trabalhar em par…
(como no scrum e em tudo que é novo temos que trabalhar a cultural da empresa, certo)

  • como que começa esse processo de sentar em dupla e programar?
  • como explicar ‘…focinho de porco não é tomada…’
#11

Acho dificuldade maior de Pair Programming quanto a questão de máquinas é o fato das pessoas considerarem as máquinas do trabalho como se fossem “suas”. Pelo que eu sei existem ambientes onde o rodízio é feito frequentemente, você troca tanto de máquina que não dá nem pra se apegar a alguma.

Como estamos acostumados a tratar nossa workstation como uma máquina pessoal acho interessante quem tiver dificuldade levar o notebook para as horas vagas.

Outro ponto importante foi sobre a questão do MSN. Estamos muito mau acostumados a conversar em momentos que deveriamos estar trabalhando (estou me incluindo). Pair programming ajuda a mudar um pouco nossos habitos ruins, IMO.

#12

Olá,

Faz certo tempo que não uso Pair Programming em meus projetos, pois tenho usado outras práticas como a inspeção de código da FDD (Feature Driven Development), mas acho a programação em par uma excelente idéia que deve ser estimulada.

Também gosto da abordagem de não usar PP em 100% da carga de trabalho, e sobre isso, já trabalhei dessa maneira no que eu chamo de Pair Solution, ou seja, é usada toda a sistemática que a programação em par oferece, só que voltada para resolução pontual daqueles problemas ?cabeludos?.

Outra variação que tenho estimulado bastante é o Pair Learnning, onde alguma necessidade de aprendizado em projeto (Ex: Requisitos, Modelagem, Novos frameworks, Ferramentas, etc.) é feita usando a dinâmica de pares.

Porém, o que é importante observar, é que mesmo que você não consiga usar totalmente a prática de PP em seus projetos, você pode começar a estimular os membros da equipe com alguma dessas idéias de trabalho em par, dessa forma, gradualmente toda a equipe começará a visualizar as vantagens dessa abordagem, fazendo com que uma possível aplicação total dessa prática seja feita de forma menos traumática.

Mas sobre a implementação de Pair Programming em si, têm um antigo artigo meu publicado na DevMedia, onde relatei algumas dificuldades e vantagens dessa prática, o link é: http://www.devmedia.com.br/articles/viewcomp.asp?comp=1694

Obrigado,

Manoel Pimentel
http://www.visaoagil.com

#13

Obrigado a todos e postaram aqui e que iram postar…

obrigado pelas experiencias compartinhadas.

#14

[quote=ORB_de_Souza]A prática tem suas vantagens mas é muito difícil de aplicá-la.Quando temos equipes mistas em termos de conhecimento pode até ser facil e vantajosa para todos.E para as mais experientes?A equipe aceitaria bem isso ?
Seria realmente nescessário ?
[/quote]

  1. o objetivo de pair programming não é só disseminar o conhecimento tecnológico genérico, mas também e principalmente disseminar o conhecimento do sistema sendo construído. Um desenvolvedor experiente pode conhecer muito a respeito das tecnologias envolvidas no projeto, mas pode saber o mesmo que um estagiário sobre o novo sistema.

  2. Desenvolvedores experientes devem ter seu código revisado. Esse é um outro benefício da pratica.

  3. Mesmo desenvolvedores experientes se distraem de vez em quando. Pair programming garante que o foco no projeto é mantido ao longo do dia, evitando distrações.

  4. Houve quem mencionasse só fazer pair quando houvesse um problema “difícil”. Eu acho que assim a prática perde quase toda sua força, já que a atitude de procurar ajuda quando está com problemas é o comportamento normal esperado de um ser humano racional. Se a equipe não faz pair grande parte do tempo, torna-se essencial a implantação de revisões formais de código.

  5. É verdade que poucas empresas fazem pair programming. Poucas também tem 100% de cobertura de testes, poucas fazem revisão de código, poucas automatizam todos os testes, quase nehuma que eu conheço usa iterações curtas (2 semanas ou menos). A lista de empresas que não adotam as melhores práticas é infindável. Isso invalida a prática? De forma alguma. Ao contrário, ela se torna um diferencial competitivo.

Abraço,
Luiz Esmiralha

#15

Para mim Pair Programming é uma ferramenta e como todas as outras deve ser usado quando houver necessidade. Aplicar cegamente 100% de Pair Programming em tudo não é uma coisa boa.

Já trabalhei com gente que é muito mais produtivo com pair programmin mas játrabalhei com gente que reduz sua produtividade. Hoje, após alguma experiência com PP eu vejo situações no assado em que deveria ter usado mas nunca imporia 100% PP como prática default em uma equipe. Passagem de conhecimento, equipe com gente sem oco, nivelamento, coaching, etc. são bons exemplos mas indiscriminadamente no dia-a-dia é overdose.

#16

para falar a verdade eu imaginava que o correto era 100%, deve ser porque participei poucas vezes da prática…
o mais difícil que eu achava era “sincronizar” o que eu estava pensando com o colega. aí me deram a dica de pensar em voz alta :smiley: no momento me pareceu bem ridículo, mas deu certo :lol:

#17

Bobmoe,

minha impressão é que não há certo ou errado quando estamos falando de práticas em XP. As práticas são contextuais e podem ser aplicadas em maior ou menor grau em determinadas equipes ou projetos.
Nada diz que se deve ou não aplicar Pair Programming 100% exceto a opinião de cada um. A opinião de Kent Beck em seu primeiro livro aconselhava a fazer Pair 100% do tempo em que estivéssemos escrevendo código que vai ser realmente integrado ao sistema. Spikes arquiteturais, provas de conceito e protótipos poderiam ser programados “solo”.

Abraço,
Luiz Esmiralha

#18