<p>Programming motherf*cker the best way. Mas nem tudo é bitolar em programação, talvez separar um tempo do sprint - 10% - seja bom pra equipe equivaler as experiencias.</p>
<p>Já trabalhei em equipe que o objetivo era que todos conhecessem os detalhes e em equipes que você é tratado como intruso caso queira saber os detalhes. Aí entra a cultura da empresa.</p>
<p>IMHO, pair programming tem muito valor em coach, mas nem tanto em velocidade de entrega quanto a custo/beneficio. Afinal, manter 2+ profissionais no mesmo problema não é barato. </p>
<p>Pair programming pra fazer um CRUD é digno de se estranhar, mas para implementar algo mais sensível talvez sej de se pensar.</p>
<p>Mas isso é minha experiência limitada</p>
<div class="gmail_quote">On Mar 12, 2012 12:57 PM,  <<a href="mailto:ulisses@ibiz.com.br" target="_blank">ulisses@ibiz.com.br</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

concordo com o autor que pode ser pouco produtivo;<br>
<br>
se vc tem que conversar - no on-going - mais que 3 mins com o seu pair, esqueça esse pair.<br>
tem alguém atrasando alguém aí nessa conversa.<br>
<br>
obviamente que conversas iniciais de desenho e diretrizes demoram mais do que isso, mas no on-going,<br>
se a equipe é homogênea, muitas conversas longas é sinal de algo errado, seja por distração pura e simples ou incompetência/ineficiência em algum canto.<br>
<br>
-----Mensagem Original----- From: breno<br>
Sent: Sunday, March 11, 2012 3:33 AM<br>
To: <a href="mailto:dojo-rio@googlegroups.com" target="_blank">dojo-rio@googlegroups.com</a> ; Perl Mongers Rio de Janeiro<br>
Subject: [Rio-pm] Pair Programming<br>
<br>
Pessoal,<br>
<br>
li recentemente um artigo muito interessante chamado "Pair Programming<br>
Considered Harmful?"<br>
<br>
<a href="http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/" target="_blank">http://techcrunch.com/2012/03/<u></u>03/pair-programming-<u></u>considered-harmful/</a><br>
<br>
O artigo apresenta pesquisas que sugerem que as pessoas são mais<br>
criativas quando desfrutam de privacidade e ausência de interrupções.<br>
Ele chega a discutir que grupos de brainstorming costumam ter menos<br>
idéias do que o mesmo número de pessoas trabalhando sozinha e depois<br>
compartilhando idéias. A questão de escritórios sem baia (open-plan)<br>
também é criticada, por ser uma grande fonte de distração e<br>
interrupções.<br>
<br>
Segundo o autor, insistir em 100% pair programming é um dogma<br>
irracional e extremamente contra-produtivo, e que a melhor solução é<br>
uma combinação dinâmica de trabalho isolado, em par e em grupo,<br>
dependendo do contexto e seguindo o bom senso.<br>
<br>
O que vocês acham?<br>
<br>
[]s<br>
<br>
-b<br>
______________________________<u></u>_________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/<u></u>listinfo/rio-pm</a><br>
<br>
<br>
______________________________<u></u>_________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org" target="_blank">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/<u></u>listinfo/rio-pm</a><br>
</blockquote></div>