FDD (Feature-Driven Development) que significa desenvolvimento guiado a funcionalidades, assim como o XP, ASD, Scrum e AUP, faz parte das metodologias ágeis originais, sendo este um modelo incremental e interativo do processo de desenvolvimento de software que tem como lema Resultados frequentes, tangíveis e funcionais.

Desenvolvido por Peter Coad e Jeff De Luca, foi inicialmente publicado em 1999 no livro “Java Modeling in Color with UML”, sendo que uma das principais obras, que possui uma versão completa da metodologia foi publicada em 2002 após sua utilização numa agência do United Overseas Bank em Singapura.

FDD incorpora muitas das boas práticas de desenvolvimento já reconhecidas pela indústria em um conjunto coeso. Estas práticas todas são orientadas a funcionalidades, que é um conceito de valor do ponto de vista do cliente. O principal objetivo do FDD é entregar uma peça de software tangível e funcional para o cliente em espaços
de tempo regulares.

Uma funcionalidade (ou feature), segundo Coad, “é uma função com valor para o cliente que pode ser desenvolvida
em duas ou menos semanas”. Pois um dos objetivos do FDD é apresentar para o cliente tais funcionalidades
em um período fixo de tempo, em geral, duas semanas ou menos. Uma funcionalidade pode ser descrita com
o seguinte template: <ação>. Exemplo:
• Calcular o valor de uma compra;
• Calcular itens em estoque;
• Listar fornecedores locais.

Papeis no FDD

Quando se trata de Metodologias ágeis existe a tendência de valorizar para as pessoas. Isso devido influência que a qualificação e desempenho do pessoal da equipe têm em métodos adaptativos de desenvolvimento de software.
É importante ressaltar que, no FDD, uma pessoa pode desempenhar mais de um papel e um papel pode ser desempenhado por mais de uma pessoa.
A seguir serão listados e especificados cada um dos papéis do FDD:

  • Gerente de Projeto: é o líder administrativo e financeiro do projeto: tem a palavra final no que se trata de escopo, cronograma e recursos do projeto.
  • Gerente de Desenvolvimento: é o líder nas atividades diárias do desenvolvimento. É responsável por resolver qualquer tipo de conflito que venha a ocorrer dentro da equipe.
  • Arquiteto-chefe: é responsável pela modelagem do projeto. Deve conduzir as sessões de modelagem de forma que a equipe de desenvolvedores possa contribuir na construção do sistema.
  • Programadores-chefe: é o líder dos pequenos times de análise, modelagem e desenvolvimento de novas funcionalidades.
  • Proprietários de código/classe (Desenvolvedores): os “Donos” de Classe trabalham orientados pelo programador Chefe executando as tarefas de modelar, codificar, testar e documentar.
  • Especialistas do Domínio (negócio): os Especialistas do domínio podem ser usuários, clientes, patrocinadores ou analistas de negócio. Sua responsabilidade é de adquirir e transmitir informações a respeito do funcionamento dos requisitos do sistema.

Em projetos maiores e que possuam tal necessidade, outros papéis podem ser incluídos no projeto, tais como:

  • Gerente de Versão: o gerente de versão controla a evolução do processo através da análise de relatórios de progresso dos programadores chefe e reuniões curtas com eles.
  • Gerente de Domínio: é o líder dos peritos do domínio e resolve suas divergências de opinião com relação aos requisitos do sistema.
  • Guru da Linguagem: o Guru da Linguagem um membro da equipe com amplo conhecimento na linguagem ou tecnologia usada no desenvolvimento do sistema.
  • Administrador de Sistema: o administrador do sistema configura, gere e resolve problemas nos servidores e redes utilizados.

E ainda outros papéis tais como: Gerente de Construção, Testadores, Implantadores, Redator Técnico e Criador de Ferramentas.

Processos do FDD

O Processo do FDD é composto por cinco etapas, sendo as três primeiras executadas uma única vez no
início do processo e as duas últimas executadas a cada interação. Segundo De Luca [3], cada etapa possui padrões que devem ser seguidos, chamados de ETVX, oriundo de Entrada (Entry), Tarefa (Task), Verificação (Verification) e saída (Exit). Ainda por De Luca, temos uma pequena descrição delas:

  1. Entrada (Entry): especifica e define os critérios de entradas para as etapas;
  2. Tarefa (Task): é composto por uma lista com as tarefas que deverão ser realizadas.
  3. Verificação (Verification): especifica tipos de avaliações (internas e externas) e inspeções de projeto e código;
  4. Saída (Exit): especifica os critérios de saída, definindo os produtos tangíveis.

Boas práticas do FDD

Em relação às práticas definidas no FDD, elas não são extremamente rígidas, pregando a adaptação ao ambiente de desenvolvimento. No entanto, existe um conjunto de práticas que são fundamentais e que definem o FDD:

  • Modelagem em objetos de domínio: construir um diagrama de classes básico com os objetos de domínio e suas relações, definindo assim uma arquitetura básica para o modelo do sistema.
  • Desenvolvimento por características: a implementação deve ser orientada pelas características.
  • Autoria individual: o código é de autoria de um “dono” da classe, o que permite uma maior rapidez na implementação das tarefas associadas.
  • Times da característica: para a implementação de uma determinada característica, o chefe programador recruta os “donos” das classes que serão usadas. Esse grupo de pessoas é o time da característica.
  • Inspeções: a forma de verificação de qualidade do código e do projeto.
  • Integração (build) regular: em um determinado período de tempo fixo devem ser integradas as características já terminadas, permitindo a verificação de erros e também criando uma versão atual que pode ser demonstrada ao cliente.
  • Gerência de configuração: manter versões de todos os artefatos criados.
  • Reportar/Visibilidade dos resultados: permitir que se conheça o progresso do projeto.

Categorized in:

Tagged in: