Daniel,

A informática no Brasil está passando por um processo de aglutinação.
Poucas grandes empresas prestam serviços para poucas grandes empresas
e é nesse tipo de projeto onde se aplica a maior parte dos
investimentos de TI.

Para que os métodos ágeis possam vingar no Brasil é necessário que as
grandes empresas comprem essa idéia. Porém, mudar a cabeça do
departamento de TI de uma Petrobras ou de uma Vale do Rio Doce é
extremamente difícil. Implantar XP em uma universidade é relativamente
simples quando comparado ao esforço monumental de tentar implanta-lo
num projeto da Petrobras executado pela IBM, por exemplo. Na segunda
situação parece que não há espaço para curiosidade, experimentalismo
ou inovação.

Hoje, ao trabalhar para a IBM, percebo que existe um enorme interesse
aqui dentro pelos métodos ágeis: vários grupos de estudo e muita gente
aplicando na prática (o Scott Ambler é da IBM já há algum tempo). Eu
mesmo estou tentando disseminar a idéia dentro do meu grupo. Tenho
tido relativo sucesso mas quero ir mais fundo.

Não é difícil convencer que a idéia é boa, mas como o Kent Beck disse:
"Parar de fumar é fácil, difícil é não voltar a fumar". Métodos ágeis
exigem muita disciplina. Eles não escondem a ineficácia atrás de
papelada, te deixam exposto à crítica e exigem foco contínuo na
correção do curso. Isso é desconfortável para quem está acostumado a
fazer gerenciamento bungie-jump ("OI, tá tudo bem? Tchaaaaaauuu..." e
some por uma semana). É muito difícil convencer uma pessoa a largar um
hábito desses, porque agindo assim essa pessoa acha que pode atuar em
um monte de projetos ao mesmo tempo ou gerenciar uma equipe de 40
pessoas sozinho (afinal, ele gasta 10 minutos por semana com cada um
deles). Para ele, é uma maneira de economizar recursos. Para mim, é
uma maneira de desperdiçar tempo... O problema é que comprovar causa e
efeito em projetos de software é muito difícil e como vou provar pra
esse cara que ele é ineficiente? Será que ele vai gostar de ouvir
isso?

Abraço,
Luiz

2008/3/28 Daniel Wildt <dwildt@...>:
>
>
>
>
>
>
> Alisson, e pode ter certeza que isto funciona para outras partes do Brasil.
>
> Aqui no Rio Grande do Sul, tem uma galera trabalhando com metodologias
> ágeis, mas eu vejo empresas chamando gente de fora do RS para apresentar
> conceitos que a gente já trabalha aqui desde 2002 (de conhecidos que tenho
> que trabalham com métodos ágeis desde esta data).
>
> Então assim como vamos precisar trazer muita gente de fora para que as
> empresas brasileiras entendam que a gente tem talento de sobra aqui, em cada
> região do Brasil precisaremos de alguém de fora vir para que as empresas
> descubram que tinha alguém a menos de 20 metros para apresentar o mesmo
> assunto. E quanto a distância, uma última experiência que tive acho que a
> distância era menos que isto ainda.
>
> O futuro? Precisamos seguir apresentando, palestrando, criando eventos para
> chamar pessoas que querem iniciar.
>
> Hoje palestrei em uma Faculdade aqui do RS sobre metodologias ágeis. A
> platéia? 6 alunos e dois professores. O mais importante, um dos professores
> foi o meu professor da primeira disciplina envolvendo engenharia de software
> que tive na faculdade, em 1997. Cara, foi uma experiência única e foi
> excelente. E eu sei que aquelas pessoas, aquelas 6 pessoas e aqueles
> professores vão falar com outras e vai ser um efeito viral. Teremos mais
> interessados e curiosos. Alguns não acreditando, alguns odiando, mas teremos
> pessoas buscando mais informação e querendo discutir. É disto que
> precisamos.
>
> E dá-lhe comunidade!
>
> Abraço,
> Daniel Wildt
> http://xp-rs.blogspot.com
>
> 2008/3/27 Alisson Vale <alisson.vale@...>:
>
>
>
> >
> >
> >
> >
> >
> >
> > Oi Vinicius,
> >
> > Concordo com tudo que você escreveu, exceto essa parte:
> >
> > > (...) Percebi, com o tempo, que podemos
> >
> > > fazer diferença na base, sim, mas é muito pequena e, freqüentemente
> efêmera.
> >
> > Não acho que o resultado do seu trabalho tenha sido pequeno ou efêmero
> > nesses seis anos. Eu e mais dezenas, centenas ou mais até, dos que
> > hoje acreditam em desenvolvimento ágil sofreram influência direta do
> > seu trabalho de orientação e divulgação. Não acredito que haja uma só
> > pessoa que tenha estudado ou lido um pouco que seja sobre
> > desenvolvimento ágil e não tenha se deparado com seu nome ou com os
> > materiais que você já publicou. É certo que a maioria desses que
> > acreditam e que já se convenceram que essa é a melhor forma de
> > trabalhar com desenvolvimento de software não estão em posições de
> > decisão dentro das empresas. Mas o que não podemos esquecer é que
> > aqueles que estão na base hoje serão os futuros líderes e gestores
> > daqui a cinco ou dez anos. Ou seja, talvez você já tenha feito uma
> > diferença bastante grande, só ainda não deu tempo de percebê-la.
> >
> > Agora, quer minha opinião sincera? Não somos nós que vamos convencer
> > quem está no topo. É o mercado internacional.No Brasil é assim que as
> > coisas funcionam. Aqui pouco se cria, muito se copia. Ou seja, depois
> > que agile se firmar de forma definitiva como mainstream (tudo indica
> > que vai) lá fora, basta contar mais cinco anos que, aí sim, nós
> > veremos todo mundo dizendo que faz agile por aqui. Quer um exemplo que
> > se encaixa perfeitamente com a questão que você levantou? Orientação a
> > objetos. Você conhece alguma empresa hoje que não assume com todas as
> > letras que seu software foi desenvolvido usando OO? No entanto, se 1%
> > delas realmente usam OO e se beneficiam do paradigma eu já diria que é
> > muito. E olha que esse paradigma tem mais de 30 anos! Quantas
> > faculdades realmente ensinam OO hoje? Alguém aqui dessa lista aprendeu
> > OO de verdade na faculdade que estudou? Quem aqui abriu o GoF em uma
> > sala de aula? Mesmo décadas depois de o paradigma se firmar, quem
> > entra na faculdade hoje aprende a programar em Pascal estruturado!
> > Acho que agile vai sofrer do mesmo mal quando virar mainstream aqui no
> > Brasil. Todo mundo vai dizer que faz, mas poucos farão de verdade. A
> > SEI vai dar um jeito de se adaptar, as empresas vão dar um jeito de se
> > adaptar, as universidades vão dar um jeito de se adaptar, mas poucos
> > entenderão de verdade o significado do que está descrito no manifesto.
> >
> > Apesar disso tudo, eu ainda acho que vale a pena vestir essa camisa.
> > Nem tanto para buscar convencer aqueles que ainda apostam no modelo
> > tradicional, mas por aqueles que já subiram no nosso barco e que agora
> > precisam saber o que fazer pra ter sucesso nessa nova abordagem.
> >
> > Um grande abraço,
> > Alisson Vale
> >
> > Em 27/03/08, Vinicius Manhaes Teles <vinicius@...> escreveu:
> >
> >
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Oi, Juan.
> > >
> > >
> > > Minha resposta curta para a sua pergunta é: sim, o mercado está mudando.
> Ele está sempre mudando. :-) Mas, talvez não tanto assim quanto gostaríamos
> e, possivelmente, não na direção que desejamos. Uma das mudanças mais
> perceptíveis é que cada vez mais gente tem ouvido falar de desenvolvimento
> ágil. Mas, isso não quer dizer necessariamente que cada vez mais gente
> esteja adotando métodos ágeis. Certamente, cada vez mais gente DIZ estar
> usando métodos ágeis. Mas, a distância entre o DIZER e o FAZER é imensa,
> sobretudo nesta área. Acredito que, daqui por diante, veremos cada vez mais
> gente falando sobre desenvolvimento ágil, mas continuaremos a ver poucos
> usando. Há algumas razões fundamentais para isso.
> > >
> > >
> > > Desenvolvimento ágil não tem a ver com Scrum, XP, FDD, Lean ou seja lá
> qual for o nome. Tem a ver, acima de tudo, com a maneira como encaramos
> desenvolvimento de software. Tem a ver com a compreensão da verdadeira
> NATUREZA do desenvolvimento de software. Os anos passam, mas a maioria
> absoluta das pessoas não consegue se livrar da idéia de que desenvolver
> software seja igual a construir prédio. As conseqüências desta dissonância
> cognitiva são infinitamente mais sérias do que a maioria de nós gostaria de
> acreditar. Escrevi exaustivamente sobre isso na minha dissertação
> (http://www.improveit.com.br/xp/dissertacaoXP.pdf, cápitulos 3 e 4), então,
> não vou me estender aqui. Apenas resumirei porque isso é tão prejudicial.
> > >
> > >
> > > O que uma empresa produz é resultado de como ela está estruturada. Quem
> tem autoridade para dizer como deve ser a estrutura de uma empresa é quem
> está no topo. Então, a estrutura de qualquer é empresa é, no fim das contas,
> o resultado do modo de pensar, da mentalidade, de quem está no comando. A
> mentalidade da maioria dos empresários, diretores e gerentes no mundo
> inteiro é, com raríssimas exceções, arcaica e incompatível com o trabalho de
> desenvolver software. Quando o topo da empresa não entende o tipo de
> mentalidade necessária para se desenvolver software de forma bem sucedida,
> não há santo que possa fazer milagre. E eu garanto, a maioria absoluta das
> pessoas que estão no comando das empresas não entende uma vírgula do que
> significa desenvolver software. Isso inclui, certamente, a maioria absoluta
> dos CIOs. Não é à toa que eles buscam recorrentemente coisas como CMMI,
> PMBOK, MPS.BR, ITIL etc, todos absolutamente incompatíveis com a NATUREZA do
> desenvolvimento de software. A mentalidade por trás destas aberrações é
> inútil, quando o assunto é software, mas casa perfeitamente com a
> mentalidade da maioria dos gestores. E não pára por aí. Nas universidades, a
> situação é igual ou pior.
> > >
> > >
> > > Veja o caso da UFRJ, por exemplo. Neste semestre, o professor de
> engenharia de software, percebendo a crescente movimentação em torno de
> métodos ágeis, resolveu gastar boa parte do seu tempo para mostrar aos
> alunos que métodos como o XP não funcionam. Afinal, se fôssemos fazer um
> prédio com XP, aconteceria mil e uma coisas horrendas. Nisso ele está certo.
> O problema, como sempre, é a maldita distinção entre construir prédio e
> desenvolver software, a qual, seria óbvia para uma criança, mas é impossível
> de ser percebida por um Ph.D(eus). Olha que loucura, em uma universidade do
> quilate da UFRJ, o cidadão, só porque é Ph.D.(eus), não precisa se dar ao
> trabalho de estudar sobre métodos ágeis, nem muito menos usá-lo, para já
> saber, desde criancinha, que não pode dar certo. E claro, um conhecimento
> destes, tão valioso, não pode ser mantido só para ele. Também é preciso
> passar adiante para os alunos, como se fosse necessário. Afinal, eles já
> estão todos estagiando em empresas entupidas de documentos e péssimas
> práticas de desenvolvimento até o último fio de cabelo.
> > >
> > >
> > > Sempre fui muito otimista, em tudo. Mas, em se tratando de
> desenvolvimento ágil, acho que meu otimismo se foi. Foram precisos seis anos
> para isso acontecer, devo dizer, mas se foi. E a razão está lá em cima, no
> topo das empresas, no topo das universidades. Está lá onde a mediocridade e
> a incompetência imperam, ao menos em se tratando de desenvolvimento de
> software e gestão de pessoas. Percebi, com o tempo, que podemos fazer
> diferença na base, sim, mas é muito pequena e, freqüentemente efêmera.
> > >
> > >
> > > Fiquei tempo suficiente nesta área para ver equipes adotarem XP,
> funcionarem super bem durante algum tempo e, mais a frente, serem impedidas
> de continuar porque a organização passa minar o andamento do grupo. É como
> um corpo estranho, que é expelido naturalmente pelas nossas células. Só para
> dar um exemplo. Em 2003, nós fizemos um projeto XP para a Vale do Rio Doce.
> Foi um projeto lindo, com tudo que se tinha direito. Até contrato de escopo
> negociável. As áreas de negócio amaram tudo o que foi feito. Adoravam os
> desenvolvedores. Depois que o sistema foi colocado no ar, foram encontrados
> apenas 3 bugs durante os seis meses seguintes. Isso é nada em um projeto de
> mais de um ano, com mais de dez pessoas envolvidas. O projeto foi um sucesso
> em praticamente todos os quesitos que se pudesse imaginar. Mas, aí é que
> estava o problema. A última coisa que alguém quer é um projeto de sucesso!
> Afinal, como ficam os demais? Quando o projeto acabou, tudo foi feito dentro
> da Vale para que nunca mais isso se repetisse. Acredite, não foi a única vez
> que vi isso acontecer. Em seis anos, eu vi muita coisa começar bem e, mais a
> frente, acabar. Por que?
> > >
> > >
> > > Porque desenvolver software com a mentalidade ágil não é compatível com
> a mentalidade de quem manda. Isso é mais do que suficiente para limitar as
> mudanças na área de software. Acredito que vai levar muito tempo para que as
> empresas passem a ter gestores que compreendam não apenas o que é fazer
> software. Mas, o que é fazer um trabalho do conhecimento. A maioria absoluta
> dos gestores tratam seus funcionários como se fossem crianças. Fica
> parecendo que os piores imbecis são justamente os que mais freqüentemente
> são escolhidos para comandar as empresas. Não parece apenas, isso realmente
> acontece e dói ver o quanto isso é comum. Enquanto estes estiverem lá em
> cima, vamos ouvir falar muito sobre desenvolvimento ágil. Mas é só. Aliás,
> não é não. Tem coisa pior. Vamos ver pessoas fazendo barbaridades e dizendo
> que estão usando desenvolvimento ágil.
> > >
> > >
> > > Para quem ainda estiver no ramo de consultoria, isso não é
> necessariamente ruim. Essa área vai bombar. Vamos ter cada vez mais espaço
> para cursos e consultoria em desenvolvimento ágil. O interesse só vai
> crescer daqui por diante. Não necessariamente pelos méritos, mas porque
> alguém ouviu dizer que agora o grande lance é fazer software com a
> ___________ (preencha com a metodologia ágil preferida).
> > >
> > >
> > > O problema dos gestores não afeta apenas o desenvolvimento de software.
> Ele é muito mais sério e muito mais abrangente que isso. Entre em qualquer
> empresa grande e o que você verá é um bando de trabalhadores do conhecimento
> sendo tratados como pedreiros por um bando de incompetentes que não
> conseguem fazer nada melhor que jogar tempo e dinheiro na lata de lixo. O
> nível de desperdício de talento, tempo, dinheiro, oportunidades etc é tão
> colossal que eu realmente não consigo compreender como alguém consegue
> trabalhar em uma empresa grande atualmente. Claro, existem exceções.
> Pouquíssimas, mas existem. São apenas isso, exceções.
> > >
> > >
> > > Desejo muita sorte e sucesso para quem continua lutando para mudar este
> panorama. Não tenho dúvidas de que as coisas irão melhorar ao longo do
> tempo. Mas, acho bastante improvável que uma mudança significativa aconteça
> no curto ou médio prazo. Enquanto as pessoas chegarem no topo das empresas
> com a mentalidade que temos hoje em dia, enquanto os professores
> universitários continuarem ensinando lixo, enquanto as empresas continuarem
> a ganhar dinheiro apesar das práticas de administração arcaicas que
> utilizam, enquanto nós aceitarmos trabalhar para estes idiotas, vai ser
> complicado.
> > >
> > >
> > > Desculpa pelo pessimismo. Não foi sempre assim. Foram necessários seis
> anos, seis turmas de XP na UFRJ, literalmente centenas de apresentações de
> XP em todo o Brasil, um mestrado, não sei quantos cursos, vários mentorings,
> alguns projetos de desenvolvimento XP, algumas conferências no exterior, um
> livro e mais um monte de coisas que eu não lembro, para me dobrar. E antes
> que alguém pense que o problema era o XP e que tudo poderia ser diferente se
> tivesse sido Scrum, FDD, Lean etc, não se enganem. O buraco é mais embaixo.
> Se você conseguiu chegar até aqui e prestou atenção ao que estou dizendo,
> tudo se resume a uma coisa: mudar é difícil? É. Mas, ainda é a parte fácil.
> O difícil mesmo é mudar de vez.
> > >
> > >
> > > O Kent Beck tem um exemplo ótimo. Segundo ele, parar de fumar é fácil.
> Tanto que tem gente que já parou várias vezes. :-) O problema é parar e
> nunca mais voltar a fumar. É a mesma coisa. Um monte de gente vai conseguir
> mudar para desenvolvimento ágil. Poucos conseguirão sustentar esta mudança.
> E eu adoraria estar falando isso de orelhada. Mas, é que eu vi as pessoas
> voltarem a fumar um número suficiente de vezes para saber que é ótimo ver
> mais movimentação atualmente sobre desenvolvimento ágil. Mas, acredito que
> seja ingênuo achar que isso implique em uma mudança significativa. Muitos
> tentarão e a maioria vai voltar às práticas antigas, simplesmente porque
> todos os incentivos nas empresas giram em torno delas e isso continuará
> assim por muito tempo.
> > >
> > >
> > > Apesar de tudo o que disse, torço, profundamente, para estar
> absolutamente equivocado! No mais, redobrem seus esforços! O desafio é bem
> maior do que parece à primeira vista.
> > >
> > >
> > > Grande abraço,
> > >
> > >
> > >
> > >
> > >
> > >
> > > Vinícius Teles
> > >
> > >
> > > Improve It
> > > Rio: +55 21 3521-6760
> > > São Paulo: +55 11 3711-3423
> > > Celular: +55 21 8716-5434
> > >
> > >
> > > Em 26/03/2008, às 03:48, Juan Bernabo escreveu:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Pessoal,
> > >
> > > Desculpem mais talvez pelo horario fiquei nostalgico, coisa de tanguero,
> bom vou fazer uma retrospectiva sobre como vejo o que tem acontecido nos
> últimos anos na saga de Agile no Brasil que é claro é completamente ego
> cêntrica e limitada visão dos fatos e gostaria tambem ter a contribuição de
> quem quiser agregar fatos a esta historia.
> > >
> > > Eu me lembro da vez que veio ao Brasil o Kent Beck, Scott Ambler, Rob
> Mee e uma galera muito legal para o evento XP 2002 organizado pelo Klaus
> Wuestefeld e sua empresa na epoca, naquela época eu estava lançando um
> piloto da revista Object Magazine Brasil, que foi um sucesso de audiência,
> porem um fracasso de bilheteria, e com a idéia de falar do ciclo de vida
> completo de desenvolvimento de software, não só de programação, porque o que
> eu via como um dos grandes problemas era a falta de integração entre as
> disciplinas, as pessoas e que isso me parecia estar no cerne da crise do
> software, la estava o Vinicius da ImproveIt, o Fabio Kon da USP e outras
> personalidades do mundo Ágil.
> > >
> > > Isso foi em 2002, parece um seculo, teve o XP 2004 com um pouco menos de
> ruido, e depois parece que ouve um inverno, em 2005 e 2006 depois de tentar
> em varias empresas de fazer o que eu sei que é entregar software de forma
> iterativa e incremental e evolutiva e ter conflitos com os mais variados
> tipos de planos malucos, processos, e politicas disfuncionais acabei me
> decidindo a mudar de negocio, não mais ter que brigar de dentro de uma
> organização para tentar mudar politicas que colocam em risco projetos, e
> fazer que as empresas com suficiente dor e/ou disposição para mudar possam
> me contratar para ajudar-las a fazer isso.
> > >
> > > Em 2006 foi uma dureza fechar algum contrato, nenhum gerente ou diretor
> queria saber de outra coisa que não fosse CMMI/MPSbr/RUP, naquela epoca eu
> começei a tentar sair da toca e conheci algumas pessoas na lista CMM-Brasil,
> hoje morta e encarnada na CMMI-Brasil, que tambem estabam falando sobre
> Agile e com serias criticas ao que empresas estavam adotando, e a gente
> sacudeu um pouquinho a poeira num primeiro Mini-Workshop de Gerenciamento
> Ágil de Projetos entre o Marcio Tierno, Jose Papo, Adail Retamal e eu e
> depois numasegunda edição organizado pelo PMI-SP que também foi muito bem.
> > >
> > > Em 2007 começou para mim a maratona de Scrum no Brasil, organizando
> treinamentos em varias capitais e fazendo palestras e webcasts adoidado,
> muito barulho em listas, e conseguimos que centenas de pessoas fissem o
> treinamento de CSM, para mim Scrum seria a arma fundamental para poder criar
> celulas de produção de software auto-geridas que pudessem adotar
> processos/praticas ágeis vindas do XP/FDD/Lean ou qualquer outra coisa que
> pudesse agregar valor a produzir software pronto em duas a quatro semanas.
> > >
> > > Como empresas não queriam ouvir falar de Agile/Scrum, a estrategia foi
> começar pelas pessoas, aqueles indivíduos que mesmo que a empresa não
> pagasse o treinamento o fariam por conta da convicção ou da dor da forma de
> trabalhar atual, e estes seriam os "early adopters" que acabariam
> evangelizando Scrum/Agile em suas organizações.
> > >
> > > Depois disto começou a emerger e sair do anonimato, pelo menos para mim,
> uma galera talentossisima que não vou me atrever a falar todos os nomes, e
> Agile deixou de ser sinônimo de coisa de programador adolescente revoltado e
> passou a ser coisa de gente grande, o que sempre foi... mais....
> > >
> > > Em 2008 ainda tem profissional que paga do seu bolso, mais muita muita
> empresa deixou a certeza de um futuro melhor cheio de processos altamente
> definidos, muitos documentos e matrizes de rastreabilidade, pela
> simplicidade e foco em resultados de Agile.
> > >
> > > Na virada do ano perdemos pelo menos uns 3 a 4 grandes valores na
> comunidade Ágil no Brasil para outros países, que vão ser muito difíceis
> repor, espero que estem bem por la Shoes, Danilo, Fábio...
> > >
> > > Neste ano começou a crescer e se fortalecer um pequeno eco-sistema de
> profissionais, consultores, empresas que é fundamental para uma adopção em
> massa possa ser realizada na nossa industria para realmente ser relevante.
> > >
> > > Por isso creio que o mercado esta mudando, falta muito ainda
> desmistificar as abordagens ágeis, educar e mostrar cases de grandes
> implantações que já estão acontecendo aqui no Brasil e seus resultados.
> > >
> > > Bom agora algumas previsões para este e os próximos anos....
> > >
> > > Acredito que no Brasil as mudanças / adopção será muito mais abrupta do
> que em outros países do mundo, e a adopção de Agile em todas suas variantes
> sobre tudo em processos híbridos com gestão baseada em Scrum ou Kanban e TOC
> e engenharia baseada em XP, FDD e sobre tudo com conceitos de Lean Software
> Development é o que me parece que vai cada vez mais o caminho para
> implantações serias.
> > >
> > > Este ano vão sair do papel Agile Alliance Brasil, Forum Agile 2008,
> Agile Magazine Brasil, como deveria ter se chamado a Object Magazine de
> 2002, novos treinamentos com personalidades internacionais, e outros colegas
> também estão em vento em popa fazendo um monte de coisas, desde
> treinamentos, coaching, palestras, revistas, tudo para aumentar a adopção e
> deixar TI um pouco mais Ágil aqui no Brasil.
> > >
> > > Quem sabe o slogam "For a Faster, Cheaper, Better & Cooler IT" pegue...
> > >
> > > Abraços,
> > > Juan.
> > > PD: quem quiser colaborar nestas empreitadas é só mandar um email.
> > >
> > > --
> > > TeamWare do Brasil
> > > Equipes Altamente Eficazes
> > > Agilidade, Pessoas e Tecnologia
> > > São Paulo: +55 (11) 5061-8221
> > > Brasilia: +55 (61) 9969-9282
> > > Boston: +1 (617) 507-1490
> > > Buenos Aires: +54 9 (11) 68195600
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Regards,
> Daniel Wildt
> http://danielwildt.blogspot.com
> http://weblogs.java.net/blog/dwildt/
>
> java.net Global Education and Learning Community (GELC) -
> http://edu-gelc.dev.java.net
> http://wiki.java.net/bin/view/People/DanielWildt

Olá Vinicius,

Me identifiquei muito com seu post. Eu tenho o mesmo sentimento que
você tem sobre a coisa vir do topo.

Realmente somos podados quando temos iniciativas que melhoras as
coisas de forma gritante, seja com metodologias ágeis ou qualquer
outra coisa. A grande maioria das empresas criam uma estrutura para
que as coisas realmente não funcionem, softwares não sejam entregues e
por ai vai. Parece que o objetivo principal é manter a estrutura do
jeito que está pois gera muito dinheiro pra todo mundo, e a parte que
perde geralmente nem sente e nem percebe isso.

Em fim, também continuo nessa luta e espero que o cenário mude, cedo
ou tarde.

Abraços!
--- In xprio@yahoogroups.com, Vinicius Manhaes Teles <vinicius@...> wrote:
>
> Oi, Alisson.
>
> Muito obrigado! Tor�o para que voc� esteja certo e, mais ainda, para
> que o mercado realmente absorva os conceitos de desenvolvimento �gil o
> mais brevemente poss�vel. � bom saber que hoje h� pessoas como voc�, e
> outros, que v�m lutando para dar continuidade ao que foi feito at� aqui!
>
> Grande abra�o,
>
> Em 27/03/2008, �s 05:05, Alisson Vale escreveu:
>
> > Oi Vinicius,
> >
> > Concordo com tudo que voc� escreveu, exceto essa parte:
> >
> > > (...) Percebi, com o tempo, que podemos
> > > fazer diferen�a na base, sim, mas � muito pequena e,
> > freq�entemente ef�mera.
> >
> > N�o acho que o resultado do seu trabalho tenha sido pequeno ou ef�mero
> > nesses seis anos. Eu e mais dezenas, centenas ou mais at�, dos que
> > hoje acreditam em desenvolvimento �gil sofreram influ�ncia direta do
> > seu trabalho de orienta��o e divulga��o. N�o acredito que haja uma
s�
> > pessoa que tenha estudado ou lido um pouco que seja sobre
> > desenvolvimento �gil e n�o tenha se deparado com seu nome ou com os
> > materiais que voc� j� publicou. � certo que a maioria desses que
> > acreditam e que j� se convenceram que essa � a melhor forma de
> > trabalhar com desenvolvimento de software n�o est�o em posi��es de
> > decis�o dentro das empresas. Mas o que n�o podemos esquecer � que
> > aqueles que est�o na base hoje ser�o os futuros l�deres e gestores
> > daqui a cinco ou dez anos. Ou seja, talvez voc� j� tenha feito uma
> > diferen�a bastante grande, s� ainda n�o deu tempo de perceb�-la.
> >
> > Agora, quer minha opini�o sincera? N�o somos n�s que vamos convencer
> > quem est� no topo. � o mercado internacional.No Brasil � assim que as
> > coisas funcionam. Aqui pouco se cria, muito se copia. Ou seja, depois
> > que agile se firmar de forma definitiva como mainstream (tudo indica
> > que vai) l� fora, basta contar mais cinco anos que, a� sim, n�s
> > veremos todo mundo dizendo que faz agile por aqui. Quer um exemplo que
> > se encaixa perfeitamente com a quest�o que voc� levantou? Orienta��o
a
> > objetos. Voc� conhece alguma empresa hoje que n�o assume com todas as
> > letras que seu software foi desenvolvido usando OO? No entanto, se 1%
> > delas realmente usam OO e se beneficiam do paradigma eu j� diria que �
> > muito. E olha que esse paradigma tem mais de 30 anos! Quantas
> > faculdades realmente ensinam OO hoje? Algu�m aqui dessa lista aprendeu
> > OO de verdade na faculdade que estudou? Quem aqui abriu o GoF em uma
> > sala de aula? Mesmo d�cadas depois de o paradigma se firmar, quem
> > entra na faculdade hoje aprende a programar em Pascal estruturado!
> > Acho que agile vai sofrer do mesmo mal quando virar mainstream aqui no
> > Brasil. Todo mundo vai dizer que faz, mas poucos far�o de verdade. A
> > SEI vai dar um jeito de se adaptar, as empresas v�o dar um jeito de se
> > adaptar, as universidades v�o dar um jeito de se adaptar, mas poucos
> > entender�o de verdade o significado do que est� descrito no manifesto.
> >
> > Apesar disso tudo, eu ainda acho que vale a pena vestir essa camisa.
> > Nem tanto para buscar convencer aqueles que ainda apostam no modelo
> > tradicional, mas por aqueles que j� subiram no nosso barco e que agora
> > precisam saber o que fazer pra ter sucesso nessa nova abordagem.
> >
> > Um grande abra�o,
> > Alisson Vale
> >
> > Em 27/03/08, Vinicius Manhaes Teles <vinicius@...>
> > escreveu:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Oi, Juan.
> > >
> > >
> > > Minha resposta curta para a sua pergunta �: sim, o mercado est�
> > mudando. Ele est� sempre mudando. :-) Mas, talvez n�o tanto assim
> > quanto gostar�amos e, possivelmente, n�o na dire��o que desejamos.
> > Uma das mudan�as mais percept�veis � que cada vez mais gente tem
> > ouvido falar de desenvolvimento �gil. Mas, isso n�o quer dizer
> > necessariamente que cada vez mais gente esteja adotando m�todos
> > �geis. Certamente, cada vez mais gente DIZ estar usando m�todos
> > �geis. Mas, a dist�ncia entre o DIZER e o FAZER � imensa, sobretudo
> > nesta �rea. Acredito que, daqui por diante, veremos cada vez mais
> > gente falando sobre desenvolvimento �gil, mas continuaremos a ver
> > poucos usando. H� algumas raz�es fundamentais para isso.
> > >
> > >
> > > Desenvolvimento �gil n�o tem a ver com Scrum, XP, FDD, Lean ou
> > seja l� qual for o nome. Tem a ver, acima de tudo, com a maneira
> > como encaramos desenvolvimento de software. Tem a ver com a
> > compreens�o da verdadeira NATUREZA do desenvolvimento de software.
> > Os anos passam, mas a maioria absoluta das pessoas n�o consegue se
> > livrar da id�ia de que desenvolver software seja igual a construir
> > pr�dio. As conseq��ncias desta disson�ncia cognitiva s�o
> > infinitamente mais s�rias do que a maioria de n�s gostaria de
> > acreditar. Escrevi exaustivamente sobre isso na minha disserta��o
(http://www.improveit.com.br/xp/dissertacaoXP.pdf
> > , c�pitulos 3 e 4), ent�o, n�o vou me estender aqui. Apenas
> > resumirei porque isso � t�o prejudicial.
> > >
> > >
> > > O que uma empresa produz � resultado de como ela est� estruturada.
> > Quem tem autoridade para dizer como deve ser a estrutura de uma
> > empresa � quem est� no topo. Ent�o, a estrutura de qualquer �
> > empresa �, no fim das contas, o resultado do modo de pensar, da
> > mentalidade, de quem est� no comando. A mentalidade da maioria dos
> > empres�rios, diretores e gerentes no mundo inteiro �, com rar�ssimas
> > exce��es, arcaica e incompat�vel com o trabalho de desenvolver
> > software. Quando o topo da empresa n�o entende o tipo de mentalidade
> > necess�ria para se desenvolver software de forma bem sucedida, n�o
> > h� santo que possa fazer milagre. E eu garanto, a maioria absoluta
> > das pessoas que est�o no comando das empresas n�o entende uma
> > v�rgula do que significa desenvolver software. Isso inclui,
> > certamente, a maioria absoluta dos CIOs. N�o � � toa que eles buscam
> > recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos
> > absolutamente incompat�veis com a NATUREZA do desenvolvimento de
> > software. A mentalidade por tr�s destas aberra��es � in�til,
quando
> > o assunto � software, mas casa perfeitamente com a mentalidade da
> > maioria dos gestores. E n�o p�ra por a�. Nas universidades, a
> > situa��o � igual ou pior.
> > >
> > >
> > > Veja o caso da UFRJ, por exemplo. Neste semestre, o professor de
> > engenharia de software, percebendo a crescente movimenta��o em torno
> > de m�todos �geis, resolveu gastar boa parte do seu tempo para
> > mostrar aos alunos que m�todos como o XP n�o funcionam. Afinal, se
> > f�ssemos fazer um pr�dio com XP, aconteceria mil e uma coisas
> > horrendas. Nisso ele est� certo. O problema, como sempre, � a
> > maldita distin��o entre construir pr�dio e desenvolver software, a
> > qual, seria �bvia para uma crian�a, mas � imposs�vel de ser
> > percebida por um Ph.D(eus). Olha que loucura, em uma universidade do
> > quilate da UFRJ, o cidad�o, s� porque � Ph.D.(eus), n�o precisa se
> > dar ao trabalho de estudar sobre m�todos �geis, nem muito menos us�-
> > lo, para j� saber, desde criancinha, que n�o pode dar certo. E
> > claro, um conhecimento destes, t�o valioso, n�o pode ser mantido s�
> > para ele. Tamb�m � preciso passar adiante para os alunos, como se
> > fosse necess�rio. Afinal, eles j� est�o todos estagiando em empresas
> > entupidas de documentos e p�ssimas pr�ticas de desenvolvimento at� o
> > �ltimo fio de cabelo.
> > >
> > >
> > > Sempre fui muito otimista, em tudo. Mas, em se tratando de
> > desenvolvimento �gil, acho que meu otimismo se foi. Foram precisos
> > seis anos para isso acontecer, devo dizer, mas se foi. E a raz�o
> > est� l� em cima, no topo das empresas, no topo das universidades.
> > Est� l� onde a mediocridade e a incompet�ncia imperam, ao menos em
> > se tratando de desenvolvimento de software e gest�o de pessoas.
> > Percebi, com o tempo, que podemos fazer diferen�a na base, sim, mas
> > � muito pequena e, freq�entemente ef�mera.
> > >
> > >
> > > Fiquei tempo suficiente nesta �rea para ver equipes adotarem XP,
> > funcionarem super bem durante algum tempo e, mais a frente, serem
> > impedidas de continuar porque a organiza��o passa minar o andamento
> > do grupo. � como um corpo estranho, que � expelido naturalmente
> > pelas nossas c�lulas. S� para dar um exemplo. Em 2003, n�s fizemos
> > um projeto XP para a Vale do Rio Doce. Foi um projeto lindo, com
> > tudo que se tinha direito. At� contrato de escopo negoci�vel. As
> > �reas de neg�cio amaram tudo o que foi feito. Adoravam os
> > desenvolvedores. Depois que o sistema foi colocado no ar, foram
> > encontrados apenas 3 bugs durante os seis meses seguintes. Isso �
> > nada em um projeto de mais de um ano, com mais de dez pessoas
> > envolvidas. O projeto foi um sucesso em praticamente todos os
> > quesitos que se pudesse imaginar. Mas, a� � que estava o problema. A
> > �ltima coisa que algu�m quer � um projeto de sucesso! Afinal, como
> > ficam os demais? Quando o projeto acabou, tudo foi feito dentro da
> > Vale para que nunca mais isso se repetisse. Acredite, n�o foi a
> > �nica vez que vi isso acontecer. Em seis anos, eu vi muita coisa
> > come�ar bem e, mais a frente, acabar. Por que?
> > >
> > >
> > > Porque desenvolver software com a mentalidade �gil n�o �
> > compat�vel com a mentalidade de quem manda. Isso � mais do que
> > suficiente para limitar as mudan�as na �rea de software. Acredito
> > que vai levar muito tempo para que as empresas passem a ter gestores
> > que compreendam n�o apenas o que � fazer software. Mas, o que �
> > fazer um trabalho do conhecimento. A maioria absoluta dos gestores
> > tratam seus funcion�rios como se fossem crian�as. Fica parecendo que
> > os piores imbecis s�o justamente os que mais freq�entemente s�o
> > escolhidos para comandar as empresas. N�o parece apenas, isso
> > realmente acontece e d�i ver o quanto isso � comum. Enquanto estes
> > estiverem l� em cima, vamos ouvir falar muito sobre desenvolvimento
> > �gil. Mas � s�. Ali�s, n�o � n�o. Tem coisa pior. Vamos ver
pessoas
> > fazendo barbaridades e dizendo que est�o usando desenvolvimento �gil.
> > >
> > >
> > > Para quem ainda estiver no ramo de consultoria, isso n�o �
> > necessariamente ruim. Essa �rea vai bombar. Vamos ter cada vez mais
> > espa�o para cursos e consultoria em desenvolvimento �gil. O
> > interesse s� vai crescer daqui por diante. N�o necessariamente pelos
> > m�ritos, mas porque algu�m ouviu dizer que agora o grande lance �
> > fazer software com a ___________ (preencha com a metodologia �gil
> > preferida).
> > >
> > >
> > > O problema dos gestores n�o afeta apenas o desenvolvimento de
> > software. Ele � muito mais s�rio e muito mais abrangente que isso.
> > Entre em qualquer empresa grande e o que voc� ver� � um bando de
> > trabalhadores do conhecimento sendo tratados como pedreiros por um
> > bando de incompetentes que n�o conseguem fazer nada melhor que jogar
> > tempo e dinheiro na lata de lixo. O n�vel de desperd�cio de talento,
> > tempo, dinheiro, oportunidades etc � t�o colossal que eu realmente
> > n�o consigo compreender como algu�m consegue trabalhar em uma
> > empresa grande atualmente. Claro, existem exce��es. Pouqu�ssimas,
> > mas existem. S�o apenas isso, exce��es.
> > >
> > >
> > > Desejo muita sorte e sucesso para quem continua lutando para mudar
> > este panorama. N�o tenho d�vidas de que as coisas ir�o melhorar ao
> > longo do tempo. Mas, acho bastante improv�vel que uma mudan�a
> > significativa aconte�a no curto ou m�dio prazo. Enquanto as pessoas
> > chegarem no topo das empresas com a mentalidade que temos hoje em
> > dia, enquanto os professores universit�rios continuarem ensinando
> > lixo, enquanto as empresas continuarem a ganhar dinheiro apesar das
> > pr�ticas de administra��o arcaicas que utilizam, enquanto n�s
> > aceitarmos trabalhar para estes idiotas, vai ser complicado.
> > >
> > >
> > > Desculpa pelo pessimismo. N�o foi sempre assim. Foram necess�rios
> > seis anos, seis turmas de XP na UFRJ, literalmente centenas de
> > apresenta��es de XP em todo o Brasil, um mestrado, n�o sei quantos
> > cursos, v�rios mentorings, alguns projetos de desenvolvimento XP,
> > algumas confer�ncias no exterior, um livro e mais um monte de coisas
> > que eu n�o lembro, para me dobrar. E antes que algu�m pense que o
> > problema era o XP e que tudo poderia ser diferente se tivesse sido
> > Scrum, FDD, Lean etc, n�o se enganem. O buraco � mais embaixo. Se
> > voc� conseguiu chegar at� aqui e prestou aten��o ao que estou
> > dizendo, tudo se resume a uma coisa: mudar � dif�cil? �. Mas, ainda
> > � a parte f�cil. O dif�cil mesmo � mudar de vez.
> > >
> > >
> > > O Kent Beck tem um exemplo �timo. Segundo ele, parar de fumar �
> > f�cil. Tanto que tem gente que j� parou v�rias vezes. :-) O problema
> > � parar e nunca mais voltar a fumar. � a mesma coisa. Um monte de
> > gente vai conseguir mudar para desenvolvimento �gil. Poucos
> > conseguir�o sustentar esta mudan�a. E eu adoraria estar falando isso
> > de orelhada. Mas, � que eu vi as pessoas voltarem a fumar um n�mero
> > suficiente de vezes para saber que � �timo ver mais movimenta��o
> > atualmente sobre desenvolvimento �gil. Mas, acredito que seja
> > ing�nuo achar que isso implique em uma mudan�a significativa. Muitos
> > tentar�o e a maioria vai voltar �s pr�ticas antigas, simplesmente
> > porque todos os incentivos nas empresas giram em torno delas e isso
> > continuar� assim por muito tempo.
> > >
> > >
> > > Apesar de tudo o que disse, tor�o, profundamente, para estar
> > absolutamente equivocado! No mais, redobrem seus esfor�os! O desafio
> > � bem maior do que parece � primeira vista.
> > >
> > >
> > > Grande abra�o,
> > >
> > >
> > >
> > >
> > >
> > >
> > > Vin�cius Teles
> > >
> > >
> > > Improve It
> > > Rio: +55 21 3521-6760
> > > S�o Paulo: +55 11 3711-3423
> > > Celular: +55 21 8716-5434
> > >
> > >
> > > Em 26/03/2008, �s 03:48, Juan Bernabo escreveu:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Pessoal,
> > >
> > > Desculpem mais talvez pelo horario fiquei nostalgico, coisa de
> > tanguero, bom vou fazer uma retrospectiva sobre como vejo o que tem
> > acontecido nos �ltimos anos na saga de Agile no Brasil que � claro �
> > completamente ego c�ntrica e limitada vis�o dos fatos e gostaria
> > tambem ter a contribui��o de quem quiser agregar fatos a esta
> > historia.
> > >
> > > Eu me lembro da vez que veio ao Brasil o Kent Beck, Scott Ambler,
> > Rob Mee e uma galera muito legal para o evento XP 2002 organizado
> > pelo Klaus Wuestefeld e sua empresa na epoca, naquela �poca eu
> > estava lan�ando um piloto da revista Object Magazine Brasil, que foi
> > um sucesso de audi�ncia, porem um fracasso de bilheteria, e com a
> > id�ia de falar do ciclo de vida completo de desenvolvimento de
> > software, n�o s� de programa��o, porque o que eu via como um dos
> > grandes problemas era a falta de integra��o entre as disciplinas, as
> > pessoas e que isso me parecia estar no cerne da crise do software,
> > la estava o Vinicius da ImproveIt, o Fabio Kon da USP e outras
> > personalidades do mundo �gil.
> > >
> > > Isso foi em 2002, parece um seculo, teve o XP 2004 com um pouco
> > menos de ruido, e depois parece que ouve um inverno, em 2005 e 2006
> > depois de tentar em varias empresas de fazer o que eu sei que �
> > entregar software de forma iterativa e incremental e evolutiva e ter
> > conflitos com os mais variados tipos de planos malucos, processos, e
> > politicas disfuncionais acabei me decidindo a mudar de negocio, n�o
> > mais ter que brigar de dentro de uma organiza��o para tentar mudar
> > politicas que colocam em risco projetos, e fazer que as empresas com
> > suficiente dor e/ou disposi��o para mudar possam me contratar para
> > ajudar-las a fazer isso.
> > >
> > > Em 2006 foi uma dureza fechar algum contrato, nenhum gerente ou
> > diretor queria saber de outra coisa que n�o fosse CMMI/MPSbr/RUP,
> > naquela epoca eu come�ei a tentar sair da toca e conheci algumas
> > pessoas na lista CMM-Brasil, hoje morta e encarnada na CMMI-Brasil,
> > que tambem estabam falando sobre Agile e com serias criticas ao que
> > empresas estavam adotando, e a gente sacudeu um pouquinho a poeira
> > num primeiro Mini-Workshop de Gerenciamento �gil de Projetos entre o
> > Marcio Tierno, Jose Papo, Adail Retamal e eu e depois numasegunda
> > edi��o organizado pelo PMI-SP que tamb�m foi muito bem.
> > >
> > > Em 2007 come�ou para mim a maratona de Scrum no Brasil,
> > organizando treinamentos em varias capitais e fazendo palestras e
> > webcasts adoidado, muito barulho em listas, e conseguimos que
> > centenas de pessoas fissem o treinamento de CSM, para mim Scrum
> > seria a arma fundamental para poder criar celulas de produ��o de
> > software auto-geridas que pudessem adotar processos/praticas �geis
> > vindas do XP/FDD/Lean ou qualquer outra coisa que pudesse agregar
> > valor a produzir software pronto em duas a quatro semanas.
> > >
> > > Como empresas n�o queriam ouvir falar de Agile/Scrum, a estrategia
> > foi come�ar pelas pessoas, aqueles indiv�duos que mesmo que a
> > empresa n�o pagasse o treinamento o fariam por conta da convic��o ou
> > da dor da forma de trabalhar atual, e estes seriam os "early
> > adopters" que acabariam evangelizando Scrum/Agile em suas
> > organiza��es.
> > >
> > > Depois disto come�ou a emerger e sair do anonimato, pelo menos
> > para mim, uma galera talentossisima que n�o vou me atrever a falar
> > todos os nomes, e Agile deixou de ser sin�nimo de coisa de
> > programador adolescente revoltado e passou a ser coisa de gente
> > grande, o que sempre foi... mais....
> > >
> > > Em 2008 ainda tem profissional que paga do seu bolso, mais muita
> > muita empresa deixou a certeza de um futuro melhor cheio de
> > processos altamente definidos, muitos documentos e matrizes de
> > rastreabilidade, pela simplicidade e foco em resultados de Agile.
> > >
> > > Na virada do ano perdemos pelo menos uns 3 a 4 grandes valores na
> > comunidade �gil no Brasil para outros pa�ses, que v�o ser muito
> > dif�ceis repor, espero que estem bem por la Shoes, Danilo, F�bio...
> > >
> > > Neste ano come�ou a crescer e se fortalecer um pequeno eco-sistema
> > de profissionais, consultores, empresas que � fundamental para uma
> > adop��o em massa possa ser realizada na nossa industria para
> > realmente ser relevante.
> > >
> > > Por isso creio que o mercado esta mudando, falta muito ainda
> > desmistificar as abordagens �geis, educar e mostrar cases de grandes
> > implanta��es que j� est�o acontecendo aqui no Brasil e seus
> > resultados.
> > >
> > > Bom agora algumas previs�es para este e os pr�ximos anos....
> > >
> > > Acredito que no Brasil as mudan�as / adop��o ser� muito mais
> > abrupta do que em outros pa�ses do mundo, e a adop��o de Agile em
> > todas suas variantes sobre tudo em processos h�bridos com gest�o
> > baseada em Scrum ou Kanban e TOC e engenharia baseada em XP, FDD e
> > sobre tudo com conceitos de Lean Software Development � o que me
> > parece que vai cada vez mais o caminho para implanta��es serias.
> > >
> > > Este ano v�o sair do papel Agile Alliance Brasil, Forum Agile
> > 2008, Agile Magazine Brasil, como deveria ter se chamado a Object
> > Magazine de 2002, novos treinamentos com personalidades
> > internacionais, e outros colegas tamb�m est�o em vento em popa
> > fazendo um monte de coisas, desde treinamentos, coaching, palestras,
> > revistas, tudo para aumentar a adop��o e deixar TI um pouco mais
> > �gil aqui no Brasil.
> > >
> > > Quem sabe o slogam "For a Faster, Cheaper, Better & Cooler IT"
> > pegue...
> > >
> > > Abra�os,
> > > Juan.
> > > PD: quem quiser colaborar nestas empreitadas � s� mandar um email.
> > >
> > > --
> > > TeamWare do Brasil
> > > Equipes Altamente Eficazes
> > > Agilidade, Pessoas e Tecnologia
> > > S�o Paulo: +55 (11) 5061-8221
> > > Brasilia: +55 (61) 9969-9282
> > > Boston: +1 (617) 507-1490
> > > Buenos Aires: +54 9 (11) 68195600
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
> Vin�cius Teles
>
> Improve It
> Rio: +55 21 3521-6760
> S�o Paulo: +55 11 3711-3423
> Celular: +55 21 8716-5434
>

Oi Vinicius,

Concordo com tudo que você escreveu, exceto essa parte:

> (...) Percebi, com o tempo, que podemos
> fazer diferença na base, sim, mas é muito pequena e, freqüentemente efêmera.

Não acho que o resultado do seu trabalho tenha sido pequeno ou efêmero
nesses seis anos. Eu e mais dezenas, centenas ou mais até, dos que
hoje acreditam em desenvolvimento ágil sofreram influência direta do
seu trabalho de orientação e divulgação. Não acredito que haja uma só
pessoa que tenha estudado ou lido um pouco que seja sobre
desenvolvimento ágil e não tenha se deparado com seu nome ou com os
materiais que você já publicou. É certo que a maioria desses que
acreditam e que já se convenceram que essa é a melhor forma de
trabalhar com desenvolvimento de software não estão em posições de
decisão dentro das empresas. Mas o que não podemos esquecer é que
aqueles que estão na base hoje serão os futuros líderes e gestores
daqui a cinco ou dez anos.  Ou seja, talvez você já tenha feito uma
diferença bastante grande, só ainda não deu tempo de percebê-la.

Agora, quer minha opinião sincera? Não somos nós que vamos convencer
quem está no topo. É o mercado internacional.No Brasil é assim que as
coisas funcionam. Aqui pouco se cria, muito se copia.  Ou seja, depois
que agile se firmar de forma definitiva como mainstream (tudo indica
que vai) lá fora, basta contar mais cinco anos que, aí sim, nós
veremos todo mundo dizendo que faz agile por aqui. Quer um exemplo que
se encaixa perfeitamente com a questão que você levantou? Orientação a
objetos. Você conhece alguma empresa hoje que não assume com todas as
letras que seu software foi desenvolvido usando OO? No entanto, se 1%
delas realmente usam OO e se beneficiam do paradigma eu já diria que é
muito. E olha que esse paradigma tem mais de 30 anos! Quantas
faculdades realmente ensinam OO hoje? Alguém aqui dessa lista aprendeu
OO de verdade na faculdade que estudou? Quem aqui abriu o GoF em uma
sala de aula? Mesmo décadas depois de o paradigma se firmar, quem
entra na faculdade hoje aprende a programar em Pascal estruturado!
Acho que agile vai sofrer do mesmo mal quando virar mainstream aqui no
Brasil. Todo mundo vai dizer que faz, mas poucos farão de verdade. A
SEI vai dar um jeito de se adaptar, as empresas vão dar um jeito de se
adaptar, as universidades vão dar um jeito de se adaptar, mas poucos
entenderão de verdade o significado do que está descrito no manifesto.

Apesar disso tudo, eu ainda acho que vale a pena vestir essa camisa.
Nem tanto para buscar convencer aqueles que ainda apostam no modelo
tradicional, mas por aqueles que já subiram no nosso barco e que agora
precisam saber o que fazer pra ter sucesso nessa nova abordagem.

Um grande abraço,
Alisson Vale

Em 27/03/08, Vinicius Manhaes Teles <vinicius@...> escreveu:
>
>
>
>
>
>
>
> Oi, Juan.
>
>
> Minha resposta curta para a sua pergunta é: sim, o mercado está mudando. Ele
está sempre mudando. :-) Mas, talvez não tanto assim quanto gostaríamos e,
possivelmente, não na direção que desejamos. Uma das mudanças mais perceptíveis
é que cada vez mais gente tem ouvido falar de desenvolvimento ágil. Mas, isso
não quer dizer necessariamente que cada vez mais gente esteja adotando métodos
ágeis. Certamente, cada vez mais gente DIZ estar usando métodos ágeis. Mas, a
distância entre o DIZER e o FAZER é imensa, sobretudo nesta área. Acredito que,
daqui por diante, veremos cada vez mais gente falando sobre desenvolvimento
ágil, mas continuaremos a ver poucos usando. Há algumas razões fundamentais para
isso.
>
>
> Desenvolvimento ágil não tem a ver com Scrum, XP, FDD, Lean ou seja lá qual
for o nome. Tem a ver, acima de tudo, com a maneira como encaramos
desenvolvimento de software. Tem a ver com a compreensão da verdadeira NATUREZA
do desenvolvimento de software. Os anos passam, mas a maioria absoluta das
pessoas não consegue se livrar da idéia de que desenvolver software seja igual a
construir prédio. As conseqüências desta dissonância cognitiva são infinitamente
mais sérias do que a maioria de nós gostaria de acreditar. Escrevi
exaustivamente sobre isso na minha dissertação
(http://www.improveit.com.br/xp/dissertacaoXP.pdf, cápitulos 3 e 4), então, não
vou me estender aqui. Apenas resumirei porque isso é tão prejudicial.
>
>
> O que uma empresa produz é resultado de como ela está estruturada. Quem tem
autoridade para dizer como deve ser a estrutura de uma empresa é quem está no
topo. Então, a estrutura de qualquer é empresa é, no fim das contas, o resultado
do modo de pensar, da mentalidade, de quem está no comando. A mentalidade da
maioria dos empresários, diretores e gerentes no mundo inteiro é, com raríssimas
exceções, arcaica e incompatível com o trabalho de desenvolver software. Quando
o topo da empresa não entende o tipo de mentalidade necessária para se
desenvolver software de forma bem sucedida, não há santo que possa fazer
milagre. E eu garanto, a maioria absoluta das pessoas que estão no comando das
empresas não entende uma vírgula do que significa desenvolver software. Isso
inclui, certamente, a maioria absoluta dos CIOs. Não é à toa que eles buscam
recorrentemente coisas como CMMI, PMBOK, MPS.BR, ITIL etc, todos absolutamente
incompatíveis com a NATUREZA do desenvolvimento de software. A mentalidade por
trás destas aberrações é inútil, quando o assunto é software, mas casa
perfeitamente com a mentalidade da maioria dos gestores. E não pára por aí. Nas
universidades, a situação é igual ou pior.
>
>
> Veja o caso da UFRJ, por exemplo. Neste semestre, o professor de engenharia de
software, percebendo a crescente movimentação em torno de métodos ágeis,
resolveu gastar boa parte do seu tempo para mostrar aos alunos que métodos como
o XP não funcionam. Afinal, se fôssemos fazer um prédio com XP, aconteceria mil
e uma coisas horrendas. Nisso ele está certo. O problema, como sempre, é a
maldita distinção entre construir prédio e desenvolver software, a qual, seria
óbvia para uma criança, mas é impossível de ser percebida por um Ph.D(eus). Olha
que loucura, em uma universidade do quilate da UFRJ, o cidadão, só porque é
Ph.D.(eus), não precisa se dar ao trabalho de estudar sobre métodos ágeis, nem
muito menos usá-lo, para já saber, desde criancinha, que não pode dar certo. E
claro, um conhecimento destes, tão valioso, não pode ser mantido só para ele.
Também é preciso passar adiante para os alunos, como se fosse necessário.
Afinal, eles já estão todos estagiando em empresas entupidas de documentos e
péssimas práticas de desenvolvimento até o último fio de cabelo.
>
>
> Sempre fui muito otimista, em tudo. Mas, em se tratando de desenvolvimento
ágil, acho que meu otimismo se foi. Foram precisos seis anos para isso
acontecer, devo dizer, mas se foi. E a razão está lá em cima, no topo das
empresas, no topo das universidades. Está lá onde a mediocridade e a
incompetência imperam, ao menos em se tratando de desenvolvimento de software e
gestão de pessoas. Percebi, com o tempo, que podemos fazer diferença na base,
sim, mas é muito pequena e, freqüentemente efêmera.
>
>
> Fiquei tempo suficiente nesta área para ver equipes adotarem XP, funcionarem
super bem durante algum tempo e, mais a frente, serem impedidas de continuar
porque a organização passa minar o andamento do grupo. É como um corpo estranho,
que é expelido naturalmente pelas nossas células. Só para dar um exemplo. Em
2003, nós fizemos um projeto XP para a Vale do Rio Doce. Foi um projeto lindo,
com tudo que se tinha direito. Até contrato de escopo negociável. As áreas de
negócio amaram tudo o que foi feito. Adoravam os desenvolvedores. Depois que o
sistema foi colocado no ar, foram encontrados apenas 3 bugs durante os seis
meses seguintes. Isso é nada em um projeto de mais de um ano, com mais de dez
pessoas envolvidas. O projeto foi um sucesso em praticamente todos os quesitos
que se pudesse imaginar. Mas, aí é que estava o problema. A última coisa que
alguém quer é um projeto de sucesso! Afinal, como ficam os demais? Quando o
projeto acabou, tudo foi feito dentro da Vale para que nunca mais isso se
repetisse. Acredite, não foi a única vez que vi isso acontecer. Em seis anos, eu
vi muita coisa começar bem e, mais a frente, acabar. Por que?
>
>
> Porque desenvolver software com a mentalidade ágil não é compatível com a
mentalidade de quem manda. Isso é mais do que suficiente para limitar as
mudanças na área de software. Acredito que vai levar muito tempo para que as
empresas passem a ter gestores que compreendam não apenas o que é fazer
software. Mas, o que é fazer um trabalho do conhecimento. A maioria absoluta dos
gestores tratam seus funcionários como se fossem crianças. Fica parecendo que os
piores imbecis são justamente os que mais freqüentemente são escolhidos para
comandar as empresas. Não parece apenas, isso realmente acontece e dói ver o
quanto isso é comum. Enquanto estes estiverem lá em cima, vamos ouvir falar
muito sobre desenvolvimento ágil. Mas é só. Aliás, não é não. Tem coisa pior.
Vamos ver pessoas fazendo barbaridades e dizendo que estão usando
desenvolvimento ágil.
>
>
> Para quem ainda estiver no ramo de consultoria, isso não é necessariamente
ruim. Essa área vai bombar. Vamos ter cada vez mais espaço para cursos e
consultoria em desenvolvimento ágil. O interesse só vai crescer daqui por
diante. Não necessariamente pelos méritos, mas porque alguém ouviu dizer que
agora o grande lance é fazer software com a ___________ (preencha com a
metodologia ágil preferida).
>
>
> O problema dos gestores não afeta apenas o desenvolvimento de software. Ele é
muito mais sério e muito mais abrangente que isso. Entre em qualquer empresa
grande e o que você verá é um bando de trabalhadores do conhecimento sendo
tratados como pedreiros por um bando de incompetentes que não conseguem fazer
nada melhor que jogar tempo e dinheiro na lata de lixo. O nível de desperdício
de talento, tempo, dinheiro, oportunidades etc é tão colossal que eu realmente
não consigo compreender como alguém consegue trabalhar em uma empresa grande
atualmente. Claro, existem exceções. Pouquíssimas, mas existem. São apenas isso,
exceções.
>
>
> Desejo muita sorte e sucesso para quem continua lutando para mudar este
panorama. Não tenho dúvidas de que as coisas irão melhorar ao longo do tempo.
Mas, acho bastante improvável que uma mudança significativa aconteça no curto ou
médio prazo. Enquanto as pessoas chegarem no topo das empresas com a mentalidade
que temos hoje em dia, enquanto os professores universitários continuarem
ensinando lixo, enquanto as empresas continuarem a ganhar dinheiro apesar das
práticas de administração arcaicas que utilizam, enquanto nós aceitarmos
trabalhar para estes idiotas, vai ser complicado.
>
>
> Desculpa pelo pessimismo. Não foi sempre assim. Foram necessários seis anos,
seis turmas de XP na UFRJ, literalmente centenas de apresentações de XP em todo
o Brasil, um mestrado, não sei quantos cursos, vários mentorings, alguns
projetos de desenvolvimento XP, algumas conferências no exterior, um livro e
mais um monte de coisas que eu não lembro, para me dobrar. E antes que alguém
pense que o problema era o XP e que tudo poderia ser diferente se tivesse sido
Scrum, FDD, Lean etc, não se enganem. O buraco é mais embaixo. Se você conseguiu
chegar até aqui e prestou atenção ao que estou dizendo, tudo se resume a uma
coisa: mudar é difícil? É. Mas, ainda é a parte fácil. O difícil mesmo é mudar
de vez.
>
>
> O Kent Beck tem um exemplo ótimo. Segundo ele, parar de fumar é fácil. Tanto
que tem gente que já parou várias vezes. :-) O problema é parar e nunca mais
voltar a fumar. É a mesma coisa. Um monte de gente vai conseguir mudar para
desenvolvimento ágil. Poucos conseguirão sustentar esta mudança. E eu adoraria
estar falando isso de orelhada. Mas, é que eu vi as pessoas voltarem a fumar um
número suficiente de vezes para saber que é ótimo ver mais movimentação
atualmente sobre desenvolvimento ágil. Mas, acredito que seja ingênuo achar que
isso implique em uma mudança significativa. Muitos tentarão e a maioria vai
voltar às práticas antigas, simplesmente porque todos os incentivos nas empresas
giram em torno delas e isso continuará assim por muito tempo.
>
>
> Apesar de tudo o que disse, torço, profundamente, para estar absolutamente
equivocado! No mais, redobrem seus esforços! O desafio é bem maior do que parece
à primeira vista.
>
>
> Grande abraço,
>
>
>
>
>
>
> Vinícius Teles
>
>
> Improve It
> Rio: +55 21 3521-6760
> São Paulo: +55 11 3711-3423
> Celular: +55 21 8716-5434
>
>
> Em 26/03/2008, às 03:48, Juan Bernabo escreveu:
>
>
>
>
>
>
>
> Pessoal,
>
> Desculpem mais talvez pelo horario fiquei nostalgico, coisa de tanguero, bom
vou fazer uma retrospectiva sobre como vejo o que tem acontecido nos últimos
anos na saga de Agile no Brasil que é claro é completamente ego cêntrica e
limitada visão dos fatos e gostaria tambem ter a contribuição de quem quiser
agregar fatos a esta historia.
>
> Eu me lembro da vez que veio ao Brasil o Kent Beck, Scott Ambler, Rob Mee e
uma galera muito legal para o evento XP 2002 organizado pelo Klaus Wuestefeld e
sua empresa na epoca, naquela época eu estava lançando um piloto da revista
Object Magazine Brasil, que foi um sucesso de audiência, porem um fracasso de
bilheteria, e com a idéia de falar do ciclo de vida completo de desenvolvimento
de software, não só de programação, porque o que eu via como um dos grandes
problemas era a falta de integração entre as disciplinas, as pessoas e que isso
me parecia estar no cerne da crise do software, la estava o Vinicius da
ImproveIt, o Fabio Kon da USP e outras personalidades do mundo Ágil.
>
> Isso foi em 2002, parece um seculo, teve o XP 2004 com um pouco menos de
ruido, e depois parece que ouve um inverno, em 2005 e 2006 depois de tentar em
varias empresas de fazer o que eu sei que é entregar software de forma iterativa
e incremental e evolutiva e ter conflitos com os mais variados tipos de planos
malucos, processos, e politicas disfuncionais acabei me decidindo a mudar de
negocio, não mais ter que brigar de dentro de uma organização para tentar mudar
politicas que colocam em risco projetos, e fazer que as empresas com suficiente
dor e/ou disposição para mudar possam me contratar para ajudar-las a fazer isso.
>
> Em 2006 foi uma dureza fechar algum contrato, nenhum gerente ou diretor queria
saber de outra coisa que não fosse CMMI/MPSbr/RUP, naquela epoca eu começei a
tentar sair da toca e conheci algumas pessoas na lista CMM-Brasil, hoje morta e
encarnada na CMMI-Brasil, que tambem estabam falando sobre Agile e com serias
criticas ao que empresas estavam adotando, e a gente sacudeu um pouquinho a
poeira num primeiro Mini-Workshop de Gerenciamento Ágil de Projetos entre o
Marcio Tierno, Jose Papo, Adail Retamal e eu e depois numasegunda edição
organizado pelo PMI-SP que também foi muito bem.
>
> Em 2007 começou para mim a maratona de Scrum no Brasil, organizando
treinamentos em varias capitais e fazendo palestras e webcasts adoidado, muito
barulho em listas, e conseguimos que centenas de pessoas fissem o treinamento de
CSM, para mim Scrum seria a arma fundamental para poder criar celulas de
produção de software auto-geridas que pudessem adotar processos/praticas ágeis
vindas do XP/FDD/Lean ou qualquer outra coisa que pudesse agregar valor a
produzir software pronto em duas a quatro semanas.
>
> Como empresas não queriam ouvir falar de Agile/Scrum, a estrategia foi começar
pelas pessoas, aqueles indivíduos que mesmo que a empresa não pagasse o
treinamento o fariam por conta da convicção ou da dor da forma de trabalhar
atual, e estes seriam os "early adopters" que acabariam evangelizando
Scrum/Agile em suas organizações.
>
> Depois disto começou a emerger e sair do anonimato, pelo menos para mim, uma
galera talentossisima que não vou me atrever a falar todos os nomes, e Agile
deixou de ser sinônimo de coisa de programador adolescente revoltado e passou a
ser coisa de gente grande, o que sempre foi... mais....
>
> Em 2008 ainda tem profissional que paga do seu bolso, mais muita muita empresa
deixou a certeza de um futuro melhor cheio de processos altamente definidos,
muitos documentos e matrizes de rastreabilidade, pela simplicidade e foco em
resultados de Agile.
>
> Na virada do ano perdemos pelo menos uns 3 a 4 grandes valores na comunidade
Ágil no Brasil para outros países, que vão ser muito difíceis repor, espero que
estem bem por la Shoes, Danilo, Fábio...
>
> Neste ano começou a crescer e se fortalecer um pequeno eco-sistema de
profissionais, consultores, empresas que é fundamental para uma adopção em massa
possa ser realizada na nossa industria para realmente ser relevante.
>
> Por isso creio que o mercado esta mudando, falta muito ainda desmistificar as
abordagens ágeis, educar e mostrar cases de grandes implantações que já estão
acontecendo aqui no Brasil e seus resultados.
>
> Bom agora algumas previsões para este e os próximos anos....
>
> Acredito que no Brasil as mudanças / adopção será muito mais abrupta do que em
outros países do mundo, e a adopção de Agile em todas suas variantes sobre tudo
em processos híbridos com gestão baseada em Scrum ou Kanban e TOC e engenharia
baseada em XP, FDD e sobre tudo com conceitos de Lean Software Development é o
que me parece que vai cada vez mais o caminho para implantações serias.
>
> Este ano vão sair do papel Agile Alliance Brasil, Forum Agile 2008, Agile
Magazine Brasil, como deveria ter se chamado a Object Magazine de 2002, novos
treinamentos com personalidades internacionais, e outros colegas também estão em
vento em popa fazendo um monte de coisas, desde treinamentos, coaching,
palestras, revistas, tudo para aumentar a adopção e deixar TI um pouco mais Ágil
aqui no Brasil.
>
> Quem sabe o slogam "For a Faster, Cheaper, Better & Cooler IT" pegue...
>
> Abraços,
> Juan.
> PD: quem quiser colaborar nestas empreitadas é só mandar um email.
>
> --
> TeamWare do Brasil
> Equipes Altamente Eficazes
> Agilidade, Pessoas e Tecnologia
> São Paulo: +55 (11) 5061-8221
> Brasilia: +55 (61) 9969-9282
> Boston: +1 (617) 507-1490
> Buenos Aires: +54 9 (11) 68195600
>
>
>
>
>
>
>
>
>

Pessoal,

Essa é para aqueles que estiverem usando Ruby on Rails. Nós acabamos
de publicar um plugin para facilitar o processo de integração
contínua. Se alguém aí precisar de algo assim, basta dar uma olhada em:

http://integration.rubyforge.org

Grande abraço,

Vinícius Teles

Variantes de Scrum tem sido amplamente adotadas com muito sucesso em projetos no mundo inteiro por empresas como Fuji-Xerox, Cannon, Honda, NEC, Epson, Brother, 3M, Xerox e Hewlett Packard.

O Scrum é utilizado atualmente como fundamento para os mais importantes frameworks de processos de desenvolvimento de software do mercado. Ele é a base da disciplina de gestão de projetos da instância open source do RUP, o OpenUP. É também utilizado como base da gestão de projetos do processo da Microsoft, o MSF Agile.

Objetivos

Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades:

• Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento.
• Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum.
• Melhorar a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento.
• Melhorar a produtividade da equipe de desenvolvimento de todas as formas possíveis
• Melhorar as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável.

• O que é Scrum?
• Porque Scrum funciona
• O que é a arte do possível?
• O que é o fluxo do Scrum?
• O que significa desenvolvimento iterativo e incremental?
• O jogo Scrum 59
• Planejamento e estimativas ágeis
• Retrospectivas de Sprints
• Como implementar Scrum a partir de uma posição sem poder
• A diferença entre planejamento e uma reunião de planejamento
• Planejamento estrategico e planejamento tático
• A reunião do Scrum e como trabalhar com uma lista de tarefas
• O jogo da Velocidade - planejando e fazendo em ação
• Escalando Scrum

Onde e Quando?

• As classes iniciam as 8:30 com o registro
• No primeiro dia a aula termina às 18:30 e no segundo dia às 17:00
• Almoços, coffe-break e estacionamento estão inclusos
• Hotel Mercure Batel - Curitiba
  

Como se registrar?

--
TeamWare do Brasil
Equipes Altamente Eficazes
Agilidade, Pessoas e Tecnologia
Tel: +55 (11) 5061-8221

Tales,

Dois monitores, mesmo conteúdo, um teclado e um mouse. O teclado e o
mouse eram empurrados de um lado para o outro quando o piloto mudava.

Abraço,
Luiz Esmiralha

2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>
>
>
>
>
>
> Oi, Esmiralha.
>
>  Só para confirmar: os dois monitores com o mesmo conteúdo, não é isso? Um
> ou
>  dois teclados?
>
>  Valeu.
>
>  Tales
>
>
>  ----- Original Message -----
>  From: "Luiz Esmiralha" <esmiralha@...>
>  To: <xprio@yahoogroups.com>
>  Sent: Monday, March 03, 2008 1:04 PM
>  Subject: Re: [xprio] programação em par com dois monitores
>
>
>  Clavius,
>
>  Já fiz Pair Programming assim e acho a situação ideal do ponto de
>  vista ergonômico. Não senti também nenhuma barreira à comunicação
>  fazendo dessa forma.
>
>  Abraço,
>  Luiz Esmiralha
>
>  2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > Oi, pessoal.
>  >
>  > Explicando como funciona XP a um pessoal de uma empresa parceira nossa,
> um
>  > deles perguntou sobre a possibilidade de utilizar dois monitores no mesmo
>  > computador, com o mesmo conteúdo na tela, para facilitar a questão do
>  > espaço
>  > na programação em par. Alguém aqui já fez isso? Como foi o resultado?
>  >
>  > Um abraço.
>  >
>  > Clavius Tales
>  > Diretor de Desenvolvimento
>  > Fortes Informática [Fortaleza]
>  > (85)4005-1111
>  > tales@...
>  > www.fortesinformatica.com.br
>
>  ===================================================
>  Acesse o Blog do XPRio: http://xprio.blogspot.com
>  ===================================================
>  Mais dados sobre XP: http://www.improveit.com.br/xp
>  Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
>  Yahoo! Groups Links
>
>

Tales, essa idéia de ter 2 monitores, sendo utilizado pela dupla, no mesmo
terminal de desenvolvimento, cada um com teclado, isso pode gerar algum
desconforto
entre a dupla, imagine que no meio do desenvolvimento, o parceiro da dupla
queira dar uma opnião, e ao invés de falar a opnião ele escreva, essa
possibilidade
é real e com certeza absoluta corre-se o risco de criar um conflito entre
a dupla. O ideal seria ter sim 2 monitores, sempre fui apto a isto, porém
apenas um teclado, para poder ficar revezando o mesmo, além de que com 2
teclados você perde um pouco a concentração no que o outro esta fazendo.

minha opnião seria esta.
abraço a todos.


>-- Mensagem Original --
>To: <xprio@yahoogroups.com>
>From: Clavius Tales (Fortes Informática) <tales@...>
>Date: Mon, 3 Mar 2008 20:59:35 -0300
>Subject: Re: [xprio] programação em par com dois monitores
>Reply-To: xprio@yahoogroups.com
>
>
>Desculpa, pessoal. Deixa eu explicar melhor. A idéia é ter dois monitores,
>
>mas o mesmo conteúdo (sinal) nas duas telas. Só para facilitar a questão
>da
>ergonomia. Para o par não ter que ficar se amontoando para ver a mesma tela.
>
>Ficariam eles lado a lado, mas cada um com seu monitor, seu teclado e seu
>
>mause, mas olhando e mexendo no mesmo conteúdo. Deu para entender?
>
>Um abraço.
>
>Tales
>
>----- Original Message -----
>From: "Marcos Tapajos" <tapajos@...>
>To: <xprio@yahoogroups.com>
>Sent: Monday, March 03, 2008 7:50 PM
>Subject: Re: [xprio] programação em par com dois monitores
>
>
>Eu e o Vinícius já usamos isso em uma empresa e funcionava bem. :-)
>Com dois monitores você pode abrir IDE + API + um monte de coisas.
>Sempre acho isso bom !
>
>[]'s
>
>Em 03/03/2008, às 11:56, Clavius Tales (Fortes Informática) escreveu:
>
>> Oi, pessoal.
>>
>> Explicando como funciona XP a um pessoal de uma empresa parceira
>> nossa, um deles perguntou sobre a possibilidade de utilizar dois
>> monitores no mesmo computador, com o mesmo conteúdo na tela, para
>> facilitar a questão do espaço na programação em par. Alguém aqui já
>> fez isso? Como foi o resultado?
>>
>> Um abraço.
>>
>> Clavius Tales
>> Diretor de Desenvolvimento
>> Fortes Informática [Fortaleza]
>> (85)4005-1111
>> tales@...
>> www.fortesinformatica.com.br
>
>Marcos Tapajós
>http://www.improveit.com.br
>Rio: +55 21 3521-6760
>São Paulo: +55 11 3711-3423
>Celular: +55 21 8709-8693
>
>
>
>===================================================
> Acesse o Blog do XPRio: http://xprio.blogspot.com
>===================================================
>Mais dados sobre XP: http://www.improveit.com.br/xp
>Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
>Yahoo! Groups Links
>
>
>
>

Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
Sun Certified Java Associate
http://pplupo.googlepages.com/
Cell. +55 (21) 81742487

Sem problema, Peter. Estava meio perdido também. Só joguei aquela mensagem pra ver se ajudava em alguma coisa.
Um abraço.
Tales
----- Original Message ----- From: "Peter Lupo" <peterplupo@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 2:40 PM
Subject: Re: [xprio] "Metodologias Tradicionais"
Não, não Clavius! Que isso! Fica à vontade! Eu só tô perdido no
assunto... hehehe... se vc explicar o ponto eu comento com prazer!!!
Abraço!
2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:

Vacilo meu. Não era pra ter ressuscitado um assunto tão antigo. Foi mal.
----- Original Message -----
From: Peter
To: xprio@yahoogroups.com
Sent: Sunday, March 02, 2008 7:01 PM
Subject: Re: [xprio] "Metodologias Tradicionais"
Sinceramente eu nem sei o que responder, de tão fora do assunto original que
estamos. Todos estes cenários aí que vcs descreveram são cenários possíveis
e há outros.
Só estou respondendo para que saibam que eu li, mas sinceramente já não sei
mais qual o ponto de vcs. :¬)
Abraço!
P.S.: Achei até que esta thread tinha terminado...
Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
Sun Certified Java Associate
http://pplupo.googlepages.com/
Cell. +55 (21) 81742487
Clavius Tales (Fortes Informática) wrote:
Pois é, Esmiralha. Optei até por cenários menos ruins. Mas é isso mesmo que
você disse.
Um abraço.
Tales
----- Original Message -----
From: "Luiz Esmiralha" <esmiralha@...>
To: <xprio@yahoogroups.com>
Sent: Sunday, March 02, 2008 4:12 PM
Subject: Re: [xprio] "Metodologias Tradicionais"
2008/3/2 Clavius Tales (Fortes Informática) <tales@...>:
Oi, Peter.
----- Original Message -----
From: Peter
To: xprio@yahoogroups.com
Sent: Wednesday, February 13, 2008 10:00 AM
Subject: Re: [xprio] "Metodologias Tradicionais"
> Mas se chego numa empresa, encontro iterações de 15 dias a 1 mês,
processo
> de aprovação de mudanças com 1 dia ou dois no máximo e designs que são
> detalhados aos poucos e até um nível não tão micro por analistas que
> também são o desenvolvedores eu não consigo responder à pergunta. Esse
é
> que é o ponto. Vc construiu um cenário impossível para uma cultura
ágil,
> mas poderia ter construído um cenário que não fosse impossível, como
este
> que eu citei. Este cenário que eu citei pode ser tradicionalista e se
vc
> não levar isto em consideração estará chamando algumas culturas
> tradicionalistas de ágeis. Simplesmente pq essas características que vc
> citou são suficientes, mas não são completas. Podem não estar presentes
e
> a cultura ainda ser tradicionalista.
Estou meio perdido na discussão - tenho mais de 300 emeios para ler. Mas
vou
citar um exemplo que aconteceu aqui na empresa que talvez dê indicativos
dessa diferença cultural.
Certo dia especifiquei um relatório (desenhei o leiaute) que queria e
passei
para um programador. Quando começou a programar e recebeu "feedback", ele
percebeu que alguns pontos daquilo que eu havia especificado não estavam
tão
bons, já que ele também conhece o sistema, pela disseminação do
conhecimento. Imediatamente ele chegou para mim (Sentar Junto) e disse:
- Tales, isso aqui não vai funcionar por causa disso, disso e disso aqui.
Que tal fazermos dessa forma?
Na mesma hora eu disse:
- Perfeito. Pode fazer.
E fez.
Num esquema tradicional, alguns exemplos de como isso poderia ter
funcionado:
Primeiro cenário:
O programador fazia como especificado, afinal não era problema dele se o
especificador não fez o trabalho dele direito.
Segundo cenário:
O programador fazia como especificado, mas na próxima oportunidade
falaria
sobre o problema sobre o problema.
Terceiro cenário:
O programador conversaria imediatamente com o especificador, que diria:
"Vou
atualizar a especificação. Já já te mando."
Em esquemas tradicionais, esses problemas acontecem aos montes, que
travam
enormemente o processo de desenvolvimento.
Tales,
Num esquema realmente tradicional, acho que o cenário é mais parecido com
esse:
O programador procura o especificador para perguntar o que fazer. O
especificador não está mais no projeto porque a fase de design já
acabou. O programador implementa do jeito que está especificado. 6
meses depois quando o sistema é entregue, o usuário percebe o
problema, solicita uma mudança e paga 100x mais caro do que teria sido
consertar quando o problema foi identificado.
Abraço,
Luiz
===================================================
Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links
===================================================
Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Desculpa, pessoal. Deixa eu explicar melhor. A idéia é ter dois monitores,
mas o mesmo conteúdo (sinal) nas duas telas. Só para facilitar a questão da
ergonomia. Para o par não ter que ficar se amontoando para ver a mesma tela.
Ficariam eles lado a lado, mas cada um com seu monitor, seu teclado e seu
mause, mas olhando e mexendo no mesmo conteúdo. Deu para entender?

Um abraço.

Tales

----- Original Message -----
From: "Marcos Tapajos" <tapajos@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 7:50 PM
Subject: Re: [xprio] programação em par com dois monitores


Eu e o Vinícius já usamos isso em uma empresa e funcionava bem. :-)
Com dois monitores você pode abrir IDE + API + um monte de coisas.
Sempre acho isso bom !

[]'s

Em 03/03/2008, às 11:56, Clavius Tales (Fortes Informática) escreveu:

> Oi, pessoal.
>
> Explicando como funciona XP a um pessoal de uma empresa parceira
> nossa, um deles perguntou sobre a possibilidade de utilizar dois
> monitores no mesmo computador, com o mesmo conteúdo na tela, para
> facilitar a questão do espaço na programação em par. Alguém aqui já
> fez isso? Como foi o resultado?
>
> Um abraço.
>
> Clavius Tales
> Diretor de Desenvolvimento
> Fortes Informática [Fortaleza]
> (85)4005-1111
> tales@...
> www.fortesinformatica.com.br

Marcos Tapajós
http://www.improveit.com.br
Rio: +55 21 3521-6760
São Paulo: +55 11 3711-3423
Celular: +55 21 8709-8693



===================================================
  Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Sem problema, Peter. Estava meio perdido também. Só joguei aquela mensagem
pra ver se ajudava em alguma coisa.

Um abraço.

Tales

----- Original Message -----
From: "Peter Lupo" <peterplupo@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 2:40 PM
Subject: Re: [xprio] "Metodologias Tradicionais"


Não, não Clavius! Que isso! Fica à vontade! Eu só tô perdido no
assunto... hehehe... se vc explicar o ponto eu comento com prazer!!!

Abraço!


2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>
>
> Vacilo meu. Não era pra ter ressuscitado um assunto tão antigo. Foi mal.
>
> ----- Original Message -----
> From: Peter
> To: xprio@yahoogroups.com
>
> Sent: Sunday, March 02, 2008 7:01 PM
> Subject: Re: [xprio] "Metodologias Tradicionais"
>
> Sinceramente eu nem sei o que responder, de tão fora do assunto original
> que
> estamos. Todos estes cenários aí que vcs descreveram são cenários
> possíveis
> e há outros.
>
> Só estou respondendo para que saibam que eu li, mas sinceramente já não
> sei
> mais qual o ponto de vcs. :¬)
>
>
> Abraço!
>
> P.S.: Achei até que esta thread tinha terminado...
>
> Peter P. Lupo
> Undergraduating in Computer Science DCC/UFRJ
> Sun Certified Java Associate
> http://pplupo.googlepages.com/
> Cell. +55 (21) 81742487
>
>
> Clavius Tales (Fortes Informática) wrote:
>
> Pois é, Esmiralha. Optei até por cenários menos ruins. Mas é isso mesmo
> que
> você disse.
>
> Um abraço.
>
> Tales
>
> ----- Original Message -----
> From: "Luiz Esmiralha" <esmiralha@...>
> To: <xprio@yahoogroups.com>
> Sent: Sunday, March 02, 2008 4:12 PM
> Subject: Re: [xprio] "Metodologias Tradicionais"
>
>
> 2008/3/2 Clavius Tales (Fortes Informática) <tales@...>:
>
>
> Oi, Peter.
>
>  ----- Original Message -----
>  From: Peter
>  To: xprio@yahoogroups.com
>  Sent: Wednesday, February 13, 2008 10:00 AM
>  Subject: Re: [xprio] "Metodologias Tradicionais"
>
>  > Mas se chego numa empresa, encontro iterações de 15 dias a 1 mês,
> processo
>  > de aprovação de mudanças com 1 dia ou dois no máximo e designs que são
>  > detalhados aos poucos e até um nível não tão micro por analistas que
>  > também são o desenvolvedores eu não consigo responder à pergunta. Esse
> é
>  > que é o ponto. Vc construiu um cenário impossível para uma cultura
> ágil,
>  > mas poderia ter construído um cenário que não fosse impossível, como
> este
>  > que eu citei. Este cenário que eu citei pode ser tradicionalista e se
> vc
>  > não levar isto em consideração estará chamando algumas culturas
>  > tradicionalistas de ágeis. Simplesmente pq essas características que vc
>  > citou são suficientes, mas não são completas. Podem não estar presentes
> e
>  > a cultura ainda ser tradicionalista.
>
>  Estou meio perdido na discussão - tenho mais de 300 emeios para ler. Mas
> vou
>  citar um exemplo que aconteceu aqui na empresa que talvez dê indicativos
>  dessa diferença cultural.
>
>  Certo dia especifiquei um relatório (desenhei o leiaute) que queria e
> passei
>  para um programador. Quando começou a programar e recebeu "feedback", ele
>  percebeu que alguns pontos daquilo que eu havia especificado não estavam
> tão
>  bons, já que ele também conhece o sistema, pela disseminação do
>  conhecimento. Imediatamente ele chegou para mim (Sentar Junto) e disse:
>
>  - Tales, isso aqui não vai funcionar por causa disso, disso e disso aqui.
>  Que tal fazermos dessa forma?
>
>  Na mesma hora eu disse:
>
>  - Perfeito. Pode fazer.
>
>  E fez.
>
>  Num esquema tradicional, alguns exemplos de como isso poderia ter
>  funcionado:
>
>  Primeiro cenário:
>  O programador fazia como especificado, afinal não era problema dele se o
>  especificador não fez o trabalho dele direito.
>
>  Segundo cenário:
>  O programador fazia como especificado, mas na próxima oportunidade
> falaria
>  sobre o problema sobre o problema.
>
>  Terceiro cenário:
>  O programador conversaria imediatamente com o especificador, que diria:
> "Vou
>  atualizar a especificação. Já já te mando."
>
>  Em esquemas tradicionais, esses problemas acontecem aos montes, que
> travam
>  enormemente o processo de desenvolvimento.
>
>
>
>
> Tales,
>
> Num esquema realmente tradicional, acho que o cenário é mais parecido com
> esse:
>
> O programador procura o especificador para perguntar o que fazer. O
> especificador não está mais no projeto porque a fase de design já
> acabou. O programador implementa do jeito que está especificado. 6
> meses depois quando o sistema é entregue, o usuário percebe o
> problema, solicita uma mudança e paga 100x mais caro do que teria sido
> consertar quando o problema foi identificado.
>
> Abraço,
> Luiz
>
>
> ===================================================
>  Acesse o Blog do XPRio: http://xprio.blogspot.com
> ===================================================
> Mais dados sobre XP: http://www.improveit.com.br/xp
> Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
> Yahoo! Groups Links
>
>
>
>
>
> ===================================================
>  Acesse o Blog do XPRio: http://xprio.blogspot.com
> ===================================================
> Mais dados sobre XP: http://www.improveit.com.br/xp
> Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
> Yahoo! Groups Links
>
>
>
>
>
>



--
Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
Sun Certified Java Associate
http://pplupo.googlepages.com/
Cell. +55 (021) 81742487


===================================================
  Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Oi, Ivan.

Era a questão ergonômica, mesmo. O pessoal achou que poderia ser
desconfortável duas pessoas num mesmo computador.

Um abraço.

Tales

----- Original Message -----
From: "Ivan Sanchez" <s4nchez@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 1:04 PM
Subject: Re: [xprio] programação em par com dois monitores


Eu trabalho com dois monitores porque aumenta minha área de trabalho.
Se estou programando em par, continuo usando as 2 telas com conteúdos
diferentes. Duplicar o conteúdo pra mim não faz sentido.

2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
> Oi, pessoal.
>
> Explicando como funciona XP a um pessoal de uma empresa parceira nossa, um
> deles perguntou sobre a possibilidade de utilizar dois monitores no mesmo
> computador, com o mesmo conteúdo na tela, para facilitar a questão do
> espaço
> na programação em par. Alguém aqui já fez isso? Como foi o resultado?
>
> Um abraço.
>
> Clavius Tales
> Diretor de Desenvolvimento
> Fortes Informática [Fortaleza]
> (85)4005-1111
> tales@...
> www.fortesinformatica.com.br


===================================================
  Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Oi, Esmiralha.

Só para confirmar: os dois monitores com o mesmo conteúdo, não é isso? Um ou
dois teclados?

Valeu.

Tales

----- Original Message -----
From: "Luiz Esmiralha" <esmiralha@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 1:04 PM
Subject: Re: [xprio] programação em par com dois monitores


Clavius,

Já fiz Pair Programming assim e acho a situação ideal do ponto de
vista ergonômico. Não senti também nenhuma barreira à comunicação
fazendo dessa forma.

Abraço,
Luiz Esmiralha

2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>
>
>
>
>
>
>
> Oi, pessoal.
>
> Explicando como funciona XP a um pessoal de uma empresa parceira nossa, um
> deles perguntou sobre a possibilidade de utilizar dois monitores no mesmo
> computador, com o mesmo conteúdo na tela, para facilitar a questão do
> espaço
> na programação em par. Alguém aqui já fez isso? Como foi o resultado?
>
> Um abraço.
>
> Clavius Tales
> Diretor de Desenvolvimento
> Fortes Informática [Fortaleza]
> (85)4005-1111
> tales@...
> www.fortesinformatica.com.br


===================================================
  Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Oi, Maurício.

Sem dúvida há uma perda nesse aspecto. Mas há um ganho em ergonomia, como
bem disse o Esmiralha, que foi exatamente o aspecto que o pessoal dessa
empresa parceira citou.

Um abraço.

Tales

----- Original Message -----
From: "Maurício Linhares" <mauricio.linhares@...>
To: <xprio@yahoogroups.com>
Sent: Monday, March 03, 2008 12:16 PM
Subject: Re: [xprio] programação em par com dois monitores


Eu acho esquisito, como é que você vai ficar discutindo com o cara
olhando pro seu monitor?

É melhor comprar um monitor grande, tipo um de 21, já tem LCD de 21
por menos de 100 reais no mecado.

2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>
>
>
>
>
>
>
> Oi, pessoal.
>
> Explicando como funciona XP a um pessoal de uma empresa parceira nossa, um
> deles perguntou sobre a possibilidade de utilizar dois monitores no mesmo
> computador, com o mesmo conteúdo na tela, para facilitar a questão do
> espaço
> na programação em par. Alguém aqui já fez isso? Como foi o resultado?
>
> Um abraço.
>
> Clavius Tales
> Diretor de Desenvolvimento
> Fortes Informática [Fortaleza]
> (85)4005-1111
> tales@...
> www.fortesinformatica.com.br



--
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) |
http://codeshooter.wordpress.com/ (en)
João Pessoa, PB, +55 83 8867-7208


===================================================
  Acesse o Blog do XPRio: http://xprio.blogspot.com
===================================================
Mais dados sobre XP: http://www.improveit.com.br/xp
Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
Yahoo! Groups Links

Eu e o Vinícius já usamos isso em uma empresa e funcionava bem. :-)
Com dois monitores você pode abrir IDE + API + um monte de coisas.
Sempre acho isso bom !

[]'s

Em 03/03/2008, às 11:56, Clavius Tales (Fortes Informática) escreveu:

> Oi, pessoal.
>
> Explicando como funciona XP a um pessoal de uma empresa parceira
> nossa, um deles perguntou sobre a possibilidade de utilizar dois
> monitores no mesmo computador, com o mesmo conteúdo na tela, para
> facilitar a questão do espaço na programação em par. Alguém aqui já
> fez isso? Como foi o resultado?
>
> Um abraço.
>
> Clavius Tales
> Diretor de Desenvolvimento
> Fortes Informática [Fortaleza]
> (85)4005-1111
> tales@...
> www.fortesinformatica.com.br

Marcos Tapajós
http://www.improveit.com.br
Rio: +55 21 3521-6760
São Paulo: +55 11 3711-3423
Celular: +55 21 8709-8693

Não, não Clavius! Que isso! Fica à vontade! Eu só tô perdido no
assunto... hehehe... se vc explicar o ponto eu comento com prazer!!!

Abraço!


2008/3/3 Clavius Tales (Fortes Informática) <tales@...>:
>
>
> Vacilo meu. Não era pra ter ressuscitado um assunto tão antigo. Foi mal.
>
> ----- Original Message -----
> From: Peter
> To: xprio@yahoogroups.com
>
> Sent: Sunday, March 02, 2008 7:01 PM
> Subject: Re: [xprio] "Metodologias Tradicionais"
>
> Sinceramente eu nem sei o que responder, de tão fora do assunto original que
> estamos. Todos estes cenários aí que vcs descreveram são cenários possíveis
> e há outros.
>
> Só estou respondendo para que saibam que eu li, mas sinceramente já não sei
> mais qual o ponto de vcs. :¬)
>
>
> Abraço!
>
> P.S.: Achei até que esta thread tinha terminado...
>
> Peter P. Lupo
> Undergraduating in Computer Science DCC/UFRJ
> Sun Certified Java Associate
> http://pplupo.googlepages.com/
> Cell. +55 (21) 81742487
>
>
> Clavius Tales (Fortes Informática) wrote:
>
> Pois é, Esmiralha. Optei até por cenários menos ruins. Mas é isso mesmo que
> você disse.
>
> Um abraço.
>
> Tales
>
> ----- Original Message -----
> From: "Luiz Esmiralha" <esmiralha@...>
> To: <xprio@yahoogroups.com>
> Sent: Sunday, March 02, 2008 4:12 PM
> Subject: Re: [xprio] "Metodologias Tradicionais"
>
>
> 2008/3/2 Clavius Tales (Fortes Informática) <tales@...>:
>
>
> Oi, Peter.
>
>  ----- Original Message -----
>  From: Peter
>  To: xprio@yahoogroups.com
>  Sent: Wednesday, February 13, 2008 10:00 AM
>  Subject: Re: [xprio] "Metodologias Tradicionais"
>
>  > Mas se chego numa empresa, encontro iterações de 15 dias a 1 mês,
> processo
>  > de aprovação de mudanças com 1 dia ou dois no máximo e designs que são
>  > detalhados aos poucos e até um nível não tão micro por analistas que
>  > também são o desenvolvedores eu não consigo responder à pergunta. Esse
> é
>  > que é o ponto. Vc construiu um cenário impossível para uma cultura
> ágil,
>  > mas poderia ter construído um cenário que não fosse impossível, como
> este
>  > que eu citei. Este cenário que eu citei pode ser tradicionalista e se
> vc
>  > não levar isto em consideração estará chamando algumas culturas
>  > tradicionalistas de ágeis. Simplesmente pq essas características que vc
>  > citou são suficientes, mas não são completas. Podem não estar presentes
> e
>  > a cultura ainda ser tradicionalista.
>
>  Estou meio perdido na discussão - tenho mais de 300 emeios para ler. Mas
> vou
>  citar um exemplo que aconteceu aqui na empresa que talvez dê indicativos
>  dessa diferença cultural.
>
>  Certo dia especifiquei um relatório (desenhei o leiaute) que queria e
> passei
>  para um programador. Quando começou a programar e recebeu "feedback", ele
>  percebeu que alguns pontos daquilo que eu havia especificado não estavam
> tão
>  bons, já que ele também conhece o sistema, pela disseminação do
>  conhecimento. Imediatamente ele chegou para mim (Sentar Junto) e disse:
>
>  - Tales, isso aqui não vai funcionar por causa disso, disso e disso aqui.
>  Que tal fazermos dessa forma?
>
>  Na mesma hora eu disse:
>
>  - Perfeito. Pode fazer.
>
>  E fez.
>
>  Num esquema tradicional, alguns exemplos de como isso poderia ter
>  funcionado:
>
>  Primeiro cenário:
>  O programador fazia como especificado, afinal não era problema dele se o
>  especificador não fez o trabalho dele direito.
>
>  Segundo cenário:
>  O programador fazia como especificado, mas na próxima oportunidade
> falaria
>  sobre o problema sobre o problema.
>
>  Terceiro cenário:
>  O programador conversaria imediatamente com o especificador, que diria:
> "Vou
>  atualizar a especificação. Já já te mando."
>
>  Em esquemas tradicionais, esses problemas acontecem aos montes, que
> travam
>  enormemente o processo de desenvolvimento.
>
>
>
>
> Tales,
>
> Num esquema realmente tradicional, acho que o cenário é mais parecido com
> esse:
>
> O programador procura o especificador para perguntar o que fazer. O
> especificador não está mais no projeto porque a fase de design já
> acabou. O programador implementa do jeito que está especificado. 6
> meses depois quando o sistema é entregue, o usuário percebe o
> problema, solicita uma mudança e paga 100x mais caro do que teria sido
> consertar quando o problema foi identificado.
>
> Abraço,
> Luiz
>
>
> ===================================================
>  Acesse o Blog do XPRio: http://xprio.blogspot.com
> ===================================================
> Mais dados sobre XP: http://www.improveit.com.br/xp
> Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
> Yahoo! Groups Links
>
>
>
>
>
> ===================================================
>  Acesse o Blog do XPRio: http://xprio.blogspot.com
> ===================================================
> Mais dados sobre XP: http://www.improveit.com.br/xp
> Livros sobre XP: http://www.improveit.com.br/xp/livros.jsp
> Yahoo! Groups Links
>
>
>
>
>
>



--
Peter P. Lupo
Undergraduating in Computer Science DCC/UFRJ
Sun Certified Java Associate
http://pplupo.googlepages.com/
Cell. +55 (021) 81742487