Please enable JavaScript.
Coggle requires JavaScript to display documents.
FDD (Feature-Driven Development) - Coggle Diagram
FDD (Feature-Driven Development)
Caracteriticas:
Desenvolvimento Orientado a Funcionalidades:
No FDD, o desenvolvimento de software é organizado em torno de funcionalidades específicas que são identificadas, projetadas e implementadas individualmente. Cada funcionalidade é uma unidade de trabalho distinta.
Modelagem por Domínio:
O FDD utiliza modelagem por domínio para entender o sistema e identificar as funcionalidades necessárias. Isso envolve a criação de modelos de domínio para representar o sistema e suas funcionalidades.
Equipes Multidisciplinares:
As equipes de desenvolvimento no FDD são multidisciplinares e incluem membros com diferentes conjuntos de habilidades, como analistas de negócios, designers, desenvolvedores e testadores.
Design por Inspeção:
O FDD enfatiza a importância do design detalhado de cada funcionalidade antes da implementação. O design é revisado e inspecionado para garantir que atenda aos requisitos.
Cronograma de Iterações Curtas:
O FDD divide o projeto em iterações curtas, geralmente de duas semanas, durante as quais as funcionalidades são projetadas e implementadas.
Relatórios de Progresso:
O FDD utiliza relatórios de progresso que fornecem informações sobre o status de cada funcionalidade e do projeto como um todo. Isso ajuda na comunicação e no acompanhamento do progresso.
Ênfase na Qualidade:
O FDD coloca uma forte ênfase na qualidade do software, com revisões frequentes, testes e garantia de qualidade.
Gerenciamento de Riscos:
O FDD aborda riscos identificados durante o desenvolvimento de software e busca mitigá-los de maneira proativa.
Flexibilidade:
Embora o FDD tenha um processo estruturado, ele permite uma certa flexibilidade para acomodar mudanças de requisitos à medida que o projeto avança.
Documentação Leve:
O FDD não exige uma quantidade excessiva de documentação, mas enfatiza documentar as informações necessárias para compreender e desenvolver as funcionalidades.
Papéis de FDD:
Gerente de projeto:
É quem trata das questões administrativas do projeto;
Possui autonomia para decidir o que deverá ser feito;
Prioriza toda e qualquer funcionalidade que entregue valor e consiga
ser realizada durante um período de tempo pré-determinado.
É o líder administrativo e financeiro do projeto: tem a palavra final no que se trata de escopo,
cronograma e recursos do projeto.
Gerente de desenvolvimento:
É responsável por retirar qualquer impedimento que a equipe possua,
Faz com que as reuniões necessárias aconteçam (principalmente com os
clientes/usuários finais);
Deve avaliar se o código realizado pelo time de desenvolvimento está nos
padrões do projeto.
É o líder nas atividades diárias do desenvolvimento. É responsável por resolver qualquer tipo de
conflito que venha a ocorrer dentro da equipe.
Arquiteto-chefe:
É responsável por questões relacionadas à definição dos componentes de software, suas propriedades externas, e seus
relacionamentos com outros softwares.
É responsável pela modelagem do projeto. Deve auxiliar a equipe de desenvolvedores e
contribuir na construção do software.
Proprietários de código:
São os responsáveis pela modelagem e desenvolvimento de novas funcionalidades de um
software.
A principal atividade de um desenvolvedor/programador é a implementação das features definidas ou pelo Gerente de Projetos ou
pelo Gerente de Desenvolvimento.
Especialistas do Domínio (negócio) (cliente)
Pode ser qualquer pessoa que tenha o melhor conhecimento sobre o software em
particular, e pode ajudar as Equipes a entendê-lo.
Sua responsabilidade é de adquirir e transmitir informações a
respeito do funcionamento dos requisitos do sistema.
Fases e Processos:
2 fases: do FDD
Concepção e Planejamento:
Pensar um pouco antes
de fazer (tipicamente de 1 a 2 semanas);
Construção:
Fazer de forma iterativa (tipicamente
em iterações de 2 semanas).
Processos do FDD: (são 5)
1 . Desenvolver um Modelo Abrangente:
1) O primeiro momento é de conhecer para analisar o sistema e o
contexto em que ele está inserido.
A partir disso são estudados os domínios do sistema e um modelo
geral é desenvolvido com base nesses estudos.
2) Criado o modelo geral, pequenas equipes são responsáveis por criar
uma modelagem superficial para cada área de domínio do sistema.
Cada modelo criado é revisado por outros membros do projeto, que não fazem parte da equipe que criou o modelo, a fim de escolher o melhor modelo de domínio para cada área.
Assim, ao final do processo os modelos escolhidos são unificados no
modelo geral do domínio do sistema e o trabalho é iniciado.
Construir a Lista de Funcionalidades:
1) Nesta fase é criada uma lista de funcionalidades do sistema,
descrevendo e identificando a área de domínio de cada uma delas.
As funcionalidades são importantes para o processo porque cada uma é uma pequena tarefa que precisa ser implementada ao projeto.
2) Os itens de funcionalidade não devem levar mais de duas semanas para serem concluídos e são ordenados na lista por ordem de prioridade no desenvolvimento.
Por exemplo, uma lista de funcionalidades pode conter os seguintes itens: “validar a senha do usuário”, “liberar o login” e “gerar relatório de vendas”.
Planejar por Funcionalidade:
1) De acordo com a lista de funcionalidades é feito o planejamento de
desenvolvimento delas.
2) Para cada funcionalidade são designados programadores-chefe
que ficarão responsáveis por algumas classes ou códigos.
3) A partir disso são formadas as equipes de planejamento e cada
integrante da equipe é encarregado de uma parte do projeto.
Detalhar por Funcionalidade:
1) Assim como na primeira fase, nessa etapa é criada uma modelagem com as funcionalidades a serem desenvolvidas.
A diferença dessa modelagem é que o programador chefe a cria de acordo com uma funcionalidade específica e a divide em classes, métodos e atributos.
Quando finalizada, a funcionalidade passa por testagens da
equipe desenvolvedora.
Construir por Funcionalidade
1) Após a modelagem passar por diversos testes, o código começa a ser implementado no sistema. Dessa forma, as funcionalidades são incorporadas e já podem ser colocadas em prática.
Efetivado o código, ele é escrito e essa funcionalidade é
concluída.
Fazem parte dessa fase a implementação das regras de negócio das classes, a inspeção do código, a condução dos testes unitários e o release da funcionalidade.
Padrão ETVX:
Entrada:
Especifica e define os critérios de entradas para as etapas.
Tarefas:
E composto por uma lista com as tarefas que deverão ser realizadas.
Verificação:
Especifica tipos de avaliação (internas e internas) e inspeções de projetos e códigos.
Saida:
Especifica os critérios de saída, definindo os produtos tangíveis.