pair programming: com um ou dois micros?

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:

- 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?

Eu também só fiz pair programming com 1 micro, e não tenho reclamações.

Moderador Membro desde: 29/07/2004 16:10:13 Mensagens: 17543 Offline

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".

boaglio wrote:
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...

Também nunca ouvi falar.

Outro dia vi um par trabalhando com dois mouses,

Isso é comum?

thingol wrote: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.

Rafael Afonso wrote:

thingol wrote: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.

Mas isso é colaboração remota. O pair programming é justamente o contrário: colaboração lado a lado :)

s4nchez wrote:

boaglio wrote:
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.

boaglio wrote:

s4nchez wrote:

boaglio wrote:
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.

cv wrote: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:

ScrumAndXpFromTheTrenchesonline07-31.pdf wrote:
We started doing this lately in one of our teams. Works quite well actually. Most of our other teams still don?t pair program very much but, having actually tried it in one team for a few sprints now, I?m inspired to try to coach more teams into giving it a shot.

Some conclusions so far about pair programming:

Pair programming does improve code quality.
Pair programming does improve team focus (for example when n the guy behind you says "hey is that stuff really necessary for this
sprint?").
Surprisingly many developers that are strongly against pair programming actually haven?t tried it, and quickly learn to like it
once they do try it.
Pair programming is exhaustive and should not be done all day. Shifting pairs frequently is good.
Pair programming does improve knowledge spread within the group. Surprisingly fast too. Some people just aren?t comfortable with pair programming. Don?t throw out an excellent programmer just because he isn?t comfortable with pair programming.
Code review is an OK alternative to pair programming. The "navigator" (the guy not using the keyboard) should have a
computer of his own as well. Not for development, but for doing little spikes when necessary, browsing documentation when the
"driver" (the guy at the keyboard) gets stuck, etc.
Don?t force pair programming upon people. Encourage people and provide the right tools but let them experiment with it at their
own pace.

Eu nunca fiz PP assim, só com um micro, mas fiquei curioso para saber se dá certo...

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...
?

cv wrote: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.

Notícias, artigos e o maior fórum brasileiro sobre Java