[Rio-pm] Pair Programming

Marcio Ferreira marciodesouzaferreira em gmail.com
Terça Março 13 16:24:06 PDT 2012


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.

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.

Escrever código é fácil, quero ver escrever algo que se mantenha intuitivo
daqui 20 anos
On Mar 13, 2012 6:50 PM, "Stanislaw Pusep" <creaktive at gmail.com> wrote:

> ++Marcio
>
> http://programming-motherfucker.com/
>
> ABS()
>
>
>
> On Tue, Mar 13, 2012 at 18:33, Tiago Peczenyj <tiago.peczenyj at gmail.com>wrote:
>
>> As metodologias "by de book" são realmente bem diferentes, mas a
>> adoção de "agile" sempre tem histórias da adoção de boas praticas em
>> adendo ao que se fazia até o momento critico onde os problemas da
>> metodologia antiga apareciam e ficava claro que deveria mudar um ou
>> mais pontos específicos.
>>
>> Se for pensar bem, ser Agil é como vc pensa o desenvolvimento como um
>> todo, pode ser Agil e usar RUP. É como o modelo toyota de produção, vc
>> não precisa de kamban ou poka-yoke para ser Lean. Scrum, por exemplo,
>> traz um conjunto grande de praticas adequadas a resolver problemas,
>> deixar as pessoas trabalharem e responderem rapido a mudanças, e
>> adotar Scrum e utilizar de forma madura demora tempo, mas com certeza
>> começou com um projeto piloto, com pessoas fazendo as coisas até meio
>> escondidas, etc.
>>
>> Agora percebam que praticamente ninguem fala de XP completo hoje em
>> dia, falam de algumas praticas do XP. Metaforas, por exemplo, eu nunca
>> vi na pratica. Mas em algum canto com certeza tem alguem usando XP de
>> raiz (provavelmente nos EUA).
>>
>> On Tue, Mar 13, 2012 at 6:25 PM, Ricardo Filipo
>> <ricardo_filipo at yahoo.com.br> wrote:
>> > Mas Pair Programming pode ser usado com qualquer metodologia, apesar de
>> que
>> > XP me parece mais adequado.
>> > Até mesmo com MPSBR, RUP e tal o PP é bacana em muitos momentos.
>> >
>> > Eu sempre uso a regra (exceto quando não uso ...):
>> > 1 - Documente
>> > 2 - Crie testes
>> > 3 - Desenvolva
>> >
>> > A questão me parece que é aplicar Agile e desenvolvimento orientado por
>> > testes nas casas de software.
>> >
>> > 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.
>> >
>> > 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".
>> >
>> > Em especial eu gosto do clássico do  Robert Nagler:
>> >
>> http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf
>> >
>> > Estou certo?
>> >
>> >
>> > ________________________________
>> > De: Cleysinho <cleysinhonv at gmail.com>
>> > Para: Perl Mongers Rio de Janeiro <rio-pm at pm.org>
>> > Enviadas: Terça-feira, 13 de Março de 2012 16:00
>> >
>> > Assunto: Re: [Rio-pm] Pair Programming
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 2012/3/13 Tiago Peczenyj <tiago.peczenyj at gmail.com>
>> >
>> > On Tue, Mar 13, 2012 at 2:32 PM, <thiagoglauco at ticursos.net> wrote:
>> >
>> > collective code ownership
>> >
>> > Tambem eh interessante pensar nisso... quanto maior a equipe, nao
>> aumenta o
>> > custo de manter o codigo coletivo?
>> >
>> >
>> > 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.
>> >
>> >
>> > Citando Tiago Peczenyj <tiago.peczenyj at gmail.com>:
>> >
>> >
>> > colocação perfeita, forçar 100% de pair programming em qualquer situação
>> > não tem justificativa. Acredito que dependendo do projeto e do time
>> haverá
>> > uma evolução ate encontrar uma taxa adequada, entretanto uma grande
>> > vantagem do pair é que o collective code ownership fica mais facil se as
>> > duplas se revezam com boa frequencia, assim todo mundo participou de
>> tudo,
>> > praticamente. Se vc conseguir obter isso de outra forma que não apenas
>> > pair, melhor.
>> >
>> > On Sun, Mar 11, 2012 at 3:33 AM, breno <oainikusama at gmail.com> wrote:
>> >
>> > Pessoal,
>> >
>> > li recentemente um artigo muito interessante chamado "Pair Programming
>> > Considered Harmful?"
>> >
>> > http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/
>> >
>> > O artigo apresenta pesquisas que sugerem que as pessoas são mais
>> > criativas quando desfrutam de privacidade e ausência de interrupções.
>> > Ele chega a discutir que grupos de brainstorming costumam ter menos
>> > idéias do que o mesmo número de pessoas trabalhando sozinha e depois
>> > compartilhando idéias. A questão de escritórios sem baia (open-plan)
>> > também é criticada, por ser uma grande fonte de distração e
>> > interrupções.
>> >
>> > Segundo o autor, insistir em 100% pair programming é um dogma
>> > irracional e extremamente contra-produtivo, e que a melhor solução é
>> > uma combinação dinâmica de trabalho isolado, em par e em grupo,
>> > dependendo do contexto e seguindo o bom senso.
>> >
>> > O que vocês acham?
>> >
>> > []s
>> >
>> > -b
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> >
>> >
>> >
>> > --
>> > Tiago B. Peczenyj
>> > Linux User #405772
>> >
>> > http://pacman.blog.br
>> >
>> >
>> >
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> >
>> >
>> >
>> > --
>> > Tiago B. Peczenyj
>> > Linux User #405772
>> >
>> > http://pacman.blog.br
>> >
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> >
>> >
>> >
>> > --
>> > .: Inteligência Coletiva :.
>> > 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’. (Pierre Lévy)
>> > www.cleysinho.blogspot.com
>> > www.bioinfopop.ufv.br
>> >
>> >
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>> >
>> >
>> > _______________________________________________
>> > Rio-pm mailing list
>> > Rio-pm at pm.org
>> > http://mail.pm.org/mailman/listinfo/rio-pm
>>
>>
>>
>> --
>> Tiago B. Peczenyj
>> Linux User #405772
>>
>> http://pacman.blog.br
>> _______________________________________________
>> Rio-pm mailing list
>> Rio-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/rio-pm
>>
>
>
> _______________________________________________
> Rio-pm mailing list
> Rio-pm at pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120313/8338a545/attachment.html>


Mais detalhes sobre a lista de discussão Rio-pm