[Rio-pm] Pair Programming

Cleysinho cleysinhonv em gmail.com
Terça Março 13 13:48:30 PDT 2012


Por outro lado ainda temos as metologias ágeis. que permite que a equipe
possa interagir dia-a-dia nos problemas que ocorrem no desenvolvimento. Eu
particularmente as aprecio em projetos multidisciplinares onde as regras de
negócio estão nas pessoas envolvidas:
- Biólogos
- Físicos
- Químico
- O gerente do supermercado

Enfim as metodologias ágeis já são aceitas como boas práticas pela
Engenharia de Software, até então não era assim.


2012/3/13 Tiago Peczenyj <tiago.peczenyj em gmail.com>

> Isso por que o modelo em cascata (waterfall) por alguma razão esta
> impregnada na cabeça de boa parte das pessoas. Mesmo sabendo que o modelo é
> um com muitas falhas (onde ja se viu testar apenas quando TUDO foi
> especificado e codificado ?!?! loucos !!) qualquer modelo moderno como RUP
> acaba sendo simplificado como as 4 fases do waterfall e longos ciclos de
> desenvolvimento e correção de bugs com atrasos monstruosos ou fracasso
> total. Sem falar que muito gerente de desenvolvimento só entende de chicote.
>
> Colocar um analista fazendo algo que não seja desenvolvimento é rebaixar
> um programador a um digitador de luxo. Se o cara não tem condições de
> pensar sozinho então deveriam incentivar que o mesmo pense e evolua. Pair
> não é uma ferramenta que vai viabilizar isso e sim a cultura de time, onde
> todos fazem praticamente tudo com responsabilidade e qualidade.
> infelizmente isso é caro.
>
>
> On Tue, Mar 13, 2012 at 5:14 PM, Cleysinho <cleysinhonv em gmail.com> wrote:
>
>> Sim e percebo que nela a arte de programar é pouco valorizada. Os
>> Analistas estão sempre acima dos programadores.
>>
>> Em 13 de março de 2012 17:08, Blabos de Blebe <blabos em gmail.com>escreveu:
>>
>> Certificação é um processo pelo qual garante-se que qualquer macaco
>>> possa executar o trabalho.
>>>
>>> 2012/3/13 Cleysinho <cleysinhonv em gmail.com>:
>>> > 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
>>>
>>
>>
>>
>> --
>> **
>>  .: 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
>>
>
>
>
> --
> 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/4c95ccd1/attachment.html>


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