[Rio-pm] Pair Programming

Terça Março 13 14:28:41 PDT 2012

Entendo louvável solução. Nem sempre as proposta da Engenharia de Software
- EL - são aplicáveis, pela existência de vários tipos de problemas e
soluções. Os requisitos não funcionais também devem ser considerados
sempre, uma vez que em ambiente de desenvolvimento não nos deparamos com as
reais demandas de usabilidade. As configurações de servidores e serviços
podem melhorar muito os aspectos de desempenho.

Em 13 de março de 2012 18:09, Tiago Peczenyj <tiago.peczenyj em gmail.com>escreveu:

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