Feature Driven Development

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Merge-arrow 2.svg
Este artigo ou secção deverá ser fundido com Desenvolvimento ágil de software. (desde outubro de 2016)
Se discorda, discuta sobre esta fusão aqui.
Question book.svg
Esta página ou secção não cita fontes confiáveis e independentes, o que compromete sua credibilidade (desde Dezembro de 2008). Por favor, adicione referências e insira-as corretamente no texto ou no rodapé. Conteúdo sem fontes poderá ser removido.
Encontre fontes: Google (notícias, livros e acadêmico)

O Desenvolvimento Guiado por Funcionalidades (do inglês, Feature Driven Development; FDD) é uma das seis metodologias ágeis originais do desenvolvimento de software. Seus representantes redigiram o Manifesto Ágil para Desenvolvimento de Software, em 2001. Nessa ocasião, o representante da FDD foi Jon Kern, que trabalhava na TogetherSoft, substituindo Peter Coad.

Origens[editar | editar código-fonte]

A FDD nasceu num projeto em Singapura, entre 1997 e 1999, a partir do Método Coad (uma metodologia completa para Análise, Desenho e Programação Orientados por Objetos, desenvolvida por Peter Coad nas décadas de 1980 e 1990) e das técnicas de gerenciamento iterativo, incremental e enxuto de projetos utilizadas por Jeff De Luca, um gerente de projetos australiano.

Seu lema é "Resultados frequentes, tangíveis e funcionais".

A primeira descrição oficial dos processos foi publicada no livro "Java Modeling in Color with UML", por Peter Coad, Eric Lefebvre e Jeff De Luca, em 1999.

O livro de referência é "A Practical Guide to Feature-Driven Development", por Stephen Palmer e John Mac Felsing, publicado em 2002 pela Prentice-Hall, compondo uma série editada pelo próprio Peter Coad.

FDD e a Família Ágil[editar | editar código-fonte]

Com relação às outras metodologias de desenvolvimento de software, situa-se numa posição intermediária entre as abordagens mais prescritivas (Processo Unificado, Cascata tradicional - Waterfall) e as abordagens Ágeis (XP - Programação Extrema, Scrum, Crystal, etc.).

Oferece um conjunto coeso de princípios e práticas tanto para a Gestão de Projetos quanto para a Engenharia de Software, mas convive bem com abordagens mais especialistas, como Scrum.

Apesar de algumas divergências pontuais com a XP, várias práticas propostas por esta última também são utilizadas por equipes usando FDD, como os testes unitários, refatoração, programação em pares, integração contínua, entre outras. Apenas a ênfase na FDD é que não é tão grande quanto na XP. A FDD também propõe práticas como inspeção formal (de desenho e de código) e posse individual/situacional de código/classe, que podem contrastar com algumas das práticas fundamentais da XP. A experiência da equipe e dos gerentes é que deve julgar quais práticas são mais apropriadas.

Os Processos[editar | editar código-fonte]

Os cinco processos da FDD

A FDD é, classicamente, descrita por cinco processos:

  • Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, análise orientada por objetos, modelagem lógica de dados e outras técnicas para entendimento do domínio de negócio em questão. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
  • Construir uma Lista de Funcionalidades: decomposição funcional do modelo do domínio, em três camadas típicas: áreas de negócio, atividades de negócio e passos automatizados da atividade (funcionalidades). O resultado é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
  • Planejar por Funcionalidade: abrange a estimativa de complexidade e dependência das funcionalidades, também levando em consideração a prioridade e valor para o negócio/cliente. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a 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. O resultado é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
  • Construir por Funcionalidade: cada esqueleto de código é preenchido, testado e inspecionado. O resultado é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.

Ligações externas[editar | editar código-fonte]