O termo Agilidade (ou Ágil) surgiu na área de Desenvolvimento de Software, em meados dos anos 90, em resposta a problemas com os métodos tradicionais de construir software vigentes na época. O método tradicional mais conhecido foi o desenvolvido por Royce em 1970, chamado de modelo Cascata ou Waterfall.

Esse modelo é composto por conjunto de fases de desenvolvimento, em que cada fase só se inicia quando se encerra a fase anterior, tendo como ponto de partida o planejamento prévio de cada etapa, no qual é redigido um escopo do andamento de cada tarefa antes do seu início.
Já Sommerville, descreve o modelo cascata com cinco fases ou estágios: definição de requisitos; projeto de sistema e software; implementação e teste unitário; integração e teste de sistema; e operação e manutenção. O modelo é ilustrado na Figura 2.

As fases do modelo também são executadas de maneira sequencial e sistemática, ou seja, uma após a outra, sendo que uma nova fase só é iniciada após a conclusão de sua antecessora. Por este motivo, é essencial que exista um comprometimento inicial do processo e que o cliente seja específico em seus requisitos, pois só ao final do projeto será analisada uma mudança no sistema.
Durante muito tempo comparava-se os projetos de desenvolvimento de software com projetos da construção civil, em que o modelo cascata funciona bem, mas essa ideia começou a ser desconstruída. Ainda em 1990, no livro “Wicked Problems, Righteous Solutions” (DeGrace & Stall, 1990 apud. Sutherland, 2004) já apresentava razões por que métodos tradicionais de desenvolvimento de software não funcionam, a partir de suas prerrogativas básicas:
- requisitos não são completamente compreendidos antes do início do projeto;
- usuários só sabem exatamente o que querem após ver uma versão inicial do produto;
- requisitos mudam frequentemente durante o processo de desenvolvimento;
- novas ferramentas e tecnologias tornam as estratégias de desenvolvimento imprevisíveis.
Não há definição universal de Agilidade, porém, todas as definições geralmente incorporam conceitos básicos de velocidade e flexibilidade para resposta a mudanças nos ambientes dinâmicos do mercado. Essas metodologias aplicam desenvolvimento iterativo e incremental em intervalos regulares e evolutivo, planejamento adaptativo, promovem entrega evolutiva e incluem outros valores e práticas que encorajam o feedback e permitem resposta flexível a mudança.
Além disso, buscam atingir diferentes aspectos do desenvolvimento de software, como o Extreme Programming (XP) em implementação de software, Test Driven development(TDD) em testes unitários e Scrum em gerenciamento do planejamento do projeto e implantação.
A popularização do termo Ágil (ou Agilidade) se deu quando 17 profissionais, em 2001, se reuniram na estação de esqui de Snowbird no estado de Utah, Estados Unidos, na intenção de unificarem sua forma de trabalho. Esses profissionais eram representantes de ideias, metodologias e processos que, em contraste com as práticas predominantes na época, estavam trazendo valor para seus clientes por meio de abordagens leves e empíricas para projetos de desenvolvimento de software. Eles já praticavam métodos leves como XP, DSDM, Scrum, FDD e etc.
Nesse encontro surgiu o Manifesto de Desenvolvimento de Software Ágil, uma declaração de valores e princípios para o desenvolvimento de software.
Entre os participantes estavam os criadores do Scrum (Ken Schwaber e Jeff Sutherland), que já estava em uso. Desta forma, o Scrum teve grande influência no manifesto.
O Manifesto do Desenvolvimento Ágil aborda valores que todos os profissionais que estavam reunidos acordaram em seguir e disseminar. São eles:
- 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
O grupo também criou 12 princícios que também devem ser seguidos por profissionais que buscam utilizar a filosofia. São eles:
- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
- Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência aos períodos mais curtos.
- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um Time de Desenvolvimento, é através de uma conversa cara a cara.
- Software funcional é a medida primária de progresso.
- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
- Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
- As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
De acordo com o estudo feito pela Mckinsey & Company que traz a análise do impacto de transformações ágeis em 22 organizações em seis setores, foram apresentados três principais resultados: melhoria da satisfação do cliente, engajamento dos funcionários e desempenho operacional. Eles compõem o que chamamos de “mecanismo de impacto ágil”.

Apesar dos resultados terem sido altamente positivos, o estudo aponta que a a extensão dos ganhos depende do nível inicial de agilidade da empresa, pois, naturalmente, aqueles que começam com linhas de base mais baixas sofrem mais alterações. Os ganhos significativos são encontrados apenas onde a Agilidade é implementada com êxito, holisticamente e com grandes ambições de melhoria de desempenho. E, por fim, ele alerta que a melhoria de 20 a 30% no desempenho financeiro pode não ser registrada como lucro e perda, pois as organizações tomam decisões estratégicas sobre a remoção de custos e o reinvestimento em crescimento e recursos.
Referências:
ROYCE, W. Managing the development of large software systems: Concepts and techniques. In: Proc. IEEE WESCOM. IEEE Computer Society Press, Los Alamitos. 1970.
SCHWABER, K. ; SUTHERLAND, J. Guia do Scrum. Disponível em
https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-PortugueseBR.pdf. Acesso em: 26 mai. 2017.
http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/8336/1/PG_COADS_2017_2_02.pdf
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo, SP: Pearson Prentice Hall, 2011.
DEGRACE,p.; STAHL, L.H. Wicked problems, righteous solutions. Englewood Cliffs, NJ: Yourdon Press Computing Series, 1990.
Kettunen, P.; LAANTI, M. Combining Agile Software Projects and Larg-scale Organizational Agility. Software Process Improvement and Practice, v. 13, 183-193, 2008.
SILVA, I. F.; NETO, P. A. M. S.; O’LEARY, P.; ALMEIDA, E. S.; MEIRA, S. R. L. Agile software product lines: a systematic mapping stud. Sortware – Pratice and Experience, v.41, 899-920, 2011.
https://www.mckinsey.com/business-functions/organization/our-insights/enterprise-agility-buzz-or-business-impact#, site acessado em 26/06/2020