[Rio-pm] Pair Programming

Terça Março 13 14:09:31 PDT 2012

E que artefato não é gerado?

Perceba que valorizar

Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente

Não significa que documentação, por exemplo, é ignorada. Pelo
contrario, em processo de adoção de metodologias ageis existe sempre o
overhead de manter os artefatos da metodologia antiga sendo produzidos
para provar que alem de funcionar não é uma "bagunça". Vi isso muito
bem claro na globo.com, nossas queries SQL passavam pelo crivo do time
de banco de dados. Cada SQL era analisado para ser "otimizado".
Durante meses tivemos que migrar alguns sistemas e isso era um grande
overhead MESMO usando hibernate configurado com second-level cache (o
time de banco não confiava). O que aconteceu é que em dado momento o
time de banco virou "gargalo" e como o trabalho era feito de uma
forma, digamos, precaria (vc tinha que colocar a query em um .doc do
word, uma por pagina) e em todo o periodo que fizemos isso NUNCA houve
uma query com problema de performance ou seja la o que for isso caiu
em desuso naturalmente.

Ate entendo que anos antes isso era necessario, mas anos antes a
integração dos sistemas era feita pelo banco de dados! E tinham
IMAGENS jpg no banco de dados! Realmente uma query alienígena iria
afetar o site inteiro.

Porém como resolvemos isso: criamos uma API REST para abstrair o
modelo de dados (ao todo foram 3 versões). Todos os sistemas agora
falam com a API e não existe time que encha o saco com cache de api
rest. É claro que existe monitoramento e preocupações com
escalabilidade mas não é com um processo engessado que vc obtem isso.

Um outro exemplo foi o uso de puppet. Hoje os projetos tem a
configuração puppetizada junto do código, assim recriar um ambiente é
tarefa relativamente simples e os times ficam responsáveis por
entender melhor os ambientes e detalhes de produção que antes
desconheciam (e sofriam as consequencias). Antes disso com todo o
processo que existia recriar um ambiente ou recuperar uma maquina era
uma tarefa herculea. Logo eu vi exemplos de artefatos sendo gerados
pela agilidade que por metodos tradicionais não foram gerados.

Mas compreendo que a realidade de alguns projetos é diferente de
outras. Um ERP é diferente de um CMS que é diferente do Kernel Linux.

On Tue, Mar 13, 2012 at 5:55 PM, Cleysinho <cleysinhonv em gmail.com> wrote:
>
> 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
>
>
> _______________________________________________
> 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