Comparação entre Metodologias Clássicas e Ágeis

Prévia do material em texto

Comparação entre Metodologias Clássicas e Ágeis 
 
 
EVANDRO RODRIGUES DE MORAES1 
 
Resumo: Neste artigo, nós estaremos vendo uma comparação entre metodologias tradicionais 
e ágeis no desenvolvimento de software. Em particular, a metodologia ágil será tratada com um 
pouco mais de detalhes, já que estaremos fazendo uma abordagem um pouco mais detalhista de 
seus objetivos. Em ambas as metodologias, daremos foco aos custos e resultados que podem 
ser obtidos quando utilizado as metodologias ágeis. Por fim, será proposta uma comparação 
entre as metodologias. 
 
Palavras-Chave: Metodologias, desenvolvimento de software, planejamento, organizacional. 
 
Comparison between Classical and Agile Methodologies 
 
 
Abstract: On this article, we will be seeing a comparison between traditional and agile 
methodologies for software development. The agile development in particular will be treated 
with some more details since we will be doing a more detailed approach to it´s objectives. For 
both methodologies we will focus on costs and results that can be reached using agile. Finally, 
a comparison between the methodologies will also be proposed. 
 
Keywords: Methodologies, software development, planning, organizational. 
 
1. Introdução 
O software, assim como todo capital, é um conhecimento incorporado pelo fato de 
inicialmente ele ser disperso, tácito, latente e incompleto. O desenvolvimento dele é um 
processo de aprendizado, um diálogo no qual o conhecimento e aprendizagem social fornecem 
subsídios para a criação de um software; tal é a interação entre usuários e projetistas, 
ferramentas e usuários, que o processo de desenvolvimento em si acaba se tornando um meio 
de comunicação, possibilitando a extração de mais conhecimento útil das pessoas envolvidas e 
favorecendo a evolução desse software. (BAETJER, 2011) 
Esse processo de desenvolvimento, ou melhor dizendo, processo de software de alta 
qualidade, seria ele um sinônimo de engenharia de software? Para Pressman a resposta seria 
sim e não, uma vez que o processo de software define uma abordagem na medida em que o 
software é construído pela engenharia. Já a engenharia engloba tecnologias que compõem o 
processo. 
 
1 Evandro Rodrigues de Moraes - Graduando em Análise e Desenvolvimento de Sistemas - FATEC Mogi Mirim 
Arthur de Azevedo 
E-mail: evandromoraes95@gmail.com 
 
2 
 
2. Desenvolvimento 
2.1 Metodologia Clássica 
Inicialmente foram propostos os modelos de processo prescritivo para auxiliar na área 
de desenvolvimento de software. Esses modelos tradicionais proporcionaram uma contribuição 
para a estrutura utilizada no trabalho de engenharia de software por um longo tempo. Porém, 
com o passar do tempo, a engenharia de software e seu produto continuam “à beira do caos”. 
(PRESSMAN, 2011) 
Essa classificação em que é colocada a engenharia de software, à beira do caos, é uma 
das implicações filosóficas que enriquecem a engenharia. Por exemplo, como os modelos 
clássicos são propostos para maximizar a estrutura e a ordem, não seriam eles inapropriados 
para um ambiente que tende a sofrer mudanças contínuas? Mas e se nós trocarmos esse modelo 
para um novo menos estruturado, seria ainda possível ter uma boa coordenação e coerência na 
desenvoltura do projeto? São situações difíceis e que necessitam de serem avaliadas para serem 
respondidas, mas temos que esclarecer que existem alternativas disponíveis para que os 
engenheiros de software explorem, uma vez que esses modelos de processo de software 
acomodam atividades metodológicas genéricas, mas que cada um deles tem como foco 
atividades diferentes e que definem um fluxo de processos que invocam atividades 
metodológicas. 
Não há respostas para perguntas como, deve-se adotar uma metodologia mais, ou 
menos, estruturada; o que temos são alternativas disponíveis para que os engenheiros tenham 
como opção. Uma delas são os modelos tradicionais porque transmitem um conjunto de 
atividades metodológicas, tarefas, produtos de trabalho, garantia de qualidade e mecanismos de 
controle de mudanças. Vamos examinar agora a abordagem de processos prescritivos, ou 
modelos clássicos, onde cada modelo de processo tem um fluxo de trabalho próprio, definindo 
assim a melhor forma para que os elementos serão inter-relacionados. (PRESSMAN, 2011) 
Entremos agora nas entrelinhas de uma das metodologias procedurais, ou metodologias 
tradicionais como ficaram conhecidas. 
2.1.1 Prototipação 
Geralmente é utilizado quando um cliente define os objetivos a serem atingidos para o 
software, porém ele não especifica detalhadamente os requisitos para determinar as funções e 
os recursos do sistema. Mas, também é comum de se encontrar o uso dessa metodologia quando 
o desenvolvedor não tem certeza sobre a eficiência dos algoritmos em um determinado 
ambiente, ou até mesmo em como deve ocorrer a interação entre homem e máquina. Para 
situações como essas, dentre outras, é comum abordar o problema através do paradigma da 
prototipação. 
O paradigma da prototipação tem início com a comunicação. É feita uma reunião com 
todas as partes envolvidas no projeto para que sejam definidos todos os objetivos principais do 
software, a partir daí são coletadas informações mais detalhadas sobre os requisitos que 
obrigatoriamente necessitam de uma definição mais bem especificada. Assim que uma iteração 
de prototipação é planejada, ocorre a sua modelagem, na forma de um projeto rápido, onde visa 
3 
 
em concentrar em uma representação dos aspectos do software visível aos usuários, como 
interfaces e formas de exibição na tela. 
O projeto rápido é o que gera a construção de um protótipo, ele será avaliado por todos 
os envolvidos para que que possam dar seus “feedbacks” e então, determinar quais os próximos 
aprimoramentos, isso ocorre conforme o protótipo se ajusta às necessidades dos interessados. 
Porém, os protótipos também atuam como mecanismo para coletar requisitos. Para protótipos 
operacionais por exemplo, pode-se utilizar partes de programas já existentes para agilizar o 
processo de geração dos protótipos e obter retorno das partes interessadas mais rapidamente. 
Brooks (1995), recomenda que o primeiro protótipo seja descartado, porque dificilmente ele é 
utilizável, devido a suas instabilidades, pode estar muito lento, grande, com usabilidade de 
difícil uso, ou até mesmo os três juntos, então para esses casos é comum recomeçar o projeto, 
porém ciente das dificuldades e necessidades de alteração na nova versão, o que facilita a 
evolução até a transformação do sistema real. 
Apesar de suas facilidades de interação entre cliente e desenvolvedor, já que os clientes 
conseguem ter uma visão prévia do sistema, podendo interagir e solicitar mudanças aos 
desenvolvedores, dos benefícios que o paradigma da prototipação trás, ela pode ser um pouco 
problemática em alguns fatores. É comum que durante a reconstrução desse sistema, a ideia 
seja manter o nível de qualidade e até mesmo melhora-lo, no entanto, as partes interessadas 
despertam o interesse de solicitar poucas alterações, com o intuito de tornar o protótipo no 
produto operacional, no entanto não é uma boa prática e deve ser evitada, pois acabam 
prejudicando a qualidade global do software e deixando de facilitar sua manutenção e 
modificações futuras. Podemos colocar a linguagem de programação como um exemplo disso, 
muitas vezes escolher a linguagem por estarem mais acostumados e não pelo ambiente em que 
ela será implementada em si ou porque oferece recursos ou facilidade de implementar 
algoritmos não por sua performance e sim para demonstrar capacidade. 
Apesar dos problemasque pode apresentar, o sucesso da prototipação vem juntamente 
de como é feito seu uso, o que pode o tornar um paradigma efetivo para a engenharia de 
software. Para que a metodologia seja utilizada efetivamente, é necessário que as regras sejam 
definidas logo no início de sua implementação, todos os envolvidos devem entender que o 
protótipo é construído apenas para servir como um mecanismo para auxiliar na definição de 
requisitos e, portanto, o mesmo será descartado e outro software final é arquitetado focando a 
qualidade. 
2.2 Metodologias Ágeis 
Em 2001, foi assinado o “Manifesto para o Desenvolvimento Ágil de Software” foi 
assinado por Kent Beck e outros dezesseis renomados desenvolvedores, consultores e autores 
da área de software. Eles desvendaram formas melhores de desenvolvimento e com isso deram 
início a um novo padrão de desenvolvimento, que tinha como intuito ajudar as pessoas a 
desenvolverem software. 
Essa metodologia diferentemente das demais existentes anteriormente, conseguia 
valorizar “Indivíduos e interações acima de processos e ferramentas. Software operacional 
acima de documentação completa. Colaboração dos clientes acima de negociação contratual. 
Respostas a mudanças acima de seguir um plano”. (PRESSMAN, 2011). Não apenas valorizar, 
4 
 
mas também conseguia sanar fraquezas reais que a engenharia de software convencional 
apresentava. Entretanto, não é indicado a ser aplicado como uma filosofia geral para todos os 
trabalhos de software, projetos e pessoas. 
Devido a economia nos dias atuais, é quase impossível se prever como um sistema irá 
evoluir ao passar do tempo, as condições de mercado estão em constante mudanças, ameaças 
competitivas surgem e as necessidades dos usuários sofrem alterações. Devido a essas 
condições não é possível determinar completamente os requisitos antes de dar início ao projeto, 
para isso é necessário que as mudanças sejam fluídas ao negócio do cliente. Fluidez implica 
diretamente em mudanças, o que geram elevados custos, principalmente sob uma má gestão. 
Contudo, as metodologias ágeis têm uma abordagem muito bem elaborada para reduzir os 
custos de mudanças ao longo do processo de desenvolvimento. 
Apesar das metodologias ágeis terem sido apresentadas para suprir deficiências das 
metodologias clássicas e resultar em melhorias em um contexto geral, ela realmente é melhor 
do que o modelo prescritivo? Segundo Alistair Cockburn (PRESSMAN, 2011, p.82), o ponto 
chave para essa resposta está na metodologia clássica, ela se esquece das fragilidades das 
pessoas que estão desenvolvendo aquele sistema. As pessoas apresentam estilos de trabalho 
diferenciados, níveis de habilidade, organização, criatividade, espontaneidade e consistências 
diferentes umas das outras. Cockburn (PRESSMAN, 2011, p.82) afirma que modelos de 
processos são capazes de “lidar com as fraquezas comuns das pessoas com disciplina e/ou 
tolerância” e que os processos prescritivos optam por disciplina, “como a consistência nas ações 
é uma fraqueza humana, as metodologias com disciplina elevada são frágeis”. 
Para que as metodologias funcionem então, elas devem apresentar mecanismos realistas, 
que estimulem a disciplina necessária ou então, que tenham uma certa “tolerância” com as 
pessoas que estão desenvolvendo os trabalhos de engenharia de software. Porém Cockburn 
ressalta, práticas de tolerância são mais adotadas e sustentadas pelas pessoas envolvidas nos 
projetos, porém podem acabar sendo menos produtivas. Logo, devemos considerar prós e 
contras para qualquer processo a ser adotado. (PRESSMAN, 2011) 
2.2.1 Fatores Humanos 
Antes de detalharmos algumas metodologias ágeis, devemos enfatizar a importância dos 
fatores humanos presentes dentro de “agile”. Cockburn e Highsmith (PRESSMAN, 2011, p.86) 
afirmam que, “O desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o 
processo de acordo com as pessoas e as equipes específicas”. Isso quer dizer que o processo se 
adapta às necessidades das pessoas e equipes e não o oposto como ocorre nas metodologias 
tradicionais. E, como os membros da equipe que orientam as características do processo, 
existem alguns traços entre as pessoas de uma equipe. 
Seguem alguns dos principais traços a serem avaliados durante a construção de uma 
equipe: 
Competência – abrange um contexto geral do desenvolvimento ágil, desde o talento 
inato, como habilidades específicas, técnicas, ou até mesmo o conhecimento generalizado do 
processo que a equipe irá aplicar para determinado sistema. Entretanto, é interessante que todas 
as partes compartilhem conhecimento com as demais pessoas da equipe. 
5 
 
Foco comum – embora os membros da equipe desempenhem tarefas que trazem 
diferentes habilidades para o projeto, todos devem estar focados em um objetivo em comum. 
Isso inclui manter o foco em adaptações contínuas, que farão com que o processo seja ajustado 
às necessidades da equipe. 
Colaboração – os membros da equipe devem colaborar entre si e com todos os 
envolvidos para que sejam criadas informações de valor para compreender o trabalho da equipe 
e consecutivamente, resultar em dados que tragam valor ao negócio do cliente. 
Tomada de decisões – as equipes devem ser autônomas para controlar o destino o qual 
o projeto deve tomar, tanto em decisões técnicas como de projeto. 
Habilidade em solução de problemas – as equipes lidam continuamente com 
ambiguidade e são continuamente atingidos por mudanças. Os integrantes devem estar cientes 
de que o problema sendo enfrentado hoje não necessariamente será o mesmo a ser solucionado 
no dia seguinte. Entretanto, as experiências adquiridas durante a execução das tarefas podem 
futuramente beneficiar essa equipe em outros projetos. 
Confiança e respeito – a equipe deve ser consistente, demonstrar confiança e respeito 
para que a torne “tão fortemente unida que o todo fica maior do que a soma das partes” 
(DeMarco e Lister, 1998, p.86) 
Auto-organização – ela implica em três contextos do desenvolvimento ágil. Primeiro, 
a equipe se organiza para trabalhar nesse projeto. Segundo, a equipe adequa o processo para 
seu ambiente local. Por fim, a equipe cria um cronograma de trabalho para cumprir a entrega 
dos incrementos. “A equipe seleciona quanto trabalho acredita ser capaz de realizar dentro da 
iteração e se compromete com o trabalho. Nada desmotiva tanto uma equipe como um terceiro 
assumir compromissos por ela. Nada motiva tanto uma equipe quanto aceitar a responsabilidade 
de cumprir completamente o prometido feito por ela própria”. (SCHWABER, 2002) 
2.2.2 Desenvolvimento de Software Adaptivo (ASD) 
O ASD foi uma proposta de Jim Highsmith para as metodologias ágeis com o intuito de 
facilitar o desenvolvimento de sistemas complexos. Esse modelo foca principalmente na 
colaboração humana auto organizadora de equipes. Podemos ressaltar que o desenvolvimento 
ágil e adaptativo baseia-se na colaboração e constitui um recurso para organizar as complexas 
interações, assim como disciplina e engenharia. Essa metodologia define um ciclo de vida de 
três fases, especulação, colaboração e aprendizagem. 
Durante a fase de especulação, são feitos planejamentos de ciclos adaptáveis. Esses 
ciclos utilizam informações do início do projeto, onde é definida a missão do cliente, as 
restrições do projeto e os requisitos básicos. Logo, são definidos os conjuntos de ciclo de 
versões, que serão requisitados para o projeto. 
Independente de quão completo esteja o plano de ciclos, inevitavelmente o plano sofrerá 
mudanças, mesmo que desde o início as mudanças visadas. Isso ocorre porque baseando-se nas 
informações coletadas a medida em que se completa os ciclos, o plano é revisto e modelado demodo que o trabalho planejado se adeque da melhor forma possível a realidade à qual a equipe 
ASD está trabalhando. 
6 
 
As pessoas do projeto utilizam a colaboração como uma forma de multiplicar seus 
talentos e produções criativas e claro, seus números absolutos. 
2.3 Comparativo entre as metodologias 
Grande parte das metodologias ágeis não chegam a ser inovadoras (COCKBURN, 
2001). O que as tornam um diferencial das metodologias tradicionais são seu foco em seus 
valores, já que seu princípio é o foco nas pessoas, já as metodologias tradicionais têm como 
foco em processos ou algoritmos. Além do que, a metodologia ágil pode ser adaptada para que 
tenha mais foco na implementação e não tanto na documentação, como ocorre na Extreme 
Programming, por exemplo, já que ela tem foco totalmente voltado à implementação e não em 
documentação. 
As metodologias ágeis são adaptivas ao invés de serem preditivas. Isso quer dizer que 
elas se adaptam durante o decorrer do projeto. Já as metodologias tradicionais impõem que os 
projetos sejam analisados previamente de tudo o que pode acontecer durante seu 
desenvolvimento. Essa análise prévia é um dos fatores negativos, uma vez que é muito cara de 
ser realizada e de difícil realização. Além de correr o risco de forçar a equipe a trabalhar sob 
pressão para seguir estritamente o planejado e, mesmo que falte tempo, acabam sendo forçados 
a fazerem várias horas extras para atenderem aquele requisito dentro do prazo. No entanto, 
muitas vezes, aquele requisito que está segurando a desenvoltura do projeto é algo que foi mal 
planejado e agora não aceitam modificações nos requisitos, já que a metodologia não prevê uma 
iteratividade entre as etapas de desenvolvimento. 
Com isso, podemos colocar que para ser classificada como uma metodologia ágil, é 
necessário que o desenvolvimento esteja pronto para aceitar mudanças, e não tentar prever o 
que está por vir. Mas, as mudanças não são o é o problema em si, mesmo porque ela irá ocorrer 
de qualquer forma, já que novas versões serão lançadas. O real problema é como as 
necessidades de mudanças serão recebidas, avaliadas e respondidas às mudanças. 
Devemos aplicar as metodologias tradicionais então, apenas quando tivermos um 
sistema claramente definido e com possíveis mudanças previsíveis, mesmo que por solicitações 
do stakeholder¹. Do contrário, as mudanças dentro do modelo clássico podem ter seu custo 
aumentado me “1x” quando feita na fase de requisitos e de “60x a 100x” quando feita durante 
a implementação (PRESSMAN, 2001) 
Ao contrário das tradicionais, as metodologias ágeis têm vários aspectos positivos, um 
deles são as entregas constantes. Essas entregas podem ser definidas como partes operacionais 
do software final, assim o cliente tem a possibilidade de ir testando e não há a necessidade de 
ficar esperando pela versão final. A integração e os testes contínuos possibilitam uma melhora 
na qualidade do software, já que não é necessário haver uma fase de integração, e sim, são 
integrados, testados e aprovados constantemente. 
Apesar das metodologias ágeis ainda estarem “crescendo”, ganhando espaço no 
mercado e entre as equipes, já vem sendo comprovado por especialistas que ela vem ganhando 
espaço e apresentando ótimos resultados quando o assunto é cumprimento de prazos, custos e 
padrões de qualidade. 
7 
 
3. Conclusão 
O objetivo das metodologias ágeis agora é eliminar seus pontos fracos cada vez mais, 
como por exemplo as longas horas trabalhadas pelos funcionários para atingirem as datas 
planejadas para o projeto, a falta de análise de riscos de forma que não se torne uma metodologia 
pesada já que em algumas metodologias nem ao menos existe uma fase de análise de riscos 
“formal”. Outro ponto importante é descobrir uma forma de implementar essas metodologias 
em grandes equipes, como fazer uma divisão de trabalho sem sobrecarregar a equipe, e 
principalmente, explorar a melhor habilidade de cada um dos integrantes, principalmente agora 
que as grandes empresas estão adotando ao modelo. 
Não apenas explorar a qualidade individual de cada um dos integrantes da equipe, mas 
também é importante resolver problemas de comunicação internamente entre todos os 
integrantes, principalmente agora que as equipes passaram estão crescendo, e porque hoje em 
dia é comum os funcionários estarem separados geograficamente. 
Uma vez que a equipe toda esteja conectada e nivelada tecnicamente, - não que todos 
devem saber sobre tudo, mas sim que todos tenham a mesma produtividade em suas respectivas 
especialidades -, não há o que justifique o uso das metodologias prescritivas, uma vez que isso 
pode acabar “engessando” a estrutura do projeto, limitando a capacidade da equipe, limitando 
prazos, deixando passar oportunidades de aprendizagem para o time em um contexto geral, e o 
pior de todos, limitam o desejo dos clientes, já que ele fica limitado a custos e modelos. 
No entanto, apesar do crescente interesse das empresas e equipes em quererem utilizar 
metodologias ágeis, faltam casos de sucesso para engatilhar o uso das metodologias. Quanto 
mais organizações fizerem uso, melhores serão os resultados empíricos, então será possível 
obter e estudar as vantagens, desvantagens, riscos e procedimentos para que as empresas 
possam se adaptar ou melhorar antes de fazer adoção ao uso de determinadas metodologias e 
possam usufruir de seus benefícios. 
4. Referências 
BAETJER, H. J. (2011). Engenharia de Software Uma Abordagem Profissional: R. S. 
PRESSMAN, Engenharia de Software Uma Abordagem Profissional (p. 52). AMGH 
Editora Ltda. 
COCKBURN, A. e HIGHSMITH, J. (2001). Agile Software Development: The Business of 
Innovation, IEEE Computer (120-122) 
COX, B. J. (2011). Engenharia de Software Uma Abordagem Profissional: R. S. 
PRESSMAN, Engenharia de Software Uma Abordagem Profissional (p. 31). AMGH 
Editora Ltda. 
DEMARCO, T e LISTER, T (1998). Peopleware, 2d ed. Dorset House 
MONIER, L. (2011). Engenharia de Software Uma Abordagem Profissional: R. S. 
PRESSMAN, Engenharia de Software Uma Abordagem Profissional (p. 37). AMGH 
Editora Ltda. 
PRESSMAN, R. S. (2011). Engenharia de Software Uma Abordagem Profissional. AMGH 
Editora Ltda. 
SCHWABER, K. (2002). Agile Processes and Self-Organization. Agile Alliance. 
8