Please enable JavaScript.
Coggle requires JavaScript to display documents.
FDD - Feature-Driven Development - Coggle Diagram
FDD - Feature-Driven Development
Significa desenvolvimento guiado a funcionalidades, seu principal objetivo é entregar ao cliente um software funcional em tempo hábil, seguindo o modelo iterativo e incremental do processo de desenvolvimento de software.
Propõe um equilíbrio entre filosofias tradicionais e
ágeis;
É prático para o trabalho com projetos iniciais, com grandes equipes, ou projetos com codificações já existentes.
Lema do FDD: “Resultados frequentes e
funcionais”
Coloca ênfase nas práticas orientadas a objetos e na gestão eficaz do desenvolvimento de software.
Características:
Modelagem de Domínio:
Característica: No FDD, a modelagem de domínio é uma atividade crítica. Isso envolve a criação de modelos de objetos para representar as principais funcionalidades do sistema.
Objetivo: Compreender e representar o domínio do problema para que a equipe tenha uma visão clara das funcionalidades necessárias.
Um dos objetivos do FDD é entregar para o cliente
funcionalidades com rapidez, em um período fixo de tempo, em geral, duas ou menos semanas;
Desenvolvimento por Funcionalidade (Feature):
Característica: O FDD divide o desenvolvimento em unidades chamadas "features" (funcionalidades). Cada feature é uma unidade distinta de funcionalidade que pode ser implementada e entregue independentemente.
Objetivo: Entregar valor incremental ao cliente, com cada feature sendo implementada em uma iteração.
Lista de Features (Feature List):
Característica: Antes de começar o desenvolvimento, a equipe cria uma lista abrangente de features que representam todas as funcionalidades necessárias para o sistema.
Objetivo: Fornecer uma visão geral do escopo do projeto e servir como base para o planejamento e acompanhamento do progresso.
Design e Desenvolvimento Iterativo:
Característica: O FDD adota uma abordagem iterativa para o design e desenvolvimento, onde cada iteração é focada na implementação de uma ou mais features.
Objetivo: Permitir adaptação a mudanças nos requisitos e garantir entregas regulares de funcionalidades completas.
Inspeção Regular de Progresso:
Característica: A equipe realiza inspeções regulares para avaliar o progresso do desenvolvimento, revisar o código e garantir a qualidade das funcionalidades entregues.
Objetivo: Identificar problemas precocemente e garantir que os padrões de qualidade e design sejam mantidos.
Modelagem por Funcionalidade (Feature Modeling):
Característica: Além da modelagem de domínio, o FDD promove a criação de modelos específicos para cada feature, auxiliando no entendimento e na implementação eficaz.
Objetivo: Melhorar a comunicação entre membros da equipe e garantir que todos tenham uma compreensão clara das features a serem implementadas.
Gerenciamento de Regras de Negócios (Business Rules Management):
Característica: O FDD inclui um foco especial na identificação e gerenciamento de regras de negócios, que são capturadas durante a modelagem de domínio.
Objetivo: Garantir que as regras de negócios sejam claramente compreendidas e incorporadas nas funcionalidades desenvolvidas.
Inspeções de Design e Código:
Característica: O FDD enfatiza a importância de inspeções regulares de design e código para garantir a consistência, qualidade e aderência aos padrões definidos.
Objetivo: Identificar e corrigir problemas de design e código antes que se tornem problemas mais sérios.
Integração Contínua:
Característica: A prática de integração contínua é enfatizada, garantindo que as novas features se integrem sem problemas ao restante do sistema.
Objetivo: Manter um código sempre funcional e pronto para entrega.
Equipe Multifuncional:
Característica: O FDD promove equipes multifuncionais que possuem todas as habilidades necessárias para projetar, desenvolver e testar features.
Objetivo: Facilitar a colaboração e a comunicação eficaz entre os membros da equipe.
Padrão ETVX:
Entry (Entrada):
Definição: A fase de entrada é o ponto inicial do processo ou tarefa. Ela estabelece as condições e pré-requisitos necessários para iniciar a tarefa com sucesso.
Propósito: Garantir que todas as condições necessárias estejam presentes antes que a tarefa ou processo seja iniciado.
Exemplo: Antes de começar a desenvolver um novo recurso de software, a entrada pode incluir a conclusão de uma análise de requisitos e a disponibilidade de recursos necessários.
Task (Tarefa):
Definição: A fase de tarefa descreve as atividades ou ações que devem ser realizadas como parte do processo ou tarefa em questão.
Propósito: Especificar claramente as etapas a serem seguidas e as atividades a serem realizadas durante a execução da tarefa.
Exemplo: Na fase de tarefa do desenvolvimento de software, as atividades podem incluir a escrita de código, a realização de testes e a documentação.
Verification (Verificação):
Definição: A fase de verificação envolve a avaliação ou revisão do trabalho realizado durante a fase de tarefa para garantir que atenda aos padrões e requisitos especificados.
Propósito: Assegurar que o trabalho realizado está em conformidade com as expectativas e padrões estabelecidos.
Exemplo: Na verificação de código, os pares de programação podem revisar o código para garantir a conformidade com as diretrizes de codificação e a ausência de erros.
Exit (Saída):
Definição: A fase de saída marca a conclusão do processo ou tarefa. Ela verifica se os objetivos foram alcançados e se os resultados são satisfatórios.
Propósito: Confirmar que os resultados finais atendem aos critérios de aceitação e estão prontos para serem passados para a próxima fase ou liberados.
Exemplo: Na conclusão de uma iteração de desenvolvimento, a saída pode incluir uma versão funcional do software, pronta para testes de aceitação do cliente.
Papéis:
Gerente de Projeto:
É o líder administrativo e financeiro do projeto: tem a palavra final no que se trata de escopo,
cronograma e recursos do projeto.
Desempenha um papel crucial na liderança técnica da equipe, garantindo que a visão arquitetônica seja mantida e que as melhores práticas de desenvolvimento sejam seguidas.
● É 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;
● Responsável por assegurar a integridade do design e da arquitetura do sistema.
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.
No FDD, o código deve ser realizado apenas por um desenvolvedor, ou seja, iniciado e terminado pelo mesmo programador.
Mantém um ambiente de desenvolvimento eficiente, garantindo compilações e integrações regulares e bem-sucedidas.
Especialistas do Domínio:
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.
Podem ser usuários, clientes, patrocinadores (servem como base de conhecimento dos desenvolvedores).
Contribui para a compreensão profunda do domínio, auxiliando na modelagem e na tomada de decisões relacionadas ao desenvolvimento.
Gerente de Desenvolvimento:
É o líder nas atividades diárias do desenvolvimento. É responsável por resolver qualquer tipo de
conflito que venha a ocorrer dentro da equipe.
Facilita o andamento do projeto, gerenciando eficazmente os recursos e assegurando que a equipe alcance seus objetivos.
Ele deverá apontar melhorias ou sugestões que colaborem no amadurecimento da equipe, em relação ao código e também de time.
● Deve avaliar se o código realizado pelo time de desenvolvimento está nospadrões do projeto;
● Faz com que as reuniões necessárias aconteçam (principalmente com os clientes/usuários finais);
● É responsável por retirar qualquer impedimento que a equipe possua;
● Gerencia o processo de desenvolvimento, incluindo prazos e recursos.
Arquiteto-chefe:
Desempenha um papel vital na definição e manutenção da arquitetura do sistema, garantindo sua coesão e evolução adequada.
É responsável pela modelagem do projeto. Deve auxiliar a equipe de desenvolvedores e contribuir na construção do software.
É responsável por questões relacionadas à definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares.
Busca facilitar a organização dos componentes de um software e melhorar a flexibilidade e portabilidade do sistema, gerando mais facilidade de manutenção.
Fases e Processos:
Concepção e Planejamento:
Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas);
CLF (Construir a Lista de Funcionalidades):
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.
Atividades principais:
Decomposição em Subfuncionalidades: Dividir funcionalidades complexas em subfuncionalidades menores.
Priorização: Priorizar as funcionalidades com base nas necessidades do cliente.
Identificação de Funcionalidades: Identificar as funcionalidades necessárias.
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.
PPF (Planejar por Funcionalidade):
De acordo com a lista de funcionalidades é feito o planejamento de desenvolvimento delas.
Para cada funcionalidade são designados programadores-chefe que ficarão responsáveis por algumas classes ou códigos.
Atividades principais:
Avaliação de Recursos: Avaliar os recursos necessários para cada feature.
Estabelecimento de Prazos: Definir prazos e iterações para o desenvolvimento.
Lista Mestre de Features: Criar uma lista detalhada de todas as features a serem desenvolvidas.
A partir disso são formadas as equipes de planejamento e cada integrante da equipe é encarregado de uma parte do projeto.
DMA (Desenvolver um Modelo Abrangente):
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.
Criado o modelo geral, pequenas equipes são responsáveis por criar uma modelagem superficial para cada área de domínio do sistema.
Atividades principais:
Identificação de Classes: Identificar as principais classes no domínio.
Definição de Relacionamentos: Estabelecer os relacionamentos entre as classes.
Modelagem Visual: Utilizar diagramas para representar visualmente o modelo.
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.
Construção:
Fazer de forma iterativa (tipicamente em iterações de 2 semanas).
DPF (Detalhar por Funcionalidade):
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.
Atividades principais:
Design Detalhado: Criar designs detalhados para cada funcionalidade.
Modelagem Visual: Utilizar diagramas para representar visualmente o design.
Revisão de Design: Realizar revisões para garantir a coesão e integridade do design.
Quando finalizada, a funcionalidade passa por testagens da equipe desenvolvedora.
CPF (Construir por Funcionalidade):
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.
Atividades principais:
Implementação: Escrever código para implementar cada funcionalidade.
Testes Unitários: Criar testes unitários para garantir a funcionalidade correta.
Integração Contínua: Integrar continuamente as funcionalidades ao longo do processo de construção.
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.