Pair programming remoto usando Eclipse

This message was edited 3 times. Last update was at 24/06/2008 15:07:50

Mas para equipes permanentemente distribuídas acredito que usar pair programming entre elas seja solucao pra nada, beira o ridiculo. Mais uma desculpa para priorizar processos e ferramentas ao invés de pessoas.

Eu discordo. Na verdade eu acho que isso depende mais do projeto (e dos próprios programadores e PMs) do que do pair programming ser remoto ou não.

Eu não vejo diferença nesse ponto entre ser remoto ou local. O que eu acredito é que qualquer adoção de ferramentas Agile ou XP só funciona se você tiver um time comprometido com isso. Você pode muito bem combinar de fazer pair programming fisicamente e ficar falando sobre o tempo. A mesma coisa pode acontecer remotamente. Além do mais, pair programming não é tudo ou nada... No meu projeto a gente costuma usar o pair programming, mesmo distribuído, em algumas situações específicas:

Quando existe uma pessoa nova no time, ou inexperiente em uma área. Desta forma, fazer par com alguém com um grande conhecimento funciona como uma grande transferência de conhecimento;

Quando existe alguma parte crítica do sistema para ser desenvolvida, como por exemplo, programação paralela, com uso de threads ou algo que o valha.

Quando se tenta adotar uma nova metodologia, é necessário comprometimento, e na adoção de pair programming para Agile, por exemplo, fica a cargo dos desenvolvedores utilizar ou não Pair Programming. Mas em um time que faz sessões distribuídas de Code Review, como é o caso do projeto que eu trabalho, eu acho melhor fazer Pair Programming e utilizar este tempo do code review para codificar e pegar bugs de forma antecipada, do que fazer uma sessão onde um programador apenas fala e o outro apenas tem que seguir mentalmente tudo o que foi feito. Eu acho que se este programador for parte ativa, no pair programming, alterando o papel de quem fica como driver e quem fica como navigator traz uma série de benefícios.

PRojetos opensource sao completamente diferente pq sao naturalmente distribuidos, qq pair-programming remoto ou nao é uma decisao unica dos programadores envolvidos na atividade. Por isso mesmo desconfio quando falam que pair programming remoto é "realidade" hoje. Como sera que é medido essa adocao pela comunidade?

E aí que eu acho que você está errado: existem projetos naturalmente distribuídos que não são necessariamente Open Source. Eu realmente não vejo como um approach que funciona em Open Source não possa funcionar necessariamente em um closed source.

Meus two cents apenas

Editado porque usei code ao invés de quote

fcoury wrote:duda,

Tudo jóia?

Eu acho que esta aplicação é parte do ECF - Eclipse Communications Framework. O último Release Candidate é o 5, e para fazer o download, use essa URL:

http://www.eclipse.org/ecf/downloads.php

Se você instalar, dá um feedback aqui nessa thread prá gente saber se funcionou, OK?

Abraços!

A versão 1.x do ECF eu já havia testado a algum tempo e não era possível fazer tudo isso tem que no vídeo não... tinha a parte de chat com suporte a vários protocolos mas não dava para compartilhar a edição de um código de um jeito aceitavel. Tinha um recurso de compartilhar arquivo mas era muito limitado... você não via a pessoa digitando...

A dúvida que eu fiquei é se esse Cola é o ECF 2.0. Vamos esperar pra ver =)... se alguém testar e quiser postar aqui tb... essas features de pair-programming ou mesmo para resolver problemas pontuais de outro desenvolvedor são interessantes e muito válidas!

Então pessoal,
Instalei o plugin e fiz alguns testes, funciona super bem, só tem alguns problemas em relação a chat (+1 de usuário no skype) pois pelo que vi ele não dá suporte, demais é show...
A parte de colaboração de código é muito boa.

Sobre o tal Cola, na verdade Cola = Collaborate, os caras abreviaram, pra variar... e o nome do plugin é DocShare, o DocShare suporta Skpye e XMPP/Google Talk. Bom deem uma olhada no site do plugin pra entender melhor, até porque eu instalei e fiz alguns pequenos testes, nada consideravel.

LINK = http://wiki.eclipse.org/DocShare_Plugin

This message was edited 1 time. Last update was at 01/07/2008 09:28:17

Meio bizarro o erro que tive.
A conexão com o GTalk não foi possivel (o que eu não acho estranho pq eu tenho que fazer uma ginástica pra conseguir dar o nó no proxy aqui para conectar).
Com msn conectou, só que somente alguns contatos aparecem e quase nunca consigo mandar msg, bem tosco (bom mas uma vez a rede pode ta barrando).
Outra dúvida que lendo os links que eu não descobri eh como criar um servidor de colaboração. Alguém sabe como o faz?

fcoury wrote:Eu não vejo diferença nesse ponto entre ser remoto ou local.

Entao me diga uma coisa: como se expressa desgosto por algum codigo incrivelmente imbecil e mal testado, como o de muitas ferramentas e bibliotecas opensource patrocinadas pela sua IBM, que nao seja arremessando um teclado em alguem?

Como fazer isso via webcam? Tem a mesma graca?

Na mesma linha de pensamento, como se expressa encorajamento e como se energiza uma equipe de desenvolvimento onde o time nao sai pra almocar junto, ou tomar uma depois do trabalho?

fcoury wrote:O que eu acredito é que qualquer adoção de ferramentas Agile ou XP só funciona se você tiver um time comprometido com isso.

Nao eh soh comprometimento, eh a filosofia. O comprometimento por si so te traz um monte de solucoes, mas nenhuma delas vai a fundo a ponto de tornar a sua organizacao/equipe consciente e capaz pra melhorar a si mesma. E por mais que se discuta isso via Skype, eu nao consigo imaginar um lugar onde as pessoas trabalhem longe uma das outras e ainda assim queiram fazer isso.

fcoury wrote:Além do mais, pair programming não é tudo ou nada... No meu projeto a gente costuma usar o pair programming, mesmo distribuído, em algumas situações específicas:

(lista de situacoes que nao faz o menor sentido excluida do quote)

Erhm, nao. Pair programming nao eh soh um jeito bonitinho e hippie de se fazer code review ou mentoring. Eh um jeito de manter o inconsciente coletivo da equipe no mesmo passo - e nao da pra "desistir" disso so pq vc quer se enfiar ali num canto e refatorar um pedaco do sistema. Eh justamente ao explicar as motivacoes pra refatorar um pedaco do sistema que vc ve onde ta o valor de fazer as coisas em grupo: as prioridades sao decididas pelo grupo, e geralmente sao bem mais afiadas.

fcoury wrote:E aí que eu acho que você está errado: existem projetos naturalmente distribuídos que não são necessariamente Open Source. Eu realmente não vejo como um approach que funciona em Open Source não possa funcionar necessariamente em um closed source.

Ja que eh assim, fica a seu criterio apontar um projeto closed source com a amplitude do kernel do Linux para nossa avaliacao.

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