Arquivo Discussoes de Programacao e Tecnologia 
Já li algumas literaturas que sugerem ter dois micros, outras não deixam claro se é um micro só…
O que a experiência de vocês mostra, ficam 2 pessoas no mesmo micro ou 2 pessoas e 2 micros lado a lado, uma codificando e a outra ajudando de outra maneira?
Cara, já programei 2 pessoas com 2 micros (caso 1) e 2 pessoas com 1 micro (caso 2).
No caso 1, funcionou quando estávamos trabalhando com o mesmo objetivo, o que não ocorre sempre.
No caso 2, ficar olhando é chato, você fica querendo que a pessoa faça o que você pensa e o inverso também é chato, ficar uma cara sapeando o que você faz sem entender seu raciocínio. Aí vc tem que ficar explicando. Em alguns momentos é bom mas fazer disso uma metodologia de trabalho é ficar inventando moda e perdendo produtividade.
Pair programming tem alguns objetivos. Na ordem do que eu considero mais importante pro nao tao essencial:
Com esses objetivos em mente, nao faz o menor sentido ter dois computadores. Na ThoughtWorks, pair programming significa usar um computador soh. Sempre.
Ao contrario do que o Marcio sugeriu, o “ficar olhando” e a explicacao constante do que vc esta fazendo sao essenciais pra pair programming funcionar direito - o que eh bem diferente de “inventar moda” ou “perder produtividade”.
Alias, Marcio, de onde vc tirou essa?
Eu também só fiz pair programming com 1 micro, e não tenho reclamações.
Nunca ouvi falar de “pair programming com 2 micros”. Se bobear os caras acabam se falando via MSN ou outra solução de instant messaging (ou pior, via email mesmo!), mesmo sentados um ao lado do outro.
A expressão “Pair programming” deveria vir com ênfase na palavra “pair” e não na palavra “programming”.
Que literaturas são essas? Agora fiquei curioso…
Também nunca ouvi falar.
Outro dia vi um par trabalhando com dois mouses,
Isso é comum?
Nunca ouvi falar de “pair programming com 2 micros”. Se bobear os caras acabam se falando via MSN ou outra solução de instant messaging (ou pior, via email mesmo!), mesmo sentados um ao lado do outro.
A expressão “Pair programming” deveria vir com ênfase na palavra “pair” e não na palavra “programming”.
Nunca ouvi falar de “pair programming com 2 micros”. Se bobear os caras acabam se falando via MSN ou outra solução de instant messaging (ou pior, via email mesmo!), mesmo sentados um ao lado do outro.
A expressão “Pair programming” deveria vir com ênfase na palavra “pair” e não na palavra “programming”.
Eu já vi em algum lugar um plugin (japonês, eu acho) do Eclipse que permite que duas pessoas em micros diferentes editem o mesmo código. Talvez seja disso que estejam falando.
Já li algumas literaturas que sugerem ter dois micros, outras não deixam claro se é um micro só…
Que literaturas são essas? Agora fiquei curioso…
Nesse documento que o autor explica como ele trabalha com SCRUM (Scrum and XP from the Trenches), ele menciona que o pair programming que ele utiliza é com dois micros lado a lado, um edita o código e outro acessa a documentação, faz alguma outra coisa para auxiliar o trabalho.
Já li algumas literaturas que sugerem ter dois micros, outras não deixam claro se é um micro só…
Que literaturas são essas? Agora fiquei curioso…
Nesse documento que o autor explica como ele trabalha com SCRUM (Scrum and XP from the Trenches), ele menciona que o pair programming que ele utiliza é com dois micros lado a lado, um edita o código e outro acessa a documentação, faz alguma outra coisa para auxiliar o trabalho.
Ia citar esse caso, já trabalhei com 2 micros em pair programming, onde um micro estava a IDE e no outro era usado para os testes e pesquisas.
Pair programming tem alguns objetivos. Na ordem do que eu considero mais importante pro nao tao essencial:
- Disseminacao de conhecimentos sobre o sistema
- Disseminacao de conhecimentos sobre a plataforma
- Facilitar a idealizacao e implementacao de novos conceitos
- Revisao de codigo
Com esses objetivos em mente, nao faz o menor sentido ter dois computadores. Na ThoughtWorks, pair programming significa usar um computador soh. Sempre.
Ao contrario do que o Marcio sugeriu, o “ficar olhando” e a explicacao constante do que vc esta fazendo sao essenciais pra pair programming funcionar direito - o que eh bem diferente de “inventar moda” ou “perder produtividade”.
Alias, Marcio, de onde vc tirou essa?
Esse é o pior Facilitar a idealizacao e implementacao de novos conceitos… hehe, lasquera
Ainda mais quando quem esta no pc é antigo na empresa e se acha, ele nunca vai aceitar ser corrigido :?
Faz umas porcarias que limita o desenvolvimento e fica envolvendo todas camadas para uma coisa simples.
Acho esse o ruim de 2 para 1, foi meu problema
Retirado do documento que mencionei acima, fica na página 91 e 92 do PDF:
Eu nunca fiz PP assim, só com um micro, mas fiquei curioso para saber se dá certo…
Pair programming tem alguns objetivos. Na ordem do que eu considero mais importante pro nao tao essencial:
- Disseminacao de conhecimentos sobre o sistema
- Disseminacao de conhecimentos sobre a plataforma
- Facilitar a idealizacao e implementacao de novos conceitos
- Revisao de codigo
Com esses objetivos em mente, nao faz o menor sentido ter dois computadores. Na ThoughtWorks, pair programming significa usar um computador soh. Sempre.
Ao contrario do que o Marcio sugeriu, o “ficar olhando” e a explicacao constante do que vc esta fazendo sao essenciais pra pair programming funcionar direito - o que eh bem diferente de “inventar moda” ou “perder produtividade”.
Alias, Marcio, de onde vc tirou essa?
Me refiro quando isso tende a virar rotina, já vi alguns malucos com essas idéias. Acho que fui um pouco exagerado mesmo.
Aqui fazemos 2 pessoas com um micro só.
Já notamos que é muito bom quando estamos criando conceitos novos, mas é muito pouco produtivo e com ganho de qualidade automamente questionável nas partes braçais do software (montar interface gráfica, por exemplo).
seila eu não iria gostar de um cara bisbilhotando meu codigo e mto menos ficar olhando o cara programar ja fiz “Pair Programing” mas com um cobolzeiro… eu com java e ele com cobol a aplicação era java e cobol…
qdo ele tinha que debugar eu tinha q ficar olhando pois não podia mexer em nada… e pra mim sequer executar a aplicação ele não podia debuggar… eu precisava testar e nao podia pq ele tava testando e vice versa…
isso era muito ruim pq fodia com a produtividade… eu nao tinha como ajudalo pq não manjo de cobol e ele não manja de java pra me ajudar dai a produtividade caia muito pois trabalhavamos em singlethread e nao em multithread…
A idéia é justamente não existir isso de “meu código”.
Eu nunca fiz PP assim, só com um micro, mas fiquei curioso para saber se dá certo…
Quando trabalhei na montagem de um framework para um grande banco, houve um PP com dois micros… alias, foi a unica experiencia que eu tive com PP (com 1 ou 2 maquinas)…
Foi bem legal, já que um fazia o framework propriamente dito e o outro construia os testes e ajustava o RSA pra receber o design das aplicações no futuro. Ficou bem feito pela equipe ser toda senior…
Acho que PP com um desenvolvedor e um analista dando pitáco no seu código é ruim… e se for dois desenvolvedores em uma maquina fica algo massante demais…
Aqui adotamos um PP meio diferenciado. Cada equipe é composta de 4 a 6 pessoas no maximo e 1 “coach”, que fica fazendo as vias dos outros 4 desenvolvedores que deveriam existir no PP normal… Esse coach não recebe “tarefa”… seu trabalho é justamente fazer PP com os outros… dá certo! Se a equipe precisar ser maior, aumentamos o numero de “coaches”…
Retirado do documento que mencionei acima, fica na página 91 e 92 do PDF:Eu nunca fiz PP assim, só com um micro, mas fiquei curioso para saber se dá certo…
Quando estou trabalhando em dupla (um computador) e por algum motivo a gente trava, normalmente fazemos uma pausa para cada um fazer sua pesquisa e depois de alguns minutos nos juntamos novamente para resolver o problema. Não considero essa pausa como PP, visto que não estamos no mesmo computador. Por outro lado, continuamos trabalhando em cima do mesmo problema, então entendo se continuarem chamando de PP neste caso…
Fico pensando no custo dissoEm PP,
Inicia-se um debate sobre a melhor solução entre soluções,
Horas depois não chegam a um veredicto, nada foi feito…
?
Se os desenvolvedores forem razoavelmente bons, eles sempre partirão da solução mais simples e que funcione, e usarão o próprio código/testes para evoluir esta solução incrementalmente. Por isso que PP não é pra qualquer um 
O código não é seu, um dia você vai sair da empresa e o código vai ficar, e outra pessoa vai cuidar dele.
[modo brincadeira]
E aliás, por que você não quer um “cara bisbilhotando meu codigo”? Não entendi… será que você está escondendo muitas gambis por aí? 
[/modo brincadeira]
Pessoal, com 2 computadores pode ser qualquer coisa menos pair programming. Consultem fontes mais confiáveis.
Seguem algumas:
http://www.extremeprogramming.org/rules/pair.html
http://en.wikipedia.org/wiki/Pair_programming
http://c2.com/cgi/wiki?PairProgramming
Todas elas falam em apenas 1 computador ou 1 teclado as que querem ser mais claras
E se o coach de uma equipe dessas eh atropelado por um caminhao?
…
E se o coach de uma equipe dessas eh atropelado por um caminhao?
Até!
Me desculpem a ignorância, mas eu preciso perguntar porque sou novo na área:
pair programming é a mesma coisa que extreme programming?
Pair programming é uma prática do extreme programming
Me desculpem a ignorância, mas eu preciso perguntar porque sou novo na área:pair programming é a mesma coisa que extreme programming?
Até!
Fico pensando no custo disso
Em PP,
Inicia-se um debate sobre a melhor solução entre soluções,
Horas depois não chegam a um veredicto, nada foi feito…
?