[Rio-pm] Pair Programming

Cleysinho cleysinhonv em gmail.com
Terça Março 13 13:55:52 PDT 2012


Pelo simples fato de uma metodologia ágil não ser um processo de
desenvolvimento de software. Pelo fato de não gerar os artefatos
necessários.

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

> 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
>
> _______________________________________________
> 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/8ebfe61b/attachment-0001.html>


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