[Rio-pm] Pair Programming

Terça Março 13 14:49:55 PDT 2012

++Marcio

http://programming-motherfucker.com/

ABS()

On Tue, Mar 13, 2012 at 18:33, Tiago Peczenyj <tiago.peczenyj em 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 em 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 em gmail.com>
> > Para: Perl Mongers Rio de Janeiro <rio-pm em 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 em gmail.com>
> >
> > On Tue, Mar 13, 2012 at 2:32 PM, <thiagoglauco em 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 em 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 em 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 em 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 em 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 em 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 em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> >
> >
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em 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 em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120313/f173fe63/attachment-0001.html>