Desenvolvimento guiado por funcionalidades: o que é e por que e como usar

Ao se falar em metodologia Ágil, você provavelmente pensa no scrum. Faz sentido, pois o scrum é citado como a metodologia mais usada por gerentes de produto e equipes de desenvolvimento nos últimos 13 anos.

Embora o scrum seja a metodologia mais usada, uma rápida leitura dos relatórios anuais do State of Agile mostra que outras metodologias, como Kanban ou algum híbrido de scrum com outras metodologias, ganharam popularidade. Uma delas é o desenvolvimento guiado por funcionalidades ou metodologia ágil FDD.

O desenvolvimento guiado por funcionalidades pode não ser tão discutido ou usado quanto outras metodologias Ágil. Porém, vale a pena dar uma olhada nele, principalmente quem precisar adaptar o desenvolvimento Ágil para um projeto de longo prazo e com uma grande equipe.

O que é FDD feature-driven development ou desenvolvimento guiado por funcionalidades?

Em 1997, Jeff De Luca trabalhava em uma equipe de 50 pessoas num projeto de desenvolvimento de software em Singapura, com duração de 15 meses. A fim de deixar a equipe de desenvolvimento mais adaptável e responsiva às necessidades do cliente, ele criou um modelo de desenvolvimento com cinco etapas, que focam o desenvolvimento de recursos em breves iterações.

O Scrum, o XP e outras metodologias Ágil usam uma abordagem iterativa para entregar um software. Por outro lado, as cinco etapas do FDD exigem que a equipe siga um conjunto de práticas recomendadas de engenharia à medida que desenvolve pequenos conjuntos de recursos em iterações de uma a duas semanas. Essas cinco etapas garantem um desenvolvimento contínuo, de forma que o projeto cresça e os novos membros da equipe se entrosem muito mais rapidamente.

Práticas recomendadas no desenvolvimento guiado por funcionalidades

Abordaremos as cinco etapas do ciclo de vida do projeto FDD mais à frente no artigo; primeiro, é importante entender os princípios fundamentais do desenvolvimento guiado por funcionalidades.

• Modelagem dos objetos do domínio: as equipes criam um diagrama de classe para descrever objetos em um domínio e as relações entre eles. Esse processo economiza tempo, pois você descobre qual função adicionar a cada recurso.
• Desenvolvimento por recurso: se uma função não puder ser implementada dentro de duas semanas, ela deve ser dividida em recursos menores e gerenciáveis.
• Propriedade individual da classe (ou código): cada classe ou grupo de código é delegado a um único proprietário.
• Equipes de recursos: embora uma só pessoa seja responsável pelo desempenho e qualidade de cada classe, um dado recurso pode envolver mais de uma classe, portanto, todos na equipe de recursos contribuem para as decisões de design e de implementação.
• Inspeções: as equipes de FDD realizam inspeções para detectar defeitos e garantir a melhor qualidade.
• Gerenciamento da configuração: prática que envolve a identificação do código-fonte de todos os recursos e a documentação das alterações.
• Cronograma regular do projeto: uma prática recomendada para que a equipe sempre tenha um sistema atualizado a mostrar ao cliente.
• Relatórios do progresso: os gerentes de projeto devem fornecer relatórios frequentes sobre o progresso do trabalho concluído.

Membros da equipe de FDD

A equipe de modelagem do FDD inclui as seguintes funções principais: 

• O gerenciador de projeto supervisiona todo o projeto.
• O arquiteto-chefe é responsável pelo projeto e pela modelagem do sistema em geral. Ele trabalha com outros desenvolvedores qualificados na fase de planejamento do ciclo de desenvolvimento.
• O gerente de desenvolvimento lidera e orienta a equipe de desenvolvimento, além de supervisionar as atividades diárias de programação.
• O programador-chefe auxilia na análise e no design e também pode ser chamado para gerenciar pequenas equipes de desenvolvimento.
• O proprietário da classe é membro das equipes de desenvolvimento menores que são lideradas pelo programador-chefe. As responsabilidades são projetar, codificar, testar e documentar recursos.
• O especialista em domínios é o membro de uma equipe que entende o problema que o cliente quer resolvido. Os desenvolvedores confiam no conhecimento desse especialista para que trabalhe e entregue o que é mais importante ao cliente.

Por que usar o desenvolvimento guiado por funcionalidades?

É bom considerar o uso da metodologia FDD se o seu projeto ficar grande e complexo demais para que equipes menores de scrum lidem efetivamente com o volume de trabalho. Essa metodologia Ágil orientada por recursos é adequada em projetos de longo prazo que mudam e adicionam recursos continuamente em iterações regulares e previsíveis. 

Por ser muito flexível, o FDD funciona com equipes pequenas a grandes equipes multifuncionais, pois foi projetado para focar sempre o que o cliente precisa e deseja.

Vantagens do desenvolvimento guiado por funcionalidades

• Passa à equipe uma compreensão muito boa do escopo e do contexto do projeto.
• Exige menos reuniões - uma das reclamações frequentes sobre o Ágil é o excesso de reuniões. O scrum usa as reuniões diárias para se comunicar; já o FDD usa a documentação.
• Usa uma abordagem centrada no usuário. No scrum, o gerente de produto geralmente é considerado o usuário final; no FDD, é o cliente.
• Funciona bem em projetos de grande escala, de longo prazo ou em andamento. Por ser muito flexível, essa metodologia pode crescer conforme sua empresa e o projeto crescem. As cinco etapas bem definidas facilitam o entrosamento de novos membros da equipe ou novos contratados no projeto.
• Divide conjuntos de recursos em partes menores e em lançamentos iterativos regulares, o que facilita o rastreamento e a correção dos erros de codificação, reduz riscos e permite resultados rápidos para atender às necessidades do cliente.

Desvantagens do desenvolvimento guiado por funcionalidades

• O FDD não é ideal em projetos menores e não funciona em projetos com apenas um desenvolvedor, pois fica difícil para poucas pessoas assumirem as várias funções sem ajuda.
• Depende muito de um programador-chefe que atue como coordenador, designer-chefe e mentor dos novos membros da equipe.
• Não fornece nenhuma documentação escrita ao cliente, embora haja muita comunicação documentada entre os membros da equipe durante os ciclos de desenvolvimento do projeto. Portanto, o cliente não obtém uma prova do próprio software.
• Enfatiza a propriedade de código individual em vez da propriedade compartilhada da equipe.
• Pode não funcionar em sistemas mais antigos, nos quais já existe um sistema em vigor e nenhum modelo geral para defini-lo. Pode ser necessário recomeçar do zero. 

As cinco etapas no ciclo de vida do projeto FDD

Agora que você entendeu os benefícios que o desenvolvimento guiado por funcionalidades pode oferecer, vamos nos aprofundar nas etapas do processo do desenvolvimento para você já começar a implementá-las com sua equipe.

Etapa 1: desenvolva o modelo geral

É quando você faz um esboço do modelo do domínio — o problema de negócios que você quer que o projeto de desenvolvimento de software resolva. A equipe trabalha em estreita colaboração com o arquiteto-chefe para definir o escopo e o contexto do sistema. Como esboço para o seu sistema, vários modelos de domínio devem ser combinados num geral.

Etapa 2: crie uma lista de recursos

A lista de recursos é semelhante ao backlog do produto no scrum. Identifique os recursos importantes ao cliente. Eles são expressos como ação, resultado e objeto (como “validar o número da conta do usuário”). 

É recomendável demorar até duas semanas para desenvolver um recurso. Mais do que isso, e ele deverá ser dividido em recursos menores.

3: planeje por recurso

Determine a ordem em que os recursos da sua lista serão desenvolvidos e implementados. Considere potenciais riscos, dependências, carga de trabalho individual e de equipe, e qualquer outro obstáculo que venha a prejudicar o desenvolvimento dos recursos.

Em seguida, delegue um conjunto de recursos aos programadores mais aptos e com capacidade para desenvolvê-los dentro do prazo especificado. 

4: crie designs por recurso

O programador-chefe determina quais recursos serão projetados e construídos em uma iteração de duas semanas. É ele quem também define as prioridades do recurso e determina quem se envolverá na equipe desse recurso. Antes de prosseguir, é necessário que toda a equipe faça uma análise do design.

5: construa por recurso

Nesta etapa, são implementados todos os itens necessários para auxiliar o design do recurso. A interface do usuário é projetada, e um protótipo do recurso é construído e testado. Se o recurso for aprovado, a versão concluída poderá ser adicionada à compilação principal e disponibilizada aos clientes. 

Se você trabalha em uma grande empresa e lidará com processos grandes e complexos, usar uma abordagem Ágil orientada por recursos pode ser ideal. O FDD foi projetado para crescer com a sua empresa e o seu projeto, e funciona bem em produtos que exigem um desenvolvimento contínuo e de longo prazo. Com o foco nos recursos, você atende às necessidades do cliente com mais rapidez e identifica e corrige os problemas que venham a surgir.