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.
- Desenvolvimento de modelo abrangente (Análise orientada por objetos);
- Construção de lista de funcionalidades (Decomposição funcional);
- Planejar por funcionalidade (Planejamento incremental);
- Detalhe por funcionalidade (Desenho orientado a objetos);
- Construção por funcionalidade (Programação e teste orientado a objetos).
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 é:
- Levantamento do domínio da aplicação = 1%;
- Projeto = 40%;
- Inspeção do projeto = 3%;
- Desenvolvimento = 45%;
- Inspeção do código = 10%;
- Integração = 1%.
Além disso, o FDD possui as chamadas melhores práticas que indicam boas práticas ao desenvolver com o FDD, são elas:
- Modelagem Orientada a Objetos do Domínio;
- Desenvolvimento por funcionalidade;
- Classe proprietária, ou seja, a unidade é feita individualmente, evitando-se assim conflitos na equipe;
- Equipes de recursos: são equipes pequenas, destinadas a desenvolver recursos necessários ao projeto, de forma secundária;
- Inspeção é realizada constantemente para garantir a boa qualidade do código e do projeto;
- Gerenciamento de configuração;
- Integração contínua para demonstrar constantemente as funcionalidades ao cliente e;
- Visibilidade de progressos e resultados.
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
- //www.devmedia.com.br/uma-visao-geral-sobre-metodologia-agil/27944
- http://www.featuredrivendevelopment.com
- http://www.heptagon.com.br/fdd, acessado em maio de 2013
