[Rio-pm] Pair Programming

Terça Março 13 13:33:02 PDT 2012

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