É 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.

1. Para equipes não tão ágeis

3. FDD Overview

4. Estudo de caso

5. Referências

7. Sua empresa é assim ?

8. Cheia de burocracia

9. A comunicação é ineficiente entre equipes

10. Mudanças organizacionais são sempre complicadas

11. Algumas acham que fazer software é como uma linha de montagem

12. Foco no planejamento antecipado do projeto

13. Projetos com documentações excessivas

14. Acabam ficando pesados e custosos para se manter

15. A qualidade e as boas práticas de desenvolvimento acabam ficando esquecidas.

16. Aumentando o risco do projeto e o seu insucesso

17. Você até pensa em mudar, mas acaba esbarrando no modelo de gestão da empresa.

18. Você até gostaria de fazer diferente

19. Mas mudanças são sempre complicadas

20. E acaba se sentindo preso a uma estrutura engessada

21. Como mudar, qual caminho escolher ?

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.

23. Lema:Resultados freqüentes, tangíveis e funcionais.

25. Seus criadores eram Peter Coade Jeff De Luca.

26. Foi publicada em 1999, no livro Java “Modeling in Colorwith UML”, de Peter Coad, Eric Lefebvre e Jeff De Luca.

28. Desenvolvimento orientado a Features Blocos bem pequenos de funcionalidades valorizadas pelo cliente, chamados de Features

29. Principais características Jeff De Luca Planejamento detalhado na etapa inicial e guiado para medição

30. Principais características Parking LotChart

31. Principais características Monitoramento detalhado dentro do projeto, com resumos de alto nível para clientes e gerentes.

32. Principais características Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos.

33. Fases do F.D.D. D.M.A C.L.F. P.P.F. D.P.F. C.P.F.

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.

35. Modelo de classes

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.

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.

41. Visão geral do ciclo da F.D.D.

42. Estudo de Caso

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);

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

50. + = +

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

52. Contatos Alexandre Rosa Email – alexrosa@gmail.com Twitter - @javalex Everton Lentez Email – lentez@gmail.com Guilherme Pinter Email – guilhermepinter@gmail.com