1. O que é FDD
1.1. È um método ágil
1.1.1. É uma metodologia ágil para gerenciamento e desenvolvimento de software criada em 1997 em um grande projeto em java para o United overseas Bank em Singapura
1.2. Busca o desenvolvimento por funcionalidade, requisito do sistema
1.2.1. Surgiu no final dos anos 90 e visa atender projetos iniciais ou com códigos já existentes.
1.2.1.1. Se relaciona juntamente com o SCRUM pelo fato de o SCRUM gerenciar o processo e o FDD no processo de desenvolvimento
1.2.1.1.1. Faz uso de teste de software para aprimorar a entrega. O desenvolvimento também é incremental, testes do inicio ao final do processo.
1.3. A soma das partes é maior que o todo
1.3.1. Desenvolvedor como único responsável pelo módulo que este desenvolve
1.3.1.1. Não deve perder tempo com documentação que não será utilizada para o desenvolvimento da etapa do software, contato com o cliente em todo o projeto.
1.3.1.1.1. cada passo tem foco em alguma funcionalidade do software;
2. FDD - Processos Básicos
2.1. Desenvolvimento de modelo abrangente (Análise orientada por objetos);
2.1.1. Construção de lista de funcionalidades (Decomposição funcional);
2.1.1.1. Planejar por funcionalidade (Planejamento incremental);
2.2. Detalhe por funcionalidade (Desenho orientado a objetos);
2.2.1. Construção por funcionalidade (Programação e teste orientado a objetos).
3. Boas Práticas de Desenvolvimento com FDD
3.1. Modelagem Orientada a Objetos do Domínio; a modelagem deve ser básica, apenas algo ilustrativo para os envolvidos no projeto.
3.1.1. Desenvolvimento por funcionalidade;
3.1.1.1. Classe proprietária, ou seja, a unidade é feita individualmente, evitando-se assim conflitos na equipe; - Um único desenvolvedor por módulo.
3.2. Equipes de recursos: são equipes pequenas, destinadas a desenvolver recursos necessários ao projeto, de forma secundária;
4. Fluxo de apontamento de tempo
4.1. É comum dividir a equipe em etapas capazes de organizar o tempo em que o projeto se encontra disponível até a entrega.
4.1.1. Levantamento do domínio da aplicação = 1%;
4.1.1.1. Conhecimento da funcionalidade = 40%;
4.2. Inspeção do projeto = 3%;
4.2.1. Desenvolvimento = 45%;
4.2.1.1. Inspeção do código = 10%;
4.3. Integração = 1%.
5. Documentação FDD
5.1. Documentação de Funcionalidades features seguem o seguinte padrão: <Ação> <resulta em> <objeto>
5.1.1. Construir a Lista de Funcionalidades
5.1.1.1. No FDD, os desenvolvedores garantem que a documentação esteja correta. Além disso, todas as conversas devem ser formais e documentadas.
6. Sprint FDD
6.1. Quanto menor, melhor, o tamanho do sprint é de 2 a 10 dias
6.1.1. recursos sejam entregues completos e funcionando pelo menos a cada 2 semanas.
6.1.1.1. A FDD dá grande ênfase à modelagem e ao design - mas não ao metal! A excelência técnica é incentivada em todos os níveis.
7. desenvolvimento orientado a recursos
7.1. Estágio 0: coletar dados obter uma compreensão precisa do conteúdo e contexto do projeto e desenvolver uma compreensão clara e compartilhada do público-alvo e de suas necessidades.
7.1.1. Desenvolva um modelo geral - quando o esboço é elaborado. a equipe desenvolverá modelos de domínio detalhados, que serão então mesclados em um modelo geral que atua como um esboço do sistema.
7.1.1.1. Plano por recurso- analise a complexidade de cada recurso e planeje as tarefas que devem ser realizadas pelos membros da equipe. todos os membros da equipe devem participar da avaliação das funcionalidades
7.2. Design por recurso - O Product Owner determinará o recurso que será projetado e construído. Ele também determinará os proprietários de classe e as equipes de recursos envolvidos, enquanto define as prioridades dos recursos.
7.2.1. Construído por recurso - Esta etapa implementa todos os itens necessários que darão suporte ao design. Aqui, as interfaces do usuário são construídas, assim como os componentes detalhados no design técnico, e um protótipo de recurso é criado. A unidade é testada, inspecionada e aprovada
8. Características
8.1. Blocos bem pequenos de funcionalidade valorizada pelo cliente
8.1.1. Planejamento detalhado e guia para medição
8.1.1.1. Resultado uteis a cada duas semanas ou menos
8.1.1.1.1. Rastreabilidade e relatórios com incríveis precisão
9. Origem do FDD
9.1. Foi apresentado em 1997 por Peter Coad e Jeff de Luca
9.2. Com a evolução de um processo mais antigo surgiram duas atualizações importantes do modelo foram apresentadas pelo Palmer e Mac Felsing em 2002 e pelo Anderson em 2004
9.2.1. Concepção e planejamento: basicamente consiste um pouco no geral 1 a 2 semanas antes de começar
9.2.2. Construção: desenvolvimento interações com o produto em ciclos 1 ou 2 semanas