home Sem categoria Feature Driven Development (FDD)

Feature Driven Development (FDD)

O processo Feature Driven Development (FDD) é baseado no método COAD, que é uma metodologia de análise orientada a objetos, que tem como foco o estudo de problemas com fundamentos baseados em conceitos palpáveis, e também se baseia em processos interativos para entendimento do contexto será analisado.

Segundo Coad, uma funcionalidade “é uma função com valor para o cliente que pode ser desenvolvida em duas ou menos semanas”, pois uma das características do FDD é realizar a apresentação de todo um conjunto de features em um período de tempo fixo.

1 Papéis do FDD no SCRUM

1.1 Gestor do Projeto / Product Owner

O gestor do projeto é quem trata das questões administrativas do projeto, onde possui autonomia para decidir o que deverá ser feito, priorizando toda e qualquer funcionalidade que entregue valor e consiga ser realizada durante aquele período de tempo pré-determinado.   

É o responsável também por uma equipa pequena, assegurando boas condições de trabalho para aumentar o rendimento de todos os envolvidos, além de decidir o que será realizado durante a sprint definida.

1.2 Gestor de Desenvolvimento / Scrum Master

O gestor de desenvolvimento é responsável por retirar qualquer impedimento que a equipe possua, além de fazer com que as reuniões necessárias aconteçam.

Ele também deve avaliar se o código realizado pelo time de desenvolvimento está nos padrões do projeto, e caso não esteja, ele deverá apontar melhorias ou sugestões que colaborem no amadurecimento da equipe, em questão ao código e também de time.

1.3 Equipe de Design / Equipe de UX

A equipe de design à partir da análise da arquitetura e documentação do projeto e/ou produto trabalhado, será responsável por toda a questão visual a ser realizado, pensando inclusive em questões de usabilidade.

1.4 Dono de Classe / Desenvolvedor

O dono de classe é membro do time de desenvolvimento, onde estará sob comando do gestor de desenvolvimento. Ele é responsável por questões relacionadas a arquitetura e testes, mas sua principal atividade é a implementação das features definidas pelo gestor do projeto.

1.5 Escritor Técnico / Analista de Requisitos

O escritor técnico é responsável pelo entendimento do produto, tendo que conhecer a área de atuação do projeto e/ou produto trabalhado, devendo ser envolvido em grande parte das decisões dos produtos, pois é ele que assegura que o sistema siga as regras de negócio de cada funcionalidade.

2 Boas Práticas

Para que o FDD flua de maneira correta existem algumas boas práticas em sua utilização, entretanto pregam a adaptabilidade no ambiente de desenvolvimento:

  • Modelagem orientada a objetos de domínio: a modelagem deve ser básica, apenas algo ilustrativo para os envolvidos no projeto.
  • Desenvolvimento por feature: implementação orientada por funcionalidade.
  • Código proprietário: o código deve ser realizado apenas por um desenvolvedor, ou seja, iniciado e terminado pelo mesmos desenvolvedor, entretanto, não impede de ser realizado o pair programming com outro desenvolvedor da equipe.
  • Equipe: equipe destinada a desenvolver funcionalidades necessárias ao projeto.
  • Inspeções: deve ser realizado o code review, para garantir que o que está sendo enviado para o ambiente de uso não resultará em bugs e problemas futuros.
  • Integração regular: em um determinado período de tempo fixo devem ser integradas as características já terminadas, permitindo a verificação de erros e também criando uma versão atual que pode ser demonstrada ao cliente.
  • Gerência de configuração: ter ambientes diferentes com versões da funcionalidade desenvolvida, atualmente é muito utilizado um ambiente de desenvolvimento, um de homologação e outro que é o ambiente estável para que os clientes utilizem.
  • Reportar/Visibilidade dos resultados: todos os envolvidos devem saber o status de desenvolvimento das funcionalidades que foram desenvolvidas, pois isso é uma maneira de aprendizado.

3 Processos Básicos

Alguns processos a serem desenvolvidos para o funcionamento básico do FDD são os seguintes:

  • Desenvolvimento de modelo abrangente (Análise orientada por objetos);
  • Construção de lista de funcionalidades;
  • Planejamento incremental por funcionalidade;
  • Projeção por funcionalidade;
  • Construção por funcionalidade.

Feature Driven Development (FDD)

4 Progresso da Equipe

O progresso da equipe é feito através de cada item adicionado para ser realizado no início do planejamento do desenvolvimento, onde deve ser estimado um nível de esforço e o nível de prioridade da funcionalidade em questão e nas reuniões que serão realizadas diariamente é feito o acompanhamento, que é quando deve ser alterado o status de desenvolvimento da feature, onde podem ser simbolizados por cores de “em andamento”, “entregue” e “atrasada”, ou simplesmente realizar a estimativa em horas que ainda resta para que a tarefa seja entregue.

A mais comum atualmente, é dividir a feature em dias de desenvolvimento, por exemplo, se me comprometi a desenvolver a feature, deverei dividi-la em funcionalidades menores que caberão em 8h de desenvolvimento, pois assim seu acompanhamento será mais fácil. É comum dividir a feature da seguinte maneira:

  • Levantamento do domínio da aplicação = 1%;
  • Conhecimento da funcionalidade = 40%;
  • Inspeção do projeto = 3%;
  • Desenvolvimento = 45%;
  • Inspeção do código = 10%;
  • Integração = 1%.

Sendo que a parte de inspeção do código e integração também devem ser estimadas quando o time de desenvolvimento por estimar o esforço para a feature em questão.

5 Documentação FDD

A documentação do FDD não é muito diferente das documentações que são comuns de serem utilizadas em metodologias ágeis. A ideia principal para a documentação é de que a feature deve entregar valor ao cliente, seguir as boas práticas e os processos básicos. Cada processo deve ser descrito em no máximo duas páginas, seguindo a estrutura: Entrada, Tarefas, Verificação e Saídas.

5.1 Documentação de Funcionalidades

A estrutura da documentação de features segue o seguinte padrão:

<Ação> <resulta em> <objeto>

Como por exemplo:

  • Calcular o total de uma venda;
  • Avaliar o desempenho de um vendedor;
  • Validar a senha de um usuário.

Feature Principal

  • Gerenciamento de senhas;

Conjunto de Features

  • Validar a senha de um usuário;

Features

  • Verificar quantidade de caracteres;
  • Verificar se na senha possui número;
  • Verificar se na senha possui letra maiúscula;
  • Verificar se na senha possui letra minúscula;
  • Verificar se na senha possui símbolo.

5.2 Revisão da Documentação

As inspeções nas documentações realizadas previnem futuros bugs no desenvolvimento, permitem a transferência de conhecimento correto, dá ao desenvolvedor os padrões que devem ser seguidos e permitem extrair métricas para melhorias tanto em processos de documentação como nos processos de desenvolvimento. Lembrando que tanto a revisão da documentação, quanto de código não são uma avaliação pessoal de performance.

6 Conclusão

O FDD é uma metodologia ágil extremamente adaptável, podendo ser acoplada facilmente à também metodologia ágil SCRUM, que tem suas vantagens pelos eventos que devem ser realizados no decorrer da sprint de desenvolvimento, permitindo um maior acompanhamento de tudo que foi proposta a ser desenvolvido, e a principal vantagem do FDD é considerar o todo maior que cada parte separadamente, pois isso estimula o espírito de equipe, e faz com que todos entendam o que o produto é, para realizar o desenvolvimento da feature, evitando futuros problemas na implementação.

O FDD é orientado às necessidades do produto, e acredito que pode agregar bastante no desenvolvimento do mesmo, pelo fato do responsável pelo produto priorizar as tarefas que irão agregar valor e em paralelo a correção de problemas que poderão aparecer.

Gostou? Compartilhe:

Letícia Barcelos

Letícia Barcelos

Graduanda em Sistemas de Informação e analista de desenvolvimento trainee na Cedro Technologies, entusiasta de novas tecnologias.