[Rio-pm] Pair Programming

Ricardo Filipo ricardo_filipo em yahoo.com.br
Terça Março 13 14:25:32 PDT 2012


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
>
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120313/51e9373c/attachment-0001.html>


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