Feature Driven Development
A FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma das seis metodologias ágeis originais, cujos 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.
Índice |
[editar] Origens
A FDD nasceu num projeto em Cingapura, 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 freqüentes, 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.
[editar] FDD e a Família Ágil
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.
[editar] Os Processos
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.
