Universidade Federal de Minas Gerais

Instituto de Ciências Exatas

Departamento de Ciências da Computação
Curso de Bacharelado em Sistemas de Informação

O uso de Métodos Ágeis para o Desenvolvimento de

Software

por

GRUPO 5
Fábio Dayrell Ferreira Martins Rosa
Jéssica Taís Carvalho Rodrigues
Maria Isná Alencar de Castro
Priscila Izabelle De - Stefano Santos
Rômulo Rafael da Silva

Artigo de Engenharia de Software

Apresentado como artigo acadêmico na disciplina de Engenharia

de Software do curso de Bacharelado em Sistemas de Informação
da UFMG.

Belo Horizonte
2017 / 2º semestre
1. INTRODUÇÃO

Diferentes métodos e modelos têm sido introduzidos por pesquisadores ao

longo dos tempo destinados ao desenvolvimento de software. Um processo de
software pode ser considerado como um conjunto de ferramentas, métodos e
práticas que são usados para produzir um produto de software.
Desde o início, diferentes metodologias foram introduzidas e usadas pela
comunidade de engenharia de software. Em 1998, o termo “ágil” (em inglês, “agile”)
foi associado a primeira vez com o termo de “processo de software” (em inglês,
“software process”). Daí, os métodos ágeis iniciaram seu processo de ascensão
culminando com surgimento do Manifesto Ágil (do inglês, “Agile Manifesto”) no ano
de 2001, como resposta à ineficiência do métodos de desenvolvimento de software
existentes em ambientes com rápida mudança.
“Ágil” (ou “Agile”) significa não somente rápido, mas também ativo e
responsivo. Este método representa uma grande saída das abordagens baseadas
em planos tradicionais para engenharia de software. Segundo William e Cockburn
(2003), o desenvolvimento ágil é “sobre feedback e mudança”, uma vez que as
metodologias ágeis são desenvolvidas para “abraçar, ao invés de rejeitar, maiores
taxas de mudança” (Muhammad e Tahir, 2004).
Os métodos ágeis são a mistura de desenvolvimento iterativo com um
conjunto de melhores práticas para lidar com mudanças de software e aumentar a
satisfação do cliente. Nos últimos anos, muitas organizações estão se adaptando
para a adoção de métodos ágeis de desenvolvimento de software.
Consequentemente, isso é impulsionado pela necessidade contínua de desenvolver
soluções de softwares melhores, mais rápidas e economicamente eficientes, além
de satisfazer as necessidades dos clientes.
Os métodos convencionais de desenvolvimento de software não são muito
eficientes para se utilizar com a rápida alteração nos requisitos e as iterações curtas
que são necessárias para uma entrega eficiente do produto.

1.1 ​Visão geral do assunto

As metodologias ágeis, como um conceito relativamente recente para a

engenharia de software, estão se tornando populares tanto na indústria quanto na
academia. Uma resposta mais rápida geralmente é produzida pelas pessoas
envolvidas usando metodologias ágeis, que por sua vez melhora o desempenho do
sistema e acelera o processo de desenvolvimento.
Embora as práticas modernas padronizadas, ferramentas e tecnologias
avançadas tenham mudado o cenário de desenvolvimento de software, segundo
Beck et al. (2001) a indústria ainda não conseguiu produzir o crescimento bem
sucedido esperado.
No desenvolvimento de software, vários são os desafios encontrados:
mudanças de escopo do projeto, os resultados percebidos pelo cliente, o
cumprimento de prazos do projeto, motivação e competências da equipe do projeto,

2
custos para a execução de projetos, rentabilidade dos projetos etc. Na realidade de
um projeto mudanças ocorrem, o cliente não sabe o que quer, as estimativas não se
confirmam, as pessoas da equipes são diferentes e os recursos são escassos.
Diante deste cenário, as metodologias ágeis propõem crenças e princípios: ​(i)
retorno sobre o investimento, (ii) melhoria de processos, (iii) desenvolvimento
de pessoas e da cultura, (iv) comunicação, (v) adaptação​ e ​(vi) inovação.
O Manifesto Ágil (2001) tem por principais pontos: ​(i) indivíduos e interação
mais que processos e ferramentas, (ii) software funcional mais que
documentação abrangente, (iii) colaboração do cliente mais que negociação
de contrato, (iv) responder a mudanças mais que seguir um plano, (v)
mudança de postura dando mais ênfase às pessoas do que a processos, (vi)
desenvolvimento iterativo e incremental, ​e (vii) visão ágil​, ou seja, prioriza o que
é mais importante e foca nisso.
Assim, enquanto as metodologias tradicionais têm um planejamento para
prevenção de mudanças, as metodologias ágeis incorporam as mudanças ao
projeto devido à necessidade, oportunidade, requisitos incompletos e outros fatores
geradores de mudanças. Daí, faz-se necessário entender os princípios, técnicas e
ferramentas das metodologias ágeis, pontuando-se as vantagens e desvantagens
delas que não implique numa “defesa cega” destas metodologias em oposição às
metodologias tradicionais, uma vez que ambas podem contribuir para projetos de
desenvolvimento de software que gere produtos finais de melhor qualidade e maior
valor percebido pelo cliente.

1.2 ​Objetivo, justificativa e motivação

1.2.1 ​Objetivos

● apresentar as principais metodologias ágeis;

● identificar as vantagens e desvantagens destas metodologias;
● relacionar as metodologias ágeis com a área de engenharia de software;
● caracterizar o cenário atual quanto ao uso das metodologias ágeis;
● apresentar o cenário futuro quanto às metodologias ágeis e a engenharia de
software.

1.2.2 ​Justificativa

Metodologias ágeis é um assunto atual, emergente e relacionado com a área

de Engenharia de Software, representando um tema recorrente entre os atores
desta área; relaciona-se diretamente com as atividades de desenvolvimento de
software através de métodos e ferramentas que, segundo defensores, potencializam
o desenvolvimento de softwares a partir da eficiência, desenvolvimento ágil e
geração de valor e benefícios para cliente. Os rápidos avanços da tecnologia, as
importantes transformações econômicas percebidas e outras necessidades têm
aumentado as exigências quanto à qualidade dos softwares e sistemas em “menor

3
tempo possível”.

1.2.3 ​Motivação

Conhecer as metodologias ágeis que dão suporte a área de engenharia de

software, compreender sua utilização no processo de desenvolvimento de software,
projetar-se quanto às tendências futuras das metodologias ágeis, desenvolvimento
de software e engenharia de software e identificar as vantagens e desvantagens das
metodologias ágeis quanto ao desenvolvimento softwares, uma vez que o mercado
tem pedido (ou mesmo, exigido), requisitos dos profissionais que envolvam
conhecimento teórico e prático sobre metodologias ágeis.

2. CONTEXTUALIZAÇÃO E TRABALHOS RELACIONADOS

Metodologias ágeis é um tema recente na área de Engenharia de Software.

Vários fatores e motivos podem ser enumerados sobre a adoção de metodologias
ágeis no desenvolvimento de software: mudanças dos requisitos definidos no início
do projeto, objetivos no início do projeto podem não estar muito claros, incertezas
do projeto, estimativas iniciais, índices de erros, necessidade de processos mais
flexíveis e menos controlados, acompanhar o aumento das necessidades e das
demandas por softwares entre outros que poderiam ser facilmente citados.
Vários pesquisadores trabalharam em metodologias ágeis como, por
exemplo, Jeffrey et al. (2007), Tore et al. (2009) e Ahmad et al. (2010). Jeffrey et al.
(2007) conduziram uma pesquisa revelando que existe uma correlação significativa
entre a implementação bem sucedida da metodologia e o treinamento sobre a
metodologia.
Tore et al. (2009) mencionaram que os desenvolvedores estavam
principalmente satisfeitos com métodos ágeis: as empresas que estavam usando o
XP (extreme programming) relataram que os funcionários estavam mais satisfeitos
com o produto e as conclusões sobre a eficácia da programação em par foram
diversas, com vários desenvolvedores considerando isso como uma prática
exaustiva porque exige muita concentração.
Ahmed et al (2010) realizaram uma pesquisa que mostrou que a metodologia
mais comumente utilizada no Paquistão é a Scrum, com cerca de 31% da indústria
utiliza Scrum (ou uma versão próxima) em 50% dos projetos.
Outros trabalhos sobre metodologias ágeis são citados: uma pesquisa de
artigos acadêmicos e científicos publicados por Rico (2008); uma pesquisa online
com mais de 3 mil pessoas pela VersionOne (2008); um trabalho de comparação
rigorosa de 26 projetos ágeis com uma base de 7.500 projetos tradicionais por Mah
(2008) da QSMA; uma pesquisa online com 642 pessoas pelo Dr. Dobb’s Journal
(2008). O artigo ​A decade of agile methodologies: Toward explaining agile software
development (Dingsoyr, 2012) examina publicações e citações para mostrar como a
pesquisas sobre metodologias ágeis progrediram nos 10 anos posteriores a
publicação do Manifesto Ágil.

4
 Assim, é possível considerar que há uma série de fatores que podem
influenciar direta ou indiretamente os projetos de desenvolvimento em um quadro
ágil. A adoção de metodologias de desenvolvimento ágil tem um impacto positivo na
produtividade e na qualidade: Tore et al. (2009) articularam que o desenvolvimento
ágil de software teve um enorme impacto em como o software é desenvolvido em
todo o mundo e em uma pesquisa de 2005 nos EUA e Europa, por exemplo, revelou
que 14% das empresas que usavam métodos ágeis e 49% das empresas estavam
cientes dos métodos ágeis e estavam interessadas em adotá-los. Outras pesquisas,
como a já citada por Mah (2008), trata sobre produtividade em projetos ágeis e
indica que projetos ágeis são 16% mais produtivos.
Atualmente, as metodologias ágeis estão se tornando cada vez mais
requeridas nas atividades relacionadas ao desenvolvimento de software. Do outro
lado, as metodologias tradicionais estão em um panorama de declínio, porém
convém destacar que as metodologias ágeis são produtos das metodologias
tradicionais, a partir do momento que estas contribuíram de diferentes maneiras:
● seja pelas necessidades que emergiram com os avanços das
tecnologias;
● os problemas e os desafios originados da aplicação de antigas
metodologias que não suportavam eficientemente o desenvolvimento
de software;
● pesquisas em engenharia de software com as finalidades de
desenvolver novas práticas ou de aperfeiçoá-las para atender as
demandas dos clientes e;
● as necessidades das equipes de desenvolvimento entre outros fatores.

3. MÉTODO DE PESQUISA

O método de pesquisa adotado no desenvolvimento deste artigo

compreende, em síntese, as seguintes etapas:
1. Definição do tema: realizada durante o mês de Agosto de 2018 entre
os membros do grupo. A definição do tema foi orientada por um
assunto mais atual dentro das várias possibilidades existentes dentro
da área de Engenharia de Software e, ao mesmo tempo, útil para o
aprendizado acadêmico e profissional;
2. Entrega da proposta de artigo: submissão através do ambiente
Moodle da disciplina de Engenharia de Software, 2017/02, em
30/08/2017. Um modelo/gabarito com a seção de “Introdução” foi o
objeto de entrega;
3. Revisão da literatura: durante o mês de Setembro, trabalhos
acadêmicos (artigos, monografias, teses, dissertações etc.) e
profissionais (ou seja, materiais disponibilizados por diferentes tipos de
organizações - empresas, comitês etc - e profissionais da área) foram
pesquisados e selecionados aqueles que estivessem congruentes aos
objetivos do trabalho;
4. Desenvolvimento do artigo: a partir dos referenciais bibliográficos
selecionados - isso não significa que novas pesquisas não foram

5
 realizadas mediante alguma necessidade - foi realizado o
desenvolvimento do trabalho ao longo do mês de Outubro;
5. Revisão do artigo: as duas primeiras semanas de Novembro
compreenderam atividades de revisão do desenvolvimento do
trabalho, apresentação e discussão dos resultados e conclusão do
artigo;
6. Apresentação do artigo: em 13/11/2017, como requisito de avaliação
da disciplina de Engenharia de Software, uma apresentação do artigo
desenvolvido foi realizada ao professor e alunos;
7. Revisão final: a partir dos feedbacks da apresentação do artigo,
novas revisões das partes de Desenvolvimento, Resultados e
Conclusão foram realizadas, para se obter uma versão final e
qualificada para submissão como entrega final;
8. Entrega final: a entrega final ocorreu através do ambiente Moodle da
disciplina em 20/11/2017.
Este artigo trata-se de uma pesquisa bibliográfica, não se fazendo
necessárias ferramentas, metodologias ou outros recursos sofisticados para o
desenvolvimento deste trabalho. Portanto, compreende um artigo de revisão da
literatura disponível sobre metodologias ágeis. Não é considerado uma revisão
sistemática por não utilizar os métodos fundamentais para este tipo de trabalho.
É importante destacar que, a partir dos objetivos, o artigo recorre a
referências bibliográficas acadêmicos e de mercado, uma vez que se trata de um
tema de interesse e de pesquisas por atores destes dois conjuntos. Ciente dos
objetivos e da importância de assegurar qualidade das fontes bibliográficas
utilizadas, a revisão e seleção demandou maior tempo e esforço por parte dos
autores para originar um trabalho final com qualidade.

4. DESENVOLVIMENTO DO TRABALHO

4.1 BREVE HISTÓRICO DA ENGENHARIA DE SOFTWARE

Segundo Macro (1990), “A Engenharia de Software é o estabelecimento do

uso de bons princípios de engenharia e boas práticas de gerenciamento, além da
evolução de ferramentas e métodos para uso apropriado, a fim de obter, dentro dos
limites existentes, um software de alta qualidade.”
O principal desafio na área de Engenharia de Software nos últimos anos (ou
mesmo décadas) tem sido o estudo e a melhoria da qualidade e redução de custo
do software produzido. Em 1980, conforme recordado por Pressman (1995), a
revista Business Week publicou uma reportagem com o título “Software: A Nova
Força Propulsora”. Essa reportagem simboliza uma atenção quanto aos benefícios
do desenvolvimento de software para as organizações.
Em meados da década de 1980, a revista Fortune lança uma reportagem de
capa “Uma Crescente Defasagem de Software” e, ao final da década, novamente a
Business Week traz um alerta ao mercado de software, aos seus autores e seus
leitores através da reportagem “A Armadilha do Software - Automatizar ou Não”. O

6
ponto de inflexão na indústria de desenvolvimento de software emerge no início da
década de 1990 através de duas reportagens: uma da Newsweek, “Podemos
Confiar em Nosso Software”, e pelo Wall Street Journal em “Criar Software Novo:
Era uma Tarefa Agonizante…”.
A história da computação é marcada por três desafiantes períodos descritos
por Pressman (1995): inicialmente, o principal desafio era desenvolver o hardware
que reduzisse o custo de processamento e armazenagem de dados, então a década
de 1980 apresenta avanços na microeletrônica que resultam em maior poder de
computação com menor custo. Na década de 1990, o desafio foi melhorar a
qualidade e reduzir os custos das soluções baseadas em computador - isto é,
soluções em software.
Atualmente, quando se trata de desenvolvimento de software (e de
engenharia de software) se percebe que estes assuntos estão em constante e
rápido desenvolvimento, pois softwares de qualidade são cada vez mais requeridos.
A engenharia e o desenvolvimento de software possuem ferramentas novas e
poderosas que são suporte para o processo de desenvolvimento (Peters, 2001).
Entre 1950 e 2000, o desenvolvimento de software passou por importantes
desafios e mudanças para acompanhar as diferentes necessidades que surgiam.
Pressman (1995), divide este intervalo em quatro grandes períodos, conforme figura
1 abaixo:

Figura 1 - A evolução do Software (Pressman, 1995)

O período atual, denominado quinta era, é sintetizado por Pressman (1995)

em três problemas macros: (1) a sofisticação do software ultrapassou a capacidade
de construir software que extraia o potencial do hardware; (2) a capacidade de
construir programas não pode acompanhar o ritmo da demanda de novos
programas e (3) a capacidade de manter os programas existentes é ameaçada por
projetos ruins e recursos inadequados.
Reitera essa visão o posicionamento de Peters (2001) ao considerar que os
desafios que os engenheiros de software encontram hoje são semelhantes aos
existentes quando a engenharia de software ainda engatinhava, ou seja, os esforços
para desenvolver softwares confiáveis são contínuos.
O processo de desenvolvimento de qualquer software impõe uma série de
problemas às equipes: dificuldades acidentais e dificuldades essenciais, problemas
conceituais, especificação de requisitos, definição e cumprimento de prazos, custo
de um projeto, produtividade, qualidade e teste de software, trabalho em equipe,
capacitação de pessoal, planejamento, motivação, manutenibilidade, gerência de

7
projeto, análise crítica (Prikladnicki, 2004).
Ainda por Prikladnicki (2004), quanto aos desafios do desenvolvimento de
software, é possível considerar os novos ambientes de desenvolvimento
(e-business, desenvolvimento Web, outsourcing, ambientes fisicamente
distribuídos), gerenciamento de riscos, capacitação de pessoal, planejamento,
padrões de desenvolvimento de software, certificação, aprendizagem
organizacional, produtividade e motivação.
A evolução da tecnologia resolveu desafios anteriores ao que se refere às
áreas da Engenharia de Software, mas ao mesmo tempo novos desafios emergiram
devido às diferentes formas possíveis de desenvolver um sistema. Ficar preso a
uma abordagem, a um modelo ou a alguma metodologia já não é mais possível
quanto à atividade de desenvolvimento de software, então é possível considerar que
a combinação de diferentes abordagens, técnicas e ferramentas podem
potencializar resultados mais precisos, adequados, elegantes e econômicos.
O bom uso e integração das partes ferramentas, métodos e processo é
necessário para que a qualidade final do software atenda aos requisitos e às
necessidades do cliente, uma vez que este é uma das principais partes
interessadas. As relações entre o proprietário do produto (e equipe) e o cliente,
entretanto, não são sempre amistosas e positivas. Para além disso, o ambiente, a
organização e as interações entre os membros da equipe de desenvolvimento
(fatores internos) e fatores externos também corroboram.
Neste breve histórico descrito sobre a Engenharia de Software, mais
especificamente para o processo de desenvolvimento de software, as metodologias
ágeis surgem como um tema recorrente entre os atores envolvidos com esse
processo. A área de Engenharia de Software é especificamente grande, com vários
assuntos integrantes, uma gama de abordagens, técnicas, ferramentas e
metodologias existentes, relacionadas e complementares para fazer frente aos
desafios e problemas inerentes da área.
Este trabalho está organizando da seguinte forma: após esse breve histórico,
discorre-se sobre o processo de desenvolvimento de software; em seguida, sobre
as metodologias tradicionais do processo de desenvolvimento de software; depois,
com maior foco, as metodologias ágeis são abordadas; trata-se, também, dos
principais problemas do desenvolvimento de software e, finalmente, os atuais
desafios quanto ao desenvolvimento de software e as conclusões e considerações
que os autores chegaram ao fim do trabalho.

4.2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Segundo Pressman (2001) - no livro “Software Engineering. A Practitioner’s

Approach” - “o principal desafio na área de Engenharia de Software nas últimas
duas décadas tem sido o estudo e a melhoria da qualidade e redução de custo do
software produzido.” Este desafio é também uma realidade atual e, talvez, com
exigências ainda maiores quanto o aumento da qualidade e a redução de custos,
uma fórmula perseguida não somente para o sucesso das organizações, quanto
para aumento da rentabilidade e lucratividade delas. Atualmente, o software ao
atender um cliente, indiretamente, atende aos interesses de vários outros

8
stakeholders, em alguns casos, interesses conflituosos.
A literatura apresenta diferentes definições sobre a Engenharia de Software,
muitas delas complementares entre si. Das definições encontradas, considera-se a
mais apropriada a este artigo ao definir a Engenharia de Software como “(...) o
estabelecimento e o uso de bons princípios de engenharia e boas práticas de
gerenciamento, além da evolução de ferramentas e métodos para uso apropriado, a
fim de obter, dentro dos limites existentes, um software de alta qualidade” (Macro,
1990).
A partir da definição anterior, destaca-se os seguinte trechos: (i) “​uso de
bons princípios”, ​(ii) “boas práticas de gerenciamento”, ​(iii) “além da evolução
de ferramentas e métodos” e ​(iv) “dentro dos limites existentes, um software
de alta qualidade”. Estes trechos destacados da definição permite importantes
considerações, as quais podem ser extensivas às metodologias ágeis:
1. em ​(i) fundamenta que bons princípios são necessários no processo de
desenvolvimento de software, independente dos métodos, abordagens,
ferramentas e metodologias adotadas e vai de encontro das capacidades e
habilidades dos membros que compõem as equipes de desenvolvimento;
2. já ​(ii)​, orienta para a importância de boas práticas de gerenciamento. Em
nível macro, o Gerente de Projetos e, em nível micro, dos membros da
equipe. Gerenciar não compreende apenas uma atividade do Gerente de
Projetos / Scrum Master (que, no caso dele, é um dos seus papéis
fundamentais), mas também da equipe por adotar boas práticas ao gerenciar
suas tarefas dentro do processo de desenvolvimento;
3. o trecho ​(iii) orienta para as melhorias e evoluções que são promovidas nas
áreas da Engenharia de Software, indicando dinamismo constante destes
elementos, para fazer frente aos desafios e problemas inerentes e
emergentes da área, especialmente nos dias atuais: necessidades urgentes,
redução de custos, alta competitividade, múltiplos interesses das partes
direta ou indiretamente envolvidas etc.;
4. provável que um dos trechos mais importantes, ​(iv) ao mencionar as
limitações que existem quando se trata de desenvolvimento de software, pois
há vários fatores que influenciam a qualidade final (tempo, recursos,
legislações, competidores, evoluções tecnológicas etc.). Ao reconhecer as
limitações, pois não é possível se fazer tudo, os atores envolvidos,
especialmente aqueles ligados diretamente ao desenvolvimento do software,
podem dedicar esforços para a qualidade final do software, sem despender
energias desnecessariamente em tarefas que, por ora, possuem limitações.

Retomando o livro “Software Engineering. A Practitioner’s Approach”,

Pressman (2001) apresenta a Engenharia de Software como uma área formada por
4 camadas, onde as três primeiras representam os elementos fundamentais e cujo
focos de ambas é a última camada denominada foco na qualidade.

9
 Figura 2 - Camadas da Engenharia de Software (Pressman, 2001)

As ferramentas de Engenharia de Software proporcionam o apoio necessário

para os metódo, como um sistema de suporte para o desenvolvimento de software.
As ferramentas podem ser automatizadas ou semi-automatizadas. Enquanto os
métodos de Engenharia de Software orientam para os detalhes para o
desenvolvimento do software - “como fazer” - e possuem um conjunto de tarefas
relacionadas (planejamento, estimativas de projeto, análise de requisitos, estrutura
de dados, arquitetura do programa, arquitetura de hardware, algoritmos, codificação,
testes, manutenções etc.).
A terceira camada, o processo, é considerado por Pressman (2001) a mais
importante na Engenharia de Software, pois representa a ligação entre ferramentas
e métodos, possibilitando o desenvolvimento racional de software. O processo
define a sequência das tarefas de desenvolvimento, quando os métodos serão
aplicados, as entregas, os controles de qualidade, a coordenação de mudanças, os
marcos de referência com a finalidade de acompanhar e avaliar o progresso do
desenvolvimento. Por fim, a última camada, o foco na qualidade, representa a
camada básica cujo resultado final depende da qualidade nas interações (quando e
como) das camadas acima.
Segundo Carvalho e Chiossi (2001), há algumas propriedades desejáveis
para um produto de software ligado à qualidade dele:
● formalidade (produtos confiáveis, controle de custos e confiança do
desempenho através de um processo sistemático);
● abstração​ (identificação dos aspectos importantes de uma realidade);
● decomposição (subdividir o processo em atividades específicas menores,
atribuídas à especialistas de diferentes áreas, melhorando o planejamento
das atividades e diminuindo o tempo extra e a complexidade);
● generalização (possibilidade da reutilização de uma solução em diferentes
pontos do sistema, porém uma solução genérica é mais custosa em termos
de velocidade de execução ou tempo de desenvolvimento, faz-se necessário
avaliar uma solução generalizada) e;
● flexibilidade (ser suficientemente flexível para permitir que componentes do
produtos desenvolvido seja útil para outros sistemas, bem como a
portabilidade entre diferentes sistemas computacionais).

10
4.3 METODOLOGIAS TRADICIONAIS DE CICLOS DE VIDA DO PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE

Segundo Peters e Pedrycz (2001), o ciclo de vida de um software é “a

definição dos passos que transformam aquela ideia no produto acabado.” O ciclo de
vida do processo de desenvolvimento de software é a parte vital do processo de
gerenciamento de software, necessários ao Gerente de Projetos e à Equipe de
Desenvolvimento.
A seguir, são apresentados os principais modelos de ciclo de vida para o
processo de desenvolvimento de software resumidamente, uma vez que este artigo
não tem por finalidade uma análise mais profunda destes modelos.

4.3.1 MODELO DE CICLO DE VIDA CLÁSSICO OU MODELO DE CASCATA

Ciclo de vida que utiliza método sistemático e sequencial, onde o resultado

de uma fase é a entrada para outra. Cada fase é estruturada como um conjunto de
atividades que podem ser executadas por pessoas diferentes, simultaneamente.

Figura 3 - Modelo de Ciclo de Vida Clássico ou Modelo Cascata (Peters e Pedrycz, 2001)

Segundo Pressman (1995) e Peters e Pedrycz (2001), este ciclo de vida

abrange atividades de: ​análise e engenharia de sistemas​, ​análise de requisitos
de software​, ​projeto​, ​codificação​, ​testes​ e ​manutenção​.

11
 Carvalho e Chiossi (2001), este modelo tem como vantagens: ​(i) ​caracteriza
fases estanques para as quais podem ser descritas técnicas para o seu
desenvolvimento de forma clara e ​(ii) é o ciclo de vida mais amplamente utilizado da
Engenharia de Software. Quanto às desvantagens, enumeram-se: ​(i) os projetos
reais raramente seguem o fluxo sequencial proposto pelo modelo, ​(ii) o cliente não
saber declarar todas as suas exigências, ​(iii) o cliente deve ter paciência, pois
qualquer erro detectado após a revisão do programa de trabalho pode ser
desastroso.

4.3.2 MODELO DE CICLO DE VIDA INCREMENTAL OU MODELO DE

PROTOTIPAÇÃO

Neste ciclo de vida, há o processo de prototipação, de tal maneira que um

produto de software é incrementado pelo programador a partir das dúvidas que
surgem quando da interação entre ele e o cliente. Isso capacita os atores do
processo de desenvolvimento do software que será implementado.

Figura 4 - Modelo de Ciclo de Vida Incremental ou Modelo de Prototipação

Segundo Pressman (1995) e Peters e Pedrycz (2001), este ciclo abrange

atividades de: ​coleta de requisitos​, ​elaboração de um projeto e ​avaliação do
protótipo. Neste contexto, o protótipo é útil para a identificação de requisitos de
software e, quando necessário, o protótipo deve ser descartado para evitar esforços
desnecessários e perda de tempo com correções.
Peters e Pedrycz (2001), este modelo tem como vantagens: ​(i) permite que o
usuário interaja de forma mais ativa na modelagem do sistema, ​(ii) facilita a
identificação dos requisitos de software e ​(iii) acelera o desenvolvimento do
sistema. Quanto às desvantagens, enumeram-se: ​(i) o cliente, ao desejar
resultados, não compreenderá que o protótipo está longe de ser o software final e
ideal, ​(ii) a gerência de desenvolvimento terá que lidar com as reclamações e, em
alguns casos, encurtar prazos ou adotar outras ações que afetem a qualidade final
do produto e ​(iii) a equipe de desenvolvimento pode gerar protótipos ineficientes,
especialmente quando há diferentes fatores e atores pressionando.

12
4.3.3 MODELO DE CICLO DE VIDA ESPIRAL

Este modelo, segundo Boehm (2000), foi desenvolvido para englobar as

melhores características dos ciclos de vida clássico e incremental, ao mesmo tempo
em que adiciona um novo elemento, a análise de risco.

Figura 5 - Modelo de Ciclo de Vida Espiral (Peters e Pedrycz, 2001)

Este ciclo de vida abrange quatro importantes atividades, conforme

Pressman (1995) e Peters e Pedrycz (2001): ​planejamento​, ​análise dos riscos​,
engenharia e ​avaliação do cliente. Este modelo é considerado a abordagem mais
realística para o desenvolvimento de software e sistemas em grande escala, uma
vez que capacita a equipe de desenvolvimento e o cliente a entender e a reagir aos
riscos em cada etapa evolutiva da espiral.
Pressman (1995) e Peters e Pedrycz (2001), este modelo tem como
vantagens: ​(i) permite um desenvolvimento evolutivo do software, ​(ii) permite uma
interação com o usuário, ​(iii) os requisitos não precisam ser todos definidos no
começo, ​(iv) é iterativo, com um marco para avaliação final de cada iteração, ​(v)
busca integração do desenvolvimento tradicional com a prototipação e ​(vi) introduz
a análise de risco. Como desvantagens, enumeram-se: ​(i) pode ser difícil
convencer grandes clientes de que a abordagem evolutiva é controlável, ​(ii) se um
grande risco não for descoberto, com certeza ocorrerão problemas, ​(iii) é mais
complexo e tem um custo mais alto do que os outros ciclos de vida; ​(iv) pode não
convergir para uma solução e ​(v) dependendo do projeto, a relação custo/benefício
pode ser duvidosa.

13
4.4 METODOLOGIAS ÁGEIS DE CICLOS DE VIDA DO PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE

Vários fatores influenciaram e catalisaram o desenvolvimento de

metodologias ágeis para o desenvolvimento de software, de maneira que o
processo pudesse atender em boa medida esses fatores derivados das crescentes
pressões do mercado por inovação, prazos, produtividade, flexibilidade, melhoria no
desempenho e na qualidade dos projetos de desenvolvimento de software e, ainda,
atingir o foco principal: satisfação do cliente.
Satisfação do cliente, seja em metodologias ágeis ou tradicionais, é um
atributo, uma consequência final desejável na execução de qualquer projeto. A
qualidade final, então, será diretamente determinada pela execução da parte vital de
um projeto: o gerenciamento do projeto, cujas responsabilidades estão sobre o
Gerente de Projetos, distribuídas para a Equipe de Desenvolvimento.
Segundo uma pesquisa realizada pela Standish Group - Chaos Report (s.d) e
citada por Steffen (2012), a área de TI possuía nas últimas duas décadas,
significativas taxas de erros.

Tabela 1 - Avaliações de projetos entregues nas últimas duas décadas (Standish Group - Chaos
Report, s.d.)

Cerca de 66% dos projetos apresentaram problemas (atrasos, estouro de

orçamentos, defeitos, não atendem as necessidades do cliente etc.) ao longo do seu
processo de desenvolvimento até a conclusão e, criticamente, resultaram em 24%
de projetos fracassados, outrora 44% com algum problema que, em maior ou menor
grau, afeta a qualidade final do software. Além disso, é importante destacar que dos
32% projetos que são considerados de sucesso, aproximadamente 20% da
funcionalidade do software é realmente útil. Estes são números um tanto quanto
críticos, preocupantes.
Deste cenário, emergiram as metodologias ágeis como uma nova forma de
gestão e desenvolvimento de software através de uma abordagem de planejamento
e ​execução iterativa e ​incremental voltado para processos empíricos: complexos,
caóticos, muitas incertezas, mudanças ao longo do processo, imprevisibilidade e
sem repetições). ​Divide-se o problema em problemas menores que geram
produtos também menores e ​visa entregar um produto funcionando

14
regularmente (entregas constantes de partes operacionais), ​aproximação e
colaboração da Equipe de Desenvolvimento com aqueles com significativo
know-how do negócio​, ​comunicação​, ​redução dos riscos associados às
incertezas do projeto (integração e testes contínuos), ​adaptativa (respostas às
mudanças de forma mais rápida e natural) e, por fim, ​satisfação final do cliente
devido à ​adoção de práticas de gestão (como, por exemplo, feedbacks) e
engenharia de software baseados nos valores e princípios do Lean e do Agile​.
Reconhece-se, assim, que o desenvolvimento de software é um processo
complicado e imprevisíveis, mas com mecanismos voltados para ações corretivas.

4.4. BREVE HISTÓRIA

O termo “Metodologias Ágeis” surgiu em 2001, nos Estados Unidos, a partir

da iniciativa de 17 especialistas em desenvolvimento de software cujo objetivo era
discutir formas de melhorar o desempenho dos seus projetos. Apesar de cada
envolvido ter suas próprias práticas teorias sobre o desenvolvimento de um projeto
de software para se ter sucesso, havia um senso comum que um certo conjunto de
princípios são necessários ser respeitados para potencializar o sucesso de um
projeto.
A partir daí, cria-se a Aliança Ágil, bem como o Manifesto Ágil, o qual contém
conceitos e princípios comuns compartilhados entre entre as metodologias ágeis.
Sob a ótica do Manifesto Ágil, o processo de desenvolvimento de software
precisaria valorizar:
● Indivíduos e interação entre eles mais que processo 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.
Conforme analisa Soares (s.d.), o Manifesto Ágil não rejeita os processos e
ferramentas, a documentação, a negociação de contratos ou o planejamento, mas
simplesmente mostra que eles têm importância secundária quando comparado com
os indivíduos e interações, com o software funcionando, com a colaboração com o
cliente e as respostas rápidas a mudanças e alterações.

4.4.1 METODOLOGIAS ÁGEIS EXISTENTES E APLICAÇÕES

Segundo Steffen (2012), “desenvolvimento ágil é o termo utilizado por

diferentes metodologias e frameworks que desenvolvem software de forma iterativa
e incremental. Algumas são mais prescritivas ou menos.”
Então, mencionando algumas das metodologias ágeis existentes: Agile at
scale methods (A-Scale), Agile Unified Process (AUP), Extreme Programming (XP),
Feature-Driven Development (FDD), Kanban, Lean Development, OpenUP, RUP e
Scrum.
Conforme será apresentado mais adiante, pesquisas apontam que o Scrum é
15
a metodologia mais utilizada. É importante destacar que cada uma das
metodologias ágeis têm suas particularidades e práticas sugeridas, sendo possível
também um mix (hibridismo) entre elas, ou seja, uma mescla dessas metodologias,
de tal maneira que as melhores práticas sejam aplicada a um processo
customizado.
Então, analisar a necessidade, a maturidade da equipe, o projeto a
desenvolver e outros fatores são importantes para que os conceitos, princípios e
práticas ágeis possa gerar benefícios esperados e não simplesmente implementar
“às cegas”. Ainda, adotar uma metodologia ágil pode evidenciar as fraquezas das
partes que compõem o processo de desenvolvimento de software, permitindo atuar
ativamente sobre elas, discutindo mudanças e as implementando através de uma
colaboração em equipe.
Logo, não é uma tarefa fácil, pois exige disciplina e determinação das partes
envolvidas, pois envolve mudanças de comportamentos. E, como toda atividade que
provoque mudanças e rupturas comportamentais, falhas podem surgir na adoção de
uma metodologia ágil: ​(i) ​filosofia ou a cultura da empresa conflita com valores e
princípios do agile, ​(ii) falta de suporte gerencial para apoiar as mudanças, ​(iii) alta
de experiência ou treinamento insuficiente no novo processo e/ou ​(iv) boicote, falta
de compromisso da própria equipe, sendo fundamental reconhecer que melhorias
são necessárias.
Este trabalho não possui o foco de discorrer sobre metodologias ágeis
específicas, uma vez que não compreende um dos objetivos, bem como há uma
significativa bibliografia, física e digital, sobre esse assunto. Tal atividade de
pesquisa é sugerida e incentivada, recomendando-se iniciar pelas metodologias
mencionadas neste tópico de trabalho por serem as principais utilizadas nas
organizações como será percebido nos próximos tópicos

4.4.2 CONTEXTO ATUAL DAS METODOLOGIAS ÁGEIS

No ano de 2015, a Reifer Consultants publicou um estudo para verificar o

nível de adoção das metodologias ágeis e a percepção de benefícios superiores
com a aplicação delas quando comparados com metodologias tradicionais (cascata,
prototipação, incremental etc.). Por representar um estudo de alcance global,
envolvendo diferentes tipos de projetos (tamanho, complexidade, duração etc.),
apresentar e analisar este estudo é congruente com dois objetivos deste trabalho: ​(i)
caracterizar o cenário atual quanto ao uso das metodologias ágeis e ​(ii) ​apresentar
o cenário futuro quanto às metodologias ágeis e a engenharia de software.
Esta pesquisa foi realizada junto a ​150 organizações localizadas em todo o
mundo e a base de análise compreende ​dados de 3.000 projetos ​dos quais 1.500
foram concluídos através de abordagens das metodologias ágeis ​e outros
1.500 foram concluídos por meio das metodologias tradicionais​. ​Nenhum dos
projetos possuíam mais de 10 anos de conclusão.
Sobre esta pesquisa, Reifer e Hastie (2017), realizou um trabalho
apresentado através do artigo “Quantitativa Analysis of Agile Methods Study (2017):
Twelve Major Findings”, o qual enumera 12 evidências que os autores consideram
ser importantes obtidas a partir de análise sobre o estudo publicado pela Reifer

16
Consultants (2015). Neste trabalho, serão destacadas as evidências que são
congruentes aos nosso objetivos e com considerações sobre os resultados
evidenciados.

4.4.2.1 PREDOMINÂNCIA DOS MÉTODOS ÁGEIS PARA O DESENVOLVIMENTO

DE SOFTWARE

Gráfico 1 - Introdução ágil mundial por número de organizações por fase de adoção da tecnologia
(Reifer e Hastie, 2017)

O gráfico acima mostra que as

metodologias ágeis continuam sendo a
abordagem para desenvolvimento de software
dominante no mundo. Importa observar,
também que a adoção das metodologias ágeis
ocorreu mais recentemente na maioria das
organizações, em maior número, entre os anos
de 2009 e 2014, sendo as organizações
localizadas no continente americano aquelas
que mais têm adotado tais abordagens.
O processo de introdução mais recente (isto é, após 2014) continua
ocorrendo em um número significativo de organizações, principalmente na América
e na Ásia, possivelmente por serem os continentes que concentram atualmente um
significativo de organizações de base tecnológica ou ligadas a tecnologia - em
nações desenvolvidas (Canadá e Estados Unidos) e emergentes (Brasil, China,
México e Rússia). Convém destacar as barras que representam a Austrália,
apontando para um número significativo de organizações naquele país que
adotaram ou estão adotando as metodologias ágeis.

4.4.2 SCRUM É A METODOLOGIA ÁGIL MAIS POPULAR

17
 Gráfico 2 - Introdução ágil mundial por número de organizações por fase de adoção da
tecnologia (Reifer e Hastie, 2017)

O gráfico acima claramente aponta para a adoção do Scrum como

metodologia ágil para o desenvolvimento de software. Porém, algumas análises são
importantes: ​(i) o Scrum é fortemente utilizado para projetos que possuem
características quanto a envolver pequenos e poucos times de desenvolvimento (até
5 times) e localizados no mesmo local para desenvolvimento de produtos (small and
medium projects); ​(ii) projetos cujas características são mais de 5 times de
desenvolvimento localizados em diferentes lugares, percebe-se uma preferência em
adotar A-Scale (metodologias agile-at-scale como, por exemplo, SAFe) e Híbridas
(metodologias que agregam características de outras para personalizar e se
adequar às características do projeto, abarcando metodologias tradicionais e/ou
Kanban e conceitos enxutos - lean concepts); ​(iii) em síntese, as metodologias mais
utilizadas no mundo, em números absolutos, são Scrum, A-Scale e metodologias
Híbridas.

4.4.3 OUTRAS EVIDÊNCIAS

O trabalho de Reifer e Hastie (2017) traz outras 10 evidências sobre o atual

contexto das metodologias ágeis quanto ao processo de desenvolvimento de
software. Estas evidências são sucintamente apresentadas a seguir:
● uso de metodologias híbridas e metodologias agil-at-scale em projetos
grandes são quase iguais: essa evidência tem relação com as dificuldades
18
 de escalar metodologias ágeis para grandes projetos, uma vez que os
esforços são difíceis e os prazos apertados.As versões múltiplas, muitas
vezes, precisam ser desenvolvidas em paralelo por equipes distintas,
localizadas em locais diferentes e/ou distantes e em ambientes distribuídos.
As entregas devem ser planejadas, coordenadas e sincronizadas de tal forma
que o desenvolvimento, a integração e os testes ocorram nos momentos
oportunos. Reifer e Hastie (2017) analisam que a adoção de metodologias
ágeis (híbridas e agile-at-scale) foi significativa, uma que aproximadamente
dois anos atrás, o uso de ágil em grandes projetos era a metade do que se vê
atualmente;
● queda da taxa de reversão de metodologias ágeis diminuiu: durante a
década de 2000 a 2010, a taxa de reversão média foi de cerca de 25% ao
tentar introduzir metodologias ágeis no mainstream. À medida que essas
metodologias obtiveram maior aceitação e amadurecimento, a taxa de
reversão melhorou e convergiu para aproximadamente 15%. Segundo Reifer
e Hastie (2017), com base em dados analisados, apenas 10% das
metodologias ágeis foram substituídas (revertidas) para outras tradicionais.

Gráfico 3 - Taxa de reversão de Metodologias Ágeis por Ano (Reifer e Hastie, 2017)

● estabilização do ganho de produtividade ágil: segundo Reifer e Hastie

(2017), a produtividade ágil, medida por saídas / unidades de entrada (linhas
de código equivalentes ou pontos de função / mês da equipe), estabilizou-se.
Para eles, as metodologias atingiram um estado estacionário na maioria das
empresas em que foram adotadas, ou seja, os ganhos realizados durante a
adoção tendem a se nivelar quando atingem um status operacional. Porém,
quando comparados os ganhos de produtividade de metodologias ágeis com
as tradicionais, há diferenças significativas. Outras questões que impactam
na produtividade das empresas, especialmente em grandes projetos ou
empresas que aplicam metodologias ágeis em toda organização, é o uso de
técnicas de gerenciamento tradicionais e adoção de um conjunto de práticas
repaginadas, porém burocráticas;
● estabilização da redução de custos ágil: com base nos dados atuais,
Reifer e Hastie (2017) identificaram que os custos, medidos em termos de $ /
unidade de produção, continuam a ser entre 5 a 12% por ano mais baratos
que as metodologias tradicionais. Os dados revelam que as reduções de
custos realizadas nos últimos 3 anos se estabilizaram à medida que as
empresas ampliaram o uso de metodologias ágeis em toda a empresa. Não

19
 necessariamente os custos foram traduzidos por redução de equipe, mas por
redução nos esforços, em geral, para se obter bons resultados. Porém, em
projetos ágeis em escala, os custos de gerenciamento são maiores para
projetos maiores, pois as despesas ágeis variam amplamente ao considerar o
domínio e contexto da aplicação;
● distribuição ágil de esforços e duração diferentes das metodologias
tradicionais: a partir de dados analisados por Reifer e Hastie (2017), a
maneira como o tempo e os esforços são distribuídos durante o
desenvolvimento de software usando metodologias ágeis difere daquela
experimentada em projetos direcionados por metodologias tradicionais.
Segundo eles, o principal motivo para essa diferença é que aqueles que
utilizam ágil enfocam seus esforços na criação de produtos funcionais em
intervalos curtos, em vez de criar documentação. Os desenvolvedores ágeis
criam e revisam o código de trabalho com o usuário, ao invés de dedicar
tempo e esforços para gerar requisitos e especificações de projeto antes do
início da codificação;

Gráfico 4 - Esforços por estágio do ciclo de desenvolvimento (Reifer e Hastie, 2017)

● ágil melhora a capacidade de cumprir prazos programados: ​o tempo de

mercado ágil, medido pelo tempo do calendário desde o início até a entrega
de software, oferece às empresas a capacidade de realizar prazos apertados
de agendamento entre 75 a 90% do tempo em relação ao desempenho
médio de 40 a 60 % dos projetos semelhantes em metodologias tradicionais.
Porém, é importante destacar que a porcentagem dos cursos que foram
prometidos e realmente entregue varia de 80 a 90% em ágil contra 95 a
100% para desenvolvimentos tradicionais (Reifer e Hastie, 2017);
● qualidade ágil é melhor do que as normas tradicionais: com base nos
resultados dos estudos de Reifer e Hastie (2017), a qualidade do software
ágil é superior ao desempenho de metodologias tradicionais por um fator de 6
a 12% em cerca de 3 anos. A qualidade do software melhora durante o
desenvolvimento e o pós-lançamento porque é projetada no produto pela
equipe de desenvolvimento à medida que o software é gerado. Quando
métodos ágeis são usados, a qualidade é considerada ao longo do processo
de desenvolvimento primeiro através dos teste e, em seguida, por

20
 abordagens contínuas de integração e teste, além da qualidade ser abordada
pelo próprio time e não por terceiros;
● valor ágil (agile value) é difícil de quantificar: as metodologias ágeis
colocam ênfase no fornecimento aos seus usuários/clientes com valor,
fornecendo produtos de software de trabalho continuamente ao longo do ciclo
de vida do desenvolvimento. O valor é geralmente medido em termos do
benefício financeiro e/ou competitivo que as organizações recebem para suas
despesas. Embora existam algumas orientações disponíveis para o
planejamento de valor, segundo Reifer e Hastie (2017), é oferecida pouca
ajuda sobre como quantificar o valor derivado desses esforços. Os autores,
sugerem então medidas clássicas devido à falta de clareza: custo/benefícios,
retorno ou retorno sobre o investimento para quantificar os retornos derivados
das abordagens ágeis;
● ágil continua a oferecer aos seus usuários uma vantagem competitiva:
muitas conclusões parecem acreditar que metodologias ágeis podem
representar uma vantagem competitiva quando as organizações aproveitam
plenamente os pontos fortes e compensam suas fraquezas. Não só as
metodologias ágeis proporcionam recompensas de produtividade, custo e
tempo de mercado, proporcionam aos usuários a capacidade de atrair e reter
o talento. Reifer e Hastie (2017) recomendam a institucionalização destas
metodologias em toda a empresa para aproveitar aqueles e outros
benefícios, estar atento ao futuro e aproveitar as melhores abordagens que
tenham funcionado para a empresa e nos projetos bem-sucedidos;
● os impactos ágeis nas práticas de aquisição do governo podem ser
importantes: Reifer e Hastie (2017) destaca que o impacto das metodologias
ágeis não se limita às práticas de desenvolvimento. Quando ágil é usado em
contratos, os impactos quanto ao planejamento, tempo, orçamentos,
requisitos, gerenciamento, progresso e o desempenho geral podem obter
benefícios significativos, principalmente quando governo e os fornecedores
estabelecem um gerenciamento colaborativo.

Outras evidências são descritas por Reifer e Hastie (2017) em seus estudos,
porém estes não serão aqui tratados. As 12 evidências apresentadas neste
trabalho, com destaque para as 3 primeiras permitem elucidar o atual cenário da
aplicação de metodologias ágeis seja no desenvolvimento de software seja em toda
a organização.

4.4.4 VANTAGENS E DESVANTAGENS DAS METODOLOGIAS ÁGEIS

Este tópico apresenta as vantagens e desvantagens das metodologias ágeis

quanto ao desenvolvimento de software. Tomás (2009), em seu trabalho “Métodos
ágeis: características, pontos fortes e fracos e possibilidades de aplicação”
apresenta e analisa seus pontos fortes e fracos.
A empresa Outsystems em seu paper “Transitioning to Agile in an AgileWay -
Amplifying Traditional Approches with Agile Technology” (2009) e citado por Tomás
(2009) comparou as duas metodologias (ágil e tradicional em cascata) em relação

21
aos ganhos de valor para o cliente e stakeholders.

Gráfico 5 - Diagrama de comparação entre metodologias ágil e tradicional (em cascata)

quanto aos ganhos de valor para clientes/stakeholders

Pelo gráfico acima:

● (i) no período inicial, ágil entrega uma primeira versão que satisfaz requisitos
mínimos, enquanto a tradicional em cascata ainda está em evolução,
normalmente sem algo funcional para entregar ao cliente;
● (ii) em ágil, o produto/software está em produção de acordo com o valor que
o cliente pretende, com entregas ao longo do tempo de versões mais
adequadas; no tradicional em cascata, há uma longa planificação que atrasa
a entrega de algo visível e essa entrega inicial é que tem maior
correspondência com o que o cliente requisita, posteriormente os requisitos
tendem a mudar, a adaptação do produto a estas mudanças é difícil
(demorada, maiores custos etc.) implicando em certo retorno menor de valor
para os clientes/stakeholders.
Para o item ​(ii)​, um gráfico complementar da VersionOne (2004-2006) e que
apresenta uma realidade mais crível e menos tendenciosa é apresentado por
Tomás (2009). Neste gráfico, as metodologias partem de um mesmo ponto e
chegam ao mesmo resultado, mas com percursos diferentes, de tal maneira que os
resultados serem relativamente próximos.

22
 Gráfico 6 - Proposta de valor em desenvolvimento ágil

Convém destacar que ao analisar sob esta perspectiva, pontos em comum e

resultados finais próximos, os caminhos seguidos pela equipe de desenvolvimento
de software, ao serem diferentes (ágil e tradicional), serão influenciados por vários
fatores no percurso que impactaram a visibilidade, adaptabilidade, valor de negócio
e risco e, por consequência, os resultados finais obtidos em tempo, custos e outras
variáveis com importantes diferentes.
Outra vantagem do ágil ​é o aumento do controle por parte dos gestores​,
pois se baseia no que está realmente em produção e no que será feito a curto prazo
(menor especulação, mais visibilidade, melhor adequação das medições e
avaliações do estado das funcionalidades e tarefas realizadas). Essa vantagem
promove ​aproximação entre desenvolvedores e gestores, maior e melhor
comunicação, potencializa a produtividade dos indivíduos​.
Tomás (2009) destaca algumas desvantagens das metodologias ágeis:
● difícil escalabilidade: o ágil não foi desenhado para projetos muito longos e
com grandes times, por isso, metodologias híbridas são, por vezes,
requeridas como solução para este problema;
● menor controle de custos: tipicamente, no ágil o projeto termina quando o
cliente não requer mais funcionalidades relevantes que se deseja, em
oposição a ser acordado um preço e um plano. Assim custos e durações
podem variar e se tornam difíceis para gestão da organização.

23
4.4.5 METODOLOGIAS ÁGEIS E INOVAÇÃO

Metodologias ágeis também são aplicadas em empresas cujo o

desenvolvimento de software não seja a principal atividade ou, ainda, quando
sequer se trata de uma organização relacionada a área de tecnologia de
informação.
Denning (2015) em seu artigo “Agile: The World’s Most Popular Innovation
Engine” discorre faz uma análise sobre a inovação, os problemas e os desafios da
indústria quanto à inovação e algumas comparações com a atividade de
desenvolvimento de software.
Segundo Curtis Carlson (2006), citado em Denning (2015), “inovação é o
principal motor de prosperidade, crescimento do emprego, responsabilidade social,
sustentabilidade ambiental e segurança nacional.” Denning discorre que, em toda
economia, o desempenho inovador ainda é fraco: em um artigo dele em fevereiro de
2015, ele trata sobre uma pesquisa da MindMatters de 150 empresas com equipes
de inovação cujo tamanho variava entre menos de 100 até mais de 1000
funcionários em diferentes segmentos de indústrias. Essa pesquisa mostrou que
apenas 5% dos entrevistados disseram que a equipe de inovação se sente
altamente motivada para inovar e, apenas 6% acreditam que seus empregadores
consideram o desenvolvimento do capital intelectual como uma função de missão
crítica. Por fim, 75% dizem que suas novas ideias são mal analisadas ou
analisadas.
Por fim, Denning considera que um dos principais elementos para os
resultados ruins da imagem da inovação em toda economia é que não há um
conjunto de processos geralmente acordados para criar sistematicamente inovações
que gerem produtos e serviços melhores, mais baratos, mais rápidos, mais leves,
mais convenientes e mais personalizados para os clientes. Ao contrário, a inovação
geralmente prossegue de forma ad-hoc, em projetos com grandes perseguidos de
forma sequencial que raramente ocorrem como esperado.

5. RESULTADOS E DISCUSSÃO

Nesta seção, propõe-se uma análise discursiva sobre os dados, descrições e

gráficos apresentados nas seções anteriores com destaque para os tópicos que
tratam das evidências encontradas por Reifer e Hastie (2017) em suas pesquisas,
as quais agregaram bastante valor e informações para este artigo sobre
metodologias ágeis e a adoção delas em desenvolvimento de software.
As metodologias ágeis são predominantes no contexto atual das atividades
que envolvem o desenvolvimento de softwares. Dentre as existentes, o Scrum se
revela, a partir de dados quantitativos, a metodologia ágil mais empregada nas
organizações e/ou por equipes de desenvolvimento. Entretanto, o Scrum possui
suas limitações quando se considera os tamanhos de projeto e de equipe,
recomendando-se sua adoção para projetos de pequeno e médio escopo com
respectivas equipes pequenas e médias localizadas em um mesmo ambiente (ou
com maior proximidade possível). Essas características são importantes para que

24
os valores, princípios e valores possam fluir com maior qualidade e potencializar
benefícios quanto ao desenvolvimento de softwares (ou outras atividades que se
possa apropriar da metodologia).
A atual dinâmica para o desenvolvimento de software é fortemente
influenciado por fatores externos e, em outra medida, pelos internos também.
Softwares úteis, de boa qualidade e eficientes são traduzidos em competitividade,
eficiência e eficácia para as organizações que deles necessitam para suportar ou
executar muitas de suas tarefas. Competitividade significa, no atual contexto, estar a
frente da concorrência, acompanhar tendências, gerar / entregar valor aos clientes e
outras partes interessadas e, potencialmente, aumentos de lucratividade,
rentabilidade e retornos sobre investimentos.
Nos tópicos anteriores, é possível identificar evidências positivas quanto às
metodologias e quando a adoção delas: ganho de produtividade, redução de custos,
distribuição de esforços, aumento da capacidade para cumprimento de prazos,
potencializada aumento da qualidade, permite a geração de vantagens competitivas
e a adoção das metodologias em outras atividades pode se apresentar benéfica.
Essas evidências positivas, porém, não são consequências naturais ao se adotar o
ágil. Como qualquer metodologia, ágil também possui suas limitações e orientações
(como, quando, onde, por que) ao se adotar.
Os trabalhos relacionados neste artigo elucidam sobre as vantagens,
desvantagens e orientações sobre a adoção de metodologias ágeis. Não é só
adotar e os problemas de desenvolvimento de softwares estarão solucionados. As
própria metodologias ágeis estão sujeitas a erros e outros efeitos colaterais e
compreender isso faz toda diferença. Os variados contextos, as diferentes partes
interessadas, as possíveis limitações e outros desafios são fatores que sempre
afetarão a qualidade final de um software e, as metodologias ágeis (bem como as
tradicionais) não foram desenvolvidas para solucioná-los, mas sim para prover
orientações e caminhos para agir. Pode-se destacar dois desafios que as
metodologias ágeis ainda não consegue tratar facilmente: escalabilidade e
controle de custos​.
Por fim, é relevante destacar que, ao se aplicar e adotar metodologias ágeis
seja no desenvolvimento de software ou em outras atividades nas quais elas
possam gerar benefícios, identificar os contextos em que os projetos e as equipes
de desenvolvimento estão / serão inseridos é pertinente para que se minimizem
erros, falhas, defeitos e outros efeitos colaterais nas atividades que serão
suportadas pelo ágil ou pelo tradicional. Dois focos importantes podem nortear nas
decisões: qualidade final ​para o software e ​agregar / gerar valor para o cliente
(e, por consequência, para a pessoa, equipe ou organização responsáveis pelo
desenvolvimento do software).

6. CONCLUSÃO

O desenvolvimento de software é uma atividade com grande importância na

economia de informação devido ao uso cada vez mais constante de softwares para
o apoio e/ou a execução de diversas atividades em diversas áreas (indústria,
comércio, serviços etc.) e segmentos (saúde, entretenimento, lazer, finanças,

25
economia, educação etc.).
Este artigo se propôs a apresentar as principais metodologias ágeis, suas
vantagens e desvantagens, sem se ater especificamente a uma ou outra. Contextos,
análises e evidências foram apresentados para contextualizar as metodologias
ágeis quanto à engenharia de software, pois elas foram desenvolvidas com a
finalidade de fornecer orientações, princípios e valores para a complexidade cada
vez maior quanto ao desenvolvimento de softwares.
Pesquisas recentes, especialmente de Reifer e Hastie (2017) por sua
atualidade e análise profunda a partir de diferentes fontes de dados, caracterizam
com boa referência e claridade o cenário atual de implantação, desenvolvimento e
desafios quanto às metodologias ágeis, permitindo projetar um futuro quanto estas
abordagens e a área de engenharia de software que, é importante considerar, não
pode ser estudada e compreendida isoladamente. Tecnologias emergentes
(aprendizagem de máquina, inteligência artificial, internet das coisas etc.) gerarão
impactos sobre a engenharia software e consequentemente em assuntos que
tangenciam esta área.
Apesar de um foco maior em metodologias ágeis, não se pode desmerecer
as contribuições que as metodologias tradicionais conceberam e foram úteis para o
desenvolvimento do ágil. Ainda, em algumas situações, é preferível adoção de
abordagens tradicionais ou, alternativamente, metodologias híbridas que se utilizam
de princípios, valores, ferramentas e outros subsídios advindos das tradicionais e/ou
ágeis. Além disso, metodologias ágeis estão em implementação em outros setores
relacionados ou nada relacionados com o desenvolvimento de software, focalizando
assim os conceitos, princípios e valores de inovação.
O artigo também dá referências e indicativos de quão importante é considerar
o contexto da aplicação, as partes interessadas, o ambiente da organização, o
histórico de projetos, as características (técnicas e relacionais) da equipe de
desenvolvimento, os processos da empresa, as ferramentas de suporte e vários
outros fatores para que, ao se adotar o ágil, não seja feito somente por
conveniências, modismos ou outros interesses que, mais a frente, poderão minar ou
reduzir a qualidade dos projetos e os resultados finais. Gerar valor ao cliente com
um projeto de qualidade é competitivamente importante, mas antes de se alcançar
isso, o caminho que as organizações e as equipes precisam seguir exige esforços
de vários atores.

7. BIBLIOGRAFIA CITADA

Agile Manifesto, Disponível em​ ​http://agilemanifesto.org/

BOEHM, B. Spiral Development: Experience, Principles and Refinements. Spiral

Development Workshop, 2000.

DENNING, Steve. “Agile: The World’s Most Popular Innovation Engine”. Forbes.

26
Acessado 18 de novembro de 2017.
https://www.forbes.com/sites/stevedenning/2015/07/23/the-worlds-most-popular-inno
vation-engine/.

DINGSOYR, Torgeir, Sridhar Nerur, VenuGopal Balijepally, e Nils Brede Moe. “A

Decade of Agile Methodologies: Towards Explaining Agile Software Development”.
Journal of Systems and Software 85, n​o 6 (junho de 2012): 1213–21.
https://doi.org/10.1016/j.jss.2012.02.033.

MACRO, A. Software Engineering – Concepts and Managements. Prentice Hall,

1990.

PETERS, J. F., PEDRYCZ, W. Engenharia de Software, Teoria e Prática, Brasil,

Editora Campus, 2001.

PRESSMAN, R. S. Engenharia de Software. Makron Books, 1995. Cap. 1, 7, 8 e 12,

1995.

PRIKLADNICKI, Rafael. “, Desafios e Abordagens do Processo de Desenvolvimento

de Software” Curso de Mestrado, Trabalho Individual I - 13 de fevereiro de 2004.
Disponível em: <​http://www.inf.pucrs.br/munddos/docs/TI1.pdf​> Acesso em
outubro-novembro / 2017.

REIFER, Donald J., Shane Hastie. “Quantitative Analysis of Agile Methods Study
(2017): Twelve Major Findings”. InfoQ. Acessado 18 de novembro de 2017.
https://www.infoq.com/articles/reifer-agile-study-2017​.

SOARES, Michel dos Santos, Comparação entre Metodologias Ágeis e Tradicionais

para o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio
Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete
Software Engineering. A Practitioner’s Approach. Fifth Edit, 2001.

STEFFEN, Juliana B. “O que são essas tais de metodologias Ágeis ?”. Blog da IBM
- 23 de janeiro 2012. Disponível em:
<​https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_
que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en​> Acesso em

27
outubro-novembro / 2017

28