O Desenvolvimento Orientado a Recursos – Feature Driven Development (FDD) – Como o nome diz, o recurso seria o aspecto mais crucial desse processo. As práticas que este método segue podem não ser novas. No entanto, sua mistura é.

Além do exposto, esse método encontra uma solução para problemas significativos e desafiadores.

Já falamos na nossa série Agile Methods sobre Crystal, DSDM, LSD, Kanban, Extreme Programming e hoje vamos falar um pouco de FDD.

  • O que é Feature Driven Development (FDD): falaremos sobre osAgile Methods: Feature Driven Development (FDD) principais aspectos do FDD. Falaremos sobre o que é focado e quais são as principais características.
  • História do Feature Driven Development (FDD) : Conheceremos a história por trás do FDD. Como seu desenvolvimento aconteceu e a razão por trás de pular outros métodos.
  • Práticas de FDD: explicação de todas as oito práticas, juntamente com exemplos e diagramas de suporte.
  • Funções e Responsabilidades: Introdução de todos os cargos nas três categorias; discutirá os papéis principais em detalhes.
  • Processo de desenvolvimento orientado a recursos: explicação dos cinco processos incluídos com a ajuda de diagramas, fluxogramas e em um modelo adequado.
  • Scrum e FDD: A discussão sobre as diferenças entre os dois métodos ocorre aqui. Esses dois métodos têm propriedades semelhantes. Portanto, é crucial saber como é diferente do Scrum.
  • Vantagens e desvantagens do Modelo de Feature Driven Development: O FDD tem muitos benefícios, mas, como qualquer outra metodologia, também possui desvantagens. Portanto, não podemos aplicá-lo cegamente em todo desenvolvimento de projeto.

O que é Feature Driven Development (FDD)?

O Feature Driven Development (FDD) é uma estrutura Agile1 que se concentra nos recursos. É uma estrutura que:

  • É curta e iterativa;
  • Enfatiza a qualidade;
  • Além do exposto, é compatível com o design de grandes projetos;
  • Oferece recursos frequentes em todas as iterações;
  • Além disso, fornece informações precisas sobre o progresso;
  • É famoso entre clientes, desenvolvedores e gerentes.

Os Valores deste framework são os valores que o tornam tão diferente dos outros frameworks, alguns deles são tão importantes e afetam todos os aspectos.

  • Primeiramente, ele se concentra no processo e não nos resultados.
  • Em segundo lugar, adota uma abordagem sistemática para manter o sistema.
  • Ainda, manter o processo simples.
  • Além do acima, as etapas do processo devem ser valiosas para cada membro da equipe
  • Além disso, os processos certos passam para o segundo plano.

História do Driven Development (FDD)

Há uma história por trás do desenvolvimento do FDD. Em 1997, Jeff De Luca era o gerente de projeto de um banco em Cingapura para um projeto consideravelmente grande e muito crítico.

Enquanto trabalhava nesse projeto, Jeff teve problemas excepcionalmente complexos. Apesar de usar todas as técnicas disponíveis, a questão permaneceu como está.

Por fim, Jeff contratou Coad, que era desenvolvedor, como resultado, os dois criaram um método chamado Feature Driven Development. No entanto eles receberam ajuda de outros 50 programadores e entregaram 2000 recursos funcionais em 15 meses.

A primeira publicação deste método aconteceu em 1999 em um livro chamado “Java Modeling in Color with UML2“.

Certamente qualquer projeto pode usar esse método. Em outras palavras, esse projeto se divide em vários recursos; cada recurso é dividido ainda mais, até que seja o menor possível.

Além disso, isso é feito para garantir que sua entrega ocorra em 2 a 10 dias e geralmente é aplicável a projetos de grande escala.

Funções e responsabilidades no Feature Driven Development

As pessoas relacionadas ao projeto são a parte mais crucial do sistema. Abaixo estão as seis funções essenciais no Feature Driven Development (FDD)

Um gerente de projeto

O gerente de projeto é responsável por compartilhar relatórios de progresso com o cliente e garantir que o projeto esteja progredindo conforme necessário.

Além disso, um gerente de projeto pode gerenciar mais de um projeto. As responsabilidades do gerente de projeto incluem:

  • Em primeiro lugar, eles são o líder administrativo do projeto. Os gerentes de projeto são responsáveis ​​pelo orçamento, pela determinação do número de funcionários, pela criação e pela circulação de relatórios de progresso.
  • Em segundo lugar, mantém a equipe focada em fornecer recursos no prazo
  • Por fim, eles são responsáveis ​​pela operação do sistema do projeto e do centro de controle.

Arquiteto Chefe

Um arquiteto é quem cria o sistema, e o arquiteto chefe lida com uma equipe de arquitetos. Em um projeto de pequena escala, pode ser uma pessoa também.

Os arquitetos-chefes são responsáveis ​​pelos seguintes itens:

  • Em primeiro lugar, eles são responsáveis ​​pelo design geral do sistema.
  • Em segundo lugar, eles são responsáveis ​​pela execução de workshops de design dentro do processo. Além disso, eles garantem que todos na equipe tenham um entendimento do design.
  • Além disso, eles orientam o projeto em dificuldades técnicas.

Gerente de desenvolvimento

O Gerente de Desenvolvimento é quem lida com a equipe de desenvolvedores e garante que eles terminem seu trabalho a tempo. Eles podem lidar com mais de um projeto ou equipe de cada vez.

Um gerente de desenvolvimento cuida das seguintes coisas:

  • Primeiro, acompanha as atividades de desenvolvimento do dia a dia.
  • Segundo, garante que não haja conflitos entre os membros da equipe.
  • Terceiro, coordena com o arquiteto-chefe e o gerente de projetos e fornece relatórios oportunos.

Programador Chefe

O programador chefe é um dos programadores mais experientes. É dever do Programador Chefe ajudar na programação e garantir que ele esteja indo na direção correta.

O programador chefe lida com um projeto em particular por vez, ele tem que:

  • Ser um desenvolvedor experiente
  • Lidera pequenas equipes de desenvolvedores
  • Desenvolvedores e gerentes respeitam suas decisões no desenvolvimento.

Proprietários da classe

Classe é o menor conjunto de desenvolvimento de recursos que se desenvolve em no máximo duas semanas.

Os proprietários da classe são os desenvolvedores que criam recursos. Além disso, eles recebem orientação do programador-chefe e enviam relatórios de progresso ao Gerente de Desenvolvimento.

Proprietários de Classe

  • Os desenvolvedores individuais
  • Crie o projeto e verifique-o quando o design for confirmado.
  • Além disso, eles fazem codificação e testes iniciais também.
  • No final, eles documentam o recurso.

Especialistas em domínio

O especialista em domínio pode ser qualquer pessoa que tenha o melhor conhecimento desse domínio em particular e pode ajudar as Equipes a entendê-lo.

Por exemplo, na escola, temos professores diferentes para diferentes disciplinas, e nenhum professor pode ensinar todas as disciplinas. Nesse caso, toda disciplina é um domínio e o professor da disciplina é um especialista em domínio.

Inclusive os Especialistas em Domínios

  • Podem ser usuários, clientes, patrocinadores;
  • Servem como base de conhecimento dos desenvolvedores.

Além dessas seis funções significativas, existem muitas funções de suporte caso a caso.

Funções de suporte

  • Gerenciador de Domínios;
  • Gerente de Liberação;
  • Guru de Linguagem;
  • Engenheiro de Design;
  • Gerente de Ferramentas;
  • Administrador do sistema;
  • Testadores;
  • Desenvolvedores;
  • Escritores técnicos.

Práticas do Feature Driven Development (FDD)

Inicialmente o design do FDD ocorreu quando o restante das estruturas não estava funcionando para Jeff. Essa estrutura é uma combinação de práticas recomendadas de outras estruturas de desenvolvimento de software.

Precisamos entender alguns termos, como o que é um recurso e como podemos desenvolvê-lo antes de entender as práticas seguidas no FDD.

Posteriormente para entender o recurso, primeiro precisamos entender sua função, uma vez que o cliente quer que a equipe de desenvolvimento desenvolva software. Os clientes desejam ter certos recursos no software, e esses recursos terão as respectivas funcionalidades.

Essas funcionalidades são conhecidas como funções.

No Feature Driven Development (FDD) , um recurso pode ser desenvolvido e entregue ao cliente dentro de uma ou duas semanas, dependendo do tamanho da equipe e da complexidade do recurso.

Para deixar mais claro, vamos considerar o MS office como o software que o cliente deseja. Agora no Office da MS, o cliente gostaria de ter:

  • MS Word;
  • MS Excel;
  • Power Point.

Esses são recursos diferentes do software. Um dos recursos que o MS Word terá pode ainda ter várias funcionalidades, como inserção, alteração de layout e alteração de exibição. Etc. Essas funcionalidades dividem-se ainda mais como:

  • Inserir uma imagem
  • Adicione uma tabela
  • Inserir uma folha
  • Adicione alguma forma
  • Insira algum clip-art etc.

Sobre funções e recursos

Qualquer função difícil de desenvolver e que não possa ser entregue nesse curto espaço de tempo (2 semanas) se divide em funções menores. Esse processo continua até que a função não seja pequena o suficiente para ser entregue em no máximo 2 semanas.

Para resumir, como sabemos quais são as funções e os recursos, vamos falar sobre as práticas seguidas pelo FDD.

Essas práticas recomendadas são as seguintes:

1. Modelagem de Objetos de Domínio

Em termos mais simples, a modelagem de objetos de domínio consiste em criar um domínio de problema e criar um diagrama de classes mostrando diferentes tipos de objetos e o relacionamento entre eles.

Em outras palavras, o modelo de objeto de domínio fornece uma estrutura geral, que detalha como vamos adicionar funções para cada recurso.

Como já discutimos as classes que vamos usar e também a interação entre essas classes, torna-se fácil para os desenvolvedores seguir essa estrutura.

Dessa forma a melhor técnica para a modelagem de objetos de domínio é modelar em cores. O que, por sua vez, significa que cores diferentes representam classes diferentes. Além disso, a categorização ocorre conforme os requisitos.

Já o UML é um conjunto de quatro cores e é chamado de diagrama da Linguagem de Modelagem Unificada.

Peter Coad sugeriu essas cores primeiro. As classes se dividem em diferentes categorias, e cada classe tem sua cor.

Cor Rosa – Intervalo de tempo

Nesta categoria, o tempo associado a um processo de negócios ou a um momento está marcado. Em outras palavras, podemos dizer qualquer coisa que tenha intervalo de tempo ou momento em que algum evento aconteceu se enquadre nessa categoria.

Por exemplo, o pedido de compra do carro pode ser classificado em rosa, pois terá a data e a hora em que o veículo foi comprado. Portanto, eles se tornam detalhes de rastreamento.

Amarelo: representa uma função ativa

Um indivíduo ou uma organização pode desempenhar uma função, uma pessoa pode desempenhar um papel único ou múltiplos papéis.

Por exemplo, em um site de vendas de carros, um cliente pode ser um comprador, um vendedor ou um corretor. Uma pessoa está desempenhando múltiplos papéis.

Verde: Festa, Local ou Coisa

Em um site de venda de carros como o compreseucarro.com, o veículo será classificado na cor verde, já que é uma coisa.

Além disso, esta categoria reconhece atributos como número de registro, número de série, número de licença, nome da pessoa etc. Esse atributo terá detalhes do comprador e do vendedor, detalhes do local ou detalhes.

Azul: como catálogo

Nesta categoria, existem principalmente descrições de catálogo, este atributo terá a lista de todos os detalhes para uma parte ou atividade específica.

Por exemplo: em um site de venda de carros, se houver um carro à venda, todas as descrições deste carro serão fornecidas.

Em outras palavras, todas as características, tipo de carro, configuração do motor e tudo serão mencionados e não apenas o carro.

2. Desenvolvimento por recurso

O Desenvolvimento Orientado a Recursos (FDD) concentra-se em recursos. Este método garante a entrega rápida do recurso correto ao cliente. Além disso, ocorre a decomposição de uma função significativa, cuja entrega e design não são possíveis de terminar em duas semanas. Acontece até que seja entregue em no máximo duas semanas.

Como resultado, uma equipe de recursos permanece pequena porque o tamanho do recurso é pequeno.

Cada membro da equipe de recursos contribui para o design e desenvolvimento de um recurso. Esta equipe trabalhará com um desenvolvedor experiente . Como resultado, isso reduz o risco e ajuda o proprietário da classe no desenvolvimento.

Um proprietário de classe pode ser membro de várias equipes de recursos ao mesmo tempo.

Os programadores chefes também são proprietários de classes e também fazem parte da equipe de recursos, liderada por algum outro membro chefe . O objetivo principal disso é ajudar os proprietários de classes.

No FDD existe um modelo específico para nomear o recurso. Abaixo está o modelo para nomear qualquer recurso

<action> o <result> <by I for I of I to> <a(n)> <object>

Exemplo: para calcular o número total de pessoas, os desenvolvedores nomearão o recurso como abaixo-

Calcule <action> o número <result> total de pessoas <objeto>

3. Propriedade de classe individual

Após a decomposição da função em pequenos recursos, ocorre a atribuição de um recurso a um desenvolvedor. Além da propriedade do recurso, também temos propriedade da classe. O que, por sua vez, significa que cada desenvolvedor recebe uma classe e esse desenvolvedor será o proprietário dessa classe em particular. Além disso, o desenvolvedor será o único responsável pela entrega total e desempenho dessa classe.

4. Equipe de recursos

A implementação de recursos requer mais de um desenvolvimento de classe. Como cada classe tem um proprietário, a equipe de recursos é composta por todos esses desenvolvedores de classe. O proprietário do recurso é um líder que deve liderar esses proprietários de classe. Além do acima, esta equipe de recursos possui todas as funcionalidades exigidas neste recurso. Portanto, ele reduz a dependência de qualquer outra equipe, e cada equipe de recursos possui totalmente seu recurso.

5. Inspeções

Depois de desenvolver qualquer recurso, é muito importante verificar a qualidade. As inspeções são realizadas para garantir a qualidade do design, do código e do recurso. Além disso, garante que está de acordo com a expectativa do cliente. A primeira fase do exame é logo após o projeto e, se houver algum problema, ele será resolvido levantando defeitos.

6. Gerenciamento de configuração

Gerenciamento de configuração significa manter um registro de toda a configuração. Ele mantém a história de uma classe à medida que ela se desenvolve. Como resultado, eles ajudam a identificar a versão mais recente dos arquivos de código-fonte.

7. Compilação regular

A construção regular garante trabalho consistente e implementação dos recursos. É necessário estar atualizado para que o cliente saiba o progresso mais recente, preciso e frequente ao longo do projeto. Além do exposto, garante que a equipe de desenvolvimento sempre tenha um sistema demonstrável pronto.

8. Visibilidade

Os gerentes precisam ficar em contato com os clientes e manter a visibilidade do andamento do projeto e seus resultados. Além disso, o gerente controla um projeto fornecendo relatórios de progresso precisos e pontuais em cada estágio.

Processos

Os processos de desenvolvimento orientado a recursos consistem em:

  • Em primeiro lugar, criando um modelo de objeto de domínio usando modelagem de objeto com seus especialistas de domínio.
  • Em segundo lugar, os desenvolvedores usam as informações da modelagem de objeto e outras atividades e criam uma lista de recursos.
  • Em terceiro lugar, um plano preliminar é preparado com base nos recursos e funções, e as responsabilidades são atribuídas.
  • Além do acima, pequenos recursos ou recursos de recurso, o que leva menos de duas semanas, são utilizados.
  • Por fim, o projeto e a codificação de cada recurso acontecem. É a fase de construção desse recurso.

Existem cinco processos documentados no FDD, conforme mostrado na figura abaixo –

FDD cinco processos

Cada um desses processos possui três critérios essenciais e possui um template representado como ETVX, que significa:

  • ENTRADA Critérios: Primeiro é Critérios de Entrada que significa selecionar que tudo estará trabalhando nele.
  • Tarefas: o segundo é Tarefas, que significa quais atividades serão realizadas nesse processo
    • Nome
    • Equipes Envolvidas
    • Obrigatório / Opcional
    • Descrição
  • Verificação: Em terceiro lugar está a Verificação, o que significa que serão feitas análises e avaliações para confirmar se a tarefa é executada corretamente.
  • Critérios de êXito: Finalmente, os Critérios de Saída, o que significa que a atividade resultante termina aqui.

Diferença entre Scrum e FDD:

Agora que sabemos sobre o FDD, vamos dar uma olhada rápida em como ele difere do Scrum, que é outro framework Agile comum.

FDDSCRUM
FDD é um método baseado em recursos. Aqui, o desenvolvedor pega os detalhes do recurso, que está com entrega pendente. Portanto, ele se concentra em entregá-lo.Scrum foca nas histórias de usuários fornecidas pelo cliente. Portanto, eles fazem seus planos de acordo.
No FDD, os desenvolvedores garantem que a documentação esteja correta. Além disso, todas as conversas devem ser formais e documentadas.Scrum diz que a documentação deve acontecer apenas quando necessária. Em outras palavras, isso significa que nem tudo requer documentação. A comunicação verbal funciona bem aqui.
O usuário final está envolvido no processo durante o relatório. Em outras palavras, os relatórios oportunos acontecem ao usuário final.No scrum, o Product Owner representa um usuário final. Além disso, o product owner confirma se o produto é adequado para o cliente ou não.
Quanto menor, melhor, o tamanho do sprint é de 2 a 10 diasO tamanho do sprint é de 2 a 4 semanas.

Vantagens e desvantagens do FDD

Vantagens

Existem muitas vantagens no Desenvolvimento Orientado a Recursos. Algumas delas são:

  • Primeiro, o acompanhamento do progresso do projeto acontece por meio de um recurso que é uma abordagem focada.
  • Em segundo lugar, permite que várias equipes trabalhem simultaneamente. O que, por sua vez, reduz o tempo.
  • Terceiro, oferece melhores facilidades de rastreamento de processo.
  • Quarto, ele pode ser dimensionado para grandes equipes ou também para um projeto.
  • Além disso, a experiência do desenvolvedor varia, e isso torna a equipe melhor. Acima de tudo, oferece melhores oportunidades de aprendizado para outros membros da equipe.

Desvantagens

  • Em primeiro lugar, ele funciona muito bem para projetos de grande porte, mas não é ideal para projetos de pequeno porte. Havia outros métodos para projetos de pequeno porte como Scrum, XP. Além disso, o desenho desse método aconteceu explicitamente para projetos de grande porte, mas posteriormente surgiu como uma desvantagem, pois sua aplicação não era possível para projetos de pequeno porte.
  • Em segundo lugar, leva a uma grande dependência de uma pessoa. O Programador Chefe desempenha muitas funções, como coordenador, designer líder e mentor. Desempenhar várias funções em um projeto de grande porte é um problema, pois aumenta as chances de erros humanos.
  • Além das desvantagens acima, o design desse método acontece de forma que as Iterações não sejam bem definidas pelo processo, ao contrário de outros métodos ágeis. Eles são específicos do projeto e atendem aos requisitos do projeto. Portanto, nenhum procedimento padrão para iteração existe.

Para concluir, o desenvolvimento orientado a recursos ajuda a obter melhores resultados, pois segue as melhores práticas. É mais organizado e permite que várias equipes trabalhem paralelamente, o que economiza tempo. Este framework ágil não é tão antigo quanto outros frameworks, mas desenvolveu seu lugar seguro no mercado atual, especialmente em projetos de grande escala.

Referências

  1. Projetos e TI – Uma pequena visão da selva ágil
  2. Amazon – Java Modeling in Color with UML
Tags:, , , ,

Leave a Reply