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.<div>
<br></div><div>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.</div>
<div><br></div><div>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. <br><br><div class="gmail_quote">
Em 13 de março de 2012 20:26, Tiago Peczenyj <span dir="ltr"><<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>></span> escreveu:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Minha dica é: pense numa versão 2.0 que possa coexistir com a atual e<br>
vá aos poucos depreciando a primeira. E crie testes para as novidades<br>
e bugfixes.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 13, 2012 at 8:24 PM, Marcio Ferreira<br>
<<a href="mailto:marciodesouzaferreira@gmail.com">marciodesouzaferreira@gmail.com</a>> wrote:<br>
> Alguém falou sobre testes aí no meio da thread - pessoal aqui escreve pra<br>
> cacete =P -, acho que isso é outro artefato que as vezes é forçado ou pose<br>
> ser melhorado.<br>
><br>
> IMHO, teste tem mais q função de retrocompatibilidade do que outra coisa.<br>
> Hoje estou trabalhando em um legado de quase 10 anos que passou na mão de<br>
> dezenas de programadores, com diversas filosofias e dogmas e lala<br>
> diferentes. O fato de não haver testes me desencoraja a refatorar a criança.<br>
><br>
> Escrever código é fácil, quero ver escrever algo que se mantenha intuitivo<br>
> daqui 20 anos<br>
><br>
> On Mar 13, 2012 6:50 PM, "Stanislaw Pusep" <<a href="mailto:creaktive@gmail.com">creaktive@gmail.com</a>> wrote:<br>
>><br>
>> ++Marcio<br>
>><br>
>> <a href="http://programming-motherfucker.com/" target="_blank">http://programming-motherfucker.com/</a><br>
>><br>
>> ABS()<br>
>><br>
>><br>
>><br>
>> On Tue, Mar 13, 2012 at 18:33, Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> As metodologias "by de book" são realmente bem diferentes, mas a<br>
>>> adoção de "agile" sempre tem histórias da adoção de boas praticas em<br>
>>> adendo ao que se fazia até o momento critico onde os problemas da<br>
>>> metodologia antiga apareciam e ficava claro que deveria mudar um ou<br>
>>> mais pontos específicos.<br>
>>><br>
>>> Se for pensar bem, ser Agil é como vc pensa o desenvolvimento como um<br>
>>> todo, pode ser Agil e usar RUP. É como o modelo toyota de produção, vc<br>
>>> não precisa de kamban ou poka-yoke para ser Lean. Scrum, por exemplo,<br>
>>> traz um conjunto grande de praticas adequadas a resolver problemas,<br>
>>> deixar as pessoas trabalharem e responderem rapido a mudanças, e<br>
>>> adotar Scrum e utilizar de forma madura demora tempo, mas com certeza<br>
>>> começou com um projeto piloto, com pessoas fazendo as coisas até meio<br>
>>> escondidas, etc.<br>
>>><br>
>>> Agora percebam que praticamente ninguem fala de XP completo hoje em<br>
>>> dia, falam de algumas praticas do XP. Metaforas, por exemplo, eu nunca<br>
>>> vi na pratica. Mas em algum canto com certeza tem alguem usando XP de<br>
>>> raiz (provavelmente nos EUA).<br>
>>><br>
>>> On Tue, Mar 13, 2012 at 6:25 PM, Ricardo Filipo<br>
>>> <<a href="mailto:ricardo_filipo@yahoo.com.br">ricardo_filipo@yahoo.com.br</a>> wrote:<br>
>>> > Mas Pair Programming pode ser usado com qualquer metodologia, apesar de<br>
>>> > que<br>
>>> > XP me parece mais adequado.<br>
>>> > Até mesmo com MPSBR, RUP e tal o PP é bacana em muitos momentos.<br>
>>> ><br>
>>> > Eu sempre uso a regra (exceto quando não uso ...):<br>
>>> > 1 - Documente<br>
>>> > 2 - Crie testes<br>
>>> > 3 - Desenvolva<br>
>>> ><br>
>>> > A questão me parece que é aplicar Agile e desenvolvimento orientado por<br>
>>> > testes nas casas de software.<br>
>>> ><br>
>>> > Quando apliquei o curso no PRODERJ, creio que a experiência mais formal<br>
>>> > que<br>
>>> > tive disto, o método usado era o RUP. Mudar de RUP pra XP/Agile é duro,<br>
>>> > especialmente para os analistas, mas a experiência mostra que é bem<br>
>>> > melhor!<br>
>>> > O principal problema do método "em cascata" é que se a comunicação<br>
>>> > "analista<-->cliente" falhar todo o software falha. Com Agile a coisa<br>
>>> > vai se<br>
>>> > formando durante o processo de desenvolvimento e o cliente pode<br>
>>> > entender se<br>
>>> > o que pediu originalmente é realmente o que queria.<br>
>>> ><br>
>>> > A frase seria: "Se o seu cliente pediu pra desenvolver determinado<br>
>>> > software,<br>
>>> > entregue imediatamente qualquer coisa. Na medida que o cliente reclamar<br>
>>> > vc<br>
>>> > vai fazendo o software como ele quer realmente. Aliás, o cliente vai<br>
>>> > reclamar de qualquer forma, mesmo que vc desenvolva o software<br>
>>> > exatamente<br>
>>> > como vc acha que ele queria que fosse".<br>
>>> ><br>
>>> > Em especial eu gosto do clássico do  Robert Nagler:<br>
>>> ><br>
>>> > <a href="http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf" target="_blank">http://www.onlineweblibrary.com/E-books/Ebook%20Progrmming/Perl/extremeperl.pdf</a><br>
>>> ><br>
>>> > Estou certo?<br>
>>> ><br>
>>> ><br>
>>> > ________________________________<br>
>>> > De: Cleysinho <<a href="mailto:cleysinhonv@gmail.com">cleysinhonv@gmail.com</a>><br>
>>> > Para: Perl Mongers Rio de Janeiro <<a href="mailto:rio-pm@pm.org">rio-pm@pm.org</a>><br>
>>> > Enviadas: Terça-feira, 13 de Março de 2012 16:00<br>
>>> ><br>
>>> > Assunto: Re: [Rio-pm] Pair Programming<br>
>>> ><br>
>>> > Entende-se que "Pair Programming" aconteça em empresas que não possuem<br>
>>> > processos de desenvolvimentos de software bem estruturados. Software<br>
>>> > documentado minimiza esforço do programador, caso se entenda que os<br>
>>> > diagramas UML estejam bem projetados e que documentação esteja bem<br>
>>> > elaborada.<br>
>>> ><br>
>>> > Estruturar processos de desenvolvimento de software não é simples e<br>
>>> > mudam a<br>
>>> > cultura organizacional de um ambiente de desenvolvimento. Na<br>
>>> > Universidade<br>
>>> > Federal de Viçosa-MG (UFV), eles estão buscando a certificação MPSbr,<br>
>>> > uma<br>
>>> > das coisas que os consultores mencionaram era a racionalização de mão<br>
>>> > de<br>
>>> > obra por projeto.<br>
>>> ><br>
>>> > 2012/3/13 Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>><br>
>>> ><br>
>>> > On Tue, Mar 13, 2012 at 2:32 PM, <<a href="mailto:thiagoglauco@ticursos.net">thiagoglauco@ticursos.net</a>> wrote:<br>
>>> ><br>
>>> > collective code ownership<br>
>>> ><br>
>>> > Tambem eh interessante pensar nisso... quanto maior a equipe, nao<br>
>>> > aumenta o<br>
>>> > custo de manter o codigo coletivo?<br>
>>> ><br>
>>> ><br>
>>> > Quanto maior a equipa maior os custos como um todo. Por isso times<br>
>>> > pequenos<br>
>>> > podem ser mais eficientes do que times grandes SE forem mais<br>
>>> > organizados e<br>
>>> > focados.<br>
>>> ><br>
>>> ><br>
>>> > Citando Tiago Peczenyj <<a href="mailto:tiago.peczenyj@gmail.com">tiago.peczenyj@gmail.com</a>>:<br>
>>> ><br>
>>> ><br>
>>> > colocação perfeita, forçar 100% de pair programming em qualquer<br>
>>> > situação<br>
>>> > não tem justificativa. Acredito que dependendo do projeto e do time<br>
>>> > haverá<br>
>>> > uma evolução ate encontrar uma taxa adequada, entretanto uma grande<br>
>>> > vantagem do pair é que o collective code ownership fica mais facil se<br>
>>> > as<br>
>>> > duplas se revezam com boa frequencia, assim todo mundo participou de<br>
>>> > tudo,<br>
>>> > praticamente. Se vc conseguir obter isso de outra forma que não apenas<br>
>>> > pair, melhor.<br>
>>> ><br>
>>> > On Sun, Mar 11, 2012 at 3:33 AM, breno <<a href="mailto:oainikusama@gmail.com">oainikusama@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > Pessoal,<br>
>>> ><br>
>>> > li recentemente um artigo muito interessante chamado "Pair Programming<br>
>>> > Considered Harmful?"<br>
>>> ><br>
>>> > <a href="http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/" target="_blank">http://techcrunch.com/2012/03/03/pair-programming-considered-harmful/</a><br>
>>> ><br>
>>> > O artigo apresenta pesquisas que sugerem que as pessoas são mais<br>
>>> > criativas quando desfrutam de privacidade e ausência de interrupções.<br>
>>> > Ele chega a discutir que grupos de brainstorming costumam ter menos<br>
>>> > idéias do que o mesmo número de pessoas trabalhando sozinha e depois<br>
>>> > compartilhando idéias. A questão de escritórios sem baia (open-plan)<br>
>>> > também é criticada, por ser uma grande fonte de distração e<br>
>>> > interrupções.<br>
>>> ><br>
>>> > Segundo o autor, insistir em 100% pair programming é um dogma<br>
>>> > irracional e extremamente contra-produtivo, e que a melhor solução é<br>
>>> > uma combinação dinâmica de trabalho isolado, em par e em grupo,<br>
>>> > dependendo do contexto e seguindo o bom senso.<br>
>>> ><br>
>>> > O que vocês acham?<br>
>>> ><br>
>>> > []s<br>
>>> ><br>
>>> > -b<br>
>>> > _______________________________________________<br>
>>> > Rio-pm mailing list<br>
>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Tiago B. Peczenyj<br>
>>> > Linux User #405772<br>
>>> ><br>
>>> > <a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Rio-pm mailing list<br>
>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Tiago B. Peczenyj<br>
>>> > Linux User #405772<br>
>>> ><br>
>>> > <a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Rio-pm mailing list<br>
>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > .: Inteligência Coletiva :.<br>
>>> > Uma inteligência distribuída por toda parte: tal é o nosso axioma<br>
>>> > inicial.<br>
>>> > Ninguém sabe tudo, todos sabem alguma coisa, todo o saber está na<br>
>>> > humanidade’. (Pierre Lévy)<br>
>>> > <a href="http://www.cleysinho.blogspot.com" target="_blank">www.cleysinho.blogspot.com</a><br>
>>> > <a href="http://www.bioinfopop.ufv.br" target="_blank">www.bioinfopop.ufv.br</a><br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Rio-pm mailing list<br>
>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>> ><br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Rio-pm mailing list<br>
>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Tiago B. Peczenyj<br>
>>> Linux User #405772<br>
>>><br>
>>> <a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
>>> _______________________________________________<br>
>>> Rio-pm mailing list<br>
>>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Rio-pm mailing list<br>
>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
><br>
><br>
> _______________________________________________<br>
> Rio-pm mailing list<br>
> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
<br>
<br>
<br>
--<br>
Tiago B. Peczenyj<br>
Linux User #405772<br>
<br>
<a href="http://pacman.blog.br" target="_blank">http://pacman.blog.br</a><br>
_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div style="font-family:'Lucida Grande',Geneva,Verdana,Arial,Helvetica,sans-serif;line-height:21px"><span style="font-family:arial;line-height:normal"><span style="font-family:sans-serif;line-height:19px"><b></b></span></span></div>
<div style="font-family:tahoma,sans-serif;line-height:21px"><div>
<span style="font-size:13px;line-height:21px"><div><span style="font-size:13px;line-height:21px">.: Inteligência Coletiva :.</span></div>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’. (</span><span style="font-size:13px;line-height:21px">Pierre Lévy)</span>
</div></div><div><a style="font-family:tahoma,sans-serif" href="http://www.cleysinho.blogspot.com" target="_blank">www.cleysinho.blogspot.com</a><br><a href="http://www.bioinfopop.ufv.br" target="_blank">www.bioinfopop.ufv.br</a><br>
<span style="font-family:tahoma,sans-serif"></span></div><div style="display:inline"></div><br>
</div>