[Rio-pm] Pair Programming

Terça Março 13 13:51:01 PDT 2012

Uma metodologia agil utiliza boas praticas da engenharia de software, não
vejo por que A engenharia de software devesse aceitar ou não. Até por que
algumas vezes falamos do aspecto gerencial do projeto. Scrum, por exemplo,
pouco fala de como desenvolver apesar de pregar um processo iterativo. Vc
pode usar as praticas de desenvolvimento do XP se quiser.

On Tue, Mar 13, 2012 at 5:48 PM, Cleysinho <cleysinhonv em gmail.com> wrote:

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