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.
