Achei fantástico este novo plugin, chamado Cola, que resolve a adoção da técnica de Pair Programming por times distribuídos. Mesmo se você tem um projeto Open Source e quer aproveitar esta prática, agora você pode, usando esta ferramenta junto com o Skype, por exemplo.
Achei bem interessante também. Programação em pares é a única coisa que já usei dessas metodologias ágeis que tem por aí, e esse eu posso garantir que é bom.
Apesar que normalmente em pares, um programa e o outro vai revisando, aí acaba prestando atenção no que o outro vai fazendo e trocando idéias durante a codificação, porém no vídeo tem dois programadores escrevendo no mesmo código ao mesmo tempo, o que acaba com a revisão que o outro vai fazendo no seu código. Mas daí é só combinar com o outro lado, isso é fácil.
Outra curiosidade que fiquei e não sei se ele disse algo sobre o assunto, é que só assisti sem som, mas e quando há a barra de rolagem, um pode estar digitando em um extremo do arquivo fonte enquanto o outro tenta se achar ou a visão dos dois é sincronizada?
Não é piada não. Apenas achei de mal gosto o comentário do amigo acima e resolvi entrar na brincadeira…
O pair programming distribuído já é realidade hoje e tem se provado bem eficaz. Na IBM, onde trabalho, existem vários times com desenvolvedores espalhados por Brasil, EUA, Índia que usam esta técnica.
Se você parar prá pensar, hoje em times grandes já se faz code review pelo telefone, usando netmeeting, por exemplo. Mas achar um bug no code review é infinitamente pior do que achar o mesmo bug na hora da codificação. Esse é um dos pontos chaves do pair programming. Fazer o mesmo usando Skype e Cola, por exemplo, pode não ser o ideal, mas eu não tenho dúvidas que é melhor que codificar sozinho.
Existem várias coisas na metodologia Agile que eu torcia o nariz, mas somente quando você começa a experimentar você vê o real valor. Outro exemplo é o Planning Poker. Parece uma coisa ridícula, mas que se prova extremamente eficaz. É engraçado porque uma coisa normalmente chata, que é dar estimativas de complexidade de desenvolvimento, passa a ser algo divertido.
Prá mim, piada é o criticar sem nenhuma experiência no assunto
Bem, no meu caso não foi não.
Deveria ter sido?[/quote]
Nao mesmo. Acho ate interessante a ideia de parear assim caso nao possa estar presente no escritorio hoje e amana.
Mas para equipes permanentemente distribuidas acredito que usar pair programming entre elas seja solucao pra nada, beira o ridiculo. Mais uma desculpa para priorizar processos e ferramentas ao inves de pessoas.
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?
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:
:arrow: 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;
:arrow: 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.
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.
Se você instalar, dá um feedback aqui nessa thread prá gente saber se funcionou, OK?
Abraços![/quote]
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.
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?
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?
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.
[quote=fcoury]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)[/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.
Ja que eh assim, fica a seu criterio apontar um projeto closed source com a amplitude do kernel do Linux para nossa avaliacao.