[Rio-pm] Pair Programming
Tiago Peczenyj
tiago.peczenyj em gmail.com
Terça Março 13 16:26:30 PDT 2012
Minha dica é: pense numa versão 2.0 que possa coexistir com a atual e
vá aos poucos depreciando a primeira. E crie testes para as novidades
e bugfixes.
On Tue, Mar 13, 2012 at 8:24 PM, Marcio Ferreira
<marciodesouzaferreira em gmail.com> wrote:
> 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 em gmail.com> wrote:
>>
>> ++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
>>
>>
>>
>> _______________________________________________
>> 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
Mais detalhes sobre a lista de discussão Rio-pm