/Desenvolvimento

voltar
/Desenvolvimento

Metodologia ou Religião?

PorThiago T. Ortiz em

A última publicação do Fabricio Vargas falando sobre o Juramento de Não-Lealdade
levantou certos comentários em algumas listas que divulgamos, que me
fizeram pensar por que em uma área puramente de exatas como a nossa
existem tantos “religiosos” e “fanáticos“.

Em se tratando de religião, eu já não consigo entender muito bem por que
muitas pessoas não respeitam uma fé diferente da sua. Com isso, cria-se
uma briga entre os dois lados que nunca vai chegar a lugar nenhum,
enquanto Deus, Alá, Buda ou Shiva não aparecerem diante de todos
esclarecendo os fatos. Briga essa que às vezes gera mais discussão do
que a própria religião.

Ainda em termos de religião, posso até dizer que é esse tipo de discussão é compreensível (ainda que eu não consiga entender). Mas como explicar esse tipo de comportamento no setor de informática?
Por que muitas pessoas não aceitam que as diferentes tecnologias e
metodologias podem coexistir e, com isso, obter-se o melhor de cada
uma? Isso só traz prejuízo aos “fiéis” dessas muitas “religiões”, das
quais podemos citar os Javaistas, Linuxistas, Agilistas, MSistas,
Anti-MSistas – dentre centenas de outras. Porém, vamos focar nos
religiosos Agilistas, ou que prefiro chamar, Pseudo-Agilistas, aqueles aos quais o juramento de Alistair Cockburn tenta dar um fim.

Não nego que as Metodologias Ágeis são boas em muitos cenários, talvez até mesmo na maioria deles, mas daí a dizer que WaterfallCMMIRUP
ou qualquer outra técnica seja inaceitável e sempre ruim, existe uma
barreira muito grande. Existem projetos de todos os tipos e nem sempre
é possível seguir uma metodologia X ou Y. Por exemplo, o Governo Brasileiro não aceita bem a ideia de um processo Ágil. Em um caso
desses, você provavelmente terá que se adequar à realidade do cliente e adaptar alguns dos seus processos.

Basicamente, o importante é fazer o melhor para o seu projeto e não
ter que se preocupar em ser um “pecador” porque usou um Gráfico de Gantt,
por exemplo. Afinal qual é o objetivo maior, ser fiel a determinada
metodologia ou o sucesso do projeto?

Algumas pessoas podem responder que não são religiosas, mas que
Waterfall é ruim sempre e correr dele é o melhor para o projeto.
Primeiro gostaria de destacar que nem eu, nem ninguém defende que
Waterfall é bom sempre. Há muitos anos essa metodologia praticamente
não é mais utilizada pela maioria. Mas daí fechar os olhos e dizer que
é ruim sempre é um comportamento que só entendi um pouco melhor após ler na Wikipedia sobre Fanatismo.

Além disso, vale lembrar que não estamos fazendo um paralelismo apenas
entre Waterfall e Ágil, existem inúmeras formas de organizar um
processo incremental além dessas duas, como as já citadas CMMI e
RUP, por exemplo. A questão não é nenhuma delas em específico, mas sim
olhar pra uma técnica qualquer e extrair dela o que mais agregar valor
ao seu projeto.

A exemplo dos Fariseus,
que se dedicaram exclusivamente ao estudo da Torá, criticando veemente
todo o resto, sobretudo o cristianismo, vejo muitas pessoas se
dedicando apenas a estudar Agilidade, sem colocá-la realmente em
prática. Se começarmos a reparar, vamos ver que muitos dos “Religiosos
Agilistas” não possuem cases sobre suas teorias para mostrar, ou são
cases específicos para uma determinada realidade. Dedicam-se a especular
sobre o sucesso do que acreditam, criticar os insucessos do que existe
e ficar especulando como resolver problemas que nem sequer existem em
sua realidade, chegando às vezes a soluções praticamente impossíveis de
serem aplicadas no mundo real. Não citarei exemplos aqui, já que o objetivo
não é atacar ninguém, mas sim mostrar que metodologias e tecnologias
servem como referência, cabe a você decidir quando e como usá-las.

Gostaria de deixar claro que sei que as Metodologias Ágeis, sem
dúvida, trouxeram inúmeros benefícios para os projetos atuais, porém
não podemos esquecer que o PMBOK
ou o CMMI, por exemplo, fizeram o mesmo quando surgiram. E da mesma
forma que o Ágil (e qualquer outra metodologia ou técnica que existe ou
vier a existir), necessitaram de adaptações em cada projeto que foram
aplicados.

Ágil resolve muitos problemas que Waterfall não resolve bem?
Sem dúvida que sim, mas obviamente não todos. Por exemplo, em
um dos nossos projetos tivemos grande liberdade para usar Agilidade,
porém após um tempo notamos certa dificuldade em gerar visibilidade do
andamento do projeto para a diretoria do cliente, por não estar ligada
diretamente ao projeto e não ter a sensação de progresso gerada, por
exemplo, com os Sprints. Nesse caso, tivemos que adaptar, e a solução foi gerar alguns artefatos do PMBOK. Para mais detalhes, não deixe de ler este artigo do Marcelo Costa, que cita exatamente esse case.

Portanto a sugestão que deixo é: use Ágil, CMMI, PMBOK, Java, .NET
ou o que for, mas esteja antenado o máximo que puder e decida você com
sua equipe qual a mais adequada, ou as mais adequadas, a serem usadas, e
faça o melhor para o seu projeto, sem se preocupar se algum teórico vai lhe chamar de “pecador”. Ninguém sabe mais sobre seu projeto que você
e sua equipe. Estude, conheça, teste e utilize da forma que achar
melhor.

Deixe um comentário! 8

8 comentários

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

  1. Fala meu xará,

    Concordo com você. Trabalhei muito tempo com waterfall e com no último ano com metodologia agil. Como você mesmo disse, metodologias ageis são realmente muito boas de se trabalhar e focar no que realmente interessa, mas nem sempre poderemos utiliza-la, por n motivos. Sou a favor de sempre buscar o melhor para a equipe e principalmente para o cliente. Não importa se seja feito usando waterfall, metodologia agil, java, .net e etc.

    Os profissionais deveriam se preocupar mais com o retorno para o cliente(nem sempre metodologia agil é a melhor alternativa), e não em usar A, B ou C.

    Parabéns pelo artigo.
    Thiago F. Pereira

  2. Fala Thiago,
    Obrigado pelos comentários. Realmente este é o espírito que tentei passar ao escrever. De ser mais importante pensar no sucesso do projeto do que seguir determinada tecnologia, arquitetura ou metodologia.

    Abração!

  3. Simplesmente perfeito, eu particularmente ja andei estudado sobre Agile e não foi o scrum ou o xp que me ajudou plena-mente no desenvolvimento dos meus projetos, e sim um pouco dos 2 mais os métodos que ja foram utilizados anteriormente aqui na empresa.

    Belo artigo Thiago!
    @alexgiroto

  4. Obrigado pelos elogios Alex.
    Partilho da mesma experiência. Até agora nos projetos que me envolvi, xp ou scrum funcionaram bem mescladas com outros metodos.

    Vlw!

  5. legal o post, bom overview, nao sabia que o governo brasileiro nao aceitava metodologia agile. Nas ultimas semanas tenho vivido isso no meu projeto, tinhamos uma nova feature pelo cliente e decidimos usar agile, e o mais importante ao final, como sempre foram as pessoas, uma vez que os envolvidos eram “agilistas” e ng estava forçado, isso contribiu muito, tanto nas iterações, discussoes e na pratica.
    Uma coisa que tenho carregado comigo é nao poder comparar o Agile com waterfall, rup, ou qualquer outra, o motivo que ao nascer cada uma dela a necessidade de negocio naquela época era outra e com certeza se nasceram rup, cmmi é pq para os negocios que haviam demanda essas tecnicas estavam atendendo de forma que o “chefe” ia pagar pelo resultado, do contrario elas nao teriam nascido, já o Agile ele vem com outro cenario e que nao está tão atrelado a ler um PMBOK e sim mais por uma questão cultural que documental.

    parabens.

  6. “Ninguém sabe mais sobre seu projeto que você e sua equipe.”

    O problema é que às vezes nem a equipe sabe sobre o próprio projeto, muitos nem querem saber, nem se esforçam, não há metologia que resolva isso.

    Outra coisa que quero comentar, sou um grande contrariador a certificações, no fundo elas não servem de nada (servem pra atrair a grana de clientes idiotas loucos por selos). Vejamos uma consultoria que tem certificação CMMI, parceiro SAP, usa PMBOK e o caramba a quatro…Mas quando vai gerenciar um projeto, não controla versão de código, os desenvolvedores não aprimoram a qualidade de seus códigos, o próprio contrato de prestação de serviço com o cliente não permite fazer refactoring, entre outras coisas que acho muito mais importante do que ter um quadro na parede da empresa. Tem muita startup por aí dando show em projetos de “grandes” consultorias certificadas, e o pior, os clientes gostam desse blá blá blá de certificação, mas não se atentam a qualidade do serviço prestado, e ainda fidelizam a parceria com a prestadora de serviço. Pra mim, isso é o fim, e eu faço parte disso ainda, infelizmente, mas por pouco tempo.

    Ahh, só pra compartilhar, hoje mesmo ouvi de uma pessoa na empresa falando sobre REST, para ela uma novidade da última modernidade do mundo da programação: “Ahhh, isso não é pra mim não, já passei desse tempo!”

    É isso aí galera, contrate empresas seladas e enfeitadas de quadros na parede que vocês vão longe.

  7. Olá, muito interessante o artigo. Só não entendi a parte “Por exemplo, em
    um dos nossos projetos tivemos grande liberdade para usar Agilidade,
    porém após um tempo notamos certa dificuldade em gerar visibilidade do
    andamento do projeto para a diretoria do cliente, por não estar ligada
    diretamente ao projeto e não ter a sensação de progresso gerada, por
    exemplo, com os Sprints”. Vocês não faziam as entregas ao final das iterações? Não trabalhavam com integração contínua? De qualquer forma eu acho que muito das coisas pregadas pelo PMBOK e pelo CMMi são feitas em metodologias ágeis – só que um nome bom para o marketing atual. Por exemplo: visibilidade ao cronograma! O pessoal do agil chama de KANBAN :)

leia mais
Este projeto é mantido e patrocinado pelas empresas: