FDD (Feature-driven development)
Desenvolvimento Orientado a Funcionalidades
Isabel Xavier / Rafael Barbosa
Engenharia de Software – FA7
O estado atual dos projetos




Planejamento pobre ou incompleto
Falta de entendimento das questões de negócio ou
técnico
Falha em não colocar as necessidades dos clientes
ou dos usuários finais em primeiro lugar
Estouro de cronograma, e entrega de produtos
indesejáveis
O que é?

Feature Driven Development
(Desenvolvimento Guiado por Funcionalidades):É uma
metodologia ágil para gerenciamento e desenvolvimento
de software. Ela combina as melhores práticas do
gerenciamento ágil de projetos com uma abordagem
completa para Engenharia de Software orientada
por objetos.
O que é Feature?

Funcionalidade
É uma funcionalidade para o detalhamento e uma
característica pequena para ser implementada,
no máximo em uma iteração, oferecendo assim o
valor ao cliente
<ação><resultado><objeto>
História da FDD

FDD foi criado em 1997 num grande projeto em Java
para o United Overseas Bank, em Singapura.

Nasceu a partir da experiência de análise e
modelagem orientadas por objetos de Peter Coad e de
gerenciamento de projetos por Jeff de Luca.
Jeff de Luca
Peter Coad
Introduzido aqui...

Primeira publicação em 1999, no do livro Java Modeling in
Color with UML, de Peter Coad, Eric Lefebvre e Jeff De Luca;
Expandido aqui...


Em 2002, Stephen Palmer
Mac Felsing publicaram o
Pratical Guide to Feature
Development,
com
a
completa;
e John
livro A
Driven
versão
Em 2003, David Anderson, o livro
Agile Management for Software
Engineering: Using the Theory of
Constraints for Business Results,
considerado por muitos como um
marco na literatura ágil.
Por que usar?



Clientes têm resultados rápidos e relatório
do status numa linguagem que eles
entendem
Gerentes de projeto têm uma visão
completa e exata do status do projeto
Desenvolvedores conseguem trabalhar em
novas coisas em poucos dias e ficam mais
envolvidos em análise, projeto e codificação
Caracteristicas da FDD

A FDD chama a atenção por algumas características peculiares:
 Resultados úteis a cada duas semanas ou menos
 Blocos bem pequenos de funcionalidade valorizada pelo
cliente,chamados "Features“
 Não existem restrições quanto à complexidade do sistema e
tamanho da equipe
 Planejamento detalhado e guia para medição
 Rastreabilidade e relatórios com precisão
 Monitoramento detalhado dentro do projeto, com resumos de
alto nível para clientes e gerentes, tudo em termos de negócio
 Fornece uma forma de saber, dentro dos primeiros 10% de um
projeto, se o plano e a estimativa são sólidos
Práticas

Modelagem de objetos de domínio



Desenvolver por funcionalidade(feature)




Formação de equipes pequenas e dinâmicas.
Inspeção (Inspection)
Uso dos melhores métodos conhecidos de detecção de erros.
Releases freqüentes


Cada classe possui um único desenvolvedor responsável
Equipe de funcionalidades


Desenvolvimento e acompanhamento do progresso através de da lista de
funcionalidades.
Proprietários de classes individuais


Exploração e explicação do problema do domínio
Resulta em um framework
Garantir que existe um sistema sempre disponível e demonstrável.
Administração de Configuração

Habilita acompanhamento do histórico do código-fonte.
Papeis

Principais
•
•
•
•
•
•
•

De apoio
•
•
•
•
•

Gerente de projeto (Project Manager)
Arquiteto líder (Chief architect)
Gerente de desenvolvimento (Development Manager)
Programador líder (Chief programmer)
Proprietário de classe (Class owner)
Especialista do domínio (Domain experts)
Gerente do domínio (Domain manager)
Gerente de versão (Release manager)
Guru de linguagem (Language lawyer/language guru)
Engenheiro de construção (Build engineer)
“Ferramenteiro” (Toolsmith)
Administrador de sistemas (System Administrator)
Adicionais
• Testadores (Testers)
• Instaladores (Deployers)
• Escritores técnicos (Technical writes)
Papeis
Suporte Documentador
Testador
Gestor de projeto
Adm. de sistemas
Eng. de builds
Gestor de
desenvolvimento
Chefe de design
CLIENTE
Programador
chefe
Dono de classe
Guru de
linguagem
Gestor de
atividade
Especialista
Papéis:
Primário
Secundário
Adicionais
Fases do FDD
A FDD é uma metodologia muito objetiva. Possui apenas duas fases:
Concepção & Planejamento: Pensar um pouco
antes de fazer (tipicamente de 1 a 2 semanas);
Construção: Fazer de forma iterativa
(tipicamente em iterações de 2 semanas).
Fases do FDD

Concepção & Planejamento
Desenvolver um modelo abrangente
 Construir a lista de funcionalidades
 Planejar por funcionalidade


Construção
Detalhar por funcionalidade
 Construir por funcionalidade

Fases do FDD
Fases do FDD - Concepção & Planejamento

Desenvolver modelo abrangente







Formar o time de modelagem.
Conduzir o Domain Walkthrough.
Estudar documentação.
Desenvolver modelos de pequenos grupos.
Desenvolver modelo da equipe.
Refinar o Modelo Abrangente.
Escrever Notas.
O Modelo de Domínio Criado Será decomposto por 3 camadas:



Área de Negócio.
Atividade de Negócio.
Automatização da Atividade (Funcionalidade).
Fases do FDD - Concepção & Planejamento

Construir a lista de funcionalidades
 Construção de uma lista de funcionalidades
importantes para o cliente onde a lista
representara o produto final a ser desenvolvido,
podendo ser necessário a inclusão de novas
funcionalidades no modelo de domínio a cada
iteração.
Fases do FDD - Concepção & Planejamento

Planejar por funcionalidade



Determinar a seqüência do desenvolvimento .
Atribuir atividades de Negócio aos
Programadores-chefes.
Atribuir Classes aos Desenvolvedores.
Fases do FDD – Construção

Detalhar por funcionalidade
 Já dentro de uma iteração de construção, a
equipe detalha os requisitos e outros artefatos
para a codificação de cada funcionalidade,
incluindo os testes. O projeto para as
funcionalidades é inspecionado e o modelo
abrangente é atualizado. O resultado é o modelo
de domínio mais detalhado e os esqueletos de
código como declaração de métodos, tipagem,
atributos e parâmetros prontos para serem
preenchidos.
Fases do FDD – Construção

Construir por funcionalidade
 Cada esqueleto de código é preenchido, testado
e inspecionado de acordo com o modelo
abrangente. O resultado é um incremento do
produto integrado ao repositório principal do
código após ter sido devidamente testado por um
outro membro da equipe se necessário, com
qualidade e potencial para ser usado pelo cliente.
Vantagens e Desvantagens


Vantagens
 Recomendado para qualquer tipo de desenvolvimento;
 Foco em “características de valor para o cliente”;
 FDD prioriza aquilo que o cliente prioriza;
 FDD possui requisitos mais formais;
 Seus princípios e práticas proporcionam um equilíbrio entre
as filosofias tradicionais e as mais extremas,
proporcionando uma transição mais suave para
organizações mais conservadoras;
Desvantagens


Ainda existem questionamento sobre a eficácia / aplicabilidade de
FDD;
Controvérsias sobre o tamanho mínimo de um time FDD;
Conclusão




É um método ágil e altamente adaptativo;
Oferece vantagens dos métodos pesados;
Oferece vantagens dos métodos extremamente ágeis;
É orientada às necessidades dos clientes,gerentes e
desenvolvedores;
Bibliografia





Heptagon: <http://www.heptagon.com.br/fdd>
FDD numa casca de banana. Um guia de rápido aprendizado para a Feature –
Driven Development de Alexandre Magno-mar.2007. Disponível em:
<http://pt.scribd.com/doc/34365766/FDD-em-Uma-Casca-de-Banana >
FDD – Feature Driven Development: <http://pt.scribd.com/doc/37146865/FDDCompleto>
FDD – Um método ágil e eficiente: < http://imasters.com.br/artigo/13370/agile/fddum-metodo-agil-e-eficiente>
FDD – Feature Driven Development: http://www2.dc.uel.br/~rlarruda/trab/fdd.pdf