Qual a diferença entre desenvolvimento tradicional e desenvolvimento ágil de software?

Resposta:

Metodologia de Desenvolvimento é o conjunto de práticas recomendadas para o Desenvolvimento de Softwares. Essas práticas podem ser subdividas em fases, para ordenar e gerenciar o processo (SOMMERVILLE, 2008). As metodologias tradicionais, também conhecidas como “pesadas”, têm como característica marcante sua divisão em etapas ou fases. Essas fases são definidas e englobam atividades como Análise, Modelagem, Desenvolvimento e Testes. Na conclusão de cada fase gerasse um marco, que pode ser um documento, como Diagramas de UML, um protótipo ou versão do software. Metodologias pesadas geralmente são desenvolvidas no “modelo em cascata”, e a cada alteração do projeto, será necessário à volta ao inicio do projeto para alteração da documentação ou de outro marco (PRESSMAN, 2006).

O termo “Metodologias Ágeis” tornou-se popular em 2001 depois que um grupo de especialistas, em desenvolvimento de software, reuniram-se para compartilhar experiências e discutir medidas que aumentassem as chances de sucesso de um projeto. Após algum tempo de pesquisa, esses especialistas publicaram um manifesto, que ficou conhecido como Manifesto for Agile Software Development [FOWLER 01]. Esse manifesto destacava quatro valores principais:

• Indivíduos e iterações mais que processos e ferramentas;

• Software funcional mais que documentação detalhada;

• Colaboração do Cliente mais que negociação de contratos;

• Responder às mudanças mais que seguir um plano.

Obs: É importante entender que o manifesto ágil não nos diz para esquecer os processos e ferramentas, a documentação, a negociação ou o planejamento, mas devemos tratá-los de maneira diferente, priorizando o foco em outros conceitos. 

______________________________________________________________________________

Abaixo seguem maiores informações sobre o desenvolvimento ágil:

Qualquer processo ágil de software é caracterizado de uma forma que se relacione a uma
série de preceitos-chave acerca da maioria dos projetos de software:

1. É difícil afirmar antecipadamente quais requisitos de software irão persistir e quais sofrerão
alterações. É igualmente difícil prever de que maneira as prioridades do cliente sofrerão alterações
conforme o projeto avança.

2. Para muitos tipos de software, o projeto e a construção são “interconduzidos”. Ou seja, ambas
as atividades devem ser realizadas em sequência (uma atrás da outra), para que os modelos
de projeto sejam provados conforme sejam criados. É difícil prever quanto de trabalho
de projeto será necessário antes que a sua construção (desenvolvimento) seja implementada
para avaliar o projeto.

3. Análise, projeto, construção (desenvolvimento) e testes não são tão previsíveis (do ponto de
vista de planejamento) quanto gostaríamos que fosse.
Dados esses três preceitos, surge uma importante questão: Como criar um processo capaz
de administrar a imprevisibilidade? A resposta, conforme já observado, consiste na adaptabilidade de processo (para alterar rapidamente o projeto e as condições técnicas). Portanto, um processo ágil deve ser adaptável.

Principios da Agilidade:

1. A maior prioridade é satisfazer o cliente por meio de entrega adiantada e contínua de software
valioso.

2. Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento. Os processos
ágeis se aproveitam das mudanças como uma vantagem competitiva na relação com o
cliente.

3. Entregue software em funcionamento frequentemente, de algumas semanas para alguns meses, dando preferência a intervalos mais curtos.

4. O pessoal comercial e os desenvolvedores devem trabalhar em conjunto diariamente ao
longo de todo o projeto.

5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e apoio necessários
e confie neles para ter o trabalho feito.

6. O método mais eficiente e efetivo de transmitir informações para e dentro de uma equipe
de desenvolvimento é uma conversa aberta, de forma presencial

7. Software em funcionamento é a principal medida de progresso.

8. Os processos ágeis promovem desenvolvimento sustentável. Os proponentes, desenvolvedores e usuários devem estar capacitados para manter um ritmo constante indefinidamente.

9. Atenção contínua para com a excelência técnica e para com bons projetos aumenta a agilidade.

10. Simplicidade — a arte de maximizar o volume de trabalho não efetuado — é essencial.

11. As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam.

12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais eficiente, então
sintoniza e ajusta seu comportamento de acordo.

Um abraço!!!

Na realidade todas as práticas que os métodos ágeis aplicam são práticas bastante conhecidas (e algumas até antigas) na literatura. O pair programming é apenas um peer review feito simultaneamente, TDD também não é novidade e assim por diante. Então pode-se dizer, sob este aspecto, que os métodos ágeis são um tanto "tradicionais". Entretanto, normalmente quando se faz esta comparação, normalmente se quer comparar os modelos de ciclo de vida dos projetos, podendo ser espiral, iterativo incremental, cascata, etc. Os métodos ágeis adotam o modelo iterativo incremental, assim como grande parte dos projetos atualmente que não usam métodos ágeis.

Uma coisa interessante é que em 1970, o Dr. Winston Royce publicou um artigo explorando os modelos de ciclo de vida. Ele partia de um simples (atividades em sequência, que hoje se chama cascata) e ia elaborando a fim de reduzir as deficiências da abordagem. Ele NUNCA sugeriu utilizar o cascata. De fato, após o diagrama no artigo dele, a primeira frase que se lê é "I believe in this concept, but the implementation described above is risky and invites failure." (em tradução livre, "Eu acredito neste conceito, mas a implementação descrita acima é arriscada e convida o fracasso"). É possível ler, nas linhas que seguem, todos os problemas atualmente associados com o cascata como a falta da possibilidade de incorporar mudanças e o primeiro feedback apenas no final do projeto.

Infelizmente um oficial do US Department of Defense achou uma boa e resolveu adotar. Como eles são o maior contratante de software do mundo, isso teve impacto nos USA e no restante do planeta. Ele reconheceu o erro em uma conversa entre ele e o Craig Larman, conforme Larman relata em "Agile and Iterative Development - A Manager's Guide".

O artigo do Winston Royce foi o Winston W. Royce (1970). "Managing the Development of Large Software Systems" in: In: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.

É possível achar online.

O primeiro artigo que chamou este modelo de "Waterfall" ("Cascata") foi:

T. E. Bell and T. A. Thayer, “Software requirements: Are they really a problem?,” presented at the 2nd international conference on Software engineering, San Francisco, California, United States, 1976, pp. 61–68. 

Também foi o primeiro artigo dedicado requisitos de software, até onde se saiba.

Parágrafo extra, não deve ser considerado parte da resposta:

Essas comparações que fazem entre métodos ágeis e tradicionais são normalmente comparações entre modelo de ciclo de vida iterativo e incremental versus cascata. Modelo de ciclo de vida iterativo e incremental pode ser utilizado em processos não-ágeis também, no entanto essa generalização de que tudo que não é ágil é cascata é muito confortável para quem acha que método ágil é bala de prata. O processo é uma coisa, o modelo de ciclo de vida é outra.

O desenvolvimento tradicional é conhecido por estabelecer uma ordem e padrão dentro do ramo de desenvolvimento de software.

Enquanto o desenvolvimento ágil busca reduzir os riscos e os custos presentes em um desenvolvimento de software, sendo uma quebra no padrão demorado e burocrático do desenvolvimento tradicional.