Na metade da década de 90, começaram a emergir modelos de desenvolvimento que iam contra aos métodos dirigidos a planos, como o modelo de desenvolvimento em “cascata”.
Nos modelos tradicionais, o foco é maior na análise de requisitos do software e projeto do que no desenvolvimento e testes. Sendo assim, em um cenário de um sistema de pequeno ou médio porte, a mudança repentina de requisitos causa mudança na especificação e no projeto, fazendo que voltem a “estaca zero”, ou seja, um grande retrabalho.
Pesquisas feitas como o Chaos Report (Standish Group) em 1994 apontaram que apenas 16% dos projetos obtinham sucesso.
Os modelos que começaram a surgir, como Extreme Programming e Scrum, começaram a priorizar o software em si, deixando um pouco de lado a parte da documentação. Atacando as condições que levavam os projetos ao fracasso, o objetivo era entregar o software ao cliente de uma forma mais rápida, para que ele já avaliasse e mostrar onde deseja alterações ou novos requisitos.
Essa abordagem só é possível com alguns valores, como a iteração constante, entrega incremental, envolvimento do cliente no desenvolvimento, busca pela qualidade e simplicidade e união da equipe de desenvolvimento. Antes, estes métodos eram chamados de métodos “leves”, para contrastar com os antigos, que eram chamadas de métodos de abordagens “pesadas”.
Em Fevereiro de 2001, dezessete desenvolvedores entusiastas se reuniram e publicaram o Manifesto Ágil (Manifesto for Agile Software Development).
“Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.
Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas;
Software em funcionamento mais que documentação abrangente;
Colaboração com o cliente mais que negociação de contratos;
Responder a mudanças mais que seguir um plano;
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”.
http://agilemanifesto.org
Os métodos ágeis são eficientes para alguns tipos de sistemas, como em desenvolvimento de produtos para venda em pequeno e médio porte ou também em desenvolvimento de sistemas que o cliente estará envolvido no processo de desenvolvimento e que não há muitas regras que afetam o software.
Aplicações web, por exemplo, aceitam bem a metodologia ágil, pois normalmente os seus requisitos mudam constantemente. A abordagem ágil pura em sistemas críticos também não é vista com bons olhos, pois estes sistemas necessitam de toda uma análise de confiança e segurança, fazendo que sejam feitas mudanças nos métodos antes serem usados.
De acordo com o Chaos Manifesto (2012, Standish Group) foi apontado que 49% de sucesso de projetos em abordagens ágeis, enquanto abordagens dirigidas a planos foram de 14%.
Entretanto, ágil não significa de sucesso. Como no momento da criação, o foco eram sistemas de pequeno e médio porte, a aplicação dos métodos em sistemas de grande porte é difícil, onde se faz de necessárias documentações e projeto já adiantados. Quanto a equipes, quando existem várias destas trabalhando, também fica mais difícil integrá-las.
Também é necessário ressaltar que quando a metodologia ágil é usada sem engajamento da equipe, é grande a possibilidade de fracasso do projeto.
