<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div>Mas Pair Programming pode ser usado com qualquer metodologia, apesar de que XP me parece mais adequado.</div><div>Até mesmo com MPSBR, RUP e tal o PP é bacana em muitos momentos. </div><div><br></div><div>Eu sempre uso a regra (exceto quando não uso ...): </div><div>1 - Documente</div><div>2 - Crie testes</div><div>3 - Desenvolva</div><div><br></div><div>A questão me parece que é aplicar Agile e<span style="font-size: 12pt; "> desenvolvimento orientado por testes </span><span style="font-size: 12pt; ">nas casas de software.</span></div><div><br></div><div>Quando apliquei o curso no PRODERJ, creio que a experiência mais formal que tive disto, o método usado era o RUP. Mudar de RUP pra XP/Agile é duro, especialmente para os analistas, mas a experiência mostra que é bem melhor! O principal problema
do método "em cascata" é que se a comunicação "analista<-->cliente" falhar todo o software falha. Com Agile a coisa vai se formando durante o processo de desenvolvimento e o cliente pode entender se o que pediu originalmente é realmente o que queria.</div><div><br></div><div>A frase seria: "Se o seu cliente pediu pra desenvolver determinado software, entregue imediatamente qualquer coisa. Na medida que o cliente reclamar vc vai fazendo o software como ele quer realmente. Aliás, o cliente vai reclamar de qualquer forma, mesmo que vc desenvolva o software exatamente como vc acha que ele queria que fosse".</div><div><br></div><div>Em especial eu gosto do clássico do Robert Nagler:</div><div><a href="http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf">http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf</a></div><div><br></div><div>Estou
certo?</div><div> </div><div><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1"> <b><span style="font-weight:bold;">De:</span></b> Cleysinho <cleysinhonv@gmail.com><br> <b><span style="font-weight: bold;">Para:</span></b> Perl Mongers Rio de Janeiro <rio-pm@pm.org> <br> <b><span style="font-weight: bold;">Enviadas:</span></b> Terça-feira, 13 de Março de 2012 16:00<br> <b><span style="font-weight: bold;">Assunto:</span></b> Re: [Rio-pm] Pair Programming<br> </font> </div> <br><meta http-equiv="x-dns-prefetch-control" content="off"><div id="yiv2135523594">Entende-se que "Pair Programming" aconteça em empresas que não possuem processos
de desenvolvimentos de software bem estruturados. Software documentado minimiza esforço do programador, caso se entenda que os diagramas UML estejam bem projetados e que documentação esteja bem elaborada. <br>
<br>Estruturar processos de desenvolvimento de software não é simples e mudam a cultura organizacional de um ambiente de desenvolvimento. Na Universidade Federal de Viçosa-MG (UFV), eles estão buscando a certificação MPSbr, uma das coisas que os consultores mencionaram era a racionalização de mão de obra por projeto.<br>
<br><div class="yiv2135523594gmail_quote">2012/3/13 Tiago Peczenyj <span dir="ltr"><<a rel="nofollow" ymailto="mailto:tiago.peczenyj@gmail.com" target="_blank" href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>></span><br><blockquote class="yiv2135523594gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="yiv2135523594im">On Tue, Mar 13, 2012 at 2:32 PM, <span dir="ltr"><<a rel="nofollow" ymailto="mailto:thiagoglauco@ticursos.net" target="_blank" href="mailto:thiagoglauco@ticursos.net">thiagoglauco@ticursos.net</a>></span> wrote:<br></div><div class="yiv2135523594gmail_quote"><div class="yiv2135523594im">
<blockquote class="yiv2135523594gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
collective code ownership<br>
<br>
Tambem eh interessante pensar nisso... quanto maior a equipe, nao aumenta o custo de manter o codigo coletivo?<br></blockquote><div><br></div></div><div>Quanto maior a equipa maior os custos como um todo. Por isso times pequenos podem ser mais eficientes do que times grandes SE forem mais organizados e focados.</div>
<div><div class="yiv2135523594h5">
<div> </div><blockquote class="yiv2135523594gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Citando Tiago Peczenyj <<a rel="nofollow" ymailto="mailto:tiago.peczenyj@gmail.com" target="_blank" href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>>:<div><div><br>
<br>
<blockquote class="yiv2135523594gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
colocação perfeita, forçar 100% de pair programming em qualquer situação<br>
não tem justificativa. Acredito que dependendo do projeto e do time haverá<br>
uma evolução ate encontrar uma taxa adequada, entretanto uma grande<br>
vantagem do pair é que o collective code ownership fica mais facil se as<br>
duplas se revezam com boa frequencia, assim todo mundo participou de tudo,<br>
praticamente. Se vc conseguir obter isso de outra forma que não apenas<br>
pair, melhor.<br>
<br>
On Sun, Mar 11, 2012 at 3:33 AM, breno <<a rel="nofollow" ymailto="mailto:oainikusama@gmail.com" target="_blank" href="mailto:oainikusama@gmail.com">oainikusama@gmail.com</a>> wrote:<br>
<br>
<blockquote class="yiv2135523594gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Pessoal,<br>
<br>
li recentemente um artigo muito interessante chamado "Pair Programming<br>
Considered Harmful?"<br>
<br>
<a rel="nofollow" target="_blank" href="http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/">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 rel="nofollow" ymailto="mailto:Rio-pm@pm.org" target="_blank" href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a rel="nofollow" target="_blank" href="http://mail.pm.org/mailman/listinfo/rio-pm">http://mail.pm.org/mailman/<u></u>listinfo/rio-pm</a><br>
<br>
</blockquote>
<br>
<br>
<br>
--<br>
Tiago B. Peczenyj<br>
Linux User #405772<br>
<br>
<a rel="nofollow" target="_blank" href="http://pacman.blog.br">http://pacman.blog.br</a><br>
<br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
Rio-pm mailing list<br>
<a rel="nofollow" ymailto="mailto:Rio-pm@pm.org" target="_blank" href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a rel="nofollow" target="_blank" href="http://mail.pm.org/mailman/listinfo/rio-pm">http://mail.pm.org/mailman/<u></u>listinfo/rio-pm</a><br>
</div></div></blockquote></div></div></div><div class="yiv2135523594HOEnZb"><div class="yiv2135523594h5"><br><br clear="all"><div><br></div>-- <br>Tiago B. Peczenyj<br>Linux User #405772<br><br><a rel="nofollow" target="_blank" href="http://pacman.blog.br">http://pacman.blog.br</a><br>
</div></div><br>_______________________________________________<br>
Rio-pm mailing list<br>
<a rel="nofollow" ymailto="mailto:Rio-pm@pm.org" target="_blank" href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a rel="nofollow" target="_blank" href="http://mail.pm.org/mailman/listinfo/rio-pm">http://mail.pm.org/mailman/listinfo/rio-pm</a><br></blockquote></div><br><br clear="all"><br>-- <br><div style="line-height:21px;">
<span style="line-height: normal; font-family: arial; "><span style="line-height: 19px; font-family: sans-serif; "><b></b></span></span></div><div style="line-height: 21px; font-family: tahoma, sans-serif; "><div>
<span style="font-size:13px;line-height:21px;"><div><span style="font-size:13px;line-height:21px;">.: Inteligência Coletiva :.</span></div>Uma
inteligência distribuída por toda parte: tal é o nosso axioma inicial.
Ninguém sabe tudo, todos sabem alguma coisa, todo o saber está na
humanidade’. (</span><span style="font-size:13px;line-height:21px;">Pierre Lévy)</span>
</div></div><div><a rel="nofollow" style="font-family: tahoma, sans-serif; " target="_blank" href="http://www.cleysinho.blogspot.com">www.cleysinho.blogspot.com</a><br><a rel="nofollow" target="_blank" href="http://www.bioinfopop.ufv.br">www.bioinfopop.ufv.br</a><br>
<span style="font-family: tahoma, sans-serif; "></span></div><br>
</div><meta http-equiv="x-dns-prefetch-control" content="on"><br>_______________________________________________<br>Rio-pm mailing list<br><a ymailto="mailto:Rio-pm@pm.org" href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br><a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br><br> </div> </div> </blockquote></div> </div></body></html>