[Rio-pm] Pair Programming

Cleysinho cleysinhonv em gmail.com
Terça Março 13 13:00:23 PDT 2012


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


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