<p>Alguém falou sobre testes aí no meio da thread - pessoal aqui escreve pra cacete =P -, acho que isso é outro artefato que as vezes é forçado ou pose ser melhorado.</p>
<p>IMHO, teste tem mais q função de retrocompatibilidade do que outra coisa. Hoje estou trabalhando em um legado de quase 10 anos que passou na mão de dezenas de programadores, com diversas filosofias e dogmas e lala diferentes. O fato de não haver testes me desencoraja a refatorar a criança.</p>

<p>Escrever código é fácil, quero ver escrever algo que se mantenha intuitivo daqui 20 anos</p>
<div class="gmail_quote">On Mar 13, 2012 6:50 PM, "Stanislaw Pusep" <<a href="mailto:creaktive@gmail.com" target="_blank">creaktive@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

++Marcio<div><br></div><div><a href="http://programming-motherfucker.com/" target="_blank">http://programming-motherfucker.com/</a><br clear="all"><br>ABS()<br><br>
<br><br><div class="gmail_quote">On Tue, Mar 13, 2012 at 18:33, Tiago Peczenyj <span dir="ltr"><<a href="mailto:tiago.peczenyj@gmail.com" target="_blank">tiago.peczenyj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



As metodologias "by de book" são realmente bem diferentes, mas a<br>
adoção de "agile" sempre tem histórias da adoção de boas praticas em<br>
adendo ao que se fazia até o momento critico onde os problemas da<br>
metodologia antiga apareciam e ficava claro que deveria mudar um ou<br>
mais pontos específicos.<br>
<br>
Se for pensar bem, ser Agil é como vc pensa o desenvolvimento como um<br>
todo, pode ser Agil e usar RUP. É como o modelo toyota de produção, vc<br>
não precisa de kamban ou poka-yoke para ser Lean. Scrum, por exemplo,<br>
traz um conjunto grande de praticas adequadas a resolver problemas,<br>
deixar as pessoas trabalharem e responderem rapido a mudanças, e<br>
adotar Scrum e utilizar de forma madura demora tempo, mas com certeza<br>
começou com um projeto piloto, com pessoas fazendo as coisas até meio<br>
escondidas, etc.<br>
<br>
Agora percebam que praticamente ninguem fala de XP completo hoje em<br>
dia, falam de algumas praticas do XP. Metaforas, por exemplo, eu nunca<br>
vi na pratica. Mas em algum canto com certeza tem alguem usando XP de<br>
raiz (provavelmente nos EUA).<br>
<div><div><br>
On Tue, Mar 13, 2012 at 6:25 PM, Ricardo Filipo<br>
<<a href="mailto:ricardo_filipo@yahoo.com.br" target="_blank">ricardo_filipo@yahoo.com.br</a>> wrote:<br>
> Mas Pair Programming pode ser usado com qualquer metodologia, apesar de que<br>
> XP me parece mais adequado.<br>
> Até mesmo com MPSBR, RUP e tal o PP é bacana em muitos momentos.<br>
><br>
> Eu sempre uso a regra (exceto quando não uso ...):<br>
> 1 - Documente<br>
> 2 - Crie testes<br>
> 3 - Desenvolva<br>
><br>
> A questão me parece que é aplicar Agile e desenvolvimento orientado por<br>
> testes nas casas de software.<br>
><br>
> Quando apliquei o curso no PRODERJ, creio que a experiência mais formal que<br>
> tive disto, o método usado era o RUP. Mudar de RUP pra XP/Agile é duro,<br>
> especialmente para os analistas, mas a experiência mostra que é bem melhor!<br>
> O principal problema do método "em cascata" é que se a comunicação<br>
> "analista<-->cliente" falhar todo o software falha. Com Agile a coisa vai se<br>
> formando durante o processo de desenvolvimento e o cliente pode entender se<br>
> o que pediu originalmente é realmente o que queria.<br>
><br>
> A frase seria: "Se o seu cliente pediu pra desenvolver determinado software,<br>
> entregue imediatamente qualquer coisa. Na medida que o cliente reclamar vc<br>
> vai fazendo o software como ele quer realmente. Aliás, o cliente vai<br>
> reclamar de qualquer forma, mesmo que vc desenvolva o software exatamente<br>
> como vc acha que ele queria que fosse".<br>
><br>
> Em especial eu gosto do clássico do  Robert Nagler:<br>
> <a href="http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf" target="_blank">http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf</a><br>
><br>
> Estou certo?<br>
><br>
><br>
> ________________________________<br>
> De: Cleysinho <<a href="mailto:cleysinhonv@gmail.com" target="_blank">cleysinhonv@gmail.com</a>><br>
> Para: Perl Mongers Rio de Janeiro <<a href="mailto:rio-pm@pm.org" target="_blank">rio-pm@pm.org</a>><br>
> Enviadas: Terça-feira, 13 de Março de 2012 16:00<br>
><br>
> Assunto: Re: [Rio-pm] Pair Programming<br>
><br>
> Entende-se que "Pair Programming" aconteça em empresas que não possuem<br>
> processos de desenvolvimentos de software bem estruturados. Software<br>
> documentado minimiza esforço do programador, caso se entenda que os<br>
> diagramas UML estejam bem projetados e que documentação esteja bem<br>
> elaborada.<br>
><br>
> Estruturar processos de desenvolvimento de software não é simples e mudam a<br>
> cultura organizacional de um ambiente de desenvolvimento. Na Universidade<br>
> Federal de Viçosa-MG (UFV), eles estão buscando a certificação MPSbr, uma<br>
> das coisas que os consultores mencionaram era a racionalização de mão de<br>
> obra por projeto.<br>
><br>
> 2012/3/13 Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com" target="_blank">tiago.peczenyj@gmail.com</a>><br>
><br>
> On Tue, Mar 13, 2012 at 2:32 PM, <<a href="mailto:thiagoglauco@ticursos.net" target="_blank">thiagoglauco@ticursos.net</a>> wrote:<br>
><br>
> collective code ownership<br>
><br>
> Tambem eh interessante pensar nisso... quanto maior a equipe, nao aumenta o<br>
> custo de manter o codigo coletivo?<br>
><br>
><br>
> Quanto maior a equipa maior os custos como um todo. Por isso times pequenos<br>
> podem ser mais eficientes do que times grandes SE forem mais organizados e<br>
> focados.<br>
><br>
><br>
> Citando Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com" target="_blank">tiago.peczenyj@gmail.com</a>>:<br>
><br>
><br>
> 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 href="mailto:oainikusama@gmail.com" target="_blank">oainikusama@gmail.com</a>> wrote:<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/03/pair-programming-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>
> _______________________________________________<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/listinfo/rio-pm</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Tiago B. Peczenyj<br>
> Linux User #405772<br>
><br>
> <a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
><br>
><br>
><br>
> _______________________________________________<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/listinfo/rio-pm</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Tiago B. Peczenyj<br>
> Linux User #405772<br>
><br>
> <a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
><br>
> _______________________________________________<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/listinfo/rio-pm</a><br>
><br>
><br>
><br>
><br>
> --<br>
> .: Inteligência Coletiva :.<br>
> Uma inteligência distribuída por toda parte: tal é o nosso axioma inicial.<br>
> Ninguém sabe tudo, todos sabem alguma coisa, todo o saber está na<br>
> humanidade’. (Pierre Lévy)<br>
> <a href="http://www.cleysinho.blogspot.com" target="_blank">www.cleysinho.blogspot.com</a><br>
> <a href="http://www.bioinfopop.ufv.br" target="_blank">www.bioinfopop.ufv.br</a><br>
><br>
><br>
> _______________________________________________<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/listinfo/rio-pm</a><br>
><br>
><br>
> _______________________________________________<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/listinfo/rio-pm</a><br>
<br>
<br>
<br>
--<br>
Tiago B. Peczenyj<br>
Linux User #405772<br>
<br>
<a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
_______________________________________________<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/listinfo/rio-pm</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<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/listinfo/rio-pm</a><br></blockquote></div>