As metodologias de desenvolvimento “ágeis” traçam as suas origens ao “Manifesto Ágil” de 2001. Estas, são frutos da frustração com as técnicas de desenvolvimento tradicionais, principalmente o chamado “waterfall”. As metodologias tradicionais são usualmente associadas a atrasos de entrega, excesso de custos, frustração dos usuários com o produto final e também com o ritmo de trabalho maluco imposto aos desenvolvedores, especialmente próximo ao prazo final de entrega.
O “waterfall” define fases precisas e seqüenciais de “levantamento”, “projeto”, “construção”, “integração”, “testes”, “implantação” e “manutenção”. É uma metodologia usada com sucesso em outros ramos da engenharia, notoriamente na construção civil e manufatura, o que dá a ela certa credibilidade e facilidade de criar paralelos e metáforas, tanto para pessoal técnico como não técnico. O “waterfall” tem também outra grande vantagem: é muito fácil de ensinar, pois as etapas são precisamente definidas, assim como suas interfaces e que tipo de informação são passadas de uma fase para outra. Por estas razões, o “waterfall” atingiu altos níveis de popularidade, apesar de seus problemas.
No “waterfall”, se uma fase deu errado, é sempre possível “apontar um culpado” em alguma fase anterior e resolver qualquer dilema. Em geral, a fase padrão para levar a culpa é a primeira, o levantamento. Por exemplo: o usuário não disse bem o que queria ou o analista que fez o levantamento não anotou direito. Ou seja, é “só fazer o levantamento direito que tudo dará certo na próxima vez”. Ou algo parecido.
Se o waterfall é tão estudado e tão preciso, por que as coisas dão tão errado? Cada um tem uma opinião ligeiramente diferente, mas as minhas razões preferidas são as seguintes:
• É impossível capturar todas as nuances no levantamento. O usuário sempre se esquece de coisas – sem querer ou até mesmo de propósito. O analista não só não é um ser onisciente e telepata como na verdade está mais interessado em produzir um monte de documentos bonitos mesmo que sem utilidade real, já que são os outros que vão construir o software. Mesmo escalonar as prioridades, ou seja dizer o que é mais ou menos importante, é uma atividade que costuma ser ofuscada por preconceitos ou modas;
• Todo software tem alguma complexidade que só pode ser definida na implementação. Quase sempre estamos fazendo algo mais complexo do que antes e usando novas tecnologias. Isto traz inerentemente uma boa dose de risco, algo que devemos gerenciar ao invés de fingir que não existe. Por mais levantamento e projeto que façamos, eles nunca serão suficientes;
• Os negócios mudam. Eu um mundo de negócios cada vez mais dinâmico, é comum durante e execução de um projeto de software que as prioridades mudem e que as pessoas troquem de emprego. Mesmo que o levantamento seja executado 100% à perfeição – algo que considero simplesmente impossível – é muito provável que no momento da implantação aquele software perfeitamente desenvolvido não adéqüe-se mais às necessidades de negócio naquele momento.
As metodologias ágeis reconhecem que os problemas acima existem e procuram abraçá-los, de forma a conviver com eles. Existem vários métodos “ágeis”, como por exemplo “Extreme Programming (XP)”, “MSF/Agile” e “Scrum”.
Pessoalmente eu estou cada dia mais interessado no Scrum, também apoiado por vários criadores do “Agile Manifest”. Ao contrário de algumas técnicas ágeis, especialmente o XP, o Scrum inclui bastante planejamento, disciplina, responsabilidade dos integrantes da equipe e gerenciamento de riscos, em um pacote que faz sentido.
É perfeitamente possível trabalhar com Scrum sem nenhuma ferramenta de software, mas obviamente as coisas ficam mais fáceis se você tiver uma ferramenta para registrar as tarefas a fazer, as feitas e prioridades. Recentemente a Microsoft anunciou apoio ao Scrum e, com o apoio do Ken Schwaber (www.scrum.org), um dos “profetas” do Scrum, criou um template “Scrum” para o Visual Studio 2010. Isto, certamente dará um impulso extra a esta técnica na plataforma Microsoft.
O Scrum não é uma “bala de prata”, pois exige mudanças culturais, tanto em quem contrata como em quem desenvolve. Ele exige que todos trabalhem em comum de forma a entregar alguma coisa que tenha valor ao negócio, substituindo o relacionamento antagonista e burocratizado tradicional.