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.
Editor, considere adicionar mês e ano na marcação. Isso pode ser feito automaticamente, com {{Fusão com|....|{{subst:DATA}}}}.

(por favor crie o espaço de discussão sobre essa fusão e justifique o motivo aqui; não é necessário criar o espaço em ambas as páginas, crie-o somente uma vez. Perceba que para casos antigos é provável que já haja uma discussão acontecendo na página de discussão de um dos artigos. Verifique ambas (1, 2) e não esqueça de levar toda a discussão quando levar o caso para a central.).
Question book.svg
Este artigo não cita fontes confiáveis e independentes (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]