Introdução ao FDD - Feature Driven Development

Veja neste artigo uma introdução ao modelo de desenvolvimento FDD - Feature Driven Development. Serão apresentadas as principais características deste modelo e como ele pode ser facilmente integrado ao Scrum, por exemplo.

Entre as metodologias ágeis que existiam antes do manifesto ágil, o FDD “Feature Driven Developement” é uma delas. Concebido originalmente por Jeff de Luca, o FDD surgiu em Singapura, entre os anos de 1997 e 1999 com base no método Coad (Criado por Peter Coad – 1980/1990) e nos processos interativos e lean já utilizados por Jeff de Luca.

O FDD busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do sistema. É pratico para o trabalho com projetos iniciais ou projetos com codificações existentes. Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia. O FDD atua muito bem em conjunto com o Scrum, pois o Scrum atua no foco do gerenciamento do projeto e o FDD atua no processo de desenvolvimento.

O FDD possui cinco processos básicos.

Assim como acontece na metodologia XP, o FDD faz uso de teste de software. Desta forma é possível utilizar TDD, aliás, é indicada a utilização deste para manter a qualidade do software.

O FDD, assim como a teoria de sistemas afirma, entende que a soma das partes é maior do que o todo. Desta forma, apesar de criar um modelo abrangente baseado no todo que será desenvolvido, esta fase inicia-se com o detalhamento do domínio do negócio com divisão de áreas que serão modeladas. O modelo só está pronto quando todos da equipe estiverem de acordo, o planejamento é feito com base na lista de funcionalidades. Se fossemos trabalhar com FDD em conjunto com o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de usuários a serem desenvolvidas.

Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este planejamento é incremental. Isto em conjunto com o Scrum, deve ser analisado como etapa de desenvolvimento do incremento, então este planejamento é feito com base no que será desenvolvido naquele incremento.

Vamos novamente ao Scrum, separando o que será feito na Sprint. Colocamos no backlog da Sprint. O que está no backlog da sprint são funcionalidades que serão desenvolvidas durante a sprint (que pode ser de duas a quatro semanas), estas tarefas são então planejadas com maior rigor, neste ponto, temos então o planejamento incremental, ou seja, planejamos apenas o que vamos desenvolver. Nesta etapa os envolvidos no processo resumem-se apenas à equipe, ou seja, os desenvolvedores, analistas, testadores, etc., que vão atuar no processo. Eles devem selecionar os itens com base no tempo que eles possuem e nas qualificações atuais da equipe.

Após o planejamento, é feito o detalhamento, nesta fase é de extrema importância que o desenho esteja de acordo com o que o cliente deseja, então é mantido contato constante com o cliente, como em todas as metodologias ágeis.

Esta documentação é a base para o desenvolvimento, não deve-se perder tempo com documentação que não será utilizada, mas é necessário documentar.

Posteriormente inicia-se a fase de desenvolvimento, esta fase é a etapa de desenvolvimento e teste real.

O desenvolvimento também é incremental, e indica-se a utilização de testes do início ao fim do processo, além da utilização de integração continua.

Um ponto que diverge do XP é que no FDD é incentivado o desenvolvedor como único responsável pelo módulo que este desenvolve, já no XP, o código é comunitário.


Figura 1: Integração contínua

A utilização da integração continua permite que a equipe esteja em contato constante com o cliente, tornando o processo ágil e com entregas constantes.

Para saber mais sobre integração continua, veja: http://www.linhadecodigo.com.br/artigo/1252/dividir-conquistar-e-integrar-conceitos-de-integracao-continua-para-testadores-ageis.aspx.

Como cada fase apresentada acima é específica e curta, e as fases se completam, são necessários relatórios para manter o controle, para analisar a quantidade de recursos que estão sendo desenvolvidos, semelhante ao burndow e o burnup do Scrum.

Segundo a metodologia, o percentual de tempo gasto em cada etapa é:

Além disso, o FDD possui as chamadas melhores práticas que indicam boas práticas ao desenvolver com o FDD, são elas:

Existem ferramentas que facilitam o desenvolvimento utilizando FDD, uma delas, livre é a FDDTools, disponível em: http://fddtools.sourceforge.net/.

Conclusão

É possível notar como o FDD pode atuar em conjunto com outras metodologias, principalmente com o Scrum, encaixando-se perfeitamente como metodologia de engenharia ágil de software com projeto ágil de software.

Além disso, é possível notar que as boas práticas do FDD podem entrar em embate com o XP, na forma em que o código é tratado por cada uma das metodologias. Lembrando que as metodologias possuem características que podem ser adaptadas à necessidade de cada empresa, se notarmos o foco principal em todas as metodologias, temos o desenvolvimento por incremento, a comunicação constante com o cliente e a integração continua.

Referências

Leia também

Artigos relacionados