Agile não é bala de prata

Esses dias numa conferência alguém veio me contar a sua história, que era de uma empresa que nos últimos anos vinha desenvolvendo seus projetos de forma tradicional, em cascata, e que tinha gostado do que tinha visto sobre metodologias ágeis e estava pensando em tentar. Ele gostou principalmente da idéia de trabalhar com desenvolvimento iterativo e decidiu que iria tentar usar Scrum na sua empresa.

Passadas algumas semanas encontrei denovo com essa pessoa em um outro evento. Para a minha surpresa, ela me disse que sua vida estava um inferno! Os clientes não estavam dispostos a fechar contratos de escopo negociável, eles queriam saber exatamente o que e quando os projetos seriam entregues. Eles definitivamente não quiseram trabalhar com desenvolvimento iterativo, até porque os projetos já eram bem curtos (menos de 1 mês). Pra terminar, por ser uma agência pequena a equipe é de menos de 10 pessoas fazendo com que uma pessoa precise trabalhar em 3 ou 4 projetos ao mesmo tempo. E por aí vai…

Então eu perguntei: Quantos projetos davam errado antes de você começar com Agile?
E ele respondeu: Todos os nossos projetos sempre foram bem sucedidos.
E eu perguntei denovo: Então qual é o problema que você está tentando resolver usando Scrum e desenvolvimento iterativo?
(silêncio…)
Eu novamente: Ok, já entendí. Faça o seguinte, volte para o seu processo de trabalho antigo. Não sei como é mas me parece ótimo.

Muita gente se surpreende quando eu falo isso. Só porque eu falo sobre desenvolvimento ágil não significa que eu acho que isso é a solução para todos os problemas. Se todos os seus clientes estão satisfeitos do jeito que você está trabalhando, seus projetos não falham, você faz ótimas entregas e tudo está ótimo, você não tem um problema. E se você não tem um problema, você não precisa resolver nada. E nesse caso eu recomendo: não use uma metodologia de desenvolvimento ágil só porque está na moda.

Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar. Geralmente em projetos de software grandes é muito difícil de planejar todos os requisitos de uma vez no início do projeto. Não seria impossível fazer isso mas o custo é tão alto que vale mais a pena planejar menos e ir adaptando o software e os requisitos ao longo do tempo até que ele esteja pronto. No cenário dessa pessoa, como os projetos são muito pequenos é perfeitamente possível planejar tudo antes em pouco tempo e desenvolver em seguida.

Em alguns outros casos onde os requisitos não mudam waterfall também pode fazer sentido. Por exemplo, quando você desenvolve software para o governo, toda a especificação do projeto normalmente é produzida e informada antes em um edital. Algumas vezes até o prazo de entrega já está definido. Eu pessoalmente já trabalhei em vários projetos desse tipo que deram certo, que foram entregues dentro do prazo, atendendo a especificação e sem maiores problemas. Como tudo estava funcionando, não havia motivo para pensar em outra forma de desenvolvimento que eventualmente poderia trazer mais problemas do que soluções, como no caso dessa pessoa que conversou comigo.

O que eu quero dizer com isso tudo é que não existe uma metodologia que funciona para todos os casos e todos os projetos do mundo. Assim como você deve usar a melhor ferramenta para cada problema, você deve usar a melhor metodologia para cada projeto.

No projeto que eu estou atualmente estamos quebrando vários paradigmas de desenvolvimento ágil. Estamos com times gigantes, usando quadros de Lean totalmente customizados misturados com Scrum e por aí vai. Estamos sempre analisando os resultados das iterações e replanejando nosso processo. Apesar de todos os livros dizerem que os times têm que ser pequenos, estamos trabalhando com um time de 20 pessoas que dá certo e está super produtivo. Esse é o espírito: faça o que for melhor para o projeto e o que te fizer ter os melhores resultados, não o que alguém diz que é certo ou é errado ou o que está na moda.

É perfeitamente possível desenvolver projetos bons em qualquer metodologia. Entenda qual é o seu cenário, quais são os seus problemas, limitações e aí sim decida qual é a melhor forma de trabalhar nos seus projetos.

Tags: , , ,

12 Responses to “Agile não é bala de prata”

  1. Você nem mesmo precisa usar metodologia. Estude todas e adapte para a sua realidade. Mas sempre deixe claro o modo como as coisas devem funcionar.

  2. Rubem Azenha says:

    Acho que alguns princípios de desenvolvimento podem ser utilizados independente de usar alguma metodologia padrão. Reuniões diárias, por exemplo, são excelentes mesmo em projetos de escopo fechado. TDD também.

  3. Muito Bom! Certa vez, Kent Beck disse que se houvesse um tipo de CMMI para XP, sei lá, um tipo XPMM, haveriam apenas dois níveis. Você alcança o nível 1 quando faz tudo igual ao livro e o 2 quando joga o livro pela janela e faz as coisas da forma que funciona melhor para você. Eu ouvi isso uns dias atrás em um entrevista com o @viniciusteles. Abraço.

  4. Lucas Castro says:

    Mas tbm, nesse exemplo o cara mergulhou a empresa na nova metodologia sem nem aprender ela direito…

    O ideal acredito eu, deveria ser escolher um projeto, de uma conta com bom relacionamento e que apoie o desenvolvimento ágil pra ser o piloto. Não adianta empurrar a empresa e os clientes pra dentro da metodologia que não vai dar certo.

    Depois do piloto, e que se aprenda a metodologia, basta mostrar os dados pros outros clientes que eles se convencerão.

  5. Olá,

    Não conhecia teu blog, mas achei mto bom o texto. Concordo plenamente. Já vi algumas palestras sobre metodologias ágeis e gostei de todas, contudo tenho consciência de que não são 100% corretas para todos os casos.

    Parabéns pelo post.

  6. Thiago Dias says:

    Uma pena aonde trabalho não entenderem o quanto uma metodologia ágil ajudaria a eles… não existe padroes, ingerencias a todo momento e mudanças num escopo que foi MUITO mal feito a todo momento, sem liderança e… cara, tem lugar ai na globo? rsrs

  7. Isso me lembra um cliente que eu tenho. Faz muito tempo que parei de fazer freelancer pois geralmente dá muita dor de cabeça. Porém, esse cliente é como o cliente perfeito: sabe o que quer, não muda os requisitos toda hora e ainda paga bem. Por isso, não precioso de nenhuma mágica ou metodologia especial para lidar com ele. Simplesmente as coisas funcionam de forma natural.

    []s

    Emerson

  8. Hugo Estevam says:

    Belo post, muitos abraçam uma causa e vão com ela até o fim, em software o lema é flexibilidade, a adaptação é sempre necessária. Mais pessoas deveria ler seu post.

  9. Até hoje continua um mistério para mim, o que é de fato que Agile resolve. Se o seu problema tem, por natureza, caracteristicas dinâmicas e seus requisitos mudam com o passar do tempo porque o problema é assim, ai sim, temos um desafio real para resolver, e talvez agilidade ajude (mas também pode ser resolvido com uma boa e competente customização de UP, ou utilizando abordagem por Aspectos). Mas, se seus requisitos mudam constantemente por incompetência na extração de requisitos, que é a esmagadora maioria dos casos que arrebentam prazos e previsões, então não existe processo, reza brava ou método que possa resolver o problema. Otima postagem, divulguei entre meus alunos, raramente a gente encontra depoimentos imparciais como esse seu. Abraço,

  10. Daniel Yokomizo says:

    “Metodologias ágeis partem do princípio de que os requisitos de um projeto de software vão mudar.”
    Na verdade não. Embora a maior parte delas tenham vindo desse mundo a família Crystal (http://alistair.cockburn.us/Crystal+methodologies) do Alistair Cockburn (http://alistair.cockburn.us, um dos signatários do Agile Manifesto) veio da experiência dele em projetos com escopo e preço fechados. De resto o artigo é excelente.

  11. Muito boa Guilherme!

    Eu gosto de ir um pouquinho mais além em uma frase. Não precisa ficar com a metodologia atual, ou não adotar tudo de uma metodologia agile não só se tudo está ótimo, mas se “está suficientemente bem”… tudo estar ótimo em geral é sinal de que tem algo de errado sendo varrido pra debaixo do tapete. Como nenhuma metodologia é perfeita, sempre vai ser “suficientemente bem”, não perfeito.
    Mas ótimo… não podemos cometer o mesmo erro que nossos antepassados cometiam, de achar que tem que ser tudo do nosso modo. parabéns,

Leave a Reply