Feature Driven Development (FDD)

1
Feature Driven Development (FDD)

• Kleber Silva, khfts_at_cin.ufpe.br
• 11/10/2005

2
Agenda

• Introdução
• Motivação
• Melhores Práticas
• Modelagem de Objeto do Domínio
• Desenvolvimento por Feature
• Class (Code) Ownership
• Equipes por Feature
• Inspeções
• Builds Regulares
• Gerência de Configuração
• Comunicação/Visibilidade dos Resultados
• Processo
• Conclusão

3
Introdução

• Desenvolvimento Ágil

() (-)
Indivíduos e Interações Processos e Ferramentas
Software Funcionando Documentação Extensa
Colaboração do Cliente Negociação de Contrato
Resposta às Mudanças Seguir um Plano
Tabela 1 Manifesto Desenvolvimento Ágil
4
Introdução

• Feature Driven Development
• Criado por Jeff De Luca em 1999, baseado em 30
  anos experiência na área de TI com envolvimento
  de Peter Coad e Steve Palmer
• Trata-se de uma compilação dos patterns of
  success percebidos
• Possui características de Desenvolvimento Ágil
• Iterações pequenas (no máximo 2 semanas)
• Centrada em Design.

• We cannot predict where a chess game will go,
  but we can learn patterns of play that bring
  success." Highsmith 2000.
• Good habits are a wonderful thing. They allow
  the team to carry out the basic steps, focusing
  on content and results , rather than process
  steps . This is best achieved when process steps
  are logical and their worth immediately obvious
  to each member.
• Coad, LeFebvre, De Luca Coad 99

5
Motivação

• 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

6
Melhores Práticas

• Modelagem de Objeto do Domínio
• Diagramas de classes dos objetos do domínio e
  seus relacionamentos são construídos
• O suporte aos aspectos comportamentais é dado por
  diagramas de seqüência em alto nível
• Ênfase não é em cima de se determinar todos os
  atributos
• Evita as inferências isoladas dos analistas, por
  se tratar de um modelo global onde todos os
  envolvidos participam.

7
Modelagem De Objeto Do Domínio
Extending that analogy a bit further, a domain
object model is like the road map that guides the
journey with it, you can reach your destination
relatively quickly and easily without too many
detours or a lot of backtracking without it, you
can very quickly end up lost or driving around in
circles, continually reworking and refactoring
the same pieces of code. Stephen Palmer
Figura 1 Modelo de Objetos Do Domínio numa Fase
Inicial
8
Desenvolvimento Por Feature
Figura 2 Decomposição do Statement Of Purpose
em Requisitos Funcionais
9
Feature
Once we have identified the classes in our
domain object model, we can design and implement
each one in turn. Then, once we have completed a
set of classes, we integrate them and hey,
presto! We have part of our system. Easy!...Well,
its a nice dream! We can produce the most
elegant domain object model possible, but if it
does not help us to provide the systems clients
with the functionality for which they have asked,
we have failed. It would be like building a
fantastic office skyscraper but either leaving
each floor unfurnished, uncarpeted, and without
staff, or furnishing it with ornamental but
impractical furniture and untrained staff. A
Practical Guide to FDD, cap 3

• Features são os requisitos funcionais com valor
  para o usuário, isto é, estão numa linguagem que
  o cliente ou usuário podem entender
• Os requisitos funcionais tendem a misturar
  funções de interface, persistência e comunicação
  em rede com funções de negócio
• Facilitam o acompanhamento da evolução do projeto
  (o quanto já foi feito) junto ao cliente.

10
Feature

• O termo feature em FDD é muito específico. Uma
  feature é uma função pequena, com valor no
  cliente expressa na seguinte forma
• ltactiongt ltresultgt ltobjectgt
• Com as proposições apropriadas entre ação,
  resultado e objeto.
• Ex. - Calcular o total de uma venda
• - Avaliar o desempenho de um vendedor.
• - Validar a senha de um usuário.
• Features vs. Casos de Uso
• Classes com funções pesadas constantemente
  acessando classes com dados pesados
• Alto acoplamento
• Baixa coesão
• Encapsulamento pobre

11
Feature

• Exemplo
• Área de Features Principal (Subject Domain Area)
• Gerenciamento de venda de produtos
• Conjunto de Features (Business Activity)
• Vender para um cliente
• Features
• Calcular o total de vendas
• Calcular o total de compras de um cliente
• Estimar o tempo de entrega de uma venda
• Calcular a taxa de uma venda

12
Class (Code) Ownership

• Class (code) ownership num processo de
  desenvolvimento denota quem é em última instância
  responsável pelo conteúdo de uma classe (parte de
  código)
• Pode ser
• Individual a classe é atribuída somente a um
  único dono
• Coletiva O time possui coletivamente a classe
  (código).

13
Individual Class Ownership

• Vantagens
• Um guardião de integridade conceitual
• Um expert para explicar uma parte do código
• Um desenvolvedor mais rápido para implementar
  essa parte de código
• É minha classe, dela me orgulho!!!
• Desvantagens
• Mudanças que dependem de outras classes
• Perda do conhecimento por ocasião da falta do
  class owner.

14
Collective Class Ownership

• Vantagens
• Resolve o problema da espera por outro para
  solução de um problema
• Desvantagens
• Facilmente degenera em não tem dono ou classes
  governadas por uma elite.

15
Equipes por Feature

• Como se organiza os class owners para construir
  as features?

Figura 3 Equipes por Feature
16
Equipes por Feature

• Normalmente pequena de três a seis integrantes
• Possui todo o código que necessita para mudar sua
  feature
• Cada membro de uma feature contribui para o
  design e implementação de uma feature sob a
  orientação de um desenvolvedor mais experiente.

17
Inspeções

• Usadas para
• Detecção de Defeitos
• Transferência de Conhecimento
• Aderência à Padrões de Codificação
• Extrair Métricas para Melhoria do Processo.
• Cuidado Não devem ser tomadas como uma avaliação
  pessoal de performance.

18
Builds Regulares

• Em intervalos regulares, o sistema completo é
  montado
• Identifica os erros de integração
• Garante um sistema up-to-date para demonstração
  ao cliente
• Um processo de geração de builds pode ser
  melhorado para
• Gerar documentação
• Rodar script de métricas e de auditoria
• Base para testes de regressão
• Construir novo build e release notes, listando
  novas features adicionadas, defeitos corrigidos,
  etc...

19
Gerência de Configuração

• Identificação do código para todas as features
  completadas
• Manutenção de um histórico de mudanças das
  classes.

20
Comunicação/Visibilidade Dos Resultados

• Progress Reporting
• Facilita o acompanhamento gerencial, através da
  coleta de informações confiáveis e precisas sobre
  o status do projeto
• Sugere um número de formatos de relatórios
  intuitivos e diretos para ilustrar o progresso.

• Closely related to project control is the concept
  of visibility, which refers to the ability to
  determine a projects true status....If the
  project team cant answer such questions, it
  doesnt have enough visibility to control its
  project.
• The working software is a more accurate status
  report than any paper report could ever be.
• Steve McConnell McConnell 98

21
Comunicação/Visibilidade Dos Resultados
KEY Work In Progress
Attention Completed
Not Started
22
Comunicação/Visibilidade Dos Resultados
23
Comunicação/Visibilidade Dos Resultados
CP-1
Status Geral
Fazendo avaliação de produtos (14)
Trabalhos em progresso
Exemplo Conjunto de Features Fazendo
avaliação de produtos Trabalho em progresso
CP-1 é o programador chefe inicial (14) esse
conjunto de Features possui 14 características
Conjunto de Features/ está 75 completado A
conclusão é para dezembro de 2001
Atenção (ie, atrasado)
Completo
Não iniciado
75
Porcentagem completa
Barra de progresso
Dez 2001
Status Completo
Completo
Mês de conclusão
MY
24
Comunicação/Visibilidade Dos Resultados
Product Sale Management (PS)
CP-1
CP-1
CP-1
CP-3
CP-2
CP-1
Invoicing Sales (33)
Making Product Assessments (14)
Setting up Product Agreements (13)
Selling Products (22)
Shipping Products (19)
Delivering Products (10)
99
30
75
10
3
Dec 2001
Dec 2001
Dec 2001
Dec 2001
Nov 2001
Dec 2001
Customer A/C Mgmt (CA)
Inventory Mgmt (IM)
CP-2
CP-2
CP-2
CP-3
CP-3
CP-3
Logging Account Transactions (30)
Opening New Accounts (11)
Moving Content (19)
Accepting Movement Requests (18)
Evaluating Account Applications (23)
Establishing Storage Units (26)
82
100
82
97
95
100
Nov 2001
Oct 2001
Nov 2001
Nov 2001
Oct 2001
Nov 2001
25
Comunicação/Visibilidade Dos Resultados
26
Processo

• Descrição
• Cada processo é descrito em não mais do que duas
  páginas de papel tamanho carta, frente-e-verso
• Cada descrição do processo apresenta-se de acordo
  com a estrutura Entrada, Tarefas, Verificação e
  Saídas (ETVX).

27
Processo

• Papéis principais
• Gerente de projeto
• Arquiteto chefe
• Especialistas no domínio
• Gerentes de desenvolvimento
• Programadores chefes
• Proprietários de classes

28
Processo
1.Desenvolver um Modelo Geral
2. Construir uma Lista de Features
3. Planejar Por Feature
4. Projetar Por Feature
5. Construir Por Feature
Figura 4 Os 5 Processos FDD
29
Desenvolver um Modelo Geral

• Adquirir conhecimento do domínio e construir o
  modelo geral
• Estabelecimento do propósito de negócio do novo
  sistema
• Construção de um modelo conceitual do sistema.

30
Atividades
Formar a Equipe de Modelagem
Walkthrough sobre o Domínio
Estudar Documentos
Desenvolver pequenos Modelos de Grupo
Desenvolver um Modelo da Equipe
Refinar o Modelo Geral
Escrever Anotações do Modelo
31
Entradas e Saídas

• Entrada
• Especialistas no domínio, programadores e
  arquitetos chefes são selecionados.
• Saídas
• Modelo geral do domínio
• Diagrama das classes principais com alguns
  métodos e atributos identificados
• Diagramas de seqüência de algumas funcionalidades
  mais complexas (se houver)
• Comentário sobre o modelo.

32
Construir lista de Features

• O domínio é decomposto até chegar nas Features
• Features são agrupadas e categorizadas
• Features são granuladas até ser necessário menos
  de 2 semanas pro seu desenvolvimento.

33
Atividades
Formar a Equipe da Lista de Features
Construir a lista de Features
34
Entradas e Saídas

• Entrada
• O processo de desenvolvimento do modelo geral ter
  sido concluído com sucesso.
• Saídas
• Uma lista das áreas do domínio identificadas
• Para cada área, uma lista de atividades de
  negócio (conjunto de Features)
• Para cada atividade, os passos a serem realizados
  (Features).

35
Planejar Por Features

• Uma data de lançamento é estabelecida para o
  release inicial
• A lista de Features priorizadas é refinada
• Dependência entre funcionalidades
• Carga de Trabalho
• Complexidade ou Risco
• Milestones
• O trabalho técnico é planejado e atribuído
  plano de desenvolvimento

36
Atividade
Formar a Equipe de Planejamento
Determinar a Seqüência de Desenvolvimento
Atribuir Conjuntos de Features para
Programadores Chefes
Atribuir Classes para Desenvolvedores
37
Entradas e Saídas

• Entrada
• O processo de construir a lista de Features ter
  sido concluído com sucesso.
• Saídas
• Áreas de Domínio com datas de término
• Atividades de negócio com datas de término
• Programadores-chefes atribuídos a atividades de
  negócio
• A lista de classes e seus donos (desenvolvedores).

38
Projetar Por Features

• Regras e transações são identificadas
• O modelo da interface do usuário é esboçado
• Diagramas de seqüência mais detalhados são
  produzidos
• Especialistas são consultados para descobrir
  qualquer necessidade específica adicional

39
Atividades
Formar a Equipe Por Feature
Estudo do Domínio
Estudar Documentos de Referências
Desenvolver Diagramas de Seqüência
Descrever os prefácios de classes e métodos
Refinar o Modelo
40
Entradas e Saídas

• Entrada
• O processo de planejamento ter sido concluído com
  sucesso
• Saídas
• Diagramas de seqüência
• Designs alternativos (caso exista)
• O modelo de objeto com classes, métodos e
  atributos novos ou atualizados
• A documentação da API do sistema
• Lista de tarefas (calendário/ To-Do)

41
Construir Por Feature

• Features são construídas implementando todas as
  classes e métodos necessários
• Testes de unidades
• Features são inseridas no build quando o teste
  resulta em sucesso

42
Atividades
Codificar
Testar Unidades
Inspecionar Código
Promover à versão atual (Build)
43
Entradas e Saídas

• Entrada
• O processo de construção por Feature ter sido
  concluído com sucesso
• Saídas
• Classe(s) e/ou método(s) que passaram na inspeção
  de código com sucesso
• Classes inseridas no build
• A conclusão da funcionalidade do cliente

44
Conclusão

• Requer alguma arte na alocação de recursos
• Permite um bom acompanhamento gerencial do status
  das atividades
• Mais leve e simples de implementar
• Favorece um bom Design do sistema.

45
Referências

• http//agilemanifesto.org/principles.html,
  Principles Behind The Agile Manifest.
• Highsmith, James A. III, 2000, "Adaptive Software
  Development A Collaborative Approach to Managing
  Complex Systems." Dorset House Publishing
• R Palmer, S. Felsing, John M. A Practical Guide
  to Feature-Driven Development. The Coad Series.
• Coad P., Lefebyre E., De Luca, J. Java Modeling
  In Color With UML Enterprise Components And
  Processes. Prentice Hall.
• http//www.cin.ufpe.br/processos/TAES3/slides-200
  4.2/FDD.ppt, Feature Driven Development.
  Apresentação por Manuela Xavier, 05/11/2004.
• http//www.nebulon.com/fdd/, Feature Driven
  Development.
• http//www.faturedrivendevelopment.com/, The
  Portal For All Things FDD.
• http//www.fddmanager.com/, FDD Manager
  Overview.
• http//fddtools.sourceforge.net/, FDD Tools
  Project.

46
Dúvidas

• ???