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.