Feature Driven Development (FDD): conheça essa metodologia

---

O processo Feature Driven Development, também conhecido como FDD, é uma metodologia de análise orientada a objetos, que tem como foco o estudo de problemas com fundamentos baseados em conceitos palpáveis. 

Também conhecida como Desenvolvimento Orientado a Recursos, também se baseia em processos interativos para entendimento do contexto que será analisado.

De acordo com Peter Coad, uma dos co-criadores, uma funcionalidade “é uma função com valor para o cliente que pode ser desenvolvida em duas ou menos semanas”, pois uma das características dessa abordagem é realizar a apresentação de todo um conjunto de features em um período de tempo fixo.

Essa orientação para resultados parciais em curtos espaços de tempo torna o modelo bastante atrativo. No entanto, para entendê-lo, fazem-se necessários uma série de conhecimentos, e é sobre isso que falaremos. Nesse artigo de Cedro, iremos te contar como esse método funciona, além de te ajudar a implementá-lo. Confira!

Qual é a principal diferença entre o FDD e o Scrum?

Para entendermos o que é Feature Driven Development é necessário sabermos em que tipo de modelo ele se encaixa, que no caso é o de desenvolvimento, extremamente focado nas atividades semanais dos times. Já o Scrum é um modelo de gerenciamento, que visa trazer agilidade nos processos de organização de uma equipe.

Por mais que sejam duas coisas distintas, na medida em que o FDD é quase que uma extensão do SCRUM, só que focalizada no desenvolvimento de softwares, esses dois modelos devem ser desempenhados juntos para que a máxima produtividade seja alcançada.

A seguir, traçaremos melhor os paralelos entre FDD e Scrum, além de informar como os dois se complementam.

Papéis do Desenvolvimento Orientado a Recursos no SCRUM

O SCRUM, um framework de gerenciamento de equipes, é amplamente utilizado. Segundo artigo da FM25, gigantes corporações do mercado, como Sony, LEGO e Simens já implementam essa técnica. Nesse sentido, o papel do Feature Driven dentro dessa alternativa é essencial.

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 equipe 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. Caso não esteja, ele deverá apontar melhorias ou sugestões que colaborem no amadurecimento da equipe, em relação ao código e também de time.

1.3 Equipe de Design/Equipe de UX

A equipe de design, a 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 realizada, pensando inclusive em termos 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 à arquitetura e testes, mas sua principal atividade é a implementação das features (funcionalidades) 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.

Boas práticas no uso do FDD

Para que o Feature Driven Development flua de maneira correta existem algumas boas práticas em sua utilização. Frequentemente, essas práticas envolvem mudanças no ambiente organizacional para que ocorram, mas têm extrema valia para o sucesso do projeto. Algumas delas são:

• 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 mesmo desenvolvedor. Entretanto, não impede de ser realizado o pair programming com outro desenvolvedor do time, e não deve excluir de maneira nenhuma o trabalho em 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 pré-determinado, 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 elaboradas. Isso é uma maneira de favorecer o trabalho conjunto, além de prevenir possíveis erros pela ausência inesperada de algum membro.

Processos Básicos

Alguns processos a serem desenvolvidos para o funcionamento básico do Feature Driven Development 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.
  

Progresso da Equipe

Como já dissemos, o Desenvolvimento Orientado por Funcionalidades é orientado por resultados. Isso significa que medir o desempenho da equipe é bastante relevante para que o método seja aplicado com eficácia, além de favorecer a gestão de talentos da corporação.

Essa medição de progresso deve ocorrer a partir de cada item que foi estipulado no início do planejamento. Nesse sentido, o nível de esforço e de prioridade dos features devem ser previamente definidos, e também serão critérios de avaliação.

Follow Ups diários e/ou semanais devem ser realizados para entender melhor o progresso dos times,  e para que as alterações nos status ocorram. Isso inclui dizer se a tarefa está “em andamento”, “entregue” ou “atrasada”.

Dentre as ações para organizar essa alocação de desempenho, a mais comum é dividir a funcionalidade em dias de desenvolvimento, na intenção de comportar as atividades de desenvolvimento das features em 8 horas de trabalho, da seguinte forma:

• 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%.

Essas estimativas são salutares para nortear como o tempo de cada tarefa será alocada, mas vale ressaltar que o foco é o cumprimento da tarefa, e todas as ações devem girar em torno disso.

Documentação no Feature Driven Development 

A documentação dessa abordagem 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 a extração de 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, mas sim do conjunto.

Conclusão

Por ser uma abordagem ágil extremamente adaptável, podendo ser acoplada facilmente à metodologia 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 proposto a ser desenvolvido. 

A principal vantagem em aplicar o desenvolvimento orientado a recursos é considerar o todo maior que cada parte separadamente. Esse fator 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.

Segundo a definição de Jeff De Luca, co-criador da metodologia, podemos definir esse o FDD como: “…uma abordagem de desenvolvimento ágil de software baseada em funcionalidades, que visa a entrega rápida e iterativa de recursos de alta qualidade para os usuários. 

Ele se concentra na colaboração entre as equipes, na decomposição do trabalho em tarefas gerenciáveis e na utilização de processos bem definidos para garantir a qualidade e a eficiência do desenvolvimento”.

Negócios e Gestão Inteligente com a Cedro Technologies! 

E aí, gostou do artigo? Aqui no blog da Cedro temos diversos conteúdos para contribuir nas rotinas das empresas e trazer muito mais sobre metodologias de desenvolvimento de projetos, além de aplicações no mercado financeiro. Acesse o blog de Cedro e confira!