DESENVOLVIMENTO

DE SOFTWARE COM
METODOLOGIAS
ÁGEIS

Diego Martins Polla de Moraes

Manifesto Ágil
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Descrever o Manifesto Ágil e seus quatro valores.

 Identificar os princípios por trás do Manifesto Ágil.
 Analisar o impacto do Manifesto Ágil nos processos de desenvolvi-
mento de software.

Introdução
Durante muito tempo, software foram construídos utilizando técnicas
de outras áreas adaptadas para a engenharia de software. Depois de
muitos projetos executados, identificou-se que esse cenário precisava
ser modificado. Muito do que se tinha como premissa para a execução
dos processos de desenvolvimento de software não se confirmou na
prática, de forma que novas formas de trabalho precisaram ser estudadas.
Além disso, a tendência da transformação digital nas organizações e na
vida das pessoas aumentou, de forma disruptiva, a demanda da área de
desenvolvimento de software, o que justifica a busca por processos que
entreguem agilidade.
Assim surgiram processos alternativos de desenvolvimento de
software, mais adequados à natureza da atividade, culminando com a
definição canônica do desenvolvimento ágil em 2001: o Manifesto Ágil.
Neste capítulo, você vai conhecer o Manifesto Ágil e descobrir formas de
aplicá-lo em um processo de desenvolvimento de software.

1 Manifesto Ágil: história e valores

A engenharia de software iniciou sua história inspirando-se em processos
de outras áreas da engenharia e da manufatura. Prikladnicki, Willi e Milani
(2014) destacam que, na segunda metade do século XX, nos primórdios da
disciplina, a engenharia de software buscou, nos setores mais promissores
2 Manifesto Ágil

na época, processos e métodos de produção — afinal, se estava dando certo

nessas áreas, por que não daria certo na engenharia de software? Instaurou-se,
portanto, uma busca por padronização de componentes e processos, visando a
uma mecanização do trabalho com software. Os software, porém, evoluíram
com muita rapidez, e os problemas com os processos chamados “pesados” e
burocráticos vieram na mesma velocidade.
Conforme Prikladnicki, Willi e Milani (2014), na década de 1990 começa-
ram a surgir processos alternativos ao desenvolvimento de software tradicional,
já que estes continham um alto nível de regras e burocracias, e foram, portanto,
considerados inadequados à natureza da atividade. De fato, é muito difícil,
até mesmo impossível, determinar como um sistema moderno vai evoluir ao
decorrer do tempo (PRESSMAN; MAXIM, 2016). Assim, é necessário estar
pronto para oferecer soluções de software que atendam às rápidas modificações
que ocorrem nos negócios: como mudanças nas necessidades dos usuários,
nas condições de mercado (concorrência) e nas exigências legais.
Na busca por novos métodos, novos processos de software, em fevereiro
de 2001, 17 estudiosos da área de engenharia de software se reuniram em
um resort de esqui em Utah, nos Estados Unidos, para discutir aspectos dos
projetos de desenvolvimento de software. Entre esses estudiosos, estavam
nomes como Kent Beck, criador da metodologia XP (Extreme Programming,
ou Programação Extrema), Jeff Sutherland e Ken Schwaber, inventores do
Scrum, Martin Fowler, autor que é grande referência na área de projeto para
desenvolvedores, Alistair Cockburn, criador da família de métodos ágeis
Crystal, além de outros estudiosos que concordavam com a necessidade de
buscar uma alternativa aos processos de desenvolvimento de software pesados,
orientados por uma forte documentação.
Highsmith (2001) relata que o resultado dessa reunião foi o documento
denominado Manifesto para Desenvolvimento Ágil de Software, assinado
por todos os participantes. Alistair Cockburn, um dos participantes que trouxe
as preocupações iniciais ao grupo, declarou que não acreditava que seriam
capazes de apresentar algo tão objetivo e que, no final da empreitada, pode
verificar que os demais participantes também ficaram com o sentimento de
dever cumprido. Certamente aquele grupo de estudiosos não tinha noção de
que aquele encontro resultaria em algo que se tornaria tão importante e valo-
rizado pelos desenvolvedores de software do mundo inteiro, por tanto tempo.
Esse grupo, cujos alguns integrantes mais tarde formaram a conhecida
Agile Alliance, preparou um conjunto de valores e princípios tão simples e
fáceis de entender quanto o que eles almejaram para o desenvolvimento de
software. Os quatro valores do Manifesto Ágil são representados no Quadro 1.
 Manifesto Ágil 3

Quadro 1. Os quatro valores do Manifesto Ágil

De acordo com o Manifesto Ágil, devemos valorizar:

Indivíduos e interações processos e ferramentas.

Software em que documentação

funcionamento abrangente.
mais que
Colaboração que negociação
com o cliente de contratos.

Responder a mudanças que seguir um plano.

Fonte: Adaptado de Beck et al. (2001).

Analisando o Quadro 1, você percebe que as sentenças à esquerda são

consideradas, pelos signatários do Manifesto Ágil, mais importantes que as da
direita. Isso não significa que os itens à esquerda devem ser menosprezados,
mas que devem ter seu valor sobreposto aos itens à direita.

Ao falar sobre agilidade, uma afirmação bem marcante de Pressman e Maxim (2016)
é a de que não precisamos optar por agilidade ou engenharia de software. Devemos
buscar uma abordagem de engenharia de software que seja ágil.

Agora, você vai conhecer cada um dos valores do Manifesto mais deta-
lhadamente e o que eles representam.

Indivíduos e interações devem ser mais valorizados

que processos e ferramentas
Com esse valor, o Manifesto busca chamar a atenção para as relações entre
os indivíduos que utilizam e aqueles que constroem o software. Um software,
apesar de ser usado em máquinas, é construído por pessoas e para pessoas.
Nesse sentido, Prikladnicki, Willi e Milani (2014) comentam sobre a confiança
tão cega que se atribuiu aos processos e ferramentas em detrimento da comu-
4 Manifesto Ágil

nicação. Assim, nesse valor, o manifesto procura reestabelecer a confiança

que as conversas, as discussões e a comunicação direta atribui a um trabalho
feito em equipe.

Software em funcionamento deve ser mais valorizado

que documentação abrangente
Com esse valor, o Manifesto provoca os projetos que passam muito tempo na
fase de planejamento e documentação, sem ter uma entrega de valor para os
usuários, o que significa o software (ou parte dele) apto para uso. Um software
é composto por todos artefatos de documentação que foram elaborados para
ele, por seu código-fonte e seu executável, que permitirá que os usuários o
utilizem. Então, a questão que se coloca é: “De que serve um software que
tem uma documentação bem elaborada, detalhada nos mínimos detalhes, mas
que não tem qualquer parte do software em funcionamento?”.
Segundo Prikladnicki, Willi e Milani (2014), esse valor pode ser con-
siderado um ponto de equilíbrio entre o documentar ao extremo e o não
documentar. No início da história da engenharia de software, muitos projetos
se tornaram reféns de seus desenvolvedores, pois não havia documentação;
sem documentação, todo o conhecimento que não se podia obter por meio
das linhas de código estava na cabeça deles. Então a solução era documentar
tudo, e as empresas passaram a contratar pessoas e, até mesmo, a criar equipes
especializadas apenas na criação de diagramas e especificações de software.
A ideia é ponderar o que, quando e como documentar: o que será útil de fato,
o que terá uma volatilidade baixa, o que será realmente usado por alguém
em algum momento.

Colaboração com o cliente deve ser mais valorizada

que negociação de contratos
Pressman e Maxim (2016) fazem algumas afirmações sobre os projetos de soft-
ware que nos permitem entender o porquê da preocupação com a colaboração:

 O escopo de um software é imprevisível, ou seja, não é possível prever

como as prioridades do cliente vão se modificar no decorrer do projeto.
 Em muitos tipos de software, os trabalhos de projeto e construção
precisam ser intercalados, e é difícil prever o tamanho do trabalho de
projeto antes que o desenvolvimento seja efetivamente iniciado.
 Manifesto Ágil 5

Mas, como em toda relação de consumo ou de prestação de serviços,

regras precisam ser definidas para a construção de um software. A proposta
é trabalhar em colaboração com o cliente para entregar um software que
realmente atenda suas necessidades e, se for necessário, realizar concessões
que não afetem significativamente a relação contratual. Segundo Prikladnicki,
Willi e Milani (2014), esse é um ponto fraco do Manifesto Ágil, pois as partes
(desenvolvedor e cliente) precisam de segurança contratual contra atitudes
de má-fé. Trabalhar com um contrato que permita um escopo totalmente
aberto, sem nenhum tipo de controle, poderia gerar um prejuízo incalculável,
inviabilizando o contrato.

Responder a mudanças deve ser mais valorizado que

seguir um plano
Existe uma análise que é muito conhecida em engenharia de software e no
gerenciamento de projetos em geral: custo das mudanças versus tempo do pro-
jeto. Quanto mais cedo são identificados pontos que precisam ser modificados,
mais barata será a modificação. Pressman e Maxim (2016) explicam que, na
fase inicial, seria necessário alterar documentos, especificações e protótipos,
o que seria pouco custoso. Mas e se a necessidade de uma modificação for
descoberta quando estão sendo executados os testes do software? Nesse caso,
seria necessário alterar os requisitos, o projeto, o código e os casos de testes,
bem como executar os testes novamente.
A preocupação com a resposta a mudanças vai ao encontro do fato de
que as mudanças vão acontecer, independentemente de nossas expectativas.
Dessa forma, as equipes de projeto de software devem estar abertas a reagir
a mudanças de forma rápida, entregando o valor que o cliente necessita para
atender suas necessidades de negócios.

2 Os 12 princípios do Manifesto Ágil

Os quatro valores do Manifesto Ágil são complementados por 12 princípios.
Esses princípios são declarações simples, mas cujo significado é bem abrangente
e contextualizado ao dia a dia de equipes de desenvolvimento de software.
No Manifesto Ágil, só estão declarados os princípios, sem qualquer tipo de
detalhamento.
A seguir, cada um desses 12 princípios será apresentado, e explicaremos
como eles podem ser aplicados em um contexto de equipes de desenvolvimento
6 Manifesto Ágil

de software. Você verá que os 12 princípios estão diretamente ligados a algum

dos quatro valores, alguns a mais de um valor. A sequência apresentada a seguir
é a sequência determinada pelo próprio Manifesto Ágil (BECK et al., 2001).

1. Nossa maior prioridade é satisfazer o cliente por

meio da entrega contínua e adiantada de software com
valor agregado
Determinar alvos de entrega contínua em períodos curtos permite que a equipe
de desenvolvimento de software apresente o resultado de seu trabalho rapi-
damente ao cliente e que ele logo colha os benefícios dessas entregas. Isso
significa que a construção do software deve ser pensada de modo a permitir que
pequenas partes sejam periodicamente entregues ao cliente; assim, ele poderá
iniciar o uso e, com isso, ter a oportunidade de evoluir o entendimento do
processo como um todo, fazendo as definições das novas entregas se basearem
na experiência de consumo das entregas já realizadas.

2. Mudanças nos requisitos são bem-vindas, mesmo

que tardiamente no desenvolvimento. Processos ágeis
tiram vantagem das mudanças, visando à vantagem
competitiva para o cliente
Esse princípio vai totalmente contra o que as metodologias tradicionais de
desenvolvimento de software preconizam. O compromisso com o escopo
inicial e a formalização das necessidades é o que todas equipes de software
sempre buscaram. O detalhe é que isso simplesmente não funciona na maioria
dos projetos de software! Os requisitos são vivos. As organizações lidam com
mudanças motivadas pela concorrência, pela legislação, pela evolução tecno-
lógica, etc., em períodos muito curtos, ao contrário do que os desenvolvedores
de software gostariam. Assim, nesse princípio, o Manifesto Ágil entende que
essa é a realidade do desenvolvimento de software e que as mudanças devem
ser aceitas. A ideia, portanto, é se preparar para elas, evitando que as restrições
de software atrapalhem os negócios das organizações.
 Manifesto Ágil 7

3. Entregar frequentemente software funcionando, de

poucas semanas a poucos meses, com preferência à
menor escala de tempo
A ideia desse princípio é definir um time-box (termo muito utilizado em am-
bientes ágeis para determinar um período específico para uma atividade) para
a entrega de software funcionando ao cliente. Se for definido que a entrega
será realizada a cada duas semanas, isso deverá ser contínuo durante todo o
tempo do projeto, o que permitirá que todos compreendam o ciclo de entregas
e estejam preparados para elas.
Observe que esse princípio está diretamente ligado aos dois primeiros, pois
a equipe só será capaz de entregar software com valor para o cliente e responder
rapidamente a mudanças se fizer entregas em tempos curtos. Mantém-se um
vínculo mais próximo com os usuários, pois a equipe executará todo o processo
de desenvolvimento de software de forma cíclica, desde o levantamento de
requisitos até a implantação.

4. Pessoas de negócio e desenvolvedores devem

trabalhar diariamente em conjunto por todo o projeto
O objetivo de aproximar os responsáveis pelas necessidades dos usuários dos
desenvolvedores é fazer as pessoas se aproximarem e “falarem a mesma língua”.
A convivência de especialistas da área de negócio com desenvolvedores facilita
o entendimento das necessidades de negócio que o software vai contemplar
e minimiza falhas de comunicação. O ideal é que essa aproximação seja feita
diretamente com representantes dos usuários, mas nem sempre os clientes e as
empresas de desenvolvimento estarão disponíveis. Nesses casos, a recomen-
dação é aumentar as oportunidades de contato entre as partes, promovendo
a maior integração possível.

5. Construa projetos em torno de indivíduos

motivados. Dê a eles o ambiente e o suporte
necessários e confie neles para fazer o trabalho
O ambiente adequado é o que vai permitir que eles executem agilidade ple-
namente, e isso envolve desde o ambiente físico, como equipamentos e fer-
ramentas (software), até a autonomia para executar o trabalho. Times ágeis
são autogerenciáveis, e isso vai acontecer principalmente se a organização
em que eles estão inseridos permitir.
8 Manifesto Ágil

6. O método mais eficiente e eficaz de transmitir

informações para e entre uma equipe de
desenvolvimento é por conversa face a face
A ideia é que sempre seja priorizada a comunicação pessoal, frente a frente.
Em ambientes de desenvolvimento de software, é muito comum ver pessoas
que trabalham a poucos metros de distância se comunicando por meio de
chat. Dessa forma, perde-se vários aspectos da comunicação presencial, como
entonação, ênfase, linguagem não verbal e, por consequência, produtividade,
pois escrever geralmente é mais demorado que falar.
Não podemos deixar de considerar que, atualmente, é muito comum exis-
tirem equipes trabalhando de forma remota, em escritórios geograficamente
distantes ou em regime de home office. Nesses casos, sugere-se que se utilize,
sempre que disponível, chamadas de vídeo. Essa iniciativa busca diminuir a
impessoalidade decorrente do distanciamento físico.

7. Software funcionando é a medida primária de

progresso
Esse princípio direciona o processo de desenvolvimento de software para a
entrega. Ter uma documentação robusta e detalhada, nas premissas do Ma-
nifesto Ágil, não tem valor se não existe um software desenvolvido com base
nessa documentação. Ou seja, valor, para o cliente, é ter um software entregue
e funcionando, não um monte de documentação acumulada sobre a mesa.

8. Processos ágeis promovem desenvolvimento

sustentável. Os patrocinadores, desenvolvedores
e usuários devem ser capazes de manter um ritmo
constante indefinidamente
Reforçando o que foi apresentado no 5º princípio, as equipes ágeis devem
ser autogerenciáveis. Aqui, a produtividade não é relacionada ao número de
horas trabalhadas, mas a manter um processo contínuo a fim de atender às
necessidades de seus usuários. A parceria constante com os fornecedores de
requisitos e os usuários do software permitirá que esse ciclo seja contínuo.
 Manifesto Ágil 9

9. Contínua atenção à excelência técnica e bom design

aumentam a agilidade
Até aqui, talvez alguns desenvolvedores mais relapsos possam ter entendido os
princípios do Manifesto Ágil como um salvo-conduto, uma liberação de regras
e padrões; afinal, não será mais necessário documentar, pois os documentos
não têm valor, e a equipe fará o que quiser, porque se autogerencia. Na verdade,
os desenvolvedores com esse pensamento não entenderam nada do Manifesto
Ágil. Esquecem que o software precisa ser entregue em condições de uso e
manutenção. Esse princípio, assim, chama a atenção para isso. Software bem
construído é software fácil de manter e evoluir. Se a equipe fará pequenas
entregas constantes, elas devem ter uma alta confiabilidade para que os usuários
se sintam confortáveis em recebê-las.

10. Simplicidade, a arte de maximizar a quantidade de

trabalho não realizado, é essencial
Desenvolver software é desenvolver um produto. Desenvolver um produto que
atenda às necessidades do usuário é o dever de um desenvolvedor de software.
Cabe perguntar, porém: “O usuário precisa de tudo isso?”; “O que realmente
fará diferença em seu processo de trabalho?”; “Será que você está construindo
um canhão para matar um mosquito?”. É muito comum que desenvolvedores
de software desejem construir soluções que utilizem o estado da arte de fun-
cionalidades e tecnologias inovadoras para validar suas próprias habilidades,
mas será que é isso mesmo que o cliente precisa? Muitas ferramentas líderes
de mercado, como o motor de busca do Google, tiveram versões iniciais
extremamente simples, e assim são até hoje.

11. As melhores arquiteturas e os melhores requisitos e

designs emergem de equipes auto-organizáveis
A famosa frase de Antoine de Saint-Exupéry “Você se torna eternamente
responsável por aquilo que cativa” é aplicação poética desse princípio ágil.
Quando uma equipe é responsável por definir algo, como uma arquitetura de
projeto, um padrão, uma meta, ela se sente responsável por aquilo e se dedica
de forma integral a garantir bons resultados. Quando a equipe recebe uma
definição, uma determinação de alguém, o resultado não é o mesmo, pois
sempre encontrará uma forma de culpabilizar outro(s) por um desempenho
indesejado. Veja um exemplo.
10 Manifesto Ágil

 Situação A: seu gerente atribui uma tarefa a você e determina que seja
executada em dois dias.
 Situação B: seu Gerente atribui uma tarefa a você e solicita que você
avalie quanto tempo é necessário para executá-la. Então, você o informa
que precisa de dois dias.

Veja que o prazo é o mesmo. Porém, se, na “Situação A”, você não cumprir
o prazo, poderá justificar, informando os motivos pelos quais não foi possível
e atribuindo a culpa a seu gerente, que determinou mal o prazo. Por outro lado,
na “Situação B”, se não cumprir o prazo, você terá que se responsabilizar
inteiramente, pois foi você quem o determinou. Temos uma tendência natural
a nos comprometermos mais com definições feitas por nós mesmos, pois, se
as fizemos, é porque é naquilo que acreditamos.

12. Em intervalos regulares, a equipe reflete sobre

como se tornar mais eficaz e, então, refina e ajusta seu
comportamento de acordo
A equipe ágil é autogerenciável. A cada projeto, precisa encontrar sua dinâmica
de trabalho, estabelecendo pontos de checagem para determinar as práticas
que estão surtindo bons resultados e que devem ser mantidas ou, até mesmo,
ampliadas, as práticas que não devem ser continuadas por estarem causando
resultados ruins e as iniciativas para resolver problemas. A partir daí, planos
de ação devem ser criados e colocados em prática. Melhoria contínua é a
chave para o sucesso.

O Manifesto Ágil está lhe parecendo muito teórico? Está com dúvidas sobre como
aplicá-lo? Digite “Saiba como as empresas estão se adaptando às novas formas de
trabalho, impostas pela transformação digital” em seu motor de busca preferido para
ter acesso a uma reportagem da revista Época que vai lhe ajudar a ter uma ideia melhor
a respeito de como aplicar o Manifesto nas organizações.
 Manifesto Ágil 11

3 O Manifesto Ágil e os processos de

desenvolvimento de software
Antes de mais nada, é importante conceituarmos processo de desenvolvimento
de software, e a definição de Schach (2009) é bem precisa: o processo de
desenvolvimento de software é forma como o software é produzido, incluindo
a metodologia, seu modelo de ciclo de vida, técnicas subjacentes, ferramentas
usadas e as pessoas que o estão criando.
Durante um bom período após a publicação do Manifesto Ágil, houve certo
antagonismo entre os estudiosos de engenharia de software. De um lado, havia
os que defendiam o que preconizava o Manifesto; do outro, os que defendiam
os processos de desenvolvimento de software tradicionais. Daí, surgiram bons
debates, alguns bastante calorosos, sobre o assunto. O saldo da “disputa”, se é
que podemos chamá-la assim, tornou-se um consenso, um acordo. Ambos os
“lados” passaram a enxergar o que havia de melhor e de necessário em ambas
as abordagens e passaram a optar por um modelo misto. Portanto, hoje, temos
equipes que predominantemente utilizam um processo de desenvolvimento
tradicional, com a inclusão de algumas práticas ágeis, e equipes ágeis que
utilizam algumas práticas de equipes tradicionais.
Analisando os processos de desenvolvimento de software tradicionais, o
que mais se enquadra nos valores e princípios do Manifesto Ágil é o processo
incremental. Conforme Pressman e Maxim (2016), o modelo incremental
disponibiliza uma série de versões, chamadas de incrementos, que dispõem,
progressivamente, mais funcionalidades, ou funcionalidades mais avançadas
conforme cada novo incremento é entregue ao usuário.
Na Figura 1, que representa o modelo incremental, é possível verificar que
todas as etapas genéricas do processo de desenvolvimento de software são
executadas n vezes durante o ciclo de vida daquele software. O primeiro incre-
mento, ou conjunto formado pelos primeiros incrementos, deve ser composto
pela base de software, pelas funcionalidades estruturantes que permitirão
que ele seja desenvolvido e evoluído ao transcorrer do tempo. É importante
mencionar que as fases de comunicação e planejamento do próximo incre-
mento iniciam durante a fase de construção e disponibilização do software,
permitindo que o trabalho flua de uma forma cíclica.
12 Manifesto Ágil

Figura 1. Processo de desenvolvimento de software incremental.

Fonte: Pressman e Maxim (2016).

A definição do conjunto inicial dos incrementos e, depois, da ordem deles

é um trabalho complexo. Para Sommerville (2018), é impossível utilizar uma
abordagem totalmente incremental para requisitos de software. É necessário que
haja um trabalho inicial sobre requisitos, sobre o escopo geral do sistema, para
identificar as diferentes partes que poderão ser desenvolvidas em momentos
diferentes incrementalmente.
É mais fácil implementar um processo ágil seguindo os valores e prin-
cípios do Manifesto Ágil em pequenas empresas e equipes. Sommerville
(2018) destaca alguns pontos que podem dificultar a implantação em grandes
organizações:

 Gerentes de projetos tradicionais, sem experiência com métodos ágeis,

podem se recusar a aceitar o risco de aplicar uma nova metodologia.
 Grandes organizações geralmente têm padrões de procedimentos de
processos e de qualidade burocráticos, incompatíveis com os métodos
ágeis.
 Métodos ágeis tendem a funcionar melhor em times com uma habili-
dade elevada. Dentro de grandes organizações, é bem comum haver
um espectro maior de níveis de habilidade pelo staff diversificado,
incluindo estagiários e funcionários carentes de habilidades necessárias
a times ágeis.
 Manifesto Ágil 13

 A resistência cultural pode ocorrer, principalmente em organizações

com um longo histórico com metodologias de gerenciamento de projetos
tradicionais.

Dessa forma, é importante ressaltar a proposta de um modelo híbrido na

adoção de métodos ágeis. Veja apresenta alguns exemplos de modelos híbridos:

 Projetos de desenvolvimento de software que utilizam os papéis, os

artefatos e as cerimônias do Scrum e as práticas da XP, como TDD
(test-driven development, ou desenvolvimento guiado por testes), re-
factoring e pair programming.
 Projeto de desenvolvimento de ERP (enterprise resource planning, ou
planejamento de recursos empresariais) modular que utiliza as carac-
terísticas do FDD ( feature-driven development, ou desenvolvimento
guiado por funcionalidades) para definição de escopo, papéis e ceri-
mônias, e artefatos do Scrum e práticas de XP para o desenvolvimento.
 Suporte e atendimento de chamados utilizam Kanban, mas papéis do
Scrum e reuniões diárias para adaptação e inspeção, e retrospectivas
para a melhoria contínua.

BECK, K. et al. Manifesto para desenvolvimento ágil de software. 2001. Disponível em:
[Link] Acesso em: 1 set. 2020.
HIGHSMITH, J. History: the agile manifesto. 2001. Disponível em: [Link]
org/[Link]. Acesso em: 1 set. 2020.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8.
ed. Porto Alegre: AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. (org.). Métodos ágeis para gerenciamento de software.
Porto Alegre: Bookman, 2014.
SCHACH, S. R. Engenharia de software: os paradigmas clássico e orientado a objetos. 7.
ed. Porto Alegre: AMGH, 2009.
SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.
14 Manifesto Ágil

Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a
rede é extremamente dinâmica; suas páginas estão constantemente mudando de
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade
sobre qualidade, precisão ou integralidade das informações referidas em tais links.