Artigo produzido no curso de pós-graduação em Engenharia de Software Centrada em Métodos Ágeis da UNA - BH

1. Feature Driven Development
Davi Busanello, Izabel Rodrigues, Kleber Sales, Mateus Alves, Priscilla
Aguiar
Centro Universitário UNA
Caixa Postal 30140-071 – Belo Horizonte – MG – Brasil
Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis
davibusanello@gmail.com, izabel.castro.rodrigues@gmail.com,
kleberhermsdorff@gmail.com, snap.mateus@gmail.com, pricaguiar@gmail.com
Abstract
The goal of this article is introduce the FDD, an agile methodology for managing
software development. It`ll be described in this article topics like the history of FDD, its
principles, values, practices and processes. This is an article presented at Agile
Software Engineering discipline.
Resumo
O objetivo deste artigo é apresentar a FDD, uma metodologia ágil para gerenciamento
de desenvolvimento de software. Será descrito neste artigo tópicos como a história do
FDD, seus princípios, valores, práticas e processos. Este é um artigo apresentado na
disciplina Engenharia de Software Ágil.

2. 1. Introdução
Softwares estão presentes em vários setores. Não é incomum ouvir-se falar que projetos
de software fracassam por não resolverem os problemas pelos quais eles foram
motivados. Muitos deles estouram orçamento, planejamento e em alguns outros
cenários, são entregues com muito menos funcionalidades do que inicialmente foram
planejados. Isso quando não são interrompidos sem entregar nenhum valor ao cliente.
No processo de desenvolvimento, temos dois modelos o iterativo e o em cascata.
O modelo em cascata tem como essência dividir o projeto com base nas atividades
necessárias para se concluir o projeto. Já no modelo iterativo, o projeto é divido em um
conjunto de funcionalidades e dentro de intervalos de tempo executamos todas as
atividades necessárias para desenvolver determinada funcionalidade. [FOWLER 2005]
Os projetos que mais fracassam utilizam o modelo de desenvolvimento em
cascata, onde passam se intervalos de tempo muito grandes (meses, anos) no
entendimento do sistema e quando de fato começam a ser construídos já perderam seu
valor, pois deixam de entregar aquilo que era importante, tinham valor. Essa situação
cria abertura para o negócio mudar e/ou as tecnologias ficarem obsoletas tornando assim
um risco para o projeto com tempos muito extensos. [COAD 1999]
Desenvolver produtos de software de forma a agregar valor cada vez mais eficaz
a quem os solicita, requer o uso de metodologias que têm como base os quatro
fundamentos de valorização:
“Indivíduos e interações mais que processos 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.”
[Agile Manifesto 2001]
Todas as metodologias tais como XP (Extreme Programming), Scrum, FDD
(Feature Driven Development), Crystal Clear, DSDM (Dynamic Systems Development
Method), AMDD (Agile Model Driven Development), Lean Software Development,
entre outros tem em sua essência os fundamentos acima.
Nesse artigo iremos falar sobre a FDD, que se constitui de uma metodologia de
desenvolvimento de software guiada por funcionalidades e que valoriza a parte de
modelagem como ponto essencial para se ter sucesso. O ponto aqui é realizar muito
desenho para que o problema seja entendido de forma bastante eficaz e mais condizente
com a realidade. Na FDD as funcionalidades são denominadas Features que é uma
funcionalidade que agrega valor ao cliente e que pode ser implementada em duas
semanas ou menos [COAD 1999]. Nesse artigo iremos apresentar sua história, as
principais práticas, princípios, valores, papéis e processos que a caracterizam.
2. História e Evolução
A FDD surgiu entre 1997 e 1999 a partir da experiência de análise e modelagem
orientada por objetos de Peter Coad e das técnicas de gerenciamento de projetos de Jeff
de Luca durante o desenvolvimento de software em um projeto Java para o United
Overseas Bank em Singapura.
1

3. Em 1999, a primeira versão oficial dos processos foi divulgada no capítulo 6 do
livro “Java Modeling in Color with UML” de Peter Coad, Eric Lefebvre e Jeff De Luca.
No ano de 2002, Stephen Palmer e John Mac Felsing, publicaram “A Pratical
Guide to Feature Driven Development.” Esse livro trouxe uma abordagem completa e
atualizada da metodologia tornando-se a literatura de referência.
Em 2003, a metodologia foi analisada por David Anderson em sua obra “Agile
Management for Software Engineering: Using the Theory of Constraints for Business
Results”.
3. Princípios e Valores
Apesar de a FDD ter surgido antes mesmo do manifesto ágil ser escrito, a mesma pode
ser considerada uma metodologia ágil por seus princípios. A metodologia tem em sua
essência resultados frequentes, tangíveis e funcionais [COAD 1999]. Abaixo a fala de
Peter Coad em sua obra:
“Feature-driven development is a process for helping teams produce frequent, tangible
working results.” [COAD 1999]
3.1 Prioriza o cliente
Dentro de um pequeno intervalo de tempo, duas semanas em geral, um conjunto de
características que possuem valor para o cliente é estudado e desenvolvido sendo
entregue funcionando ao cliente. Isso garante estabilidade e entrega contínua de novas
funcionalidades. [BARKER 2003]
“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua
de software de valor.” [Agile Manifesto 2001]
3.2 Adaptável a mudanças
A FDD possui natureza iterativa. Se na fase de modelagem uma área de risco é
identificada, onde os requisitos ainda não estão bem fundamentados ou até mesmo que
estejam previstos para mudar, a FDD permite que o isolamento dessa área seja feito
para garantir que o menor impacto ocorra quando a mudança acontecer. [BARKER
2003]
“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.” [Agile Manifesto 2001]
3.3 Priorizar a menor escala de tempo
A FDD utiliza um prazo de duas semanas. Em geral, a cada uma semana uma release é
entregue para a realização dos testes de sistema. [BARKER 2003]
“Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo.” [Agile Manifesto 2001]
3.4 Pessoas do Negócio e Desenvolvedores trabalham juntas
A FDD não obriga a presença diária do cliente. No entanto, prevê como obrigatória a
presença dos especialistas de domínio do cliente no processo de desenvolvimento do
modelo abrangente e da lista de features. Durante o processo de detalhamento e
2

4. construção, a presença do cliente se dá através de testes de sistema, feedback de
usabilidade, testes de performance, relatório de erros, etc. [BARKER 2003]
“Pessoas do negócio e desenvolvedores devem trabalhar diariamente juntos durante
todo o projeto.” [Agile Manifesto 2001]
3.5 Indivíduos Motivados
A FDD enfatiza a necessidade de utilização de ferramentas de suporte para garantir que
o ambiente de trabalho e a infraestrutura tenha todas as condições para se obter o
sucesso.O mecanismo da FDD proporciona desenvolvedores motivados pois, a cada
duas semanas eles tem coisas novas para se fazer. Pessoas de gestão sempre tem a
possibilidade de planejar faturamento do que foi feito. Clientes tem uma melhor
visibilidade do que está sendo realizado, onde o projeto está e de uma maneira que eles
entendem.
“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho” [Agile Manifesto 2001]
3.6 Comunicação Face a Face
Conforme já dito anteriormente a FDD proporciona momentos que enfatizam a
comunicação aberta.
“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através de conversa face a face” [Agile Manifesto 2001]
3.7 Medida do progresso
O fluxo de trabalhos dos times garante entrega ideal de funcionalidades. A FDD possui
ferramentas embutidas para permitir monitoração, medição eficaz e geração de
relatórios para acompanhamento do progresso pela gestão.
“Software funcionando é a medida primária do progresso” [Agile Manifesto 2001]
3.8 Desenvolvimento Sustentável
Os aspectos de ritmo de trabalho, contato com o cliente, entrega ideal continuamente já
citados garantem um desenvolvimento sustentável.
“Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um
ritmo constante indefinidamente.” [Agile Manifesto 2001]
3.9 Excelência Técnica
A FDD oferece grande ênfase à modelagem e ao desenho até uma qualidade essencial.
A excelência técnica é incentivada em todos os níveis.
“Contínua atenção a excelência técnica e bom design aumenta a agilidade.” [Agile
Manifesto 2001]
3.10 Simplicidade
Ao invés de incentivar um ciclo constante de refatoração, a FDD apóia a ideia de se
fazer bastante desenho de modo que a construção seja otimizada quando for iniciada.
“Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.”
[Agile Manifesto 2001]
3

5. 3.11 Equipes Auto-Organizáveis
As equipes de features tem provado ser altamente eficazes de várias maneiras. Elas
mantêm canais de comunicação a um nível mínimo, diminuindo elevados custos. É
centrada em uma pequena equipe ágil centrada em um conjunto de funcionalidades
relacionadas. Promove orientação para acelerar o aprendizado e otimiza seu fluxo de
trabalho. Está concentrada em oferecer qualidade através da requisição de inspeção de
desenho e de código.
“As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis”
[Agile Manifesto 2001]
3.12 Melhoria Contínua
Os checkpoints regulares garantem que o progresso e o desempenho são revisados.
Monitoração embutida identifica áreas de risco rapidamente e permitem que os mesmos
sejam mitigados de uma melhor maneira.
“Em intervalos regulares, o time reflete sobre como se tornar mais eficaz e então refina
e ajusta seu comportamento em conseqüência disso.” [Agile Manifesto 2001]
4. Práticas
4.1 Modelagem de Objetos de Domínio com cores
Essa prática fundamenta-se no desenho de diagrama de classes representando os objetos
significativos para o problema do domínio e suas relações [Palmer, Felsing 2002]. A
FDD utiliza a técnica de modelar usando as cores amarelo, rosa, azul e verde descrita
em Java modeling in Color with UML. [COAD 1999]
A modelagem de domínio permite que os membros da equipe compartilhem uma
visão comum sobre o sistema. [PALMER 2002]
O modelo deve ser baseado na visão de especialistas de domínio de forma que o
conhecimento necessário seja documentado e disseminado na equipe e sirva de base
para que novas funcionalidades possam ser acrescentadas a ele. [PALMER 2002]
4.2 Desenvolvimento por Features
Nessa prática temos a ação de dividir funcionalidades do sistema em pequenas partes
que podem ser implementadas em até duas semanas. Essas são escritas no seguinte
formato: <ação><resultado><objeto>. [PALMER 2002]
4.3 Propriedade de Código
A FDD utiliza propriedade única de código. A propriedade única garante a integridade
conceitual do modelo, velocidade na implementação de novas funcionalidades (o
desenvolvedor autor do código está mais familiarizado com aquele pedaço de código)
[PALMER 2002].
4.5 Times organizados por Features
Embora as classes não tenham propriedade coletiva, para desenvolver uma
funcionalidade normalmente existirá mais de uma classe envolvida e possivelmente
mais de um desenvolvedor. Em virtude disso, os times são formados conforme a
4

6. atribuição de propriedade das classes envolvidas na sua implementação [PALMER
2002].
4.5 Inspeções
A inspeção é feita visando eliminar erros e pode ser feita baseada em métricas de
código. Essa prática traz benefício uma vez que o desenvolvedor se sente motivado a
adotar boas práticas e padrões de codificação determinados pela empresa. [PALMER
2002].
4.6 Agendamento de Builds Regulares
Em intervalos regulares de tempo, o código das funcionalidades concluídas deve ser
integrado e realizado o build.
4.7 Relatar Progresso
A FDD possui mecanismos de gerar relatórios para reportar progresso à gestão e ao
cliente.
4.7 Gerenciamento de Configuração
O gerenciamento de configuração serve para controlar as versões e rastrear artefatos
[GOYAL 2008].
5. Papéis
A FDD possui seis papéis principais envolvidos no processo. São eles: Gerente de
Projetos, Arquiteto Chefe, Gerente de Desenvolvimento, Programador Chefe, Dono de
Classe e Especialistas de domínio. [GOYAL 2008]
O Gerente de projetos tem como atribuições relatar progresso, gerenciar
recursos, orçamento, etc. É um papel de caráter administrativo.
O Arquiteto chefe é responsável por desenhar um modelo geral do problema de
domínio e conduzir sessões de modelagem.
O Gerente de Desenvolvimento possui a tarefa de liderar de forma geral as
atividades de desenvolvimento e resolver conflitos entre programadores chefes. Esse
papel requer que a pessoa que o desempenhe tenha boas habilidades técnicas.
O Programador Chefe é um programador mais experiente que participa de
atividades relacionadas à modelagem e desenvolvimento da solução. Em geral lidera
outros programadores.
Dono de Classe: São membros do time de desenvolvimento que atuam sob a
liderança de programadores chefe que tem por funções modelar, codificar, testar e
documentar as funcionalidades para o novo sistema de software.
Especialistas de domínio: São usuários chaves, analistas de negócios,
patrocinadores ou profissionais com mais de uma função das já citadas. Profissionais
que ocupam esse papel são a principal fonte de conhecimento na qual os
desenvolvedores recorrem para melhor entendimento do problema a fim de realizar a
entrega correta do sistema solicitado. Esses são profundos conhecedores do negocio e
são indispensáveis para o sucesso do projeto. [GOYAL 2008]
5

7. Além dos papéis principais [GOYAL 2008] cita que durante a adoção da FDD
podemos nos deparar com outros sete papéis.
Language Guru que se caracteriza por ser especialista em uma linguagem ou
tecnologia e estará mais evidente nos projetos onde essa tecnologia ou linguagem for
utilizada pela primeira vez.
Build Engineer é responsável por rodar, configurar e dar manutenção no
processo de build.
Toolsmith: responsável por criar pequenas ferramentas de desenvolvimento para
as equipes de testes e conversão de dados.
System Administrator: Responsável por configurar, gerenciar, solucionar
problemas de todos os servidores e estações de trabalho específicas da equipe do
projeto.
6. Processos
Segundo a descrição oficial [COAD 1999], podemos utilizar o seguinte template para
escrever uma Feature: <ação> o <resultado> <de|para|por> um|a <objeto>.
Exemplo: Calcular o total de uma venda.
A FDD possui cinco processos que fazem parte de duas fases. A figura 1 ilustra
esse cenário.[Nebulon 2012]
Figura 1. Processos FDD
Para um melhor entendimento dos processos [Nebulon 2012], organizamos as
tarefas correspondentes aos processos nas tabelas 1, 2, 3, 4 e 5.
Tabela 1. Tarefas do Processo 1 - Desenvolver um Modelo Abrangente
Tarefa
Formar
a
equipe
modelagem
de
Conduzir um passo a passo
do domínio
Estudar documentos
Detalhamento
Forma - se a equipe por
especialistas de domínio e
alguns desenvolvedores
Um especialista de domínio
realiza uma explicação, visão
geral do que será modelado
Estudo opcional de documentos
de requisitos funcionais que
6
Responsável
Gerente de Projetos
Tipo
Obrigatório
Gerente de Projetos
Obrigatório
Equipe de Modelagem
Opcional

8. Desenvolver modelos em
pequenos grupos
Desenvolver um modelo do
time
Refinar o modelo geral de
objetos
Escrever
modelo
anotações
no
podem estar no formato de
casos de uso, modelo de dados,
guias de usuário, quaisquer
outros documentos que estejam
disponíveis e que auxiliem no
entendimento do problema
São formados grupos de até 3
componentes
que
geraram
modelos. Fica a cargo do
Arquiteto chefe propor ou não
um modelo base e modelos
alternativos
Da etapa anterior surge um
modelo do time
As iterações das tarefas
anteriores geram modelos para
atualizar o modelo geral
Anotações para referências
futuras são realizadas
Equipe de Modelagem
em pequenos grupos
Obrigatório
Equipe de Modelagem
Obrigatório
Arquiteto Chefe e
Equipe de Modelagem
Obrigatório
Arquiteto Chefe e
Programador Chefe
Obrigatório
Tabela 2. Tarefas do Processo 2 - Construir a Lista de Features
Tarefa
Formar a equipe da Lista de
Features
Construir a lista de Features
Detalhamento
Os principais programadores do
processo 1 compõe a equipe da
Lista de Features.
A lista é construída extraindo as
funcionalidades encontradas no
processo anterior e colocadas no
formato.
<ação><resultado><objeto>
Responsável
Gerente de Projetos e
Gerente de
Desenvolvimento
Equipe da lista de
Features
Tipo
Obrigatório
Obrigatório
Tabela 3. Tarefas do Processo 3 - Planejar por Feature
Tarefa
Formar
a
equipe
de
planejamento
Determinar a sequencia de
desenvolvimento
Atribuir um conjunto de
Features a programadores
chefes
Atribuir
classes
desenvolvedores
Detalhamento
Gerente de desenvolvimentos +
principais programadores
Levando – se em conta
dependência,
risco
e
complexidade a ordem de
execução é determinada.
Analisando dependência de
classes,
complexidade,
sequencia a lista é atribuída aos
programadores chefes.
Tipo
Obrigatório
Equipe de Planejamento
Obrigatório
Equipe de Planejamento
Obrigatório
Equipe de Planejamento
a
Responsável
Gerente de Projetos
Obrigatório
Tabela 4. Tarefas do Processo 4 - Detalhar por Feature
Tarefa
Formar a equipe de Feature
Conduzir um estudo sobre o
domínio de negocio
Detalhamento
O Programador chefe identifica
as classes envolvidas em sua
lista
e
seus
respectivos
programadores responsáveis e
forma sua equipe
O especialista de domínio
conduz um estudo sobre o que
vai ser implementado
7
Responsável
Programador Chefe
Tipo
Obrigatório
Especialista de Domínio
Opcional

9. Estudar documentos de
referência
Refinar o modelo de objetos
Escrever classes e métodos
iniciais
Fazer o projeto de inspeção
A
equipe
estuda
a
documentação de apoio
O programador chefe refina o
modelo para adicionar classes,
métodos, atributos e cria
diagramas que são submetidos
ao controle de versão.
Usando o modelo refinado da
etapa anterior, o desenvolvedor
grava suas classes, métodos,
atributos
iniciais
e
o
programador chefe gera a
documentação da API e
submete a publicação na
intranet do projeto.
É realizada a inspeção e as
alterações são submetidas a um
controle de mudanças.
Equipe de Feature
Opcional
Programador Chefe
Obrigatório
Equipe de Feature
Obrigatório
Equipe de Feature
Obrigatório
Tabela 5. Tarefas do Processo 5 - Construir por Feature
Tarefa
Implementar
classes
métodos
e
Conduzir uma inspeção de
código
Fazer Testes Unitários
Promover versão para build
Detalhamento
O desenvolvedor implementa o
que é necessário para sua
feature.
Realiza-se uma nova inspeção.
Responsável
Equipe de Feature
Tipo
Obrigatório
Equipe de Feature
Obrigatório
O dono da classe realiza testes
unitários.
Depois de inspecionado e
testado o código é promovido
para o build.
Equipe de Feature
Obrigatório
Equipe de Feature e
Programador Chefe
Obrigatório
7. Conclusão
Após a análise e levantamento dos principais pontos da metodologia Feature Driven
Development, pode-se dizer que a mesma é aplicável para projetos de pequeno, médio e
grande porte. Demonstra ser uma solução viável para aquelas organizações que não
dispõe de facilidade de se manter o cliente sempre por perto como requer, por exemplo,
o XP.
A FDD parece amenizar ou resolver impasses entre desenvolvedores e gerentes
e também entre cliente e equipe contratada para desenvolvimento de algum produto. A
natureza iterativa, com momentos que incentivam a transparência e a comunicação
levam a um melhor relacionamento entre os envolvidos em todo o processo.
Pode-se dizer que parece ser bastante razoável de ser implementada naquelas
organizações onde se percebe um caráter bastante conservador, com papéis e
responsabilidades bastante definidas.
O motivo pelo qual leva ainda muitos projetos serem desenvolvidos utilizando o
modelo cascata que é tentar ter-se uma melhor previsibilidade do andamento das
atividades pode ser resolvido com todos os recursos que a FDD propõe de relatórios de
fácil entendimento para a gestão e para o cliente. Esses recursos deixam muito
transparentes os pontos onde se tem “gaps” ou onde tudo ocorre conforme esperado.
8

10. Um ponto que parece ser negativo em algum dado momento é o fato da
propriedade única de código. Essa questão se utilizada com muito rigor não se
permitindo a quebra dessa regra, pode levar até a paralisia nas atividades impactando o
bom andamento do projeto.
Para concluir a FDD é uma boa opção para se introduzir metodologias ágeis por
todos os seus aspectos que não levam nenhuma questão ao extremo e ainda garante um
alto nível de qualidade na entrega de novos produtos de software.
Referências
COAD, Peter, LEFEBVRE, Eric, DE LUCCA, Jeff. “Java modeling in Color with
UML”, Prentice Hall PTR, 1999
Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software. Disponível
em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 14 de abril de 2013.
Nebulon PTy Ltd (2012). Consultoria de Jeff De Luca. Disponível em:
<http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf>. Acesso em: 28
de abril de 2013
BARKER, Gavin(2003). The Agile Umbrella. Feature Driven Development. Disponível
em: <http://www.featuredrivendevelopment.com/node/531>. Acesso em: 14 abril 2013.
PALMER , Stephen R.; FELSING, John M. “A Practical Guide to Feature-Driven
Development”, Prentice-Hall, 2002, p.35-54.
GOYAL, Sadhna. Major Seminar On Feature Driven Development Agile Techniques
for Project Management and Software Engineering. Munich, 2008. Disponível em:
<http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf>. Acesso em: 22 abril
2013
FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005
9