FDD FDD FDD FDD

<A> <R> <O>

Feature-Driven Development






Descrio dos Processos



Concepo e Planejamento
Construo
Desenvolver
um Modelo
Abrangente
Planejar
por
Feature
Detalhar
por
Feature
Construir
por
Feature
Mais contedo na forma
Mais forma que contedo
Modelo de Objetos
Pacotes de Trabalho
Requisitos
Produto
Plano de
Desenvolvimento
Progresso
Construir
a Lista de
Features




Traduo da descrio oficial em www.featuredrivendevelopment.com
por Adail Muniz Retamal
www.heptagon.com.br

V. 1.2 Maio/2008
FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 2
FDD Processo n 1: Desenvolver um Modelo Abrangente


uma atividade inicial que abrange todo o projeto, realizada por membros do domnio do negcio e por
desenvolvedores, sob a orientao de um modelador de objetos experiente, no papel de arquiteto lder.

Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Ento, so realizados estudos mais
detalhados sobre o domnio do negcio para cada rea a ser modelada. Aps cada estudo dirigido sobre o
domnio, pequenos grupos so formados por membros do domnio do negcio sendo estudado e por
desenvolvedores, que comporo seus prprios modelos que satisfaam o domnio em questo. Os pequenos
grupos apresentam seus modelos para serem revisados por parceiros e para discusso. Um dos modelos
propostos, ou uma combinao dos modelos, selecionada por consenso, tornando-se, assim, o modelo para
aquela rea do domnio do negcio. Realiza-se, ento, uma combinao do modelo da rea do domnio
dentro de um modelo abrangente, ajustando a forma do modelo se for necessrio.

O modelo de objetos , ento, iterativamente atualizado em seu contedo pelo processo n 4 Detalhar por
Funcionalidade.





Critrios de Entrada

Os especialistas no domnio do negcio, os programadores lderes e o arquiteto lder foram selecionados.





Atividades

Formar a Equipe de Modelagem Gerente do Projeto Obrigatria

A equipe de modelagem composta de membros permanentes das reas do domnio do negcio e de
desenvolvimento, especificamente os especialistas no domnio e os programadores lderes. feito um rodzio
com os outros integrantes do projeto atravs das sesses de modelagem, de modo que todo mundo tenha a
chance de participar e ver o processo em ao.


Estudo Dirigido Sobre o Domnio Equipe de Modelagem Obrigatria

Um especialista no domnio do negcio apresenta uma viso geral da rea do domnio que ser modelada.
Essa apresentao deve tambm incluir informao que estiver relacionada a esta rea do domnio, mas no
necessariamente uma parte de sua implementao.


Estudar a Documentao Equipe de Modelagem Opcional

A equipe estuda os documentos de referncia ou de requisitos disponveis, tais como modelos de objetos,
requisitos funcionais (tradicionais ou no formato de casos de uso), modelos de dados e guias do usurio.



FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 3
Desenvolver o Modelo Eq. Modelagem em Pequenos Grupos Obrigatria

Formando grupos com no mais de trs componentes, cada pequeno grupo compor um modelo que suporte
a rea do domnio. O arquiteto lder pode propor um modelo base para facilitar o progresso das equipes. Um
membro de cada grupo apresenta o modelo proposto por seu grupo para a rea do domnio. O arquiteto lder
tambm pode propor outros modelos alternativos. A equipe de modelagem seleciona um modelo proposto ou
compe um modelo pela combinao das idias propostas nos modelos apresentados.


Refinar o Modelo de Objetos Abrangente Arquiteto Lder, Equipe de Modelagem Obrigatria

Freqentemente, o modelo de objetos abrangente atualizado com novas formas de modelo produzidas pelas
iteraes da atividade Desenvolver o Modelo descrita acima.





Verificao

Avaliao Interna e Externa Equipe de Modelagem, Negcio Obrigatria

Realiza-se uma auto-avaliao ou uma avaliao interna atravs da participao ativa dos especialistas no
domnio. Quando necessria, uma avaliao externa pode ser feita pedindo-se ao negcio (usurios) que
confirme ou esclarea as questes que afetam o modelo.





Critrios de Sada


O resultado do processo o modelo de objetos:

Diagramas de classes com foco na forma do modelo, isto , quais classes esto no domnio, como esto
conectadas umas s outras e sob quais restries;
Mtodos e atributos identificados so colocados nas classes;
Diagrama(s) de seqncia, se houver;
Comentrios sobre o modelo para registrar o motivo pelo qual uma forma de modelo foi escolhida e/ou
quais alternativas foram consideradas.




FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 4
FDD Processo n 2: Construir a Lista de Funcionalidades


uma atividade inicial que abrange todo o projeto, para identificar todas as funcionalidades que satisfaam
aos requisitos.

Uma equipe, geralmente composta apenas por programadores lderes do processo n 1, formada para
decompor funcionalmente o domnio em reas, atividades de negcio dentro delas e passos dentro de cada
atividade de negcio, formando assim a lista categorizada de funcionalidades. A categorizao de mais alto
nvel para a lista de funcionalidades vem da diviso do domnio feita pelos especialistas do domnio no
processo n 1.





Critrios de Entrada

Os especialistas no domnio do negcio, os programadores lderes e o arquiteto lder foram selecionados.





Atividades

Formar a Equipe da Lista de
Funcionalidades
Gerente do Projeto, Gerente de
Desenvolvimento
Obrigatria

A equipe composta por programadores lderes da equipe de modelagem do processo n 1.


Construir a Lista de Funcionalidades Equipe da Lista de Funcionalidades Obrigatria

A equipe deve identificar o conjunto de funcionalidades usando o conhecimento adquirido no processo n 1.
Esta simplesmente uma decomposio funcional nas reas definidas a partir da diviso do domnio pelos
especialistas em cada domnio nos diversos estudos dirigidos realizados no processo n 1. Ela decomposta
em reas que englobam atividades de negcio, que so, por sua vez, decompostas em passos
(funcionalidades). As funcionalidades so funes granulares, expressas em termos que possuem valor para o
cliente, usando o seguinte modelo de nomeao:

<ao> <resultado> <objeto>

Exemplos: calcular o total de uma venda, calcular a quantidade total vendida por um varejista para uma
descrio de produto.

As funcionalidades so granulares de acordo com a regra de que uma funcionalidade no levar mais do que
duas semanas para ser completada, mas no to granulares ao nvel de getters e setters (os mtodos de
acesso aos atributos de uma classe). Duas semanas so um limite superior; a maioria das funcionalidades
leva muito menos tempo do que isso. Quando um passo de uma atividade de negcio parece maior do que
duas semanas, o passo quebrado em passos menores, que ento tornam-se funcionalidades.


FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 5
Verificao

Avaliao Interna e Externa Equipe da Lista, Negcio Obrigatria

Realiza-se uma auto-avaliao ou uma avaliao interna atravs da participao ativa dos membros da equipe
de modelagem. Quando necessria, uma avaliao pode ser feita pedindo-se aos especialistas no domnio do
negcio da equipe de modelagem ou ao negcio (usurios) que confirmem ou esclaream as questes que
afetam a lista de funcionalidades.





Critrios de Sada


O resultado do processo a lista de funcionalidades:

Uma lista de reas;
Para cada rea, uma lista de atividades de negcio dentro daquela rea;
Para cada passo da atividade de negcio, uma funcionalidade que satisfaa ao passo.

FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 6
FDD Processo n 3: Planejar por Funcionalidade


uma atividade inicial que abrange todo o projeto, para produzir o plano de desenvolvimento.

O gerente de projeto, o gerente de desenvolvimento e os programadores lderes planejam a ordem na qual as
funcionalidades sero implementadas, baseada nas dependncias entre elas, na carga de trabalho da equipe de
desenvolvimento e tambm na complexidade das funcionalidades a serem implementadas. As principais
atividades neste processo no so uma seqncia estrita. Como muitas atividades de planejamento, elas so
consideradas em conjunto, com refinamentos feitos a partir de uma ou mais atividades e ento considerando
os outros novamente.

Um cenrio tpico levar em conta a seqncia de desenvolvimento, depois levar em conta a atribuio das
atividades de negcio aos programadores lderes e, ao faz-lo, considerar quais das classes principais
(apenas) so atribudas a quais desenvolvedores (lembrar que o programador lder tambm um
desenvolvedor).

Quando esse equilbrio for alcanado, e a seqncia de desenvolvimento e a atribuio das atividades de
negcio aos programadores lderes estiver essencialmente completada, ento a posse das classes estar
completada (alm das classes principais que j foram consideradas para posse).





Critrios de Entrada

O processo Construir a Lista de Funcionalidades foi completado.





Atividades

Formar a Equipe de Planejamento Gerente do Projeto Obrigatria

A equipe de planejamento composta pelo gerente de desenvolvimento e pelos programadores lderes.


Determinar Seqncia de Desenvolvimento Equipe de Planejamento Obrigatria

A equipe de planejamento deve atribuir uma data (ms e ano apenas) para o trmino de cada atividade de
negcio. A identificao da atividade de negcio e a data de trmino (e dessa forma a seqncia de
desenvolvimento) baseada em:

Dependncias entre as funcionalidades em termos de classes envolvidas;
Distribuio da carga de trabalho entre os proprietrios das classes;
Complexidade das funcionalidades a serem implementadas;
Adiantamento das atividades de negcio de alto risco ou complexidade;
Considerao de qualquer marco externo (visvel) do projeto, como verses beta, demonstraes,
pontos de verificao e todos os produtos que satisfaam tais marcos.

FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 7

Atribuir Atividades de Negcio aos
Programadores Lderes
Equipe de Planejamento Obrigatria

A equipe de planejamento deve atribuir programadores lderes como proprietrios de atividades de negcio.
A atribuio baseada em:

Seqncia de desenvolvimento;
Dependncias entre as funcionalidades em termos de classes envolvidas;
Distribuio da carga de trabalho entre os proprietrios das classes (lembrar que os programadores
lderes tambm so proprietrios de classes);
Complexidade das funcionalidades a serem implementadas.


Atribuir Classes aos Desenvolvedores Equipe de Planejamento Obrigatria

A equipe de planejamento deve atribuir desenvolvedores como proprietrios de classes. Os desenvolvedores
so proprietrios de vrias classes. A atribuio das classes aos desenvolvedores baseada em:

Distribuio da carga de trabalho entre os desenvolvedores;
Complexidade das classes;
Uso das classes (ex. alta utilizao);
Seqncia de desenvolvimento.





Verificao

Auto-Avaliao Equipe de Planejamento Obrigatria

Como o planejamento uma atividade de equipe, realiza-se uma auto-avaliao pela participao ativa dos
programadores lderes, gerente de desenvolvimento e gerente de projeto.





Critrios de Sada


O resultado do processo o plano de desenvolvimento, consistindo em:

Atividades de negcio com datas de trmino (ms e ano);
Programadores lderes atribudos a atividades de negcio;
reas com datas de trmino (ms e ano), derivadas da data do ltimo trmino de suas respectivas
atividades de negcio;
Lista das classes e seus respectivos desenvolvedores proprietrios (a lista de proprietrios de classes).

FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 8
FDD Processo n 4: Detalhar por Funcionalidade


uma atividade para cada funcionalidade, para produzir o pacote de projeto (design) para a funcionalidade.

Certo nmero de funcionalidades so agendadas para desenvolvimento ao atribu-las a um programador
lder. Ele seleciona as funcionalidades para desenvolvimento a partir de sua caixa de entrada de
funcionalidades atribudas. Ele pode escolher diversas funcionalidades que utilizem as mesmas classes (e
portanto, desenvolvedores). Operacionalmente, com freqncia acontece o caso de conjuntos de
funcionalidades serem agendados para desenvolvimento de uma vez pelo programador lder. Tal conjunto
chamado de Pacote de Trabalho do programador lder.

O programador lder, ento, forma uma equipe de funcionalidades, identificando os proprietrios das classes
(desenvolvedores) que provavelmente sero envolvidos no desenvolvimento das funcionalidades que ele
selecionou. Esta equipe produz o(s) diagrama(s) de seqncia para a(s) funcionalidade(s) atribuda(s). O
programador lder, ento, refina o modelo de objetos, baseado no contedo do(s) diagrama(s) de seqncia.
Os desenvolvedores escrevem os prefcios das classes e mtodos. Realiza-se uma inspeo no projeto
(design).





Critrios de Entrada

O processo de planejamento foi completado.





Atividades

Formar a Equipe de Funcionalidades Programador Lder Obrigatria

O programador lder identifica as classes que provavelmente sero envolvidas no projeto deste conjunto de
funcionalidades e, consequentemente, atualiza o banco de dados de funcionalidades. Da lista de proprietrios
de classes, o programador lder identifica os desenvolvedores necessrios para formar a equipe de
funcionalidades. Como parte deste passo, o programador lder cria um novo pacote de projeto (design) para
a(s) funcionalidade(s) como parte do Pacote de Trabalho.


Estudo Dirigido do Domnio Especialista no Domnio Opcional

O especialista no domnio apresenta uma viso geral da rea do domnio para a funcionalidade a ser
projetada. Essa apresentao deve tambm incluir informao que estiver relacionada a esta funcionalidade,
mas que no seja necessariamente uma parte de sua implementao. Esta uma atividade opcional, baseada
na complexidade da funcionalidade e/ou de suas interaes.
FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 9

Estudar a Documentao de Referncia Equipe de Funcionalidades Opcional

A equipe de funcionalidades estuda o(s) documento(s) de referncia para a funcionalidade a ser projetada,
todos os memorandos de confirmao, desenhos de telas, especificaes de interface com sistemas externos e
qualquer outra documentao de suporte. Esta uma atividade opcional, baseada na complexidade da
funcionalidade e/ou de suas interaes.


Desenvolver o(s) Diagrama(s) de Seqncia Equipe de Planejamento Obrigatria

Desenvolver o(s) diagrama(s) de seqncia necessrio(s) para a funcionalidade a ser projetada. Os arquivos
do(s) diagrama(s) devem ser submetidos ao sistema de controle de verses. Quaisquer projetos (designs)
alternativos, decises de projeto, esclarecimentos de requisitos e comentrios tambm so registrados e
descritos na seo de alternativas de projeto (design) do Pacote de Projeto (Design).


Refinar o Modelo de Objetos Programador Lder Obrigatria

O programador lder cria uma rea para a equipe de funcionalidades para a(s) funcionalidade(s). Esta rea
pode ser um diretrio em um servidor de arquivos ou um diretrio em seus prprios computadores, que so
copiados para o servidor pelo programador lder quando necessrio, ou utiliza-se uma rea de trabalho
fornecida pelo sistema de controle de verses. O propsito da rea da equipe de funcionalidades para que o
trabalho em andamento possa ser compartilhado e estar visvel pelos membros da equipe de funcionalidades,
mas invisvel para o resto do projeto.

O programador lder refina o modelo para adicionar novas classes, mtodos, atributos e/ou fazer alteraes
aos j existentes, baseado no(s) diagrama(s) de seqncia definido(s) para a(s) funcionalidade(s). Isto resulta
na atualizao dos arquivos fontes da linguagem de implementao na rea da equipe de funcionalidades. O
programador lder cria diagramas do modelo num formato publicvel. Esses arquivos devem ser submetidos
ao sistema de controle de verses e publicados na intranet do projeto.


Escrever Prefcios de Classes e Mtodos Equipe de Funcionalidades Obrigatria

Utilizando os arquivos fontes da linguagem de implementao atualizados pela atividade Refinar o Modelo
de Objetos, que esto na rea da equipe de funcionalidades, o proprietrio da classes escreve os prefcios de
classe e mtodos para cada item definido pela funcionalidade e pelo(s) diagrama(s) de seqncia. Isto inclui
tipos de parmetros, tipos de retorno, excees e mensagens. Uma vez que cada desenvolvedor completou
sua tarefa, o programador lder gera a documentao da API usando <sua ferramenta> e a submete para
publicao na intranet do projeto.





Verificao

Inspeo do Projeto (Design) Equipe de Funcionalidades Obrigatria

Realiza-se uma inspeo no projeto (design) com os membros da equipe de funcionalidades ou com outros
membros do projeto. A deciso de inspecionar com a equipe de funcionalidades ou com outros membros do
projeto cabe ao programador lder. Aps o aceite, uma lista de tarefas gerada para cada classe afetada, e
cada membro da equipe inclui suas tarefas sua agenda de tarefas. O programador lder tambm deve
combinar as alteraes da rea compartilhada pela equipe de funcionalidades de volta ao sistema de controle
de verses.
FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 10

Critrios de Sada


O resultado do processo um Pacote de Projeto (Design) inspecionado com sucesso. O pacote de projeto
consiste em:

Uma capa com comentrios, que completa e descreve o pacote de projeto de tal forma a ser suficiente
para futuros revisores;
Os requisitos referenciados (se houver) na forma de documentos e de todos os memorandos de
confirmao relacionados, e documentao de apoio;
O(s) diagrama(s) de seqncia;
Alternativas de projeto (design) (se houver);
O modelo de objetos com classes, mtodos e atributos novos/atualizados;
A sada gerada pela <sua ferramenta> para os prefcios de classes e mtodos, criados ou modificados por
esse projeto (design);
Lista de tarefas e agendamentos para itens de ao nas classes afetadas para cada membro da equipe.

FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 11
FDD Processo n 5: Construir por Funcionalidade


uma atividade para cada funcionalidade, para produzir uma funo com valor para o cliente
(funcionalidade).

Comeando com o pacote de projeto (design), os proprietrios de classes implementam os itens necessrios
para que suas classes suportem o projeto para esta funcionalidade. O cdigo desenvolvido passa pelo teste de
unidade e pela inspeo a ordem aqui determinada pelo programador lder. Aps passar pela inspeo, o
cdigo promovido verso atual (build).





Critrios de Entrada

O processo Detalhar por Funcionalidade foi completado, isto , o pacote de projeto (design) passou
com sucesso pela inspeo.





Atividades

Implementar Classes e Mtodos Equipe de Funcionalidades Obrigatria

Os proprietrios de classes implementam os itens necessrios para satisfazer aos requisitos de suas classes
para esta funcionalidade.


Inspecionar o Cdigo Equipe de Funcionalidades Obrigatria

Uma inspeo no cdigo, com membros da equipe de funcionalidades ou outros membros do projeto (a
deciso cabe ao programador lder), realizada antes ou aps o teste de unidade (a deciso tambm cabe ao
programador lder).


Teste de Unidade Equipe de Funcionalidades Obrigatria

Os proprietrios de classes testam seus cdigos para certificar que todos os requisitos de suas classes foram
satisfeitos. O programador lder determina quais testes de unidade no nvel da equipe de funcionalidades so
necessrios (se houver). Isto , se algum teste envolvendo as classes desenvolvidas para esta funcionalidade
exigido.


Promover Verso Atual (Build) Prog Lder, Equipe de Funcionalidades Obrigatria

As classes somente podem ser promovidas para a verso atual (build) aps uma inspeo de cdigo com
sucesso. O programador lder monitora as classes sendo promovidas individualmente, atravs de informaes
dos desenvolvedores, e o ponto de integrao para a funcionalidade inteira.


FDD Feature-Driven Development Descrio de Processos
Heptagon Tecnologia da Informao Ltda Pg. 12

Verificao

Inspeo do Cdigo e Teste de Unidade Prog Lder, Equipe de Funcionalidades Obrigatria

Uma inspeo de cdigo com sucesso, juntamente com o trmino dos testes de unidade com sucesso,
formam a verificao da sada deste processo. A inspeo do cdigo e o teste de unidades so descritos
acima.





Critrios de Sada


O resultado do processo :

Classes e/ou mtodos que passaram na inspeo de cdigo com sucesso;
Classes que foram promovidas verso atual (build);
O trmino de uma funo com valor para o cliente (funcionalidade).