É notável que a F.D.D. (Feature Driven-Development) é uma das metodologias ágeis que mais se aproxima do modelo tradicional, pois concentra uma boa parte da sua energia em etapas de planejamento, onde muitas outras não possuem um foco tão explicito. A ideia é mostrar a todos, como esta metodologia proporciona uma adaptação mais suave dos modelos tradicionais aos modelos agilistas.
22. FeatureDriven-Developement (F.D.D) Combina as melhores práticas do gerenciamento ágil de projetos, mas com nível mínimo de processo definido para modelagem de software.
34. Desenvolver Modelo Abrangente Conjunto de técnicas para entendimento do domínio de negócio em questão. Seu resultado é um modelo de objetos de alto nível, que guiará a equipe durante os ciclos de construção.
36. Construir Lista de Funcionalidades Decomposiçãofuncional do modelo de domínio, emtrêscamadastípicas: áreas de negócio, atividades de negócioe funcionalidades.
37. Planejar por Feature Nesta fase realiza-se a estimativa das funcionalidades, assim como suas dependências. O resultado é um plano de desenvolvimento, com os pacotes de trabalho na seqüência apropriada para a construção.
38.
39. Detalhar por Feature Nestafase a equipedetalhaosrequisitos e outrosartefatosparacodificação de cadafuncionalidade, incluindo testes e inspeção de design.Oresultado é o modelo de domíniomaisdetalhado e classes stubs prontasparacodificar.
40. Construir por Feature Nestafasecadaclasse stub (Esqueleto) é preenchida, testada e inspecionada, gerandocomoresultado um incremento do produtoouuma feature pronta.
43. Cenário em 2008: Complexidade alta; Iniciou o desenvolvimento em 2008; Levou cerca de 4 meses para ser feita a análise inicial; Desenvolvimento executado por equipe terceirizada; Problemas encontrados: Nenhuma entrega para o usuário; Documentação não foi respeitada pelo fornecedor; Conhecimento com equipe externa (terceirizada); Estudo de Caso – Projeto X
44. Estudo de Caso – Projeto X Cenário em 2009: Projeto teve seu desenvolvimento internalizado; Sem metodologia de desenvolvimento; Problemas encontrados: Comunicação ineficiente; Sem entrega parcial para o usuário; Conhecimento do negócio com equipe externa (terceirizada);
45.
46. Estudo de Caso – Projeto X Cenário em 2010: Necessidades de mudanças Ampliação da equipe de desenvolvimento interna; Absorver o conhecimento técnico; Implementação de grandes features, porém com entregas freqüentes; Criar/utilizar uma metodologia adequada a empresa;
47. Estudo de Caso – Projeto X RUP FDD XP Quero Liberdade Equipes Pequenas Quero Controle Equipes grandes Rigor Obrigatório Quero apenas o Processo Suficiente. Escalável para Equipes Médias e Pequenas
48. Estudo de Caso – Projeto X Alguns resultados da FDD na equipe: Integração da equipe – Formação dos times Entendimento do projeto – Criação do Modelo Abrangente Analise de negócio e requisitos – Adaptação da WBS para FBS Mudança da visão tradicional para o ágil dos envolvidos no projeto. Entregas freqüentes de features para o cliente. Entrega da primeira release
49. Resultados obtidos no projeto: Maior segurança para empresa, acostumada com o modelo tradicional; Documentação necessária feita pela equipe; Entendimento do negócio por todos os envolvidos no projeto; Aceitação da cultura Ágil, dando abertura para outras metodologias; Estudo de Caso – Projeto X
51. Referências Alguns links: FDD – www.featuredrivendevelopment.com Heptagon – www.heptagon.com.br Visão ágil – visaoagil.wordpress.com GUFDD – http://br.groups.yahoo.com/group/gufdd/ FDD em uma casca de banana - http://amagno.blogspot.com/2007/04/fdd-em-uma-casca-de-bananas.html Blog do Abu – http://blogdoabu.blogspot.com