Como mencionado anteriormente, Jeff Luca foi o criador da FDD. Ele propôs uma solução que é uma mistura de 5 processos que abrangem: o desenvolvimento do modelo, sua listagem, design, planejamento e a implementação de das funcionalidades. Para facilitar o entendimento do FDD, o próximo post irá descrever os 5 processos básicos de FDD.
1º processo: desenvolvimento de um modelo geral
Neste primeiro processo, o FDD empurra equipes para construir um modelo de objeto do problema de domínio. Diferentemente de outras metodologias, a modelagem no FDD é uma atividade multifuncional, iterativa e colaborativa. Os membros da equipe (desenvolvimento, especialistas em domínio e programadores-chefe) trabalham juntos para compor um modelo para a área do domínio e são guiados por um arquiteto-chefe.
A ideia é ter equipes diferentes propondo modelos diferentes e, mais tarde, depois de serem revisados, seja escolhido uma opção de modelo ou misture-os. Finalmente, o modelo de área do domínio será incorporado no modelo geral. O resultado é um modelo de objetos (e/ou de dados) de alto nível, que guiará a equipe durante os ciclos de construção.
Essa forma de concepção é uma ótima maneira de iniciar o projeto, pois permite que a equipe obtenha uma sólida compreensão do projeto, bem como uma comunicação sólida.
2º processo: criando a lista de recursos
Nesse processo a lista de funcionalidades pode ser comparada com o backlog do produto no scrum, e as funcionalidades seriam algum tipo de história de usuário. Depois de ter o modelo geral pronto, com base no conhecimento obtido durante essa fase, teremos que identificar as funcionalidades que são mais importantes para o cliente e que deverão guiar o projeto. As funcionalidades não devem levar mais do que duas semanas para serem concluídos e, se o fizerem, devem ser colocados em mais de uma funcionalidade. Elas geralmente são expressas como uma ação, resultado e objeto. O resultado desse processo é uma hierarquia de funcionalidades que representa o produto a ser construído (também chamado de product backlog, ou lista de espera do produto).
3º processo: planejando por funcionalidade
O terceiro processo, é mais ou menos sobre o planejamento em que ordem as funcionalidades serão implementadas, trata-se de organizar. Os conjuntos de tarefas que são atribuídas aos programadores. Também deve ser levado em consideração a prioridade e valor para o negócio/cliente. O resultado desse processo é um plano de desenvolvimento, com os pacotes de trabalho na sequência apropriada para a construção.
Obviamente, durante o planejamento, levamos em consideração aspectos diferentes, como riscos, dependências de complexidade, carga de trabalho da equipe, etc.
4º processo: detalhando por funcionalidade
Como durante todos os processos, utilizamos o conhecimento que recebemos do primeiro processo de modelagem. O programador chefe assume a responsabilidade de selecionar um grupo de funcionalidades que devem ser desenvolvidos a seguir. Ele também terá que determinar as classes de domínio que serão envolvidas. Depois que o grupo de funcionalidades for definido, todos começam a trabalhar juntos para fazer o trabalho, onde o especialista em domínio será responsável por analisar e projetar uma solução para cada funcionalidade. O resultado desse processo é o modelo de domínio mais detalhado e os esqueletos de código prontos para serem preenchidos.
5º processo: construindo por recurso
Com base no trabalho realizado no processo de detalhamento da funcionalidade, os responsáveis pela classe atribuída na tarefa, terão de implementar todos os itens que são necessários para suportar os detalhes da funcionalidade. Dessa forma, trabalhamos no código que foi desenvolvido, realizamos testes unitários e inspeções de código para garantir que tudo esteja correto e seja aprovado pelo programador-chefe que dará o aval para sua entrega ao cliente. O resultado desse processo é um incremento do produto integrado ao repositório principal de código, com qualidade e potencial para ser usado pelo cliente/usuário.
Fonte: https://apiumhub.com/tech-blog-barcelona/feature-driven-development/
https://pt.wikipedia.org/wiki/Feature_Driven_Development
https://imasters.com.br/artigo/13370/agile/fdd-um-metodo-agil-e-eficiente/
Nenhum comentário:
Postar um comentário