Unidade 1

Métodos Tradicionais e Métodos Ágeis de Desenvolvimento de

Software. Manifesto Ágil.

Disciplina: Metodologias Ágeis de Desenvolvimento

Prof. Vinícius Alves Silva

1 Métodos Tradicionais e Métodos Ágeis de Desenvolvimento de
Software

1.1 Metodologias tradicionais de desenvolvimento

Com a criação dos computadores, por volta da década de 40, empresas e

instituições de pesquisa voltaram seus esforços e investimentos para aprimorar
armazenamento e processamento, ou seja, o foco principal daquela época era o
hardware. Todo esforço resultou em computadores cada vez mais compactos e robustos.
A evolução do hardware possibilitou também a criação de softwares mais
complexos, que eram construídos sem nenhuma metodologia.
Neste período ocorreu a chamada Crise do Software. A “crise do software” foi um
termo cunhado para descrever as dificuldades enfrentadas no desenvolvimento de
software no fim da década de 60, quando a Engenharia de Software era praticamente
inexistente. O termo expressava as dificuldades do desenvolvimento de software frente ao
rápido crescimento da demanda. As causas da crise do software estão ligadas à
complexidade do processo de software e a relativa imaturidade da Engenharia de
Software como profissão (SOMMERVILLE, 2011).
A crise se manifestava de várias formas:
● Projetos estourando o prazo;
● Software de baixa qualidade;
● Software muitas vezes não satisfaz os requisitos;
● Projetos ingerenciáveis e código difícil de manter.

Durante anos de sua história, a Engenharia de Software inspirou-se em processos

de manufatura para a consolidação de seus métodos de trabalho. Nascida na segunda
metade do século XX, buscou em setores emergentes da indústria da época grande parte
das teorias e dos métodos de produção. Em especial, o campo automobilístico, em ampla
ascensão industrial, teve importante papel para a constituição da nova indústria de TI.
Graças ao modelo de produção em série de Henry Ford, altamente inspirado por
Frederick Taylor, todo o pensamento tradicional da ciência do desenvolvimento de
software desenrolou-se com intenso foco na padronização de componentes e processos e
na mecanização do movimento.
Uma característica das metodologias tradicionais envolve principalmente métodos
mais burocráticos e documentação abrangente.

1.2 O Manifesto Ágil

Na primavera de 2000, alguns renomados pesquisadores e desenvolvedores se

reuniram para discutir práticas de desenvolvimento de software que fossem “mais leves”,
ou seja, que fossem menos burocráticas e com foco no software em si, ao invés de foco
na documentação. Foi dessa conclusão que Robert Cecil Martin resolveu criar um
encontro para pessoas interessadas nos então chamados “métodos leves”.

Robert Cecil Martin

também conhecido como "Uncle Bob" (Tio Bob em português), é uma grande
personalidade da comunidade de desenvolvimento de software, atuando na área desde
1970. Atualmente é consultor internacional e autor de vários livros abordando o tema.

Muitas pessoas foram contatadas, porém apenas 17 estavam presentes em

fevereiro de 2001 em um resort de esqui nas montanhas nevadas de Utah.
Durante essa reunião um grande consenso sobre como deveriam ser os métodos
de desenvolvimento de software foi criado e batizado como “Manifesto Ágil”. O Manifesto
é fruto de grandes pensadores da área de software, frustrados com os resultados ruins
nos projetos a nível global. Ninguém entrega no prazo, todo software tem bugs, nunca
entrega-se o que o cliente quer, etc, etc. Note a preocupação em não assumir uma atitude
de ‘jogue fora tudo que sabe’, mas sim em dar mais importância às pessoas e às
entregas, à ação, ao valor gerado, ao contrário do pensamento mais tradicional que se
perpetuava da década de 70 (durante a Crise do Software) até o início dos anos 2000
(DUARTE, 2016).
Uma parte importante do manifesto destaca o seguinte: “estamos descobrindo
maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a
fazê-lo. Através deste trabalho, passamos a valorizar (PRIKLADNICKI et. al., 2014):
● indivíduos e interações mais que processos e ferramentas;
Com a Engenharia de Software Tradicional, passamos a crer tão cegamente nos
processos e nas ferramentas que deixamos de nos comunicar. Esquecemos que são as
pessoas que fazem software. Em vez de conversas e discussões, os desenvolvedores
passaram a receber especificações escritas. Elas são importantes, sim, mas não
comunicam tão bem como uma boa discussão (presencial ou a distância), ou esboços,
rabiscos e modelos. Obviamente, ferramentas são importantes. É muito mais difícil fazer
as coisas sem elas. Processos, igualmente. Ainda assim, não devemos deixar de valorizar
as pessoas e não devemos deixar de nos comunicar. Isso faz parte de trabalho em
equipe.

Devemos entender que o desenvolvimento de software é uma atividade humana e que

a qualidade da interação entre as pessoas pode resolver problemas crônicos de
comunicação. Processos e Ferramentas são importantes, mas devem ser simples e úteis.

● software funcionando mais que documentação abrangente;

No início da engenharia de software (e em muitos locais até hoje), muitas organizações
ficaram reféns de seus desenvolvedores. Como não havia documentação, todo o
conhecimento estava em suas mentes. Perder uma dessas pessoas significava um
prejuízo incalculável. A solução encontrada foi documentar os processos para a
posteridade. Surgiram, então, as figuras de analistas de sistemas e documentadores,
profissionais contratados não para programar, mas para produzir modelos gráficos e
textuais. Talvez tenhamos errado na mão, e a proposta agora seja a de encontrar um
ponto de equilíbrio. O Manifesto não nega a importância da documentação. No entanto, é
preferível a entrega de software funcionando do que uma documentação abrangente,
exagerada e cheia de desperdícios. Quando somos contratados, o resultado esperado é
software funcionando, com qualidade. Documentação e manutenibilidade fazem parte
dessa qualidade. Devemos refletir mais sobre “o que” documentar e “quando”
documentar. Devemos refletir sobre o que é útil de fato e o que ficará defasado
rapidamente ou sequer será lido algum dia. Isso gera um tremendo desperdício e
encarece o que fazemos.

O maior indicador de que sua equipe realmente construiu algo é software funcionando.
Clientes querem é resultado e isso pode ser com software funcionando. Documentação
também é importante, mas que seja somente o necessário e que agregue valor.

● colaboração com o cliente mais que negociação de contratos;

Escopo é uma questão complexa e difícil de ser definida precisamente num texto de
contrato. Geralmente são criadas cláusulas e mais cláusulas com o objetivo de proteger
tanto o contratante quanto o contratado, na tentativa de fechar o escopo o máximo
possível, e são impostos processos complexos, burocráticos e frustrantes para mudanças.
O resultado continua ruim. Esse é um ponto fraco do Manifesto e dos Métodos Ágeis,
constantemente criticado devido à sua fragilidade e pessoalidade. É algo que
definitivamente ainda tem muito a evoluir. Sabemos que, quando a relação é bem
construída, os resultados são melhores. No entanto, as partes precisam de alguma
segurança contra atitudes de má fé.

Devemos atuar em conjunto com o cliente e não “contra” ele ou ele “contra” a gente. O
que deve acontecer é colaboração, tomada de decisões em conjunto e trabalho em
equipe, fazendo que todos sejam um só em busca de um objetivo. O Manifesto coloca o
cliente como um membro da equipe de desenvolvimento.

● responder a mudanças mais que seguir um plano.

Desenvolver software é um processo de aprendizado, tanto da equipe quanto do próprio
cliente. Assim, é natural e inevitável que haja mudanças. Acreditamos que as mudanças
são ótimas oportunidades para que o sistema desenvolvido seja mais aderente às
necessidades do cliente, além de contribuírem muito para os resultados desejados. Por
isso, devemos fazer o possível para recebê- -las e acolhê-las de braços abertos. Em
projetos, normalmente temos a ideia de que será traçado um plano no início do prazo e de
que ele será seguido até o final. É muito difícil tomar tantas decisões acertadas no início
do projeto, no momento em que menos se conhece a solução, principalmente em um
ambiente instável como o nosso, em termos de tecnologia, pessoal e negócio. Até
podemos seguir o plano, mas o resultado final pode não resolver o problema do cliente.
Por isso, para acolhermos realmente as mudanças, precisamos replanejar o tempo todo.
Os processos de planejamento ágil normalmente incluem ciclos PDCA em diversos níveis
(diário, semanal, mensal, trimestral, etc.), em que há a oportunidade de reflexão e
readequação dos rumos tomados pelo projeto.

Desenvolver software e produtos é um ambiente de alta incerteza e por isso não

podemos nos debruçar em planos enormes e cheio de premissas. O que deve ser feito é
aprender com as informações e feedbacks e adaptar o plano a todo momento.

O Manifesto Ágil não rejeita os processos nem as ferramentas, a documentação

abrangente, a negociação de contratos ou o plano preestabelecido, mas indica que eles
têm importância secundária quando comparados com indivíduos e interações, com
software funcionando, com colaboração com o cliente e com respostas rápidas a
mudanças. A questão não é a mudança em si, mesmo porque ela ocorre de forma
frequente nos projetos. A questão é como receber, avaliar e responder a elas. Além disso,
os autores do Manifesto Ágil definiram 12 princípios:
● Nossa maior prioridade é satisfazer ao cliente com entrega contínua e adiantada de
software com valor agregado.
● Mudanças de requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Os processos ágeis tiram vantagem das mudanças, visando à vantagem
competitiva para o cliente.
● Entregar software funcionando frequentemente, de poucas semanas a poucos
meses, com preferência para a escala menor de tempo.
.

No desenvolvimento ágil ter entregas

frequentes é vital para o sucesso do projeto
ou produto. É por meio de entregas
frequentes que vai existir feedback e as
correções assertivas de rota.

Quando falamos de entregar com

frequência, não estamos falamos de
estocar software pronto para homologação
e sim de entregar para seu usuário final
experimentar o que foi feito.

Figura 1. Entrega contínua (Fonte: MÉTODO ÁGIL, 2018).

● Pessoa de negócios e desenvolvedores devem trabalhar diariamente em conjunto

por todo o projeto.
A colaboração entre time e stakeholders
.

deve ser natural e consistente, uma vez

que em Métodos Ágeis os requisitos
devem ser leves e a mudança deve ser
aceita naturalmente e como resultado de
feedbacks de software entregue.

Figura 2. Colaboração com o cliente.

● Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o

suporte necessário e confie neles para realizar o trabalho.
 ● O método mais eficiente e eficaz de transmitir informações para a equipe e entre a
equipe de desenvolvimento é a conversa frente a frente.
● Software funcional é a medida primária de progresso.
● Processos ágeis promovem um desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
sempre.
● Contínua atenção à excelência técnica e bom projeto aumenta a agilidade.
● Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é
essencial.
● As melhores arquiteturas, os melhores requisitos e projetos emergem de times
auto-organizáveis.
● Em intervalos regulares, o time reflete sobre como pode ser mais eficaz, então
refina e ajusta seu comportamento de acordo.
.

O modelo de entrega ágil é baseado em

ciclos iterativos e incrementais, o que traz
flexibilidade e adaptabilidade. Uma
característica importante é a inspeção e
adaptação dos ciclos e iterações, focados
em gerar melhoria contínua para as
equipes e processos. Ambientes ágeis de
desenvolvimento normalmente são
construídos por equipes que tem
autonomia e que são capazes de se auto-
organizar em busca de objetivos.

Figura 3. Equipes auto-organizáveis (Fonte: MÉTODO ÁGIL, 2018).

1.3 Comparativo entre desenvolvimento tradicional e ágil

A tabela a seguir ilustra um comparativo entre o desenvolvimento tradicional de

software e o desenvolvimento utilizando Métodos Ágeis.
O assunto é extenso e surgem muitas questões ao primeiro contato com esta nova
proposta de desenvolvimento de software. A agilidade questiona modelos consolidados
por meio de uma revisão de valores da indústria de TI. Aos poucos, empresários e
gestores estão cedendo à tradição industrial em prol de novos paradigmas de trabalho.
No Brasil, empresas de todos os portes, públicas e privadas, estão aderindo ao
movimento. No entanto, ainda há muito preconceito e receio nos altos escalões
gerenciais.
TRADICIONAL MÉTODOS ÁGEIS
Pressupostos Sistemas totalmente Software adaptativo e de alta
fundamentais especificáveis, previsíveis; qualidade; pode ser desenvolvido
desenvolvidos a partir de um por equipes pequenas utilizando os
planejamento extensivo e princípios da melhoria contínua do
meticuloso projeto e testes orientado a rápida
resposta a mudanças
Controle Orientado a processos Orientado a pessoas
Estilo de Comandar e controlar Liderar e colaborar
gerenciamento
Gestão do Explícito Tácito
conhecimento
Atribuição de Individual – favorece a Times auto-organizáveis – favorece
papéis especialização a troca de papéis
Comunicação Formal Informal
Ciclo do projeto Guiado por tarefas ou atividades Guiado por funcionalidades do
produto
Modelo de Modelo de ciclo de vida Modelo iterativo e incremental
desenvolvimento (Cascata, Espiral, iterativo e
incremental)
Forma/estrutura Mecânica (burocrática com Orgânica (flexível e com incentivos
organizacional muita formalização) a participação e cooperação social)
desejada
Sucesso Cumprimento de prazos, custo e Valor que o projeto agrega ao
(principais atendimento ao escopo cliente
parâmetros) inicialmente definido
Tabela 1 - Desenvolvimento tradicional e ágil. Adaptado de Prikladnicki et. al. (2011).
2 Referências

AGILE MANIFESTO. Disponível em http://agilemanifesto.org/. Acessado em 10 de

fevereiro de 2022.

DUARTE, Luiz. Scrum e Métodos Ágeis: Um Guia Prático. Editora LuizTools. Edição do
Kindle. 2016.

MÉTODO ÁGIL. Disponível em http://www.metodoagil.com/. Acessado em 10 de fevereiro

de 2022.

PRIKLADNICKI, Rafael; WILL, Renato; MILANI, Fabiano. Métodos Ágeis para

Desenvolvimento de Software. Editora Bookman, 2014.

SOMMERVILLE, Ian. Engenharia de software. 9. ed. Rio de Janeiro: Pearson Education

do Brasil, 2011.