[Rio-pm] Pair Programming

Terça Março 13 14:33:53 PDT 2012

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