Desde algumas polêmicas que ocorreram no Scrum Gathering neste ano, tenho discutido em diversos fóruns de discussões e eventos sobre o que tem ocorrido com a nossa comunidade de desenvolvimento ágil. Eu temo pelo o que pode ocorrer com o Agile aqui no Brasil. O que matou o RUP pode também matar o Agile.
Quando eu estava no começo da minha carreira, no início dos anos 90, por incrível que possa parecer os métodos eram ágeis. O cliente e os reais usuários eram muito próximos e participavam ativamente do projeto. O ciclo, apesar de não ter formalidades iterativas, era focado em entregas frequentes. Apesar das arquiteturas fracas, a qualidade era boa e a satisfação dos usuários era maior. Trabalhei com Clipper, Visual Basic 3-6, Mumps e outras coisas da época – além de administrar redes Novell 3.12 e Lantastic. Os projetos eram divertidos, focados em resultados e na maioria das vezes o financiador ficava no seu pé. Eu me lembro do Tonhão, o gerente financeiro da Rede America Burger & Pasta, meu primeiro (e único) emprego como programador CLT. O Tonhão todas as sextas batia na minha mesa no CPD e perguntava: “-E aí Japa, tá pronto?”. Todas as sextas, religiosamente às 15:00 o Tonhão cobrava sobre aquele sistema de controle de caixa das lojas que acabou com os disquetes e com muita burocracia, pois usava comunicação via modem.
Nos meados de 1996 recebí uma ligação de um amigo meu do colégio técnico dizendo que as consultorias estavam pagando R$ 22,00 a hora para projetos do Bug do Milênio em COBOL. Bem, para a época esse valor era bastante significativo, topei na hora e lá fui eu ter a experiência de uma empresa grande. Se existe uma coisa que você pode responsabilizar sobre a bagunça que existe no mercado de TI hoje essa coisa é O BUG DO MILÊNIO. Eu estranhei muito trabalhar em consultorias nessa época. Os projetos chegavam e nem tinha uma única reunião com o cliente. Na maioria das vezes tinha um gerente-proxy entre a equipe e os clientes. Os projetos Y2K eram ainda mais peculiares. Teve projetos que o trabalho era passar uma ferramenta de detecção de problemas Y2K, ir até o código indicado pela ferramenta e fazer as alterações, mas sem recompilar e sem qualquer teste. Eu me sentia um digitador. Levei até uma bronca de um coordenador por tentar compilar o projeto para ver se nossas alterações ao menos geravam os binários. Meu coordenador gritou que aquilo não era escopo do projeto. Nesse momento eu ví que qualidade não era uma preocupação central das consultorias.
Passada a fase Y2K, começaram os projetos Internet e de sistemas periféricos de grandes implementações ERP. O problema é que o desenvolvimento de software empírico (que eu apliquei nos meus estágios e lá na Rede America) não atendia às necessidades de projetos outsourcing. Gerentes queriam controles, relatórios e Gantt Charts. A preocupação maior era a mesma dos projetos Y2K – O ESCOPO. Se você estivesse numa consultoria no final dos anos 90, você compreenderia perfeitamente o mindset do SEI com o seu CMM. Os gerentes de consultorias buscavam algo que amarrasse a equipe ao contrato com o cliente. Meio por fora de tudo isso comecei a estudar Orientação a Objetos, OMT, Booch, e mais pra frente, a UML e o RUP. Minha primeira experiência prática com o RUP foi num projeto internacional para a Phillips Medical Systems em 1999.
Esse projeto da Phillips era um sistema orçamentário empresarial que integrava vários departamentos, inclusive a matriz em Rotterdam. Foi desenvolvido em Visual Basic, Orientado a Objetos e banco de dados Oracle. Quando olhei o RUP pela primeira vez gostei de Casos de Uso, Iteratividade e o foco Arquitetural. Neste projeto a equipe variou entre 3 a 5 pessoas. No início estabelecemos uma Visão para definir o problema junto aos usuários, o ciclo iterativo era de 30 dias e tinha perto de 15 casos de uso (que escrevemos de maneira correta). Usamos o famigerado Visual SourceSafe (o supra-sumo da época) e somente uns 6 ou 7 diagramas UML foram mantidos como artefatos (além do MER). O foco sempre era entregar o produto e não preencher artefatos. A gente até tinha alguns testes automatizados, mas a maioria dos testes era manual. Entregamos o projeto após 3 ou 4 iterações e foi um sucesso! A satisfação dos usuários foi além das expectativas. A partir desse projeto, o modo que eu instancio o RUP é assim: Iterativo, Orientado ao Usuário (Casos de Uso) e centrado em Arquitetura.
Quando voltei desse projeto para a consultoria um dos meus gerentes queria saber como foi o processo. Eu comecei a falar que o cliente participou bastante e que as entregas a cada 30 dias foram determinantes para diminuir os riscos. E a pergunta que se seguiu traduz bastante o mindset de um gerente (da época ou de hoje): “- Legal, legal, Rodrigo, mas quais eram os documentos que vocês preenchiam?”. Aí eu falei que usamos a Visão, os Casos de Uso, a UML, o MER… logo em seguida veio a pergunta número 2: “- Você poderia me dar um exemplo de cada um para usar no projeto XPTO?”. Hoje eu vejo que ele estava buscando respostas fáceis. Na época eu poderia ter dado minha cópia do livro sobre Unified Process dos Três Amigos, porém, o que eu fiz foi copiar um disquete com os artefatos. Ainda hoje ainda me culpo por ter feito aquilo, mas eu era ainda um profissional inexperiente, com pouco mais de 5 anos de estrada. Colaborei para a ilusão daquele gerente por respostas fáceis. Me desculpe se você era um dos desenvolvedores do projeto XPTO na virada do ano 2000. Me desculpe se um dia, um gerente chegou para você entregando um disquete dizendo: “- Olha, o preenchimento desses artefatos garantirão o sucesso do projeto.”
Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário – implementar – entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.
No ano de 2003 eu ví a primeira palestra de um “especialista” falando absurdos sobre o RUP, no melhor estilo Waterfall. Ele disse coisas do tipo “Levantar todos os requisitos na concepção”, “Modelar tudo na fase de elaboração”, e principalmente, o cara pregava descaradamente a errônea sequência Casos de Uso – UML – Codificação – Testes, e uma irracional separação de papéis que está em uso até hoje. Ele teve até tempo de mostrar como preenchia alguns artefatos. Nesse tempo eu não era tão crítico como hoje, e nem mesmo para os meus amigos que assistiram a palestra eu alertei contra as falácias daquele fanfarrão.
A cada dia que se passou desde então, ví mais e mais pessoas falando absurdos do RUP. Quando se diz RUP atualmente no mercado muitos torcem o nariz, associam com cascata, associam com artefatos, associam com ferramentas Rational, e principalmente, associam com esse pensamento burocrático da virada do milênio. Muitos dos que criticam são agilistas famosos, mas que não tem mais de 10 anos de experiência. Eu queria que a maioria desses consultores e especialistas Agile estivessem lá nos anos 90, reclamando da implementação OO nos produtos base da Microsoft, tentando entender Objective-C e vendo uma esperança OO mais simples no Delphi como alternativa. A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.
Em 2003-2004 eu tive o primeiro contato com o Extreme Programming num projeto J2EE para um grande Call Center Vendas, um projeto único no mundo, clusterizado, distribuído, Swing e mensageria. Sobre o XP, quer saber? Não ví quase nada de novo. Agora Casos de Uso são User Stories menores, o ciclo iterativo é mais curto, o desenvolvimento é orientado a testes (isso sim achei uma boa idéia, apesar de não compreender bem nos primeiros projetos) e a programação é em par (isso também geralmente não é uma azeitona fácil de engolir logo de primeira). Eu particularmente tenho dificuldade em parear com algumas pessoas devido ao meu déficit de atenção. Eu olhei para o XP e no primeiro momento ví que muito do que diziam do XP era algo parecido com o que a gente fazia nos anos 90, principalmente a parte do cliente presente. Todos os meus clientes no início dos anos 90 eram presentes. Comparado com a visão do desenvolvimento de software das consultorias o XP era o cúmulo da controvérsia. Já na mentalidade de um desenvolvedor de software dos anos 90, o XP faz todo sentido do mundo. Meu primeiro contato com o Scrum foi em 2005. E mais uma vez tive aquele sentimento: Sim, é bem diferente das práticas erradas do mercado, porém, não é muito diferente do RUP. Ele diz mais sobre ROI e sobre um importante Product Owner, mas também me lembro do Tonhão como um Product Owner nato nos anos 90. Em 2005 o Scrum era o cúmulo do descontrole de custos do projeto, por conta do seu escopo aberto e por conta do mindset PMBOK, mas para um desenvolvedor dos anos 90, simplesmente é o retorno aquilo que a gente já fazia: nos anos 90 não tinha pressão para se entregar tudo, mas havia pressão para resolver os problemas de negócio do cliente. E eu me lembro do Tonhão todas as sextas me cobrando aquilo que estava pronto, doido para colocar a aplicacão no ar só para ter certeza que ninguém na rede estava roubando ele.
A grande questão sobre o Agile Movement é sua mudança cultural. Infelizmente são poucas as pessoas que se divertiram fazendo software nos anos 90 – se você costuma tratar os desenvolvedores como crianças, lentamente eles se convencem que são crianças. O manifesto é um grito contra as coisas erradas do mercado. É uma emancipação dos desenvolvedores que não querem ser crianças. É uma injeção pragmática contra o pensamento pseudo-tradicionalista, controlador e traumatizado que existe hoje no mundo empresarial, especialmente na indústria do desenvolvimento de software.
O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos – violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mindset de besteirols e libertinagens Agile, eu me lembro do mindset burro e burocrático que contaminou o RUP.
O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.
Mais sobre o assunto “queda do Agile”:
Agile está morto! D-us salve o Agile! – José Papo
The Decline and Fall of Agile – James Shore
Por que dizemos não à certificação de Scrum Master – Vinicius Teles
A Completa Irrelevância do Certified Scrum Master – Philip Calçado
Flaccid Scrum – Martin Fowler
Esse artigo e a palestra que ministro com mesmo título é inspirado em “What Killed Smalltalk Could Kill Ruby, Too”, Keynote do Robert Martin (ou Uncle Bob) na RailsConf ’09. Uma das melhores palestras que já ví. Veja abaixo:
Rodrigo,
Excelente artigo. Também concordo que o que vai matar o Agile é a falta de entendimento.
Mesmo sendo uma “metodologia” que bate muito na questão cultural, há de se criar formas de que empresas que adotem determinados padrões são certificadas. O problema é que a palavra certificação é polêmica. Temos que pensar em alguma forma.
Qual é o melhor exemplo de falta de entendimento sobre agile no dia-a-dia? É justamente empresas utilizando a metodologia XP ou Scrum, por exemplo, sem conhecer o mínimo dos princípios ágeis e sem ter transformado sua cultura.
Você acredita que ouvi na semana passada lá na minha empresa algo do tipo: “A partir de agora, todas as fábricas irão utilizar Scrum”. Fiquei indignado e joguei uma série de perguntas, apesar de já saber que a jogada era pura política: “O cliente sabe e comprou a ideia? A forma de negociar contratos será revista? As pessoas foram treinadas?”.
O que vai matar o agile é o modismo, a utilização por marketing, consequencias da falta de entendimento colocada por vc.
Abração!
Rafael
@rsouzaramos
http://www.conhecimentoeti.com
Espetacular como você passa sua experiência de forma simples e clara!
Mantém a dignidade e postura de um desenvolvedor/analista experiente focando suas idéias e a transmissão das mesmas.
Li este post e vou seguir esse blog!
Onde eu trabalho adotamos metodologias tradicionais, como CMMI… Ainda não tenho o poder de discutir metodologias à um nível bom, mas sei que alguns projetos se tornam um Caos por causa do CMMI… As vezes era pra ser algo tão simples, mas levam algumas semanas em função da quebra do processo em algumas partes…
Eu não diria melhor, Rodrigo. Perfeito!
Certa vez vi o Uncle Bob dizendo em uma palestra que XP (e eu estendo a afirmação para Agile de um modo geral) é o modo como os programadores se comportam na natureza. Ou seja, dê um problema para um grupo de programadores e o processo a que eles vão chegar será bem parecido com XP. É simplesmente natural. A cada dia me convenço um pouco mais disso, e seu texto ajudou ainda mais.
A alternativa burocrática, por outro lado, não tem nada de natural. Afinal de contas, pilhas de documentos não tornam nada mais fácil e não melhoram o produto final. E é só isso que programadores querem: chegar com o mínimo de esforço a um produto de qualidade.
Novamente, parabéns pelo texto. Muito bem colocado.
Muito bom artigo, Rodrigo!
Me fez lembrar os velhos tempos… Não sou tão velho quanto você, mas em 97 lá estava eu começando a fazer trabalhos divertidos com Clipper e Delphi; e começando a aprender Java.
E acho que esse sentimento que você passou no artigo, de simplicidade, praticidade, desburocratização, é bem o que o Kent Back fala em seu livro de XP, né? Porque logo no comecinho ele fala do tempo que seu pai era programador e as coisas eram bem mais simples, e os programadores se divertiam, e as coisas saim no prazo, etc, etc, e fala do tempo dele, quando toda a diversão parece ter sido engolida por “departamentalismo e afins”. Ele fala sobre o prazer de programar, o prazer de entregar software funcionando, software que agrade o cliente; e tudo isso rápido, mas não com prazo absurdo, onde se tem que trabalhar dia e noite, final de semana, etc.
Bem, seu artigo me fez lembrar dos meus velhos tempo (que não é tão velho assim) e das citações do Kent Back no inicio de seu livro sobre XP.
Mais uma vez, parabéns! Ficou grande pra caramba, mas ficou bom… heheheh
:codezone
Excelente texto! O que voce vivenciou é a prova concreta de que priorização de pessoas e agilidade(http://agilblog.locaweb.com.br/2009/04/25/metodologias-ageis-sao-processos-agilidade-e-cultura/) direcionam projetos ao caminho do sucesso independente de qualquer “onda” de metodologias e ferramentas que possam aparecer.
A apresentação “Agile as Practiced Today is the new Waterfall” está no mesma sintonia do seu post:
http://blogs.agilefaqs.com/2009/04/29/agile-as-practiced-today-is-the-new-waterfall/
Valeu por compartilhar 🙂
BTW, fiz uma relação entre cultura ágil e a história da ID Software no inicio dos anos 90. Eles rodavam num esquema parecido com o que voce tinha com o “Tonhão”
http://harryreflections.blogspot.com/2009/06/getting-real-back-in-early-90s-secret.html
[]’s
Rodrigo, em poucas palavras: Excelente artigo!
No AgileBrazil 2009, no RJ, eu fiz uma pergunta na mesa redonda sobre a queda do agile e fui respondido muito bem, na minha opinião, pelo pessoal.
Agora, este post completa a resposta à minha pergunta daquela época de maneira espetacular.
Obrigado,
Marcelo Zeferino
Excelente artigo. Concordo plenamente com você!
A forma como o Agile vem sendo adotado pelas empresas é de dar medo.
Muitas iniciativas frustadas são resultado, em sua maiora, das tentativas marketeiras (insanas) de convencer o cliente/equipe de que você pode ser mais rápido nas suas entregas adotando o Agile. A falta de conhecimento na adoção do Agile acaba gerando rumores injustos de que o problema é o Agile e não a forma como vem sendo utilizado.
Obrigado por compartilhar sua experiência.
@pablo_souza
Excelente artigo Rodrigo.
Já trabalhei em uma empresa onde começamos a utilização de scrum por um pequeno grupo de desenvolvedores. Em determinado momento, isso se tornou algo da moda, e toda a empresa passou a utilizar scrum. Mas na verdade, apenas colavam post-it na parede.
Da mesma forma esta empresa, antes do scrum, os analista, eram obrigados a entregar os casos de uso de um projeto, isso fazia parte do processo de desenvolvimento da empresa, que dizia ser baseado no RUP. Sabe o que acontecia? Nós desenvolvedores, começávamos a desenvolver e o analista trazia um caso de uso para a gente validar se estava parecido com o que estávamos fazendo. Tem cada coisa muito louca por aí.
Muito bom o artigo. Parabéns.
Rodrigo.
Excelente artigo, com toda certeza devemos parar e aprender com o passado.
Parabens.
Abraço
Fernando
Olá Rodrigo,
Como sempre me supreendo com seus artigos. Sempre gostei muito da forma como escreve e expressa seus pensamentos e neste artigo você se superou novamente.
Me identifico muito na forma como você pensa. Os valores do RUP, do Agile, do Lean e de mais abordagens existentes só podem ser usadas de forma inteligente se houver realmente uma mudança da conciência coletiva que proporciona a prática correta dos princípios.
Deixo aqui o trecho do artigo que mais gostei:
“…ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.”
Parabéns,
Paulo.
Pingback:O melhor da semana 27/09 a 03/10 « QualidadeBR
Olá Rodrigo, gostei bastante do seu artigo estou começando a estudar SCRUM, TDD e DSDM agora.
Eu só acho que você pegou um pouco pesado demais com as companhias e com os gerentes.
As companhiam fecham os escopos e evitam ao máximo os “golden plates” pois isso já causou e ainda causa muito prejuízo finaneiro às mesmas, é comum se gastar mais em projetos, pois, os clientes não aceitam as entregas “levantadas” por outros funcionários anteriores à eles.
Os gerentes também sofrem muita pressão para que o trabalho flua como uma brisa leve e em 99% dos casos não é bem assim, veja no seu próprio artigo quando você fala que abraçou uma nova oportunidade em cobol para o bug do milenio, não sei se havia um GP na época, mas, com certeza hoje os GPs são pressionados ao fato de que se ele perder 100% da equipe o trabalho tem que ser entregue no mesmo prazo, com a mesma qualidade, com o mesmo custo e com o mesmo escopo. Por isso que a burocracia (preenchimento de templates e documentos) e o distanciamento (uma área isolada conversa sobre escopo com o cliente) foram implementados.
Mas concordo com você que o trabalho sofreu grandes alterações, é por isso também que um desenvolvimento de SW com uma equipe de especilistas trabalhando em métodos ágeis custa $$ e o mesmo SW desenvolvido por uma empresa com CMMI 5 custa $$$$$$$$.
E acho que o RUP não morreu, assim como cobol não morreu, assim como ASP não morreu.
E acredito que voce tenha esquecido de mencionar o fato de que muitos clientes não querem, nem podem ficar em contato diário (ou constante) com as equipes que estão desenvolvendo SW.
De qualquer forma é uma boa analise de que as equipes e empresas devem adotar as metodologias por politica ou concepcao e não por modismo, etc.
Danilo Almeida, PMP
esse post me lembro de um estagiário falando sobre a empresa em que ele trabalhava:
“cara, a gente faz reunião em pé!!!” – com uma empolgação absurda!
eu ri muito nesse dia. vamos dar um desconto pq ele era apenas um estagiário. mas foi muito engraçado! rsrs
Parabéns, excelente análise!
O mercado quer garantias e acha que certificações é suficiente pra isso… CMM, SCJP, CCNA… agora CSM, CPO e certificar conceito é bem complicado.
Rodrigo,
Lí seu artigo e fiquei com uma dúvida: se você mudou do RUP para metodologia Ágil e está considerando o Lean mesmo tendo após mencionar que ambas funcionam bem, a mudança está sendo justificada pela tendência do mercado?
[]s
Guilherme Zambon
É uma simples evolução normal. Também tive fracassos com RUP e com Agile. Agile mudou o RUP nos termos que disse aqui (creio que a maior contribuição do Agile foi entregas mais rápidas, TDD, CI e Pairing).
Hoje vejo que certos projetos usei conceitos do Lean, mesmo sem saber o que era isso. Vejo que o Lean é possível com as avanços das tecnologias e arquiteturas atuais também. É uma evolução natural. Conversei bastante com o Alisson Valle durante o Ágiles 2009 (o Alisson é a maior autoridade em Lean aqui no BR). Sempre ví que o desenvolvimento iterativo é uma limitação do seu processo e não uma “feature” desejável. O Alisson está me convencendo que desenvolvimento iterativo é uma disfunção.
Sim, estou evoluindo para o Lean, não pelo mercado, já que aqui no BR só a empresa do Alisson está aplicando Lean com maturidade.
Pingback:Um novo olhar! | Arquitetura da Informação
Pingback:O que matou o RUP pode matar o Agile | Arquitetura da Informação
Rodrigo,
Parabéns pela matéria, me fez retornar àquela época em que fui desenvolvedor no final dos anos 80 e inicio dos 90.
Naquela época o desenvolvimento de software era divertido mas sem deixar de ser responsável. Fazíamos software como se estivessemos escrevendo um livro ou pintando um quadro, era feito por paixão e não por um real à mais no valor/hora.
Sei que isso vai soar como algo surrealista, mas vale a pena perguntar para quem viveu aquela época dentro de empresas desenvolvendo sistemas com dbase, clipper, c(ansi), delphi, vb 3, pascal e etc.
Eu acho que vale a pena resgatar esses assuntos, não como saudosismo, mas sim como conhecimento de como as coisas funcionavam muito melhor.
De qualquer forma o que vale sempre é o bom senso de se analisar cada projeto com suas peculiaridades e definir de forma pensada e inteligente a maneira mais adequada de tocá-lo. A tal busca de respostas fáceis que você citou se traduz em erros fatais na condução de projetos.
Excelente artigo,
Resumindo: O que vale não são as técnicas, diagramas ou ferramentas mas sim os princípios.
Desde que os princípios sejam bem compreendidos, vc pode até inventar uma metodologia XPTO e chamar de ágil que funcione para a sua empresa.
Aliás antes do Tonhão, a Toyota ja utilizava esses princípios há mais de 30 anos. Leia o livro ‘O Modelo Toyota – The Toyota Way”.
Gostaria de agradecer por seu artigo!
Nem tanto pelos conceitos que ele apresentou mas por me fazer relembrar os anos 90, principalmente os clientes! Foi uma volta ao passado, as horas junto com grupos de desenvolvedores comendo amendoim e tomando coca-cola, um ajudando o outro e todo mundo jogando “karateka” ou “Lost World” na hora do almoço!
E tinha os clientes malas que toda hora tinham uma idéia nova para o sistema. Me lembro de uma secretária já senhora que desceu umas três vezes até o “CPD” para me pedir uma alteração em um relatório, na quarta vez eu disse: “Senhora, isso aqui não é fast-food de programa não!” Foi um auê, tive que falar com o diretor e tudo mais.
Saudades dessa época em que desenvolver era pura diversão, fazíamos porque gostávamos da coisa.
Obrigado Rodrigo.
Olá Rodrigo!
Muito legal seu texto e esse resumo histórico que vc colocou com suas experiências. Sou também um desenvolvedor da década de 90 e passei por algumas coisas parecidas. Gostei principalmente da sua análise sobre as más interpretações que as pessoas fazem dos novos conceitos que surgem. E é incrível como geralmente são essas pessoas que estão em posição de decisão nas empresas.
Não sou nenhum especialista em RUP e muito menos em métodos ágeis mas com uma lida no livro do Craig Larman – Utilizando UML e Padrões – acho que compreendi bem o espírito do PU de iterações, abraçar a mudança, não planejar muito para o futuro porque será apenas meras especulações e feedbacks constantes. Quer dizer, logo na primeira leitura aquilo foi uma iluminação pois tudo faz muito sentido e não compreendo como alguém pode interpretar tudo tão equivocadamente a ponto de de dizer que “na fase de concepção deve-se levantar todos os requisitos”. Acho que essas pessoas têm severos déficits de comprensão de texto e saem por aí falando bobeiras. Na empresa onde trabalho recentemente foi adotado o RUP como processo visando atingir o CMM nivel 2. Foi incrível o número de controvérsias e más interpretações e no final foi gerado um processo pesado e burocrático (como se fosse isso que o CMM prega).
Sou um afiquicionado por OO e acho que compreendo bem os conceitos de modelagem. Gostei quando vc diz: “A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.” As empresas adotam Java acreditando que terão automaticamente as vantagens da OO mas o que vejo ser produzido nos projetos são códigos mal projetados (com métodos extensos e classes sem significado) e nenhuma preocupação em modelarem o domínio da aplicação. E o pior que no final, como todos os artefatos foram produzidos, eles acham que o produto tem uma ótima qualidade. Bullshit!
A meu ver o código é o artefato mais importante gerado e isso tem que ser feito com todo o cuidado e dedicação. Um bom código é auto-explicativo, dispensa documentação e pode ser alterado sem muita dificuldade. Por isso penso que as atividades de anáilse e projeto deveriam ser as mais valorizadas e intensificadas com terinamento nas empresas. O grosso do trabalho de desenvolvimento, e também a parte mais difícil, é um bom projeto e é nisso que as empresas deveriam apostar suas fichas, mehorando a habilidade de seus programadores em analisar e projetar.
Recentemente vc esteve em minha cidade, Campo Grande, dando um treinamento organizado pelo Lucas (Landir). Na ocasião não pude participar mas quem sabe no próximo.
Continue o bom trabalho e até a próxima!
Pingback:André Nascimento » Blog Archive » Não se iluda com o Scrum de prateleira
Pingback:Papéis na transição do modelo tradicional para o Scrum « Keep Thinking
Rodrigo,
excelente sua forma de falar (escrever) e tem razão ao criticar os modelos aplicados nas empresas. O que a gente mais tem visto são gestores cheios de certificações e pouquíssimo bom senso. É preciso ter controle, mas gastar 50% do seu dia preenchendo formulários e planilhas pra ter controle é demais. Como ser ágil quando se gasta tanto tempo controlando ?
E pior, com o advento das fábricas de software os clientes (usuários) estão cada vez mais distantes dos desenvolvedores. Ou seja, o famoso telefone sem fio… quando o requisito chega na mão do desenvolvedor já não tem nada a ver com o que foi pedido.
Assisti de camarote a migração de um sistema em Powerbuilder para Java, mas partindo do zero, sem reaproveitar nada. Começaram pelos casos de uso com uma empresa terceirizada X onde havia alta rotatividade de analistas… cada caso de uso ficou de um jeito e sem nenhuma profundidade… com aquele caso de uso dava pra fazer várias implementações que atendiam plenamente o que estava escrito… depois contrataram uma empresa Y para implementar o código porque eles afirmaram que o projeto que demorava N meses dava pra entregar em metade do tempo. E quem vendeu a implementação usou os casos de uso para cobrar, mas quando chegou na mão de quem ia implementar disseram “mas este caso de uso precisa de um detec (detalhamento técnico)”. Resultado que a empresa contratante teve que fazer um detec para cada caso de uso, ou seja, refazer todo requisito que já haviam pago para empresa X e pra variar descobriram ao detalhar que muitos casos de uso não se falavam entre si e tinham falhas graves de requisito. Por sorte (ou azar, não sei) a empresa Y topou implementar durante a elaboração dos detecs, mas imagina o risco de retrabalho. Enfim, em quase duas vezes N meses ainda vejo o seguinte cenário: metade do sistema está em produção funcionando, outra metade está em desenv/testes e devido a demora já temos outros vários pacotes de entrega com alterações dos requisitos (evolutivo/corretivo).
Parece que escolheram todas as metodologias e não usaram nenhuma. Gastaram o dobro do preço, o dobro do tempo e não tem ninguém satisfeito com o resultado.
Como vc sintetizou bem em seu artigo, paga-se caro pela falta de conhecimento/entendimento de metodologias.
Pingback:#ffffuuuuconf « Gandralf's Blog
Simplesmente fantástico suas colocações.