Nem só de Scrum vive o ágil, já ouviu falar em FDD?

Para entendermos sobre o FDD devemos voltar aos anos 1997 e conhecer um pouco da história de Jeff DeLuca, um desenvolvedor autodidata nascido em 1964 que por anos trabalhou na IBM onde desenvolveu vários projetos como por exemplo um software de rede para conectar diferentes tipos de sistemas de computadores da IBM, saindo de lá em 1993, como Arquiteto Sênior de Sistemas para formar sua própria empresa, a Nebulon Pty.

Em 1997 ao participar de um grande projeto de desenvolvimento em java Jeff concebeu a metodologia FDD que por sua essência foca na entrega frequente de pequenos trechos (funcionalidades ou iterações) de ”software funcionando” (parece com SCRUM ?). Este projeto tinha como características um prazo de 15 meses e foi tocado por um time de 50 pessoas para um banco de Cingapura, logo após este projeto outro foi iniciado, desta vez com um time de  250 pessoas e duração de 18 meses.

O FDD foi descrito em detalhes pela primeira vez no capítulo 6 do livro de Modelagem Java em cores com UML por Peter Coad, Eric LeFebvre e o proprio Jeff De Luca, como sendo um é um processo de desenvolvimento de software centrado no cliente e em sua arquitetura, O termo “cliente” no FDD é usado para representar o que no Agile Modeling (AM) chamamos de partes interessadas  e no eXtreme Programming (XP) é chamado de clientes.Outra característica básica do FDD é que o mesmo e orientado a recursos, ou seja,os recursos são a base na metodologia FDD.

Um recurso pode ser expressado por um pequeno incremento de valor ao cliente. Por exemplo, “Calcular o total de uma venda”, “Validar a senha de um usuário” ou “Autorizar a transação de vendas de um cliente”. Os recursos são para o FDD, assim como as histórias do usuário para o Scrum.

Ciclo de vida  FDD

Existem cinco atividades principais no FDD que são executadas iterativamente. A primeiro é Desenvolver um Modelo Geral,seu objetivo é identificar e entender os fundamentos do domínio que seu sistema está abordando e, ao longo do projeto, desenvolver esse modelo para refletir o que está construindo. A segunda etapa é Criar a Lista de Funcionalidades, agrupando-os em conjuntos e áreas de assunto relacionados. Esses dois primeiros passos são mapeados para o esforço inicial. Em seguida, Planeja-se as Funcionalidades, é onde se produz o plano de desenvolvimento e atribui-se a propriedade dos recursos  do desenvolvimento do projeto baseando-se em suas dependências, na equipe de desenvolvimento, na carga horária e na complexidade das funcionalidades. A maior parte do esforço em um projeto de FDD, aproximadamente 75%, é composta pelas quarta e quinta etapas: Design por Funcionalidades e Construção por Funcionalidade. Essas duas atividades  incluem tarefas como modelagem detalhada, programação, teste e empacotamento do sistema.

FDD x SCRUM

Sabe-se que o FDD e o  Scrum estão intrinsecamente relacionados, porém algumas diferenção são de grande importância serem mencionas tais como: o FDD e focado em recursos (em oposição as entregas do SCRUM). Recursos são uma peça fundamental do FDD; eles são para FDD o que as histórias de usuários são para o Scrum.Durante o FDD, um recurso deve ser entregue entre 2 a10 dias,diferentemente do Scrum, no qual os sprints geralmente duram de duas a quatro semanas.O FDD valoriza a documentação mais do que outros métodos (incluindo Scrum e XP), o que também cria diferenças nos papéis das reuniões. No Scrum, as equipes normalmente se reúnem diariamente; no FDD, as equipes confiam na documentação para comunicar informações importantes e, portanto, não costumam se reunir com a mesma frequência.Outra diferença importante é o usuário final; no FDD, o usuário real é visto como o usuário final, enquanto no Scrum é normalmente o Dono do produto que é visto como o usuário final.

Composição do Time FDD

A equipe do FDD está baseada nas seguintes funções:

Gerente de Projeto: supervisiona todo o projeto assim como no Waterfall .
Arquiteto chefe: Responsável pelo design e modelagem geral do sistema. O arquiteto chefe trabalha com outros desenvolvedores qualificados na fase de planejamento do ciclo de desenvolvimento.
Gerente de Desenvolvimento: Lidera e orienta a equipe de desenvolvimento e supervisiona as atividades de programação diárias.
Programador Chefe: ajuda na análise e no design e também pode ser designado para gerenciar pequenas equipes de desenvolvimento.
Proprietário da classe: é um membro das equipes de desenvolvimento menores, lideradas pelo programador chefe. As responsabilidades incluem projetar, codificar, testar e documentar recursos.
Especialista em domínio: é membro de uma equipe que entende qual o  problema do cliente precisa ser resolvido. Os desenvolvedores confiam no conhecimento do especialista em domínio para garantir que eles estejam trabalhando e entregando o que é mais importante para o cliente.

Principais Vantagens do FDD

Como as essência do FDD e estar baseado em recursos podemos elencar algumas vantagens claras de sua adoção dentre elas estão: Gerenciamento mais claro do projeto: No FDD, o sistema em geral é construído progressivamente através do desenvolvimento de recursos – planejado, projetado e construído individualmente e depois incorporado ao modelo geral. Isso facilita o gerenciamento do processo, pois há apenas um recurso para focar por vez (em vez de gerenciar o sistema geral de uma só vez).


Minimizando a complexidade: o FDD divide o projeto geral em pequenos componentes para que possam ser entregues em curtos períodos de tempo. Isso ajuda as equipes de desenvolvimento a minimizar as complexidades associadas ao processo de desenvolvimento do sistema. Se a equipe tende a atrasar os cronogramas de desenvolvimento, o FDD pode deixá-lo mais organizado.

Construindo produtos melhores: o modelo FDD é um modelo iterativo que permite à equipe de desenvolvimento de software apresentar o produto intermitentemente, internamente ou para o cliente. Devido a essa transparência, é possível receber feedback frequente e, como resultado, o software pode ser colaborativamente aprimorado.

Enfim, vimos que vários recursos,fases,papeis e artefatos do FDD se entrelaçam com outros frameworks e metodologias de gerenciamento  e gestão de projetos, não há uma receita de bolo, cabe a cada organização e gestor aplicar aquilo que mais tenha aderência ao momento e estrutura organizacional executora.

 

 

 

 

 

 

Compartilhe com ........

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *