a99aa53f-54e1-47e9-87d7-c24ae39ead2a (1)

Prévia do material em texto

DESENVOLVIMENTO 
DE SOFTWARE COM 
METODOLOGIAS 
ÁGEIS 
Luis Gustavo Maschietto 
Feature Driven 
Development (FDD)
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:
  Explicar a metodologia do Feature Driven Development (FDD).
  Identificar os processos básicos do FDD e a sua documentação. 
  Compreender o contexto de aplicação do FDD. 
Introdução
Neste capítulo, você vai conhecer as características da metodologia do 
desenvolvimento orientado a funcionalidade, do inglês Feature Driven 
Development (FDD), os processos básicos que são apresentados pela 
documentação FDD e o seu contexto de aplicação. Você aprenderá 
também a maneira como são formadas as equipes e a responsabilidade 
de cada função para a execução dos processos e o levamento das fun-
cionalidades do sistema a ser desenvolvido.
1 Metodologia FDD
No período de 1997 a 1999, o FDD surgiu para solucionar problemas enfren-
tados na engenharia de uma plataforma de empréstimos para corporações no 
banco internacional United Overseas Bank (UOB) — localizado na cidade 
de Cingapura. O projeto que envolvia essa plataforma apresentava alto grau 
de complexidade e a sua consultoria produziu diversas páginas de casos de 
uso, mas sem colocar em execução grande parte do que foi elaborado. Diante 
de vários problemas, Jeff De Luca, um membro da equipe, convenceu a em-
presa a liderar o projeto com um número reduzido de pessoas para treinar 
outros membros da equipe e para desenhar o sistema. Jeff De Luca já havia 
adotado, em outros projetos, formas leves de processo com alta iteração e 
estava disposto a tentar novas estratégias para a plataforma de empréstimos 
(ANWER et al., 2017).
Para projetar o sistema, Jeff De Luca contratou Peter Coad, que era co-
nhecido por projetar sistemas orientados a objetos e por desenvolver padrões 
e estratégias de análise. Além de Peter, Stephen Palmer entrou para equipe 
com a função de gerente de desenvolvimento e contribuiu para a execução 
de novas rotinas. Depois de aproximadamente um ano e meio de trabalho, 
graças à equipe composta por 50 pessoas, diversas funcionalidades foram 
entregues com sucesso e com uma economia considerável no orçamento 
previsto inicialmente. O sistema entregue foi nomeado de Power Lender e está 
sendo utilizado até os dias de hoje. Apesar de o projeto ter sido um sucesso 
graças às diretrizes seguidas pela equipe, não existiu nenhuma iniciativa para 
documentar, de forma oficial, esse novo processo. Mesmo assim, é possível 
encontrar informações em sites e artigos sobre as rotinas utilizadas (ANWER 
et al., 2017). 
Em 2001, Peter Coad foi convidado para uma reunião a respeito das meto-
dologias ágeis que se tornou referência para as discussões relacionadas a essa 
prática, porém, ele não conseguiu comparecer e delegou a responsabilidade 
para o diretor de serviços da TogetherSoft, Jon Kern. A partir desse evento, o 
FDD foi visto como o precursor de todas as metodologias consideradas oficiais 
do movimento ágil (PRIKLADNICKI; WILLI; MILANI, 2014).
A feature é considerada uma funcionalidade pequena que tem maior rele-
vância para o cliente no contexto do domínio do negócio a ser desenvolvido. 
Para atender a esses requisitos, a equipe do projeto deverá desenvolver essa 
funcionalidade em aproximadamente 80 horas, ou seja, em um tempo menor 
do que duas semanas. Em comparação a outras funcionalidades do projeto 
que requerem poucas horas de trabalho, uma feature, portanto, deverá receber 
uma maior atenção pela equipe de trabalho. A teoria de processos consegue 
explicar o que são funcionalidades para a metodologia FDD a partir do enten-
dimento do domínio de negócios que são decompostos em áreas de negócio 
como vendas, compras, operações e marketing. Para cada área pertencente 
ao domínio de negócio, são identificados processos que apresentam passos e 
tarefas bem definidos que podem ser automatizados por sistemas ou manuais. 
Esses passos automatizados são vistos como funcionalidades de um projeto 
de FDD (PRIKLADNICKI; WILLI; MILANI, 2014).
Em relação à equipe de trabalho e à sua estrutura (Figura 1), o FDD define 
ações, desempenhadas por cada pessoa inserida no projeto, que fornecem uma 
execução coordenada e harmoniosa para todas as funções de trabalho existen-
tes. Outro fator marcante nas funções executadas em projetos que utilizam a 
Feature Driven Development (FDD)2
metodologia FDD é a alta importância do fator humano e a interdependência 
sistêmica dos componentes organizacionais, o que torna perceptíveis as carac-
terísticas sociais embutidas nessa metodologia. O FDD apresenta uma equipe 
formada pelos seguintes profissionais: programadores líderes, arquiteto líder, 
especialistas no domínio de negócio, gerente de desenvolvimento, gerente de 
projeto e proprietários de classes (PRIKLADNICKI; WILLI; MILANI, 2014).
Programadores líderes: lideram equipes de trabalhos que são compostas 
por desenvolvedores mais experientes. Eles são responsáveis por coordenar 
o desenvolvimento, participar das defi nições técnicas e montar as equipes. 
Normalmente esses programadores lideram de 2 a 5 pessoas, dependendo do 
contexto do projeto.
Arquiteto líder: tem experiência na modelagem e na análise de sistemas, 
além de habilidades de liderança em equipes de desenvolvimento dos modelos 
do sistema. Essa função também poderá ser assumida por desenvolvedores 
experientes em projetos menores ou por consultores externos capazes de 
agregar novas experiências. 
Especialistas no domínio de negócio: são responsáveis por comunicar e 
orientar a equipe do projeto a cumprir os requisitos estabelecidos pelo cliente. 
Essa função é desempenhada por consultores externos e usuários.
Gerente de desenvolvimento: exerce a função de liderança no projeto para 
atender às orientações do gerente de projeto. Com habilidades gerenciais e 
técnicas para orientar a equipe de desenvolvimento, o gerente de projeto poderá 
exercer essa função em equipes reduzidas de projeto.
Gerente de projeto: gerencia todo o projeto e promove ações para a equipe. 
Esse profi ssional é responsável por reportar as atividades para a alta gerência 
e clientes. Essa função contribui para uma maior efi ciência nas ações execu-
tadas pela equipe.
Proprietários de classes: são representados pelos desenvolvedores da equipe, 
que são responsáveis pelas classes do modelo do projeto. O proprietário deverá 
participar das equipes de implementação de funcionalidades que correspondem 
à sua classe subordinada.
3Feature Driven Development (FDD)
Figura 1. Estrutura da equipe de FDD.
Fonte: Prikladnicki, Willi e Milani (2014, p. 73).
Além das funções mencionadas, há a necessidade de equipes consideradas 
de apoio ao projeto. Entre elas, é possível citar, de acordo com Gahyyur et 
al. (2018):
  especialista em linguagens, plataformas e tecnologias: são responsáveis 
por dar suporte técnico especializado ao projeto. Essa função deve ser 
ocupada por uma pessoa que tem grande experiência e conhecimento 
das técnicas definidas para o projeto, devendo ser um mentor para 
intervir em situações específicas no desenvolvimento;
  gerente de produto: responsável pela escolha de quais funcionalidades 
deverão ser incluídas para cada versão, bem como por definir o ciclo 
de vida do produto;
  testadores: responsáveis por controlar a qualidade do produto por meio 
de recursos de regressão, aceitação e testes de integração;
  assistente de projeto: responsável por cuidar dos detalhes do projeto e 
permitir maior liberdade para o gerente de projeto em questões mais 
táticas e estratégicas. Esse profissional também promove reuniões e 
eventos de integração para motivar a equipe, toma conta das finanças 
e cuida da comunicação entre o seu grupo.
Feature Driven Development (FDD)4
Jeff De Luca tem 25 anos de experiência na gestão de projetos e trabalhou na IBM por 
cerca de 11 anos e na atual Nebulon, da qual é proprietário. Apesar de sua brilhante 
atuação nos processosde desenvolvimento de sistemas, o que lhe rendeu diversos 
prêmios pelo seu trabalho, ele nunca chegou a completar a educação secundária. 
Mesmo com habilidades apuradas em Tecnologia da Informação, ele é um grande 
conhecedor das relações humanas, e isso o fez ser um grande líder visionário. Peter 
Coad, Eric Lefebvre, Jedd De Luca apresentaram seus estudos sobre FDD no livro Java 
Modeling in Color with UML.
Peter Coad escreveu diversos livros sobre programação orientada a objetos, mode-
lagem e análise, além de ser coautor da UML em Cores e dos métodos Coad-Yourdon. 
Ele fundou a empresa Together-Soft, que desenvolvia soluções para a conversão de 
código-fonte em UML e de UML para código-fonte. Em 2003, sua empresa foi vendida 
e hoje ele concentra seus esforços em projetos pessoais que utilizam seus conceitos 
de arquiteturas que têm como base os componentes.
2 Processos básicos do FDD e sua documentação 
O FDD consiste nos seguintes processos (MASSARI, 2018):
  desenhar um protótipo do produto;
  montar um alista de funcionalidades do produto;
  planejar e desenvolver por funcionalidade.
De acordo com Pressman (2011), o FDD segue algumas abordagens, como 
técnica por meios verbais, gerência de complexidade e problemas de projetos 
com base em funcionalidades, comunicação, colaboração entre pessoas da 
equipe, textos e gráficos. Essa metodologia engloba alguns processos, os quais 
são evidenciados na Figura 2, como: 
  desenvolvimento de um modelo abrangente a partir da definição do 
escopo do projeto e de um estudo do domínio do negócio;
  construção de uma lista de funcionalidades para entender as necessi-
dades do cliente; 
  planejamento por funcionalidades e por prioridades;
  projeto que estabelece uma atividade a ser realizada para cada funcio-
nalidade listada; 
5Feature Driven Development (FDD)
  construção por funcionalidades a partir do código gerado para cada 
funcionalidade listada.
Figura 2. Processos da metodologia FDD.
Fonte: Adaptada de Barcelos (2019).
Em sua documentação, Paz, Duarte e Bigão (2017), apresentam que a meto-
dologia FDD abrange algumas diretrizes para os processos de desenvolvimento 
da aplicação. Acompanhe a ordem dos processos a seguir.
DMA (desenvolver um modelo abrangente) — Realizada por desenvolve-
dores e membros do domínio do negócio sob a orientação de um arquiteto 
líder. É considerada a atividade inicial que engloba todo o projeto em que são 
compartilhados os requisitos apontados, a síntese do projeto e o conhecimento 
adquirido na análise. Nessa etapa inicial, são apresentados os modelos desen-
volvidos para a revisão de decisões que serão tomadas ao longo do processo. 
Por ser gerado um modelo inicial, alguns especialistas consideram que se trata 
de um resgate ao modelo em cascata, porém, na visão de Stephen Palmer, a 
ideia é buscar uma antecipação e a adaptação das atividades do projeto no 
início da etapa de desenvolvimento. Nessa fase, é realizada uma modelagem 
por cores para estimular um processo colaborativo da equipe a partir do uso 
de notas coloridas (Figura 3).
  Momento-intervalo rosa: representa os serviços, eventos e atividades 
no domínio do negócio. Para a identificação do arquétipo (que são 
Feature Driven Development (FDD)6
modelos ou padrões passíveis de serem reproduzidos em simulacros ou 
objetos semelhantes), é utilizada uma cor e um estereótipo <<momento-
-intervalo>> ou <<ie>>. Para detalhar, é usado o estereótipo <<mi-
-detalhe>> ou <<ie-xan>>.
  Pessoa-lugar-coisa verde: pode representar algum objeto, um local ou uma 
pessoa (física ou jurídica). Esses arquétipos são identificados pela cor 
verde e o estereótipo correspondente <<party>>, <<place>> ou <<thing>>. 
Em geral, eles são representados por cadastro e relatórios simples. 
  Papel-amarelo: representa uma coisa, um lugar ou uma pessoa em um 
evento de negócio. Sua cor é o amarelo e o estereótipo é <<role>>.
  Descrição-azul: representa algo, como um item em um catálogo. Essa 
descrição é utilizada para concentrar dados que são comuns a diversos 
objetos. Ela possibilita perguntas de negócios, como a quantidade de 
objetos de um determinado tipo. As descrições formam tabelas de 
referência que são utilizadas em campos de escolha a partir de uma 
lista de opções (combos e lookups), como ocorre em categorias, grupos 
e estado civil. Usa-se o estereótipo <<description>>.
Figura 3. Exemplo do uso das cores na plataforma FDD para indicar o tipo de classe en-
volvida no processo.
Fonte: Embarcadero Home (c2020).
7Feature Driven Development (FDD)
CFL (construir a lista de funcionalidades) — Identifi ca as funcionalidades 
mais importantes para atender aos requisitos do sistema. A lista de funcionali-
dades geralmente é categorizada nos níveis de passos da atividade de negócio, 
das atividades de negócio e das áreas de negócio. A decomposição em níveis 
dá origem à estrutura de desmembramento de funcionalidades, do inglês 
Feature Breakdown Structure (FBS), que é considerada o mapa do produto. 
Nesse processo, não existe a priorização entre as funcionalidades listadas ou 
a classifi cação em necessárias ou desejáveis, o foco, portanto, é a defi nição do 
que o produto deverá ser para satisfazer os requisitos de usuário de negócio.
PPF (planejar por funcionalidade) — Nessa fase, o gerente de projeto tem 
a responsabilidade de ordenar quais funcionalidades serão consideradas para 
implementação. Essa escolha se baseia na complexidade das funcionalidades, 
na carga de trabalho da equipe e nas dependências existentes. Outro ponto 
relevante para esse projeto é a estimativa de tempo para a implementação das 
funcionalidades.
DPF (detalhar por funcionalidade — Refere-se à produção de um pacote de 
desenho (design) para cada funcionalidade. O principal objetivo do processo 
é preparar esse pacote para ser implementado pelos desenvolvedores. Nessa 
fase, são produzidos diagramas de sequência ou máquina de estados para as 
funcionalidades. O programador líder tinha a função de refi nar o modelo de 
objetos a partir dos diagramas gerados. Ao fi nal do processo, podem ser feitas 
revisões pela equipe em reuniões formais ou entre os próprios pares.
CPF (construir por funcionalidade) — Consiste em uma atividade realizada 
por funcionalidade para a produção de algo com valor ao cliente. Os proprie-
tários de classes são responsáveis por implementar os itens necessários para 
que as classes possam suportar o desenho de cada funcionalidade a partir do 
pacote produzido no processo anterior. Os códigos que são desenvolvidos 
devem passar por inspeção e por testes. Após a aprovação o código, fi nalmente 
ele será promovido à build (compilação) atual.
Feature Driven Development (FDD)8
Em relação ao processo de número 2, a decomposição a partir de uma lista de funcio-
nalidades também pode ser apresentada por um Mapa Mental. Ferramentas existentes 
no mercado para esse tipo de apontamento, como o Balanced Scorecard, possibilitam 
inserir anotações em cada entidade do mapa. Essas anotações permitem documentar 
informações de progresso, detalhamento dos requisitos, entre outras informações. 
O FDD recomenda a utilização das oito práticas listadas a seguir por 
Massari (2018):
1. a equipe deve explorar e entender o problema relacionado ao negócio a 
ser desenvolvido, portanto, é fundamental que as pessoas relacionadas 
à parte técnica também entendam as regras de negócios estabelecidas 
para o desenvolvimento de sistema. Dessa forma, a equipe deve entender 
e explorar o produto a ser desenvolvido;
2. as entregas devem ser curtas e o desenvolvimento precisa ocorrer por 
funcionalidade ( feature). Intervalos curtos de tempo para as entregas 
possibilitam a identificação de problemas e riscos futuros, por essa 
razão, ter o feedback dos clientes possibilita a realização de mudanças 
se houver falhas no sistema;
3. responsabilidade individual do código gerado: cada desenvolvedor deve 
ser responsável pela elaboração do código gerado no sistema;4. cada funcionalidade deverá ser desenvolvida por uma equipe de trabalho, 
sendo assim, cada funcionalidade será desenvolvida por uma equipe 
de especialista para aquela função;
5. verificações do andamento da execução das atividades: inspeção exe-
cutada constantemente para garantir a qualidade, ou seja, para prevenir 
problemas antes da entrega do sistema;
6. gerenciamento de configurações: mudanças devem ser rastreadas em 
cada equipe de trabalho a partir da utilização de um controle de versões 
do sistema. Dessa forma, é possível controlar quem realizou a mudança, 
identificar falhas e retroceder o processo se for necessário;
7. frequência nas compilações: com isso, é possível verificar se o novo 
código conseguirá se integrar ao código existente;
9Feature Driven Development (FDD)
8. visibilidade de progresso e resultado: os processos desenvolvidos de-
verão ser testados a partir das exibições dos resultados, dessa forma, 
há uma maior transparência no projeto.
Na Figura 4, é possível verificar um exemplo sobre a decomposição de 
processos e os passos que podem ser automatizados a partir do desenvolvimento 
de um sistema e que, portanto, são vistas como possíveis funcionalidades para 
o FDD. No exemplo, o processo identificado como Enviar pedido será Enviar 
um pedido para um fornecedor. Conforme descrito por Prikladnicki, Willi 
e Milani (2014), a estrutura da documentação do FDD segue um modelo de 
nomenclatura para cada funcionalidade identificada, que você pode ver a seguir:
  Nomenclatura: 
 ■ <Ação><Resultado><Objeto>
  Substituição na nomenclatura com as preposições do exemplo proposto: 
 ■ <Enviar><um pedido> para <um fornecedor> 
Figura 4. Exemplo de decomposição de processos e análise de funcionalidades no FDD.
Fonte: Prikladnicki, Willi e Milani (2014, p. 69).
A construção sintática a partir da identificação de uma ação, resultado 
e objeto de uma atividade dentro de um processo, permite padronizar as 
Feature Driven Development (FDD)10
funcionalidades e otimizar a comunicação. A identificação das preposições 
presentes nas atividades auxilia na leitura e escrita das funcionalidades e na 
alocação de classes, nomes e parâmetros para a realização das operações. 
Outros exemplos poderiam ser (PRIKLADNICKI; WILLI; MILANI, 2014):
  agendar visita de vendedor;
  enviar confirmação de realização de um pedido por e-mail.
  imprimir cupom fiscal de venda;
  calcular valor total de venda.
Outra vantagem descrita por Prikladnicki, Willi e Milani (2014), é o seu 
uso na identificação de funcionalidades-chave a partir da análise das seguintes 
características:
  funcionalidades que são valorizados pelo cliente;
  funcionalidades passíveis de futuras melhorias;
  funcionalidades que podem apresentar defeitos;
  funcionalidades que poderão gerar um acordo para uma conversação 
futura;
  funcionalidades que poderão ser testadas para sua aceitação no projeto.
3 Contexto de aplicação do FDD
No mercado, existem diversos modelos de gestão e metodologias para a constru-
ção de sistemas computacionais. Os métodos ágeis são amplamente utilizados 
por terem diretrizes efi cientes e com nível de qualidade satisfatório para diversos 
tipos de sistemas e em grupos de trabalhos diversifi cados. Empresas iniciantes no 
mundo corporativo escolhem preferencialmente recursos ágeis por serem rotinas 
consolidadas e com histórico de sucesso para o desenvolvimento de software. 
Metodologias como Scrum se tornaram quase unânimes, porém, diversas 
mudanças em metodologias tradicionais foram aperfeiçoadas com novas 
abordagens para manter seu espaço no mercado. Um exemplo desse tipo de 
metodologia é a Corrente Crítica, introduzida por Goldratt em 1997, que ainda 
tem espaço em organizações de diversos ramos de atividade e de diversos 
tamanhos para o gerenciamento de seus portfólios (KAHMANN et al., 2014). 
Nos dias de hoje, além da evolução das metodologias tradicionais, é comum 
verificar o uso de metodologias combinadas para que se tenha uma maior 
confiabilidade no projeto. Diversos autores de metodologias para o desenvolvi-
11Feature Driven Development (FDD)
mento de sistemas já mencionaram os benefícios da junção de diretrizes, como 
o criador do método Kanban, David Anderson, que propôs a combinação de 
FDD com a Corrente Crítica para a obtenção de uma visão geral de projeto. 
Apesar de muitas vezes ser crítico e não ser incisivo em seu marketing, para 
uma melhor divulgação, o FDD ainda se apresenta relevante, principalmente 
por empresas insatisfeitas com o uso de metodologias XP, Scrum, Kaban, entre 
outras. Sua relevância também é determinada por apresentar princípios sólidos 
de Engenharia de Software, dinâmicas sociais eficientes e flexibilidade para 
o suporte de diferentes técnicas e pelo fato de o FDD estar focado na equipe 
de trabalho. Portanto, mesmo com diversas metodologias no mercado, o FDD 
ainda se mostra relevante e útil para o meio corporativo. David Anderson, 
criador do Kanban, também utilizou o FDD como um meio de inspiração para 
compor as diretrizes de sua metodologia. Além do FDD, é possível verificar, 
na metodologia Kanban, influências da Teoria das Restrições e do Sistema 
Toyota de Produção (MAZUCO, 2017). 
Na Figura 5 é possível verificar a combinação de FDD e Scrum. O FDD 
é adaptado para trabalhar em um ambiente Scrum, dessa forma, também 
poderão ser executadas práticas Scrum em ambiente FDD (PRIKLADNICKI; 
WILLI; MILANI, 2014).
Figura 5. Combinação de FDD e SCRUM.
Fonte: Prikladnicki, Willi e Milani (2014, p. 95).
Feature Driven Development (FDD)12
Em relação às vantagens do uso do FDD em comparação com a outras 
metodologias, é possível citar (COIMBRA, 2020):
  suas práticas e princípios são capazes de proporcionar um equilíbrio 
entre as filosofias extremas e as mais tradicionais, o que proporciona 
uma mudança menos impactante em organizações mais conservadoras;
  a metodologia FDD tem requisitos mais formais;
  a metodologia FDD valoriza o recurso que o cliente valoriza;
  a metodologia FDD tem o foco nas características de valor para o cliente;
  essa metodologia é recomendada para qualquer tipo de desenvolvimento.
A relevância do FDD para projetos que utilizam metodologias hibridas é 
o fato de ele apoiar organizações com capacitação de pessoas e estimular um 
tipo de trabalho voltado para interações sociais. Para o FDD, a construção 
de um software é uma atividade humana na qual as pessoas se mobilizam 
para a solução de um problema comum. Todas as atividades executadas para 
encontrar as soluções para os desenvolvimentos das funcionalidades dependem 
de rotinas presentes no cotidiano das pessoas, como reuniões, comunicações, 
debates e construção de ideias, portanto, aproximar a equipe de trabalho na 
execução de rotinas similares às do seu cotidiano permite um desenvolvimento 
mais eficiente e natural, o que estimula, por consequência, o sucesso final do 
projeto (PRIKLADNICKI; WILLI; MILANI, 2014).
ANWER, F. et al. Agile software development models TDD, FDD, DSDM, and crystal 
methods: a survey. International Journal of Multidisciplinary Sciences and Engineering, v. 8, 
n. 2, p. 1–10, 2017. Disponível em: https://www.researchgate.net/publication/316273992_
Agile_Software_Development_Models_TDD_FDD_DSDM_and_Crystal_Methods_A_
Survey. Acesso em: 27 out. 2020.
BARCELOS, L. Feature Driven Development (FDD). CEDRO: technologies, 2019. Dispo-
nível em: https://blog.cedrotech.com/feature-driven-development-fdd/. Acesso em: 
28 out. 2020.
COIMBRA, R. Agile methods: feature driven development (FDD). Projetos e TI, 2020. 
Disponível em: https://projetoseti.com.br/agie-methods-feature-driven-development-
-fdd/. Acesso em: 27 out. 2020.
13Feature Driven Development (FDD)
EMBARCADERO HOME, c2020. Disponível em: https://edn.embarcadero.com/article/
images/33736/03000006.png. Acesso em: 28 out. 2020.
GAHYYUR, S. A. K. et al. Evaluation for feature driven development paradigm in context 
of architecture design augmentationand perspective implications. International Journal 
of Advanced Computer Science and Applications, v. 9, n. 3, p. 236–247, 2018. Disponível em: 
https://www.researchgate.net/publication/326059638_Evaluation_for_Feature_Dri-
ven_Development_Paradigm_in_Context_of_Architecture_Design_Augmenta-
tion_and_Perspective_Implications. Acesso em: 28 out. 2020.
KAHMANN, A. et al. Teoria das restrições e gestão de projetos: corrente crítica: uma 
revisão sistemática de literatura. Revista Espacios, v. 35, n. 13, 2014. Disponível em: 
https://www.revistaespacios.com/a14v35n13/14351303.html. Acesso em: 28 out. 2020.
MASSARI, V. L. Gerenciamento ágil de projetos. 2. ed. Rio de Janeiro: Brasport, 2018.
MAZUCO, A. S. C. Percepções de práticas ágeis em desenvolvimento de software: benefícios 
e desafios. Dissertação (Mestrado em Computação Aplicada) — Instituto de Ciências 
Exatas, Universidade de Brasília, Brasília, 2017. Disponível em: https://repositorio.unb.br/
bitstream/10482/25332/1/2017_AlanSaulodaCostaMazuco.pdf. Acesso em: 28 out. 2020.
PAZ, F. J.; DUARTE, F. S.; BIGÃO, E. S. Análise comparativa das metodologias ágeis: SCRUM, 
XP e FDD. Revista da Jornada de Pós-Graduação e Pesquisa — Congrega Urcamp, n. 
14, p. 260–279, 2017. Disponível em: http://revista.urcamp.tche.br/index.php/rcjpgp/
article/view/859. Acesso em: 28 out. 2020.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. ed. Porto 
Alegre: AMGH, 2011.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. (org.). Métodos ágeis para desenvolvimento de 
software. Porto Alegre: Bookman, 2014.
Leituras recomendadas
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e projeto orientados 
a objetos e ao desenvolvimento interativo. Porto Alegre: Bookman, 2007.
PRESSMAN, R.; MAXIM, B. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 8. ed. Rio de Janeiro: Addison Wesley, 2007.
Feature Driven Development (FDD)14
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.
15Feature Driven Development (FDD)