O documento discute o modelo de desenvolvimento Feature-Driven Development (FDD), que visa melhorar a eficiência em empresas com alta burocracia e comunicação ineficiente. FDD é uma metodologia ágil que promove entregas frequentes de funcionalidades, permitindo planejamento detalhado e monitoramento contínuo, e é exemplificada por estudos de caso que mostram sua eficácia. O texto também menciona a história do FDD, suas principais características e referências para mais informações.

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

2. AGENDA Introdução

3. FDD Overview

4. Estudo de caso

5. Referências

6. ContatosIntroduçãoVamos começar....

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.

24. Um pouco da históriaCriada em 1997 num grande projeto em Java para o UnitedOverseasBank, em Singapura.

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.

27. Em 2002, Stephen Palmer e John Mac Felsing publicaram o livro “A PraticalGuide to FeatureDrivenDevelopment”, com a versão completa, atualizada e comentada da metodologia.Principais característicasResultados úteis a cada duas semanas ou menos

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

29. Principais característicasJeff De LucaPlanejamento detalhado na etapa inicial e guiado para medição

30. Principais característicasParking LotChart

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

32. Principais característicasFornece 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.AC.L.F.P.P.F.D.P.F.C.P.F.

34. Desenvolver Modelo AbrangenteConjunto 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 FuncionalidadesDecomposiçãofuncional do modelo de domínio, emtrêscamadastípicas: áreas de negócio, atividades de negócioe funcionalidades.

37. Planejar por FeatureNesta 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 FeatureNestafase 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 FeatureNestafasecadaclasse 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 XCená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 XCenário em 2010:Necessidades de mudançasAmpliaçã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 XRUPFDDXPQuero LiberdadeEquipes Pequenas Quero ControleEquipes grandesRigor ObrigatórioQuero apenas o ProcessoSuficiente.Escalável para Equipes Médias e Pequenas

48. Estudo de Caso – Projeto XAlguns resultados da FDD na equipe:Integração da equipe – Formação dos timesEntendimento do projeto – Criação do Modelo AbrangenteAnalise de negócio e requisitos – Adaptação da WBS para FBSMudanç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ênciasAlguns links:FDD – www.featuredrivendevelopment.comHeptagon – www.heptagon.com.brVisão ágil – visaoagil.wordpress.comGUFDD – 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.htmlBlog do Abu – http://blogdoabu.blogspot.com

52. ContatosAlexandre Rosa Email – alexrosa@gmail.comTwitter - @javalexEverton LentezEmail – lentez@gmail.comGuilherme PinterEmail – guilhermepinter@gmail.com