ANÁLISE COMPARATIVA ENTRE MÉTODOS ÁGEIS E TRADICIONAIS NO
DESENVOLVIMENTO DE SOFTWARE
Jonatas Bernardes de Oliveira¹; Lauenia Princia Ferreira da Costa² ; Lucas Henrique de
Castro Oliveira ³, Rhaellen Lorena de Jesus Gonçalves 4, Maria Aparecida Reis França 5
1, 2, 3, 4, 5
Universidade de Uberaba - UNIUBE
jonatas-bernardes@[Link]; [Link]@[Link]
Resumo
Quando surgiu a demanda por software
surgiu também a dificuldade em produzi- 1 Introdução
los com qualidade. Logo criou-se regras e Nas últimas décadas do século XX,
valores a serem seguidos para projetar e período em que as empresas começaram
desenvolver softwares que melhor a investir em softwares, os profissionais da
atendessem às necessidades dos usuários área de tecnologia não estavam
e clientes. preparados para a alta demanda de
Com essa necessidade de criação de desenvolvimento de aplicações, o que
regras e valores surgiram algumas resultava, muita das vezes, em um
metodologias de desenvolvimento: desenvolvimento precário e sem princípios
cascata, prototipação e espiral. Atualmente para serem seguidos. Este fato veio a
são nomeadas de metodologias alimentar a chamada “crise do software”,
tradicionais, pelo motivo de anos mais que teve seu início por volta dos anos de
tarde terem surgido outras. 1970 ocasionada por incidentes de
Essas outras, chamadas de metodologias software.
ágeis, são compostas por características
um pouco diferentes, mas carregam o Na primavera do ano de 2000,
mesmo objetivo: criar softwares de dezessete profissionais que já utilizavam
qualidade. meios diferentes de métodos de
Com o objetivo de estudar a diferença planejamento de desenvolvimento de
entre os dois tipos de metodologia, software se reuniram, todos com a
tradicional e ágil, desenvolvemos um intenção de debater as principais
aplicativo de chat utilizando a metodologia diferenças entre seus pensamentos, além
cascata e, mais tarde, o mesmo aplicativo da forma com que cada um lidava com
utilizando a metodologia Scrum. desenvolvimento de aplicações
computacionais.
Apesar de suas diferenças, ambas as
metodologias foram eficientes, mas a O resultado da reunião foi o
Scrum proporcionou um melhor resultado. desenvolvimento de um documento
Analisamos o desenvolvimento do projeto chamado de “Manifesto Ágil”. Este
e a resposta encontrada para que uma manifesto é uma declaração de diversas
metodologia tenha gerado um produto opiniões desses profissionais, que
melhor que a outra está na comunicação chegaram ao consenso que existem regras
entre a equipe e o cliente realizada mais e valores primordiais que devem ser
frequentemente na Scrum. seguidos e priorizados para se
desenvolver softwares com eficiência
temporal com qualidade.
Palavras-chave: projeto, planejamento, O planejamento com usos de métodos
qualidade do software. distintos para se realizar um objetivo não é
algo novo, pois o ser humano pode pensar
de diferentes formas e mesmo assim
alcançar o cumprimento do objetivo Figura 1 - O modelo em cascata.
proposto. É notável e aceitável que muitas
vezes podemos ter opiniões diferentes
sobre como realizar da melhor maneira
uma determinada tarefa a nós proposta.
Sobre este fato podemos perceber que não
existe em nenhuma parte do mundo
alguém que possa afirmar concretamente
que um método seja infalível, pois segundo
Aristóteles (GRÉCIA, 384 a.C. – 322 a.C.)
“Não há um só método para estudar as
coisas”.
O uso de métodos ágeis em diversos
desenvolvimentos (principalmente de Fonte: Dos autores baseado em Casa da
software) é amplamente incentivado consultoria (2017).
atualmente em contraposição ao uso de
métodos tradicionais. Este artigo tem como
objetivo discorrer sobre o tema O modelo é composto pelas fases de
apresentado se baseando em uma requerimento, projeto, implementação,
experiência no desenvolvimento de um verificação e manutenção.
aplicativo móvel utilizando os dois métodos O Scrum é uma metodologia ágil. Foi
mencionados. criado por Jeff Sutherland e Ken Schwaber
voltado, inicialmente, para planejar
2 Materiais e Métodos somente projetos de software. Atualmente,
Tanto nas metodologias tradicionais é utilizado também em outros tipos de
quanto nas metodologias ágeis de projeto, como em otimização no processo
desenvolvimento é preciso planejar e só de criação e construção de produtos
depois executar. Uma das diferenças entre (FONTES, 2019).
elas é o quanto se planeja antes de Diferente do cascata, o Scrum não é
executar o desenvolvimento de um constituído por fases. Os projetos são
software. Nas metodologias tradicionais a divididos por ciclos, chamados de sprints,
maior parte do tempo do projeto é que duram entre duas e quatro semanas.
reservado para planejar enquanto, nas Durante as sprints ocorrem
metodologias ágeis, o planejamento é feito planejamentos, reuniões, designação de
de forma iterativa e incremental, de acordo papéis para os membros da equipe,
com as necessidades descobertas pelo desenvolvimento de software e testes.
caminho (CÁCERES, 2015).
Para comparar o método tradicional com
o método ágil de desenvolvimento de Figura 2 - Ciclo Scrum.
software selecionamos a mais utilizada
entre as metodologias tradicionais e a mais
utilizada entre as metodologias ágeis:
Cascata e Scrum, respectivamente.
O modelo em cascata é o mais antigo de
todos os métodos. Foi criado em 1970 por
Winston Walker Royce. O nome se dá
devido às suas fases, por serem
sequenciais e cascateadas (DIAS, 2019).
Implementação
O programador o fez tentando alcançar, ao
máximo, os objetivos descritos na fase de
requerimento, para atender as
expectativas do cliente.
Testes
Com o desenvolvimento finalizado, os
desenvolvedores iniciaram os testes para
verificar as lógicas internas e
funcionalidades externas do aplicativo.
Fonte: Desenvolvimento ágil (sem data) Manutenção
Alguns erros foram descobertos durante os
Para analisar o funcionamento das testes e logo foram corrigidos. O aplicativo
metodologias foram desenvolvidos dois estava pronto para ser entregue ao cliente.
aplicativos de chat para a troca instantânea
de mensagens. Primeiramente foi Desenvolvimento em Scrum
desenvolvido seguindo as regras do Nada poderia ser iniciado sem antes fazer
cascata e, mais tarde, foi desenvolvido o a análise de requisitos mas, para ser ágil,
mesmo aplicativo seguindo as regras do foi feito um pequeno questionário e uma
scrum. rápida entrevista com o cliente. Rápido
porque, dessa vez, não seria a única vez
Desenvolvimento em Cascata que ele seria contatado durante o projeto.
Com as respostas em mãos, foi feita uma
Requerimento
breve descrição para o aplicativo.
Nessa parte foi feita uma análise e
Como sugestão do criadores dos métodos
definição de requisitos. Um questionário foi
ágeis, foram mapeados os stakeholders,
cuidadosamente elaborado, pelo motivo de
foram levantados os riscos (imprevistos
ser a única vez que teríamos contato com
que poderiam vir a acontecer) e foram
o cliente durante o projeto, e foi feita uma
descritas as possíveis soluções para
entrevista para descobrir os serviços que
contornar tais riscos.
precisavam ser fornecidos pelo aplicativo
Em seguida, foram definidos os recursos
de chat.
materiais e recursos humanos que seriam
Conclui-se que, foi feita uma descrição
necessários para o projeto.
detalhada do aplicativo e desenhado o
O Time Scrum é composto pelo Product
diagrama de caso de uso, o diagrama de
Owner, o Time de Desenvolvimento e o
sequência e o diagrama de classes.
Scrum Master (SCHWABER;
Projeto SUTHERLAND, 2017).
Foi iniciada esta etapa pensando na Dessa forma, foram definidos Jonatas
arquitetura do software. Para definir a Bernardes como Scrum master (o
lógica de programação e os recursos de responsável por facilitar reuniões e
software que seriam utilizados no projeto, remover os impedimentos da equipe),
foi desenhado o diagrama de componentes Lauenia Ferreira como Product Owner
e o diagrama de container. Depois disso, (responsável pela qualidade do
foram mapeados os stakeholders (todas as produto/software), Lucas Castro e
pessoas que poderiam estar envolvidas no Rhaellen Lorena como desenvolvedores
projeto) e, por fim, foi feito o design das (responsáveis pelo desenvolvimento do
telas. aplicativo).
Para desenvolver uma maior empatia com com o resultado, mas exigiu algumas
o usuário, antes de dar início ao alterações.
desenvolvimento o product owner Por fim, foram feitas as reuniões de
escreveu algumas User Stories (possíveis Sprint Review (reunião para revisar o que
tarefas que o usuário realizaria no foi feito durante a sprint) e a Sprint
aplicativo) e, em seguida, desenvolveu o Retrospective (reunião para analisar os
Product Backlog, que se trata de uma lista erros e buscar formas de melhorar).
de tarefas a serem desenvolvidas durante
o projeto. Segunda Sprint
Conforme mencionado, os projetos em Foi iniciada a segunda sprint com a
Scrum são divididos em ciclos, e assim foi elaboração de um novo, ainda curto,
feito. Foi estipulado que um mês seria o questionário e agendamento de uma nova
prazo suficiente para finalizar o entrevista com o cliente, para falar sobre
desenvolvimento do aplicativo, então esse as alterações e foram acrescentadas no
tempo foi dividido em dois ciclos de duas Product Backlog as novas tarefas.
semanas, ou duas sprints. Durante a Sprint Planning foram
selecionadas as tarefas que restaram no
product backlog e transferidas para a
Primeira Sprint Sprint Backlog.
Para dar início a sprint, o Scrum Master Foram feitas novamente as reuniões
agendou a Sprint Planning (reunião de diárias até concluir a sprint. Quando o time
planejamento da sprint). Durante a reunião de desenvolvimento concluiu o aplicativo,
foram selecionados os itens do product foram feitos novamente os testes e
backlog (lista de tarefas) que achamos que corrigidos os erros.
seria possível concluir até o final da sprint O resultado foi apresentado ao cliente,
e, com o consentimento de toda a equipe, que ficou totalmente satisfeito, e foi
foram criadas as seguintes definições de finalizada a sprint com a Sprint Review,
pronto: o código do aplicativo deveria ser para revisar o que foi feito durante a
comentado de forma construtiva, para que segunda sprint e a Sprint Retrospective,
outros programadores pudessem editá-lo para analisar novamente os erros e sugerir
facilmente; quando terminadas as tarefas melhorias para o próximo projeto.
da lista, o código deveria ser testado pelo
programador e depois por outro colega da Cascata ou Scrum?
equipe, para evitar os erros. Apesar de suas diferenças, ambas as
Durante a sprint foram realizadas as metodologias foram eficientes para o
Daily Meetings (reuniões diárias), que desenvolvimento do aplicativo. Portanto,
eram momentos quando todos da equipe para analisar os resultados, foi preciso
contavam ao Scrum Master o que havia definir o que levar em consideração antes
feito no dia e o que pretendiam fazer no de apontar a melhor metodologia.
próximo dia, compartilhando os
impedimentos, caso houvesse. Foi levado em consideração os
No final da sprint, todas as tarefas seguintes pontos:
haviam sido concluídas com sucesso e, ● comunicação entre os membros da
começou-se os testes. equipe
Os erros descobertos foram corrigidos e ● preocupação com a qualidade do
então foi apresentado o que havia sido software
feito para o cliente para saber se ele estava ● preocupação com a usabilidade do
satisfeito e se poderia ser dada software
continuidade no projeto. Ele ficou satisfeito ● a qualidade da documentação do
software
● envolvimento do usuário (cliente)
durante o desenvolvimento
● o modo como os softwares são
testados
● a facilidade ao dar manutenção no
software
● o nível de aceitação para alterações
de requisitos no software
3 Resultados esperados
O desenvolvimento em Cascata foi
bastante efetivo e proporcionou ótimos
resultados.
Já o desenvolvimento em Scrum foi um
pouco mais complexo, mas foi isso que
gerou diferença entre os dois aplicativos.
Ambos os aplicativos foram construídos
com as opções de realizar cadastro, fazer Fonte: Dos autores
login, iniciar conversas, visualizar
conversas anteriormente iniciadas e
anexar imagens da galeria.
Utilizar Scrum como metodologia Figura 4 - Enviar arquivos (scrum).
permitiu acrescentar as funcionalidades de
fazer login somente com o webmail da
Uniube, de anexar fotos instantâneas da
câmera, criar grupos de contatos e uma
barra de pesquisa para facilitar a busca por
contatos.
Figura 3 - Enviar arquivos (cascata).
Fonte: Dos autores.
Figura 5 - Com Pesquisa (scrum).
Fonte: Dos autores. Fonte: Dos autores.
Figura 6 - Sem Pesquisa (cascata).
Figura 8 - Sem a possibilidade de criar
grupo(cascata).
Fonte: Dos autores.
Fonte: Dos autores.
As diferenças aconteceram devido à
possibilidade de se desenvolver software
em ciclos, que é uma das propriedades das
metodologias ágeis.
Dessa forma, ao invés de o cliente ter
recebido o aplicativo somente quando
estava completo, como no Cascata,
Figura 7 - Criar grupo (scrum).
quando foi finalizada a primeira sprint, o
resultado foi apresentado e ele
compartilhou sua sincera opinião e exigiu Scrum foi bem mais flexível. As alterações
que fossem incluídas as outras que o cliente exigiu durante a reunião
funcionalidades. foram realizadas com facilidade.
4 Discussão Realizar alterações no aplicativo
Enquanto que no modelo em Cascata a desenvolvido em Cascata seria muito mais
comunicação é quase opcional, quando se complexo e demorado devido ao código
trata do Scrum a comunicação é pouco organizado, sem citar a
obrigatória e ocorre por meio das reuniões possibilidade de se criar erros.
diárias, reuniões de planejamento da
sprint, reuniões de revisão da sprint e 5 Conclusão
reuniões de retrospectiva da sprint. A metodologia que gerou um software de
Ambas as metodologias, têm suas maior qualidade foi, sem dúvidas, a Scrum.
vantagens se tratando da preocupação O desenvolvimento de projetos utilizando
com a qualidade e usabilidade do software essa metodologia trouxe a convicção de
mas, analisando o resultado final, a Scrum que o produto a ser desenvolvido sempre
permitiu a geração de um software de esteve em nosso controle. As reuniões
maior qualidade graças à comunicação diárias deixavam todos os integrantes do
entre os membros da equipe e a grupo atentos a todos os detalhes e essa
comunicação entre cliente e equipe. comunicação foi de suma importância para
A metodologia que leva vantagem em o sucesso do aplicativo desenvolvido. A
relação à qualidade da documentação do forma de trabalhar no Scrum é um pouco
software é, sem dúvida, a Cascata. Nela foi complexa, mas gera efeitos significativos
preciso criar uma diversidade de no decorrer do projeto.
diagramas para planejar o funcionamento
do software antes de dar início ao Referências
desenvolvimento.
Em relação ao envolvimento do cliente CÁCERES, Luis. Metodologias ágeis ou
durante o desenvolvimento do software, na tradicionais: quais são as melhores para
metodologia em Cascata se faz contato o meu projeto? Disponível em:
com ele somente no início do projeto, [Link]
quando ocorre o levantamento de odologias-ageis-ou-tradicionais-qual-e-a-
requisitos e, depois disso, só é contatado melhor-para-meu-
no dia da entrega do software, o que pode projeto#:~:text=A%20primeira%20grande
ser prejudicial. %20diferença%20entre,descobrindo%20o
Apesar de ambas as metodologias %20percurso%20no%20caminho.. Acesso
terem suas fases de testes, utilizar Scrum em: 01 out. 2020.
tornou possível explorar o modo como se
testa: além do programador, outra pessoa BERNARDO, Kleber. Manifesto ágil,
realizou os testes. Dessa forma, os testes como tudo começou. [S. l.]: Cultura Ágil,
não foram deixados somente na 8 dez. 2014. Disponível em:
responsabilidade de quem criou o código e [Link]
mais erros foram descobertos. agil-como-tudo-comecou/. Acesso em: 01
Quanto à facilidade de dar manutenção out. 2020.
no software, em Scrum foi mais simples.
De acordo com a definição de pronto CASA DA CONSULTORIA. Modelo em
criada, o código deveria ser comentado de cascata: o que é e como funciona.
forma construtiva. Logo, era um código Disponível em:
auto explicativo. [Link]
Se tratando do nível de aceitação para cascata/. Acesso em: 01 out. 2020.
alterações de requisitos no software,
DESENVOLVIMENTO ÁGIL. Scrum. [Link]
Disponivel em: m. Acesso em: 01 out. 2020.
[Link]
crum/. Acesso em: 01 out. 2020. SCHWABER, Ken; SUTHERLAND, Jeff.
Guia do Scrum: Um guia definitivo para o
DIAS, Ricardo Pereira. O modelo em Scrum: As regras do Jogo. 2. ed. Scrum
cascata. Disponível em: Guides, 2017. Disponível em:
[Link] [Link]
modelo-em-cascata-f2418addaf36. mguide/v2017/2017-Scrum-Guide-
Acesso em: 01 out. 2020. [Link]. Acesso em: 14
out. 2020.
FONTES, Alexia. Scrum: entenda como
funciona esse método ágil. Disponivel em: