[Rio-pm] Pair Programming

Terça Março 13 19:49:26 PDT 2012

Esses problemas existem, um sistema acadêmico de uma Universidade possui o
seu core (matriculador) em cobol até hoje, outras implementações foram
feitas em asp e Delphi. O matriculador funciona tão bem que ainda não o
reescreveram. Esse matriculador foi construído no final da década de 60,
implementado por um ex-padre holandês que se "estacionou" no Brasil.

Eu particularmente gosto dos artefatos do RUP. Nestes casos de sistemas
onde muitas pessoas o desenvolve, a documentação ajudar a indetificar de
forma clara as funcionalidades e se possível gerar uma matriz de
rastreabilidade.

Manutenção em sistemas na minha opnião é um desafio e ter que ler código
como única documentação pode aumentar tempo e custo. Na maioria das vezes
refatorar é a melhor opção.

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

> Minha dica é: pense numa versão 2.0 que possa coexistir com a atual e
> vá aos poucos depreciando a primeira. E crie testes para as novidades
> e bugfixes.
>
> On Tue, Mar 13, 2012 at 8:24 PM, Marcio Ferreira
> <marciodesouzaferreira em gmail.com> wrote:
> > Alguém falou sobre testes aí no meio da thread - pessoal aqui escreve pra
> > cacete =P -, acho que isso é outro artefato que as vezes é forçado ou
> pose
> > ser melhorado.
> >
> > IMHO, teste tem mais q função de retrocompatibilidade do que outra coisa.
> > Hoje estou trabalhando em um legado de quase 10 anos que passou na mão de
> > dezenas de programadores, com diversas filosofias e dogmas e lala
> > diferentes. O fato de não haver testes me desencoraja a refatorar a
> criança.
> >
> > Escrever código é fácil, quero ver escrever algo que se mantenha
> intuitivo
> > daqui 20 anos
> >
> > On Mar 13, 2012 6:50 PM, "Stanislaw Pusep" <creaktive em gmail.com> wrote:
> >>
> >> ++Marcio
> >>
> >> http://programming-motherfucker.com/
> >>
> >> ABS()
> >>
> >>
> >>
> >> On Tue, Mar 13, 2012 at 18:33, Tiago Peczenyj <tiago.peczenyj em gmail.com
> >
> >> wrote:
> >>>
> >>> As metodologias "by de book" são realmente bem diferentes, mas a
> >>> adoção de "agile" sempre tem histórias da adoção de boas praticas em
> >>> adendo ao que se fazia até o momento critico onde os problemas da
> >>> metodologia antiga apareciam e ficava claro que deveria mudar um ou
> >>> mais pontos específicos.
> >>>
> >>> Se for pensar bem, ser Agil é como vc pensa o desenvolvimento como um
> >>> todo, pode ser Agil e usar RUP. É como o modelo toyota de produção, vc
> >>> não precisa de kamban ou poka-yoke para ser Lean. Scrum, por exemplo,
> >>> traz um conjunto grande de praticas adequadas a resolver problemas,
> >>> deixar as pessoas trabalharem e responderem rapido a mudanças, e
> >>> adotar Scrum e utilizar de forma madura demora tempo, mas com certeza
> >>> começou com um projeto piloto, com pessoas fazendo as coisas até meio
> >>> escondidas, etc.
> >>>
> >>> Agora percebam que praticamente ninguem fala de XP completo hoje em
> >>> dia, falam de algumas praticas do XP. Metaforas, por exemplo, eu nunca
> >>> vi na pratica. Mas em algum canto com certeza tem alguem usando XP de
> >>> raiz (provavelmente nos EUA).
> >>>
> >>> On Tue, Mar 13, 2012 at 6:25 PM, Ricardo Filipo
> >>> <ricardo_filipo em yahoo.com.br> wrote:
> >>> > Mas Pair Programming pode ser usado com qualquer metodologia, apesar
> de
> >>> > que
> >>> > XP me parece mais adequado.
> >>> > Até mesmo com MPSBR, RUP e tal o PP é bacana em muitos momentos.
> >>> >
> >>> > Eu sempre uso a regra (exceto quando não uso ...):
> >>> > 1 - Documente
> >>> > 2 - Crie testes
> >>> > 3 - Desenvolva
> >>> >
> >>> > A questão me parece que é aplicar Agile e desenvolvimento orientado
> por
> >>> > testes nas casas de software.
> >>> >
> >>> > Quando apliquei o curso no PRODERJ, creio que a experiência mais
> formal
> >>> > que
> >>> > tive disto, o método usado era o RUP. Mudar de RUP pra XP/Agile é
> duro,
> >>> > especialmente para os analistas, mas a experiência mostra que é bem
> >>> > melhor!
> >>> > O principal problema do método "em cascata" é que se a comunicação
> >>> > "analista<-->cliente" falhar todo o software falha. Com Agile a coisa
> >>> > vai se
> >>> > formando durante o processo de desenvolvimento e o cliente pode
> >>> > entender se
> >>> > o que pediu originalmente é realmente o que queria.
> >>> >
> >>> > A frase seria: "Se o seu cliente pediu pra desenvolver determinado
> >>> > software,
> >>> > entregue imediatamente qualquer coisa. Na medida que o cliente
> reclamar
> >>> > vc
> >>> > vai fazendo o software como ele quer realmente. Aliás, o cliente vai
> >>> > reclamar de qualquer forma, mesmo que vc desenvolva o software
> >>> > exatamente
> >>> > como vc acha que ele queria que fosse".
> >>> >
> >>> > Em especial eu gosto do clássico do  Robert Nagler:
> >>> >
> >>> >
> http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf
> >>> >
> >>> > Estou certo?
> >>> >
> >>> >
> >>> > ________________________________
> >>> > De: Cleysinho <cleysinhonv em gmail.com>
> >>> > Para: Perl Mongers Rio de Janeiro <rio-pm em pm.org>
> >>> > Enviadas: Terça-feira, 13 de Março de 2012 16:00
> >>> >
> >>> > Assunto: Re: [Rio-pm] Pair Programming
> >>> >
> >>> > 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
> >>>
> >>>
> >>>
> >>> --
> >>> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
>
> --
> 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/2ef87662/attachment-0001.html>