FDD

em uma casca de banana

Um guia de rpido aprendizado para a

Feature-Driven Development

mar.2007

aXmagno
www.axmagno.com

O que FDD?
Feature-Driven Development (FDD) uma metodologia gil para o
processo de engenharia de software, que foi elaborada com foco na
entrega frequente de software funcionando para os clientes e na
utilizao de boas prticas durante o ciclo de seu desenvolvimento.
Uma caracterstica marcante da FDD o fato dela
favorecer fortemente o envolvimento de clientes (interno
ou externo) ao processo de planejamento e
desenvolvimento do software.

Feature-Driven Development (FDD) um processo de

desenvolvimento de software iterativo e incremental.
Diferentemente de outras metodologias, a FDD no
extremamente focada na programao ou no modelo, mas sim
utiliza o bom senso para abstrair o melhor dos dois mundos.

O que no FDD?
A FDD no uma metodologia descrita em uma coleo com
30(trinta) volumes de livros. Portanto, ela no uma bblia a
ser seguida por sua equipe de desenvolvimento.
A FDD no uma metodologia de gerenciamento de
projetos de software. Apesar de, em suas prticas, existirem
atividades relacionadas a esse fim, a FDD tem como principal foco
cobrir o processo da engenharia de software, e no do
gerenciamento.

A FDD no uma bala de prata, portanto, ela no resolver

todos os problemas do mundo, ou mesmo os da sua
empresa. No entanto, a FDD o auxiliar a tornar o processo de
engenharia de software da sua empresa mais eficiente, e a criar
em sua equipe uma cultura voltada rpida entrega de software
para o cliente.

Por que devo

usar FDD?
Porque em projetos de software precisamos
mais do que apenas cdigo escrito e funcionando.
Porque a FDD oferece planejamento e modelo na
medida certa! Sem exageros, mas tambm sem ausncia.

Porque os processos da FDD favorecem a

aproximao de especialistas de negcio, gerentes e
desenvolvedores.
Porque FDD gil, e nos permite realizar entregas
frequentes aos nossos clientes.
Porque decompondo o produto em funcionalidades
estou mais prximo de estar sempre entregando algo
de valor para o meu cliente.
Porque utilizando a prtica de proprietrios de classes,
garanto a responsabilidade, especialidade e familiaridade dos
desenvolvedores com determinado pedao de cdigo.
Com isso, tenho sempre manuteno rpida e de qualidade
em qualquer parte do meu sistema.
Porque os mecanismos de visualizao de
progresso da FDD, tais como o Parking Lot,
nos permitem ter, a qualquer momento, uma
visualizao exata de onde estamos.
Porque as prticas da FDD contribuem para
um grande envolvimento do cliente no projeto, fazendo
com que, rapidamente, este passe a chamar o seu
projeto de NOSSO PROJETO.
Porque a inspeo de cdigo e de design, que uma das
prticas da FDD, nos garante qualidade no produto final.
Porque FDD funciona!

Quem quem?
Ol! Eu sou a Gerente do Projeto, e
como tal sou responsvel por todos os
assuntos administrativos do projeto, o que
inclui o gerenciamento de recursos,
oramento, equipamentos e outros. Minha
principal meta fornecer subsdios para
que nenhum fator externo atrapalhe a
produtividade da equipe do projeto.

Como Especialista do negcio uso meu

conhecimento no negcio para apresentar
equipe do projeto as necessidades para
que o software possua valor real para ns.
Estou sempre disponvel para fornecer aos
desenvolvedores maior detalhamento
sobre determinada funcionalidade. Sou um
membro fixo da equipe e sempre estou
fornecendo feedback das entregas para
todos os envolvidos.

Por possuir bastante experincia tcnica

em modelagem orientada a objetos, e
habilidade para atuar como facilitador na
absoro das regras de negcio, fui
escolhido para ser Arquiteto deste
projeto. Serei, portanto, responsvel pela
ltima palavra em toda arquitetura do
sistema.

Como Gerente de Desenvolvimento,

sou responsvel por liderar o dia-a-dia do
desenvolvimento do produto. Por ser o
responsvel por resolver qualquer conflito
tcnico que exista entre programadoreschefes, preciso possuir boa experincia no
desenvolvimento de software e nas
tecnologias que estaro sendo utilizadas
no projeto.

Sou um dos Programadores-chefes da

nossa equipe e sou responsvel por liderar
pequenos grupos de desenvolvedores
durante a construo das funcionalidades
do produto. Tambm atuo como
desenvolvedor e, normalmente, atribuda
a mim a propriedade das classes mais
complexas do sistema. Possuo, ainda,
papel fundamental nas fases de absoro
do conhecimento de negcio e no
planejamento das funcionalidades.

Eu sou programadora (class-owner) e

sempre estou compondo pequenas
equipes de funcionalidades nas quais
programo, diagramo, testo e documento as
funcionalidades a mim atribudas pelo
Programador-chefe da equipe.

A FDD fo rne ce , a ind a , p a ra a q ue le s p ro je to s ma io re s e /o u ma is co mp le xo s,

papis auxiliares , ta is co mo : Ge re nte d e R e le a se , Testadores , Escrito re s
t cnico s, Guru d a ling ua g e m, Ad ministra d o r d e Siste ma , Imp la nta d o re s e o u tro s .

O que feature?
Features(funcionalidades) so expresses granulares que
representem algum valor para o cliente.
Funcionalidades so nomeadas atravs do uso do template

<ao><resultado><objeto>

Alguns exemplos de funcionalidades:

Calcular o desconto de uma venda
Listar os clientes ativos de uma empresa
Destacar os clientes devedores de uma empresa
Imprimir a nota fiscal de uma venda
Validar a senha de um usurio
Enviar e-mail com os resultados mensais de uma empresa
Uma funcionalidade deve ter uma granularidade que no
ultrapasse o tamanho de sua iterao. Por exemplo,
se foi definido que o projeto ter iteraes de
2(duas) semanas, voc no deve possuir
funcionalidades que ultrapassem esse tamanho(tempo).
Quando isso acontecer, voc deve procurar
decomp-la em mais features.

um conjunto de funcionalidades que

voc entregar para seu cliente ao final de
uma iterao(ou release), portanto, no
economize tempo, ateno e criatividade
no processo de definio das mesmas.

O ciclo de vida
da FDD
O ciclo de vida da FDD composto de 05(cinco)
prticas. So elas:
1. Desenvolver um modelo abrangente

Este processo abrange todo o projeto, o que significa

que ele ser executado uma nica vez no
projeto.
Formar o time de modelagem: este time
normalmente composto por especialistas de
negcio e programadores, sendo facilitados por um
arquiteto com experincia em modelagem.
Conduzir o Domain Walkthrough(Estudo dirigido
sobre o domnio): os especialistas de negcio
apresentaro ao restante da equipe uma viso do
produto. Aps isso, realizaro apresentaes
focadas em pequenas partes do negcio.
Estudar documentao: Dependendo da
complexidade da rea de negcio apresentada, a
equipe pode solicitar um intervalo para estudar a
documentao fornecida pelo especialista de
negcio.
Desenvolver modelos de pequenos grupos: aps
cada apresentao(ou estudo), a equipe dividida
em pequenos grupos, que elaboraro uma proposta
de modelo(sem detalhamento) para aquela parte
especfica do negcio que foi apresentada.
Desenvolver o modelo da equipe: as propostas so
apresentadas e uma delas, ou uma combinao
delas, escolhida por consenso para ser o modelo
para aquela parte do negcio apresentada.
Refinar o modelo abrangente: o modelo escolhido
incluso no modelo abrangente do produto. Este
modelo abrangente o resultado da juno de
todos os modelos escolhidos para cada parte do
negcio apresentada.
Escrever notas: notas e observaes so includas
no modelo abrangente.
As atividades vo se repetindo at que tenhamos um
modelo abrangente que cubra todas as partes de
negcio previstas para o produto(ou release).

2. Construir a lista de funcionalidades

Este processo abrange todo o projeto, o que significa

que ele ser executado uma nica vez no
projeto.

Formar o time da lista de funcionalidades:

normalmente, este time composto unicamente
pelos programadores-chefes que participaram do
processo anterior.

Construir a lista de funcionalidades: as partes do

produto, que foram identificadas e modeladas no
processo anterior, so aqui identificadas como
reas de negcio. Dentro de cada rea de

negcio, o time deve conseguir identificar as atividades de negcio daquela rea

especfica e, dentro destas atividades, as funcionalidades que a compem.

3. Planejar por funcionalidades

Este processo abrange todo o projeto, o que significa que ele ser executado uma
nica vez no projeto.
Formar o time de planejamento: normalmente este time composto pelo gerente de
projeto, gerente de desenvolvimento e programadores-chefes.
Determinar a sequncia do desenvolvimento: o time determina a seqncia do
desenvolvimento baseando-se nas dependncias entre elas, na carga de trabalho da
equipe de desenvolvimento e tambm na complexidade das funcionalidades a serem
implementadas.
Atribuir atividades de negcio aos programadores-chefes: cada programador-chefe fica
responsvel por um conjunto de atividades de negcio. Ele ser o programador-chefe
de todas as funcionalidades que compem suas atividades.
Atribuir classes aos desenvolvedores: cada classe passar a ter um dono. Este
dono, que um programador, ser o responsvel por qualquer manuteno
necessria naquela classe. As classes so distribudas pelo time levando em
considerao a experincia, carga e sequncia de trabalho de cada desenvolvedor.

4. Detalhar por funcionalidade

Este processo ser executado uma vez para cada funcionalidade.

Formar a(s) equipe(s) de funcionalidades: sabendo quais as classes que sero
envolvidas no desenvolvimento de determinada funcionalidade, o programador-chefe
convoca os desenvolvedores responsveis por cada classe envolvida para fazer parte
da equipe.
Conduzir Domain Walkthrough(Estudo dirigido sobre o domnio): dependendo do nvel
de complexidade da funcionalidade e de quo clara ela est para a equipe, o
programador-chefe pode convocar um especialista de negcio para promover uma
apresentao detalhada daquela funcionalidade para a equipe.
Estudar documentao relacionada: ainda dependendo do nvel de entendimento do
time, pode ser reservado um perodo para ser estudada documentao de negcio e
anotaes relacionadas quela funcionalidade.
Desenvolver diagrama(s) de sequncia: o time desenvolve o(s) diagrama(s) de
sequncia relacionado(s) quela funcionalidade.
Refinar o modelo abrangente: j com um maior entendimento do negcio, o time se
sente seguro em refinar o modelo abrangente, incluindo mtodos e atributos nas
classes envolvidas no desenvolvimento da funcionalidade.
Escrever prlogo de mtodos e classes: Com as informaes geradas pelo(s)
diagrama(s) de sequncia, cada programador responsvel por criar os prlogos de
suas classes. Isto inclui cabealhos de mtodos com tipagem de parmetros, atributos e
outros. Vale lembrar que apenas os prlogos so criados aqui, nada de
implementao deve ser realizado.
Inspeo de design: o programador-chefe da funcionalidade deve convidar algum outro
membro do time do projeto para avaliar o que foi feito em sua classe durante este
processo.

5. Desenvolver por funcionalidade

Este processo ser executado uma vez para cada funcionalidade.
Implementar classes e mtodos: cada desenvolvedor implementa suas classes e
mtodos de acordo com a viso abrangente e detalhamento realizados nos processos
anteriores.

Inspecionar cdigo: cada desenvolvedor deve convidar algum outro membro do time(da
funcionalidade ou do projeto) para avaliar o que foi feito em sua classe durante este
processo.

Teste unitrio: cada desenvolvedor responsvel por executar os testes de unidade nos
mtodos de suas classes para garantir o alcance das necessidades do negcio.

Promover a build: estando a classe inspecionada e testada, ela ento pode ser
promovida a build.

A empresa, o projeto.

Um projeto

A Equipe de Tecnologia da UNITY EVENTOS precisa iniciar

um projeto para o desenvolvimento de um sistema que
gerencie o processo de realizao e inscrio em eventos
realizados pela empresa.
A equipe optou por utilizar a FDD como metodologia,
juntamente com o ferramental de desenvolvimento j
utilizado pela empresa: Delphi, Together e SQL Server.

O time.
unitYeventos

unitYeventos

unitYeventos

Mnica Silva

Joo Marcos

Thomz Bin

GERENTE DE PROJETO

ESPECIALISTA DE
NEGCIO

ARQUITETO

unitYeventos

unitYeventos

unitYeventos

Paulo Martins

Carlos Jnior

Paula Pimenta

GERENTE DE DESENV.
/ PROG. CHEFE

PROG. CHEFE

PROGRAMADORA

unitYeventos

unitYeventos

unitYeventos

Raimunda Lins

Jos Pintado

ESPECIALISTA DE
NEGCIO

PROGRAMADOR

Thiago Pires
PROGRAMADOR

Processo 1: Desenvolver um modelo

abrangente

Formar o time de modelagem

Como nossa equipe pequena, acredito que

possa ser interessante que nosso time de
modelagem seja composto por todos os
membros do projeto.

Mnica Silva
GERENTE DE PROJETO

Conduzir o Domain Walkthrough

Raimunda Lins
ESPECIALISTA DE
NEGCIO

O processo de organizao de um evento

sobre o qual explanarei aqui basicamente
composto das seguintes etapas: primeiramente
definimos o tema e perodo do evento, aps isso
realizamos uma tomada de preo em centro de
convenes e hotis que possuam auditrio com
a capacidade necessria para o evento. A lista de
auditrios candidatos realizada a partir de
contatos anteriores e lista de pginas amarelas...
<< continua explanao >>

Estudar documentao

Thomz Bin
ARQUITETO

Pessoal, como todos decidimos que a equipe

necessita de um maior aprofundamento no
assunto explanado pela Raimunda, realizaremos
uma pausa de 45 minutos para estudarmos a
documentao por ela entregue. Vocs podem
realizar este estudo aqui mesmo ou em suas
mesas, como preferirem. Portanto, s 15:45
retornaremos para iniciarmos o desenvolvimento
do modelo.

Desenvolver modelos de pequenos grupos

Agora, com um conhecimento mais abrangente

sobre a organizao de um evento, vamos nos
dividir em grupos para a elaborao de propostas
para um modelo do que foi exposto, seguindo o
uso da UML em cores. Para isto importante que
cada equipe possua programador(es) e
especialistas de negcio.

Equipe A

Equipe B

Paulo Martins
GERENTE DE DESENV.
/ PROG. CHEFE

Joo Marcos
ESPECIALISTA DE
NEGCIO

Paula Pimenta
PROGRAMADORA

Thiago Pires
PROGRAMADOR

Carlos Jnior
PROG. CHEFE

Jos Pintado
PROGRAMADOR

Esta a nossa proposta de

modelo para a rea de
organizao de eventos...
<<detalhamento >>

Paulo Martins
GERENTE DE DESENV.
/ PROG. CHEFE

Raimunda Lins
ESPECIALISTA DE
NEGCIO

Vejamos agora o nosso modelo...<<detalhamento >>

Jos Pintado
PROGRAMADOR

Bom pessoal, olhando o que cada um dos modelos

tinha de bom, e com algumas sugestes minhas, temos
aqui o nosso modelo para o processo de organizao
de eventos da Unity.

Thomz Bin
ARQUITETO

Refinar o modelo abrangente

Aps a explanao de outras reas de negcio, tais como inscrio de
congressistas no evento e recrutamento de palestrantes, o modelo
abrangente final foi o seguinte:

Processo 2: Construir a lista de funcionalidades

Formar o time da lista de funcionalidades

Mnica Silva
GERENTE DE PROJETO

Paulo Martins
GERENTE DE DESENV.
/ PROG. CHEFE

O time da Lista de Funcionalidades ser

composto pelos dois Programadores-Chefes
presentes no primeiro processo.

Construir a lista de funcionalidades

Carlos Jnior
PROG. CHEFE

Paulo, nessa fase precisaremos identificar

o conjunto de funcionalidades usando o
conhecimento adquirido na Fase 1.
Precisaremos identificar as reas de
Negcio apresentadas. Depois estas
reas sero decompostas em reas de
atividades de negcio, que, por sua
vez, sero decompostas em
funcionalidade. Estas funcionalidades
so granulares e criadas a partir do
template:

Paulo Martins
GERENTE DE DESENV.
/ PROG. CHEFE

<ao> <resultado> <objeto>

Processo 3: Planejar por funcionalidades

Formar o time de planejamento

O time de Planejamento ser formado pelo
gerente de desenvolvimento, pelos
programadores-chefes e pelo cliente
(interno ou externo).
Paulo Martins
GERENTE DE DESENV.
/ PROG. CHEFE

Determinar a sequncia do desenvolvimento

Esta sequncia baseada em:
- Dependncia entre as funcionalidades em termos de classes
envolvidas;
- Distribuio de carga de trabalho entre os proprietrios das
classes;
- Complexidade das funcionalidades a serem implementadas;
- Adiantamento das atividades de negcio de alto risco ou
complexidades;
- Prioridade do cliente;

Raimunda Lins
ESPECIALISTA DE
NEGCIO

Eu preciso que a parte de organizao do

evento esteja disponvel o quanto antes,
sendo que a montagem da grade de
palestras pode ficar mais para frente. Outra
atividade que tambm de extrema
importncia a de inscrio dos
congressistas, pois assim que a
organizao do evento tiver sido finalizada,
iniciaremos as inscries.
Carlos Jnior
PROG. CHEFE

Ok! Baseando-se ento nesta sua priorizao,

analisaremos a dependncia das classes,
carga de trabalho e complexidade, para
definirmos a sequncia de desenvolvimento.

Atribuir atividades de negcio aos programadoreschefes

Atribuir classes aos programadores

Processo 4: Detalhar por funcionalidade

Formar o time da funcionalidade

O time da funcionalidade Registra informaes de
um auditrio ser composto por:

Carlos Jnior
PROG. CHEFE

Thiago Pires

Jos Pintado

PROGRAMADOR

PROGRAMADOR

Como Carlos chegou a esses nomes para o time desta

funcionalidade? Simples! Verificando as classes que seriam
envolvidas na funcionalidade e verificando seus respectivos
proprietrios.

Conduzir o Domain Walkthrough

O Especialista do Negcio apresenta ao time da funcionalidade, uma

viso mais detalhada da rea de domnio a ser projetada.

<< detalhes sobre

registrar informaes
de um auditrio >>
Raimunda Lins
ESPECIALISTA DE
NEGCIO

Thiago Pires

Jos Pintado

PROGRAMADOR

PROGRAMADOR

Estudar documentao relacionada

A equipe da funcionalidade estuda o(s) documento(s) de referncia.
Desenhos de telas, memorandos, especificaes de interface, e qualquer
outra documentao considerada importante para um bom
planejamento da funcionalidade.

Desenvolver diagrama(s) de sequncia(s)

Refinar o modelo abrangente

Escrever prlogo de mtodos e classes

Inspeo de design

Carlos Jnior
PROG. CHEFE

Paula, voc poderia por favor

realizar a inspeo de design
da feature Registrar
Informaes de um
Auditrio?

Paula Pimenta
PROGRAMADORA

Processo 5: Desenvolver por funcionalidade

O time da funcionalidade mantido para agora, aps detalhar e
planejar o seu desenvolvimento, partir para a sua codificao.

Implementar classes e mtodos

Os proprietrios de classes implementam os tens necessrios para

satisfazer os requisitos de suas classes para esta funcionalidade.

Thiago Pires
PROGRAMADOR

Teste de unidade
Utilizando recurso da prpria ferramenta de desenvolvimento adotada, o
time realiza teste de unidade em todos os mtodos implementados para
esta funcionalidade. A poltica de teste de unidade, ou seja, por quem
ser realizado e em que exato momento, deve ser definida pelo
programador-chefe da funcionalidade.

Carlos Jnior
PROG. CHEFE

Inspecionar cdigo
Seguindo o mesmo mecanismo utilizado na inspeo de design, o
programador-chefe solicita que um outro programador, ou mesmo um
outro programador-chefe, inspecione todo o cdigo implementado para
esta funcionalidade.

Promover a build

Carlos Jnior

Este o momento de
integrar todas as classes e
mtodos desenvolvidos para
esta funcionalidade.

PROG. CHEFE

DONE!
Jos Pintado

Thiago Pires

PROGRAMADOR

PROGRAMADOR

Visibilidade gerencial

Mnica Silva
GERENTE DE PROJETO

Durante todos os releases e iteraes do projeto,

eu, como gerente de projeto, tenho que possuir
mecanismos para visualizar o andamento das
atividades, ou melhor, das funcionalidades. Consigo
isto atravs do Parking Lot, um dos principais
grficos gerenciais da FDD.

Seqncia do projeto
Aps a promoo a build de uma funcionalidade(ou pacote de
funcionalidades), os processos 4 e 5 vo sendo repetidos para cada
nova funcionalidade(ou pacote) prevista para a iterao corrente.
Ao final de cada iterao, a lista de funcionalidades(backlog) deve
ser revisada, quando ento podero ser adicionadas ou removidas
novas funcionalidades na lista.

Dvidas freqentes
Existem ferramentas disponveis para FDD?
Sim, existem vrias ferramentas especficas para o uso dos processos da FDD,
dentre elas podemos citar: FDDTracker(www.fddtracker.com) e
FDDTools(fddtools.sourceforge.net) como as principais, sendo que a primeira
ideal para quem precisa de uma ferramenta mais abrangente, e a segunda
para quem quer apenas controlar as funcionalidades do projeto e visualiz-las
atravs do Parking Lot. Ferramentas de grandes fornecedores, como o Caliber
da Borland e o RequisitePro da IBM/Rational, tambm suportam as
funcionalidades da FDD, mas sem seus recursos especficos. J o Visual Studio
Team System, da Microsoft, possui um plug-in especfico para FDD que foi
desenvolvido por uma empresa indiana chamada Cognizant
(www.cognizant.com).
Vale ainda frisar que, com simples planilhas eletrnicas ou mesmo post-its,
voc consegue sem muitas complicaes montar um ambiente para completo
acompanhamento de projetos FDD.
Posso utilizar FDD em conjunto com outra metodologia?
O uso da FDD em conjunto com alguma metodologia de gerenciamento de
projeto muito comum. Como exemplo podemos citar a dobrinha
Scrum/FDD que, sendo bem planejada, pode ser de grande valia para seus
projetos de software.
Na FDD, como tratado o processo de levantamento de requisitos?
A FDD pressupe que, ao entrar na fase de desenvolvimento do modelo
abrangente, voc j tenha em mos os requisitos do seu projeto, sejam eles
use-cases, storys ou qualquer outra coisa. Portanto, a FDD considera que o
processo de levantamento de requisitos deva ser executado antes de voc
entrar nas prticas de engenharia, ou seja, antes de entrar na FDD. No post
FDD e requisitos (www.axmagno.com) comento mais sobre este assunto.
Posso utilizar FDD em projetos relacionais, ou seja, sem nenhum uso
de orientao a objetos?
Apesar da documentao da FDD ser sempre recheada das palavras classes,
objetos e diagramas, nada nos impede de utiliz-la em projetos
relacionais/procedurais. Uma vez que voc considere o modelo abrangente da
Fase 1 como um MER ao invs de um diagrama de classes, todas as prticas
seguintes sero aplicadas a ele. David Anderson fala sobre um projeto
relacional onde aplicou FDD no post FDD in non-OO projects em
www.agilemanagement.net. Em breve devo estar escrevendo algo sobre a
minha experincia neste tipo de projeto aqui mesmo em www.axmagno.com.
Como est sendo o uso da FDD pelo mundo?
A Trail Ridge Consulting realizou uma pesquisa sobre o uso de prticas geis
em projetos de software pelo mundo. Nela podemos perceber que a FDD,
juntamente com a Extreme Programming so as duas metodologias geis para
a engenharia de software de maior destaque. A Heptagon disponibilizou em
uma verso em portugus desta pesquisa em seu site www.heptagon.com.br,
Vale a pena dar uma conferida nos resultados.

Como fao estimativas em FDD?

A FDD no define uma prtica oficial para estimativas. No livro Agile
Management for Software Engineer, David Anderson sugere uma tabela de
medidas no-lineares, baseadas em um certo grau de dificuldade para serem
utilizadas em projetos FDD que faam uso dos arqutipos de Peter Coad, mas
apenas uma sugesto.
Com o uso do Scrum em conjunto com a FDD, a prtica do Planning Poker para
definir o tamanho das funcionalidades pode ser uma boa opo, sendo esta a
minha prtica preferida.
Ao utilizar FDD sou obrigado a utilizar UML em cores?
No. O modelo abrangente da FDD pode ser tranquilamente desenvolvido
fazendo o uso da UML padro, ou como j citei anteriormente do modelo
entidade/relacionamento. No entanto, no podemos deixar de frisar que os
arqutipos da UML em cores funcionam muito bem para projetos FDD e, na
minha opinio, sempre que possvel devem ser utilizados.
Onde consigo mais informaes sobre FDD?
aXmagno: www.axmagno.com
Heptagon: www.heptagon.com.br
Nebulon Jeff De Luca: www.nebulon.com
FDD Oficial Site: www.featuredrivendevelopment.com
David Anderson: www.agilemanagement.net
Stephen Palmer: www.step-10.com
Grupo de Usurios da FDD: http://br.groups.yahoo.com/group/gufdd

Sobre o autor
Alexandre Magno Figueiredo vive em So Paulo
-SP, onde trabalha como consultor em liderana e
gerenciamento de projetos de software atravs do
uso de metodologias e processos geis,
principalmente FDD e Scrum. Atua na rea de
software h mais de 14 anos, j tendo participado de
projetos de variadas dimenses de lead time, escopo
e investimento. Certified Scrum Master, possuindo
ainda certificaes dos fornecedores IBM e Borland, e
dos grupos OMG e PMI. Pode ser encontrado em
axmagno@gmail.com ou no Palestra Itlia assistindo
aos jogos do Palmeiras.