SlideShare uma empresa Scribd logo
1 de 10
Baixar para ler offline
Feature Driven Development
Davi Busanello, Izabel Rodrigues, Kleber Sales, Mateus Alves, Priscilla
Aguiar
Centro Universitário UNA
Caixa Postal 30140-071 – Belo Horizonte – MG – Brasil
Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis
davibusanello@gmail.com, izabel.castro.rodrigues@gmail.com,
kleberhermsdorff@gmail.com, snap.mateus@gmail.com, pricaguiar@gmail.com
Abstract
The goal of this article is introduce the FDD, an agile methodology for managing
software development. It`ll be described in this article topics like the history of FDD, its
principles, values, practices and processes. This is an article presented at Agile
Software Engineering discipline.
Resumo
O objetivo deste artigo é apresentar a FDD, uma metodologia ágil para gerenciamento
de desenvolvimento de software. Será descrito neste artigo tópicos como a história do
FDD, seus princípios, valores, práticas e processos. Este é um artigo apresentado na
disciplina Engenharia de Software Ágil.
1. Introdução
Softwares estão presentes em vários setores. Não é incomum ouvir-se falar que projetos
de software fracassam por não resolverem os problemas pelos quais eles foram
motivados. Muitos deles estouram orçamento, planejamento e em alguns outros
cenários, são entregues com muito menos funcionalidades do que inicialmente foram
planejados. Isso quando não são interrompidos sem entregar nenhum valor ao cliente.
No processo de desenvolvimento, temos dois modelos o iterativo e o em cascata.
O modelo em cascata tem como essência dividir o projeto com base nas atividades
necessárias para se concluir o projeto. Já no modelo iterativo, o projeto é divido em um
conjunto de funcionalidades e dentro de intervalos de tempo executamos todas as
atividades necessárias para desenvolver determinada funcionalidade. [FOWLER 2005]
Os projetos que mais fracassam utilizam o modelo de desenvolvimento em
cascata, onde passam se intervalos de tempo muito grandes (meses, anos) no
entendimento do sistema e quando de fato começam a ser construídos já perderam seu
valor, pois deixam de entregar aquilo que era importante, tinham valor. Essa situação
cria abertura para o negócio mudar e/ou as tecnologias ficarem obsoletas tornando assim
um risco para o projeto com tempos muito extensos. [COAD 1999]
Desenvolver produtos de software de forma a agregar valor cada vez mais eficaz
a quem os solicita, requer o uso de metodologias que têm como base os quatro
fundamentos de valorização:
“Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano.”
[Agile Manifesto 2001]

Todas as metodologias tais como XP (Extreme Programming), Scrum, FDD
(Feature Driven Development), Crystal Clear, DSDM (Dynamic Systems Development
Method), AMDD (Agile Model Driven Development), Lean Software Development,
entre outros tem em sua essência os fundamentos acima.
Nesse artigo iremos falar sobre a FDD, que se constitui de uma metodologia de
desenvolvimento de software guiada por funcionalidades e que valoriza a parte de
modelagem como ponto essencial para se ter sucesso. O ponto aqui é realizar muito
desenho para que o problema seja entendido de forma bastante eficaz e mais condizente
com a realidade. Na FDD as funcionalidades são denominadas Features que é uma
funcionalidade que agrega valor ao cliente e que pode ser implementada em duas
semanas ou menos [COAD 1999]. Nesse artigo iremos apresentar sua história, as
principais práticas, princípios, valores, papéis e processos que a caracterizam.

2. História e Evolução
A FDD surgiu entre 1997 e 1999 a partir da experiência de análise e modelagem
orientada por objetos de Peter Coad e das técnicas de gerenciamento de projetos de Jeff
de Luca durante o desenvolvimento de software em um projeto Java para o United
Overseas Bank em Singapura.

1
Em 1999, a primeira versão oficial dos processos foi divulgada no capítulo 6 do
livro “Java Modeling in Color with UML” de Peter Coad, Eric Lefebvre e Jeff De Luca.
No ano de 2002, Stephen Palmer e John Mac Felsing, publicaram “A Pratical
Guide to Feature Driven Development.” Esse livro trouxe uma abordagem completa e
atualizada da metodologia tornando-se a literatura de referência.
Em 2003, a metodologia foi analisada por David Anderson em sua obra “Agile
Management for Software Engineering: Using the Theory of Constraints for Business
Results”.

3. Princípios e Valores
Apesar de a FDD ter surgido antes mesmo do manifesto ágil ser escrito, a mesma pode
ser considerada uma metodologia ágil por seus princípios. A metodologia tem em sua
essência resultados frequentes, tangíveis e funcionais [COAD 1999]. Abaixo a fala de
Peter Coad em sua obra:
“Feature-driven development is a process for helping teams produce frequent, tangible
working results.” [COAD 1999]
3.1 Prioriza o cliente
Dentro de um pequeno intervalo de tempo, duas semanas em geral, um conjunto de
características que possuem valor para o cliente é estudado e desenvolvido sendo
entregue funcionando ao cliente. Isso garante estabilidade e entrega contínua de novas
funcionalidades. [BARKER 2003]
“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua
de software de valor.” [Agile Manifesto 2001]
3.2 Adaptável a mudanças
A FDD possui natureza iterativa. Se na fase de modelagem uma área de risco é
identificada, onde os requisitos ainda não estão bem fundamentados ou até mesmo que
estejam previstos para mudar, a FDD permite que o isolamento dessa área seja feito
para garantir que o menor impacto ocorra quando a mudança acontecer. [BARKER
2003]
“Mudanças nos requisitos são bem-vindas, mesmo que tardiamente no
desenvolvimento. Processos ágeis tiram vantagem das mudanças visando
vantagem competitiva para o cliente.” [Agile Manifesto 2001]

3.3 Priorizar a menor escala de tempo
A FDD utiliza um prazo de duas semanas. Em geral, a cada uma semana uma release é
entregue para a realização dos testes de sistema. [BARKER 2003]
“Entregar frequentemente software funcionando, de poucas semanas a poucos
meses, com preferência à menor escala de tempo.” [Agile Manifesto 2001]
3.4 Pessoas do Negócio e Desenvolvedores trabalham juntas
A FDD não obriga a presença diária do cliente. No entanto, prevê como obrigatória a
presença dos especialistas de domínio do cliente no processo de desenvolvimento do
modelo abrangente e da lista de features. Durante o processo de detalhamento e
2
construção, a presença do cliente se dá através de testes de sistema, feedback de
usabilidade, testes de performance, relatório de erros, etc. [BARKER 2003]
“Pessoas do negócio e desenvolvedores devem trabalhar diariamente juntos durante
todo o projeto.” [Agile Manifesto 2001]
3.5 Indivíduos Motivados
A FDD enfatiza a necessidade de utilização de ferramentas de suporte para garantir que
o ambiente de trabalho e a infraestrutura tenha todas as condições para se obter o
sucesso.O mecanismo da FDD proporciona desenvolvedores motivados pois, a cada
duas semanas eles tem coisas novas para se fazer. Pessoas de gestão sempre tem a
possibilidade de planejar faturamento do que foi feito. Clientes tem uma melhor
visibilidade do que está sendo realizado, onde o projeto está e de uma maneira que eles
entendem.
“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho” [Agile Manifesto 2001]
3.6 Comunicação Face a Face
Conforme já dito anteriormente a FDD proporciona momentos que enfatizam a
comunicação aberta.
“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através de conversa face a face” [Agile Manifesto 2001]
3.7 Medida do progresso
O fluxo de trabalhos dos times garante entrega ideal de funcionalidades. A FDD possui
ferramentas embutidas para permitir monitoração, medição eficaz e geração de
relatórios para acompanhamento do progresso pela gestão.
“Software funcionando é a medida primária do progresso” [Agile Manifesto 2001]
3.8 Desenvolvimento Sustentável
Os aspectos de ritmo de trabalho, contato com o cliente, entrega ideal continuamente já
citados garantem um desenvolvimento sustentável.
“Os processos ágeis promovem desenvolvimento sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um
ritmo constante indefinidamente.” [Agile Manifesto 2001]

3.9 Excelência Técnica
A FDD oferece grande ênfase à modelagem e ao desenho até uma qualidade essencial.
A excelência técnica é incentivada em todos os níveis.
“Contínua atenção a excelência técnica e bom design aumenta a agilidade.” [Agile
Manifesto 2001]
3.10 Simplicidade
Ao invés de incentivar um ciclo constante de refatoração, a FDD apóia a ideia de se
fazer bastante desenho de modo que a construção seja otimizada quando for iniciada.
“Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.”
[Agile Manifesto 2001]
3
3.11 Equipes Auto-Organizáveis
As equipes de features tem provado ser altamente eficazes de várias maneiras. Elas
mantêm canais de comunicação a um nível mínimo, diminuindo elevados custos. É
centrada em uma pequena equipe ágil centrada em um conjunto de funcionalidades
relacionadas. Promove orientação para acelerar o aprendizado e otimiza seu fluxo de
trabalho. Está concentrada em oferecer qualidade através da requisição de inspeção de
desenho e de código.
“As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis”
[Agile Manifesto 2001]
3.12 Melhoria Contínua
Os checkpoints regulares garantem que o progresso e o desempenho são revisados.
Monitoração embutida identifica áreas de risco rapidamente e permitem que os mesmos
sejam mitigados de uma melhor maneira.
“Em intervalos regulares, o time reflete sobre como se tornar mais eficaz e então refina
e ajusta seu comportamento em conseqüência disso.” [Agile Manifesto 2001]

4. Práticas
4.1 Modelagem de Objetos de Domínio com cores
Essa prática fundamenta-se no desenho de diagrama de classes representando os objetos
significativos para o problema do domínio e suas relações [Palmer, Felsing 2002]. A
FDD utiliza a técnica de modelar usando as cores amarelo, rosa, azul e verde descrita
em Java modeling in Color with UML. [COAD 1999]
A modelagem de domínio permite que os membros da equipe compartilhem uma
visão comum sobre o sistema. [PALMER 2002]
O modelo deve ser baseado na visão de especialistas de domínio de forma que o
conhecimento necessário seja documentado e disseminado na equipe e sirva de base
para que novas funcionalidades possam ser acrescentadas a ele. [PALMER 2002]
4.2 Desenvolvimento por Features
Nessa prática temos a ação de dividir funcionalidades do sistema em pequenas partes
que podem ser implementadas em até duas semanas. Essas são escritas no seguinte
formato: <ação><resultado><objeto>. [PALMER 2002]
4.3 Propriedade de Código
A FDD utiliza propriedade única de código. A propriedade única garante a integridade
conceitual do modelo, velocidade na implementação de novas funcionalidades (o
desenvolvedor autor do código está mais familiarizado com aquele pedaço de código)
[PALMER 2002].
4.5 Times organizados por Features
Embora as classes não tenham propriedade coletiva, para desenvolver uma
funcionalidade normalmente existirá mais de uma classe envolvida e possivelmente
mais de um desenvolvedor. Em virtude disso, os times são formados conforme a
4
atribuição de propriedade das classes envolvidas na sua implementação [PALMER
2002].
4.5 Inspeções
A inspeção é feita visando eliminar erros e pode ser feita baseada em métricas de
código. Essa prática traz benefício uma vez que o desenvolvedor se sente motivado a
adotar boas práticas e padrões de codificação determinados pela empresa. [PALMER
2002].
4.6 Agendamento de Builds Regulares
Em intervalos regulares de tempo, o código das funcionalidades concluídas deve ser
integrado e realizado o build.
4.7 Relatar Progresso
A FDD possui mecanismos de gerar relatórios para reportar progresso à gestão e ao
cliente.
4.7 Gerenciamento de Configuração
O gerenciamento de configuração serve para controlar as versões e rastrear artefatos
[GOYAL 2008].

5. Papéis
A FDD possui seis papéis principais envolvidos no processo. São eles: Gerente de
Projetos, Arquiteto Chefe, Gerente de Desenvolvimento, Programador Chefe, Dono de
Classe e Especialistas de domínio. [GOYAL 2008]
O Gerente de projetos tem como atribuições relatar progresso, gerenciar
recursos, orçamento, etc. É um papel de caráter administrativo.
O Arquiteto chefe é responsável por desenhar um modelo geral do problema de
domínio e conduzir sessões de modelagem.
O Gerente de Desenvolvimento possui a tarefa de liderar de forma geral as
atividades de desenvolvimento e resolver conflitos entre programadores chefes. Esse
papel requer que a pessoa que o desempenhe tenha boas habilidades técnicas.
O Programador Chefe é um programador mais experiente que participa de
atividades relacionadas à modelagem e desenvolvimento da solução. Em geral lidera
outros programadores.
Dono de Classe: São membros do time de desenvolvimento que atuam sob a
liderança de programadores chefe que tem por funções modelar, codificar, testar e
documentar as funcionalidades para o novo sistema de software.
Especialistas de domínio: São usuários chaves, analistas de negócios,
patrocinadores ou profissionais com mais de uma função das já citadas. Profissionais
que ocupam esse papel são a principal fonte de conhecimento na qual os
desenvolvedores recorrem para melhor entendimento do problema a fim de realizar a
entrega correta do sistema solicitado. Esses são profundos conhecedores do negocio e
são indispensáveis para o sucesso do projeto. [GOYAL 2008]

5
Além dos papéis principais [GOYAL 2008] cita que durante a adoção da FDD
podemos nos deparar com outros sete papéis.
Language Guru que se caracteriza por ser especialista em uma linguagem ou
tecnologia e estará mais evidente nos projetos onde essa tecnologia ou linguagem for
utilizada pela primeira vez.
Build Engineer é responsável por rodar, configurar e dar manutenção no
processo de build.
Toolsmith: responsável por criar pequenas ferramentas de desenvolvimento para
as equipes de testes e conversão de dados.
System Administrator: Responsável por configurar, gerenciar, solucionar
problemas de todos os servidores e estações de trabalho específicas da equipe do
projeto.

6. Processos
Segundo a descrição oficial [COAD 1999], podemos utilizar o seguinte template para
escrever uma Feature: <ação> o <resultado> <de|para|por> um|a <objeto>.
Exemplo: Calcular o total de uma venda.
A FDD possui cinco processos que fazem parte de duas fases. A figura 1 ilustra
esse cenário.[Nebulon 2012]

Figura 1. Processos FDD

Para um melhor entendimento dos processos [Nebulon 2012], organizamos as
tarefas correspondentes aos processos nas tabelas 1, 2, 3, 4 e 5.
Tabela 1. Tarefas do Processo 1 - Desenvolver um Modelo Abrangente
Tarefa
Formar
a
equipe
modelagem

de

Conduzir um passo a passo
do domínio
Estudar documentos

Detalhamento
Forma - se a equipe por
especialistas de domínio e
alguns desenvolvedores
Um especialista de domínio
realiza uma explicação, visão
geral do que será modelado
Estudo opcional de documentos
de requisitos funcionais que

6

Responsável
Gerente de Projetos

Tipo
Obrigatório

Gerente de Projetos

Obrigatório

Equipe de Modelagem

Opcional
Desenvolver modelos em
pequenos grupos

Desenvolver um modelo do
time
Refinar o modelo geral de
objetos
Escrever
modelo

anotações

no

podem estar no formato de
casos de uso, modelo de dados,
guias de usuário, quaisquer
outros documentos que estejam
disponíveis e que auxiliem no
entendimento do problema
São formados grupos de até 3
componentes
que
geraram
modelos. Fica a cargo do
Arquiteto chefe propor ou não
um modelo base e modelos
alternativos
Da etapa anterior surge um
modelo do time
As iterações das tarefas
anteriores geram modelos para
atualizar o modelo geral
Anotações para referências
futuras são realizadas

Equipe de Modelagem
em pequenos grupos

Obrigatório

Equipe de Modelagem

Obrigatório

Arquiteto Chefe e
Equipe de Modelagem

Obrigatório

Arquiteto Chefe e
Programador Chefe

Obrigatório

Tabela 2. Tarefas do Processo 2 - Construir a Lista de Features
Tarefa
Formar a equipe da Lista de
Features
Construir a lista de Features

Detalhamento
Os principais programadores do
processo 1 compõe a equipe da
Lista de Features.
A lista é construída extraindo as
funcionalidades encontradas no
processo anterior e colocadas no
formato.
<ação><resultado><objeto>

Responsável
Gerente de Projetos e
Gerente de
Desenvolvimento
Equipe da lista de
Features

Tipo
Obrigatório

Obrigatório

Tabela 3. Tarefas do Processo 3 - Planejar por Feature
Tarefa
Formar
a
equipe
de
planejamento
Determinar a sequencia de
desenvolvimento

Atribuir um conjunto de
Features a programadores
chefes
Atribuir
classes
desenvolvedores

Detalhamento
Gerente de desenvolvimentos +
principais programadores
Levando – se em conta
dependência,
risco
e
complexidade a ordem de
execução é determinada.
Analisando dependência de
classes,
complexidade,
sequencia a lista é atribuída aos
programadores chefes.

Tipo
Obrigatório

Equipe de Planejamento

Obrigatório

Equipe de Planejamento

Obrigatório

Equipe de Planejamento

a

Responsável
Gerente de Projetos

Obrigatório

Tabela 4. Tarefas do Processo 4 - Detalhar por Feature
Tarefa
Formar a equipe de Feature

Conduzir um estudo sobre o
domínio de negocio

Detalhamento
O Programador chefe identifica
as classes envolvidas em sua
lista
e
seus
respectivos
programadores responsáveis e
forma sua equipe
O especialista de domínio
conduz um estudo sobre o que
vai ser implementado

7

Responsável
Programador Chefe

Tipo
Obrigatório

Especialista de Domínio

Opcional
Estudar documentos de
referência
Refinar o modelo de objetos

Escrever classes e métodos
iniciais

Fazer o projeto de inspeção

A
equipe
estuda
a
documentação de apoio
O programador chefe refina o
modelo para adicionar classes,
métodos, atributos e cria
diagramas que são submetidos
ao controle de versão.
Usando o modelo refinado da
etapa anterior, o desenvolvedor
grava suas classes, métodos,
atributos
iniciais
e
o
programador chefe gera a
documentação da API e
submete a publicação na
intranet do projeto.
É realizada a inspeção e as
alterações são submetidas a um
controle de mudanças.

Equipe de Feature

Opcional

Programador Chefe

Obrigatório

Equipe de Feature

Obrigatório

Equipe de Feature

Obrigatório

Tabela 5. Tarefas do Processo 5 - Construir por Feature
Tarefa
Implementar
classes
métodos

e

Conduzir uma inspeção de
código
Fazer Testes Unitários
Promover versão para build

Detalhamento
O desenvolvedor implementa o
que é necessário para sua
feature.
Realiza-se uma nova inspeção.

Responsável
Equipe de Feature

Tipo
Obrigatório

Equipe de Feature

Obrigatório

O dono da classe realiza testes
unitários.
Depois de inspecionado e
testado o código é promovido
para o build.

Equipe de Feature

Obrigatório

Equipe de Feature e
Programador Chefe

Obrigatório

7. Conclusão
Após a análise e levantamento dos principais pontos da metodologia Feature Driven
Development, pode-se dizer que a mesma é aplicável para projetos de pequeno, médio e
grande porte. Demonstra ser uma solução viável para aquelas organizações que não
dispõe de facilidade de se manter o cliente sempre por perto como requer, por exemplo,
o XP.
A FDD parece amenizar ou resolver impasses entre desenvolvedores e gerentes
e também entre cliente e equipe contratada para desenvolvimento de algum produto. A
natureza iterativa, com momentos que incentivam a transparência e a comunicação
levam a um melhor relacionamento entre os envolvidos em todo o processo.
Pode-se dizer que parece ser bastante razoável de ser implementada naquelas
organizações onde se percebe um caráter bastante conservador, com papéis e
responsabilidades bastante definidas.
O motivo pelo qual leva ainda muitos projetos serem desenvolvidos utilizando o
modelo cascata que é tentar ter-se uma melhor previsibilidade do andamento das
atividades pode ser resolvido com todos os recursos que a FDD propõe de relatórios de
fácil entendimento para a gestão e para o cliente. Esses recursos deixam muito
transparentes os pontos onde se tem “gaps” ou onde tudo ocorre conforme esperado.
8
Um ponto que parece ser negativo em algum dado momento é o fato da
propriedade única de código. Essa questão se utilizada com muito rigor não se
permitindo a quebra dessa regra, pode levar até a paralisia nas atividades impactando o
bom andamento do projeto.
Para concluir a FDD é uma boa opção para se introduzir metodologias ágeis por
todos os seus aspectos que não levam nenhuma questão ao extremo e ainda garante um
alto nível de qualidade na entrega de novos produtos de software.

Referências
COAD, Peter, LEFEBVRE, Eric, DE LUCCA, Jeff. “Java modeling in Color with
UML”, Prentice Hall PTR, 1999
Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software. Disponível
em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 14 de abril de 2013.
Nebulon PTy Ltd (2012). Consultoria de Jeff De Luca. Disponível em:
<http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf>. Acesso em: 28
de abril de 2013
BARKER, Gavin(2003). The Agile Umbrella. Feature Driven Development. Disponível
em: <http://www.featuredrivendevelopment.com/node/531>. Acesso em: 14 abril 2013.
PALMER , Stephen R.; FELSING, John M. “A Practical Guide to Feature-Driven
Development”, Prentice-Hall, 2002, p.35-54.
GOYAL, Sadhna. Major Seminar On Feature Driven Development Agile Techniques
for Project Management and Software Engineering. Munich, 2008. Disponível em:
<http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf>. Acesso em: 22 abril
2013
FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005

9

Mais conteúdo relacionado

Mais procurados

Processo de certificação CMMI
Processo de certificação CMMIProcesso de certificação CMMI
Processo de certificação CMMI
thomasdacosta
 

Mais procurados (20)

Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Requisitos de software
Requisitos de softwareRequisitos de software
Requisitos de software
 
Manual de Consultoria
Manual de ConsultoriaManual de Consultoria
Manual de Consultoria
 
Aula2 producao i
Aula2 producao iAula2 producao i
Aula2 producao i
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Scrum em 15 minutos
Scrum em 15 minutosScrum em 15 minutos
Scrum em 15 minutos
 
Feedback. Arte de dar e receber feedback
Feedback. Arte de dar e receber feedbackFeedback. Arte de dar e receber feedback
Feedback. Arte de dar e receber feedback
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Scrum
ScrumScrum
Scrum
 
Qualidade de Software
Qualidade de SoftwareQualidade de Software
Qualidade de Software
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
Aula05 - Metodologias Ágeis
Aula05 - Metodologias ÁgeisAula05 - Metodologias Ágeis
Aula05 - Metodologias Ágeis
 
Processo de certificação CMMI
Processo de certificação CMMIProcesso de certificação CMMI
Processo de certificação CMMI
 
Aula 6 - Qualidade de Software
Aula 6 - Qualidade de SoftwareAula 6 - Qualidade de Software
Aula 6 - Qualidade de Software
 
Agile SCRUM
Agile SCRUMAgile SCRUM
Agile SCRUM
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 
Comparativo entre Processos Ágeis
Comparativo entre Processos ÁgeisComparativo entre Processos Ágeis
Comparativo entre Processos Ágeis
 
Apostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do ScrumApostila Scrum: Fundamentos do Scrum
Apostila Scrum: Fundamentos do Scrum
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Gráfico de gantt
Gráfico de ganttGráfico de gantt
Gráfico de gantt
 

Destaque (6)

Sap – stablility and abstract principle
Sap – stablility and abstract principleSap – stablility and abstract principle
Sap – stablility and abstract principle
 
Open4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSourceOpen4Education | MC122 - Introdução a ALM OpenSource
Open4Education | MC122 - Introdução a ALM OpenSource
 
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
ALM Open Source Ponta a Ponta - Minicurso Globalcode MC-122
 
Feature Driven Development (FDD)
Feature Driven Development (FDD)Feature Driven Development (FDD)
Feature Driven Development (FDD)
 
Feature Driven Development
Feature Driven DevelopmentFeature Driven Development
Feature Driven Development
 
FDD
FDDFDD
FDD
 

Semelhante a Feature driven development

Grupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptxGrupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptx
ssuser064821
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPRO
Wildtech
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
Leandro Rezende
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
Caroline Seara
 

Semelhante a Feature driven development (20)

O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
Desenvolvimento Ágil: um survey baseado em experiências profissionais @ CONIC...
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Metodos ageis
Metodos ageisMetodos ageis
Metodos ageis
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2Métodos ágeis de desenvolvimento2
Métodos ágeis de desenvolvimento2
 
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do ConhecimentoMétodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
Métodos Ágeis de Gestão de Projetos aplicados à Gestão do Conhecimento
 
Leds zeppellin infraestrutura de apoio ao desenvolvimento
Leds zeppellin   infraestrutura de apoio ao desenvolvimentoLeds zeppellin   infraestrutura de apoio ao desenvolvimento
Leds zeppellin infraestrutura de apoio ao desenvolvimento
 
Grupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptxGrupo 3 - Gestão Ágil (3).pptx
Grupo 3 - Gestão Ágil (3).pptx
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPRO
 
Artigo23
Artigo23Artigo23
Artigo23
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)Artigo Pós graduação_Caroline Seara (2)
Artigo Pós graduação_Caroline Seara (2)
 

Feature driven development

  • 1. Feature Driven Development Davi Busanello, Izabel Rodrigues, Kleber Sales, Mateus Alves, Priscilla Aguiar Centro Universitário UNA Caixa Postal 30140-071 – Belo Horizonte – MG – Brasil Curso de Pós Graduação em Engenharia de Software Centrada em Métodos Ágeis davibusanello@gmail.com, izabel.castro.rodrigues@gmail.com, kleberhermsdorff@gmail.com, snap.mateus@gmail.com, pricaguiar@gmail.com Abstract The goal of this article is introduce the FDD, an agile methodology for managing software development. It`ll be described in this article topics like the history of FDD, its principles, values, practices and processes. This is an article presented at Agile Software Engineering discipline. Resumo O objetivo deste artigo é apresentar a FDD, uma metodologia ágil para gerenciamento de desenvolvimento de software. Será descrito neste artigo tópicos como a história do FDD, seus princípios, valores, práticas e processos. Este é um artigo apresentado na disciplina Engenharia de Software Ágil.
  • 2. 1. Introdução Softwares estão presentes em vários setores. Não é incomum ouvir-se falar que projetos de software fracassam por não resolverem os problemas pelos quais eles foram motivados. Muitos deles estouram orçamento, planejamento e em alguns outros cenários, são entregues com muito menos funcionalidades do que inicialmente foram planejados. Isso quando não são interrompidos sem entregar nenhum valor ao cliente. No processo de desenvolvimento, temos dois modelos o iterativo e o em cascata. O modelo em cascata tem como essência dividir o projeto com base nas atividades necessárias para se concluir o projeto. Já no modelo iterativo, o projeto é divido em um conjunto de funcionalidades e dentro de intervalos de tempo executamos todas as atividades necessárias para desenvolver determinada funcionalidade. [FOWLER 2005] Os projetos que mais fracassam utilizam o modelo de desenvolvimento em cascata, onde passam se intervalos de tempo muito grandes (meses, anos) no entendimento do sistema e quando de fato começam a ser construídos já perderam seu valor, pois deixam de entregar aquilo que era importante, tinham valor. Essa situação cria abertura para o negócio mudar e/ou as tecnologias ficarem obsoletas tornando assim um risco para o projeto com tempos muito extensos. [COAD 1999] Desenvolver produtos de software de forma a agregar valor cada vez mais eficaz a quem os solicita, requer o uso de metodologias que têm como base os quatro fundamentos de valorização: “Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano.” [Agile Manifesto 2001] Todas as metodologias tais como XP (Extreme Programming), Scrum, FDD (Feature Driven Development), Crystal Clear, DSDM (Dynamic Systems Development Method), AMDD (Agile Model Driven Development), Lean Software Development, entre outros tem em sua essência os fundamentos acima. Nesse artigo iremos falar sobre a FDD, que se constitui de uma metodologia de desenvolvimento de software guiada por funcionalidades e que valoriza a parte de modelagem como ponto essencial para se ter sucesso. O ponto aqui é realizar muito desenho para que o problema seja entendido de forma bastante eficaz e mais condizente com a realidade. Na FDD as funcionalidades são denominadas Features que é uma funcionalidade que agrega valor ao cliente e que pode ser implementada em duas semanas ou menos [COAD 1999]. Nesse artigo iremos apresentar sua história, as principais práticas, princípios, valores, papéis e processos que a caracterizam. 2. História e Evolução A FDD surgiu entre 1997 e 1999 a partir da experiência de análise e modelagem orientada por objetos de Peter Coad e das técnicas de gerenciamento de projetos de Jeff de Luca durante o desenvolvimento de software em um projeto Java para o United Overseas Bank em Singapura. 1
  • 3. Em 1999, a primeira versão oficial dos processos foi divulgada no capítulo 6 do livro “Java Modeling in Color with UML” de Peter Coad, Eric Lefebvre e Jeff De Luca. No ano de 2002, Stephen Palmer e John Mac Felsing, publicaram “A Pratical Guide to Feature Driven Development.” Esse livro trouxe uma abordagem completa e atualizada da metodologia tornando-se a literatura de referência. Em 2003, a metodologia foi analisada por David Anderson em sua obra “Agile Management for Software Engineering: Using the Theory of Constraints for Business Results”. 3. Princípios e Valores Apesar de a FDD ter surgido antes mesmo do manifesto ágil ser escrito, a mesma pode ser considerada uma metodologia ágil por seus princípios. A metodologia tem em sua essência resultados frequentes, tangíveis e funcionais [COAD 1999]. Abaixo a fala de Peter Coad em sua obra: “Feature-driven development is a process for helping teams produce frequent, tangible working results.” [COAD 1999] 3.1 Prioriza o cliente Dentro de um pequeno intervalo de tempo, duas semanas em geral, um conjunto de características que possuem valor para o cliente é estudado e desenvolvido sendo entregue funcionando ao cliente. Isso garante estabilidade e entrega contínua de novas funcionalidades. [BARKER 2003] “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” [Agile Manifesto 2001] 3.2 Adaptável a mudanças A FDD possui natureza iterativa. Se na fase de modelagem uma área de risco é identificada, onde os requisitos ainda não estão bem fundamentados ou até mesmo que estejam previstos para mudar, a FDD permite que o isolamento dessa área seja feito para garantir que o menor impacto ocorra quando a mudança acontecer. [BARKER 2003] “Mudanças nos requisitos são bem-vindas, mesmo que tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.” [Agile Manifesto 2001] 3.3 Priorizar a menor escala de tempo A FDD utiliza um prazo de duas semanas. Em geral, a cada uma semana uma release é entregue para a realização dos testes de sistema. [BARKER 2003] “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.” [Agile Manifesto 2001] 3.4 Pessoas do Negócio e Desenvolvedores trabalham juntas A FDD não obriga a presença diária do cliente. No entanto, prevê como obrigatória a presença dos especialistas de domínio do cliente no processo de desenvolvimento do modelo abrangente e da lista de features. Durante o processo de detalhamento e 2
  • 4. construção, a presença do cliente se dá através de testes de sistema, feedback de usabilidade, testes de performance, relatório de erros, etc. [BARKER 2003] “Pessoas do negócio e desenvolvedores devem trabalhar diariamente juntos durante todo o projeto.” [Agile Manifesto 2001] 3.5 Indivíduos Motivados A FDD enfatiza a necessidade de utilização de ferramentas de suporte para garantir que o ambiente de trabalho e a infraestrutura tenha todas as condições para se obter o sucesso.O mecanismo da FDD proporciona desenvolvedores motivados pois, a cada duas semanas eles tem coisas novas para se fazer. Pessoas de gestão sempre tem a possibilidade de planejar faturamento do que foi feito. Clientes tem uma melhor visibilidade do que está sendo realizado, onde o projeto está e de uma maneira que eles entendem. “Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho” [Agile Manifesto 2001] 3.6 Comunicação Face a Face Conforme já dito anteriormente a FDD proporciona momentos que enfatizam a comunicação aberta. “O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face” [Agile Manifesto 2001] 3.7 Medida do progresso O fluxo de trabalhos dos times garante entrega ideal de funcionalidades. A FDD possui ferramentas embutidas para permitir monitoração, medição eficaz e geração de relatórios para acompanhamento do progresso pela gestão. “Software funcionando é a medida primária do progresso” [Agile Manifesto 2001] 3.8 Desenvolvimento Sustentável Os aspectos de ritmo de trabalho, contato com o cliente, entrega ideal continuamente já citados garantem um desenvolvimento sustentável. “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.” [Agile Manifesto 2001] 3.9 Excelência Técnica A FDD oferece grande ênfase à modelagem e ao desenho até uma qualidade essencial. A excelência técnica é incentivada em todos os níveis. “Contínua atenção a excelência técnica e bom design aumenta a agilidade.” [Agile Manifesto 2001] 3.10 Simplicidade Ao invés de incentivar um ciclo constante de refatoração, a FDD apóia a ideia de se fazer bastante desenho de modo que a construção seja otimizada quando for iniciada. “Simplicidade, a arte de maximizar a quantidade de trabalho não realizado, é essencial.” [Agile Manifesto 2001] 3
  • 5. 3.11 Equipes Auto-Organizáveis As equipes de features tem provado ser altamente eficazes de várias maneiras. Elas mantêm canais de comunicação a um nível mínimo, diminuindo elevados custos. É centrada em uma pequena equipe ágil centrada em um conjunto de funcionalidades relacionadas. Promove orientação para acelerar o aprendizado e otimiza seu fluxo de trabalho. Está concentrada em oferecer qualidade através da requisição de inspeção de desenho e de código. “As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis” [Agile Manifesto 2001] 3.12 Melhoria Contínua Os checkpoints regulares garantem que o progresso e o desempenho são revisados. Monitoração embutida identifica áreas de risco rapidamente e permitem que os mesmos sejam mitigados de uma melhor maneira. “Em intervalos regulares, o time reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento em conseqüência disso.” [Agile Manifesto 2001] 4. Práticas 4.1 Modelagem de Objetos de Domínio com cores Essa prática fundamenta-se no desenho de diagrama de classes representando os objetos significativos para o problema do domínio e suas relações [Palmer, Felsing 2002]. A FDD utiliza a técnica de modelar usando as cores amarelo, rosa, azul e verde descrita em Java modeling in Color with UML. [COAD 1999] A modelagem de domínio permite que os membros da equipe compartilhem uma visão comum sobre o sistema. [PALMER 2002] O modelo deve ser baseado na visão de especialistas de domínio de forma que o conhecimento necessário seja documentado e disseminado na equipe e sirva de base para que novas funcionalidades possam ser acrescentadas a ele. [PALMER 2002] 4.2 Desenvolvimento por Features Nessa prática temos a ação de dividir funcionalidades do sistema em pequenas partes que podem ser implementadas em até duas semanas. Essas são escritas no seguinte formato: <ação><resultado><objeto>. [PALMER 2002] 4.3 Propriedade de Código A FDD utiliza propriedade única de código. A propriedade única garante a integridade conceitual do modelo, velocidade na implementação de novas funcionalidades (o desenvolvedor autor do código está mais familiarizado com aquele pedaço de código) [PALMER 2002]. 4.5 Times organizados por Features Embora as classes não tenham propriedade coletiva, para desenvolver uma funcionalidade normalmente existirá mais de uma classe envolvida e possivelmente mais de um desenvolvedor. Em virtude disso, os times são formados conforme a 4
  • 6. atribuição de propriedade das classes envolvidas na sua implementação [PALMER 2002]. 4.5 Inspeções A inspeção é feita visando eliminar erros e pode ser feita baseada em métricas de código. Essa prática traz benefício uma vez que o desenvolvedor se sente motivado a adotar boas práticas e padrões de codificação determinados pela empresa. [PALMER 2002]. 4.6 Agendamento de Builds Regulares Em intervalos regulares de tempo, o código das funcionalidades concluídas deve ser integrado e realizado o build. 4.7 Relatar Progresso A FDD possui mecanismos de gerar relatórios para reportar progresso à gestão e ao cliente. 4.7 Gerenciamento de Configuração O gerenciamento de configuração serve para controlar as versões e rastrear artefatos [GOYAL 2008]. 5. Papéis A FDD possui seis papéis principais envolvidos no processo. São eles: Gerente de Projetos, Arquiteto Chefe, Gerente de Desenvolvimento, Programador Chefe, Dono de Classe e Especialistas de domínio. [GOYAL 2008] O Gerente de projetos tem como atribuições relatar progresso, gerenciar recursos, orçamento, etc. É um papel de caráter administrativo. O Arquiteto chefe é responsável por desenhar um modelo geral do problema de domínio e conduzir sessões de modelagem. O Gerente de Desenvolvimento possui a tarefa de liderar de forma geral as atividades de desenvolvimento e resolver conflitos entre programadores chefes. Esse papel requer que a pessoa que o desempenhe tenha boas habilidades técnicas. O Programador Chefe é um programador mais experiente que participa de atividades relacionadas à modelagem e desenvolvimento da solução. Em geral lidera outros programadores. Dono de Classe: São membros do time de desenvolvimento que atuam sob a liderança de programadores chefe que tem por funções modelar, codificar, testar e documentar as funcionalidades para o novo sistema de software. Especialistas de domínio: São usuários chaves, analistas de negócios, patrocinadores ou profissionais com mais de uma função das já citadas. Profissionais que ocupam esse papel são a principal fonte de conhecimento na qual os desenvolvedores recorrem para melhor entendimento do problema a fim de realizar a entrega correta do sistema solicitado. Esses são profundos conhecedores do negocio e são indispensáveis para o sucesso do projeto. [GOYAL 2008] 5
  • 7. Além dos papéis principais [GOYAL 2008] cita que durante a adoção da FDD podemos nos deparar com outros sete papéis. Language Guru que se caracteriza por ser especialista em uma linguagem ou tecnologia e estará mais evidente nos projetos onde essa tecnologia ou linguagem for utilizada pela primeira vez. Build Engineer é responsável por rodar, configurar e dar manutenção no processo de build. Toolsmith: responsável por criar pequenas ferramentas de desenvolvimento para as equipes de testes e conversão de dados. System Administrator: Responsável por configurar, gerenciar, solucionar problemas de todos os servidores e estações de trabalho específicas da equipe do projeto. 6. Processos Segundo a descrição oficial [COAD 1999], podemos utilizar o seguinte template para escrever uma Feature: <ação> o <resultado> <de|para|por> um|a <objeto>. Exemplo: Calcular o total de uma venda. A FDD possui cinco processos que fazem parte de duas fases. A figura 1 ilustra esse cenário.[Nebulon 2012] Figura 1. Processos FDD Para um melhor entendimento dos processos [Nebulon 2012], organizamos as tarefas correspondentes aos processos nas tabelas 1, 2, 3, 4 e 5. Tabela 1. Tarefas do Processo 1 - Desenvolver um Modelo Abrangente Tarefa Formar a equipe modelagem de Conduzir um passo a passo do domínio Estudar documentos Detalhamento Forma - se a equipe por especialistas de domínio e alguns desenvolvedores Um especialista de domínio realiza uma explicação, visão geral do que será modelado Estudo opcional de documentos de requisitos funcionais que 6 Responsável Gerente de Projetos Tipo Obrigatório Gerente de Projetos Obrigatório Equipe de Modelagem Opcional
  • 8. Desenvolver modelos em pequenos grupos Desenvolver um modelo do time Refinar o modelo geral de objetos Escrever modelo anotações no podem estar no formato de casos de uso, modelo de dados, guias de usuário, quaisquer outros documentos que estejam disponíveis e que auxiliem no entendimento do problema São formados grupos de até 3 componentes que geraram modelos. Fica a cargo do Arquiteto chefe propor ou não um modelo base e modelos alternativos Da etapa anterior surge um modelo do time As iterações das tarefas anteriores geram modelos para atualizar o modelo geral Anotações para referências futuras são realizadas Equipe de Modelagem em pequenos grupos Obrigatório Equipe de Modelagem Obrigatório Arquiteto Chefe e Equipe de Modelagem Obrigatório Arquiteto Chefe e Programador Chefe Obrigatório Tabela 2. Tarefas do Processo 2 - Construir a Lista de Features Tarefa Formar a equipe da Lista de Features Construir a lista de Features Detalhamento Os principais programadores do processo 1 compõe a equipe da Lista de Features. A lista é construída extraindo as funcionalidades encontradas no processo anterior e colocadas no formato. <ação><resultado><objeto> Responsável Gerente de Projetos e Gerente de Desenvolvimento Equipe da lista de Features Tipo Obrigatório Obrigatório Tabela 3. Tarefas do Processo 3 - Planejar por Feature Tarefa Formar a equipe de planejamento Determinar a sequencia de desenvolvimento Atribuir um conjunto de Features a programadores chefes Atribuir classes desenvolvedores Detalhamento Gerente de desenvolvimentos + principais programadores Levando – se em conta dependência, risco e complexidade a ordem de execução é determinada. Analisando dependência de classes, complexidade, sequencia a lista é atribuída aos programadores chefes. Tipo Obrigatório Equipe de Planejamento Obrigatório Equipe de Planejamento Obrigatório Equipe de Planejamento a Responsável Gerente de Projetos Obrigatório Tabela 4. Tarefas do Processo 4 - Detalhar por Feature Tarefa Formar a equipe de Feature Conduzir um estudo sobre o domínio de negocio Detalhamento O Programador chefe identifica as classes envolvidas em sua lista e seus respectivos programadores responsáveis e forma sua equipe O especialista de domínio conduz um estudo sobre o que vai ser implementado 7 Responsável Programador Chefe Tipo Obrigatório Especialista de Domínio Opcional
  • 9. Estudar documentos de referência Refinar o modelo de objetos Escrever classes e métodos iniciais Fazer o projeto de inspeção A equipe estuda a documentação de apoio O programador chefe refina o modelo para adicionar classes, métodos, atributos e cria diagramas que são submetidos ao controle de versão. Usando o modelo refinado da etapa anterior, o desenvolvedor grava suas classes, métodos, atributos iniciais e o programador chefe gera a documentação da API e submete a publicação na intranet do projeto. É realizada a inspeção e as alterações são submetidas a um controle de mudanças. Equipe de Feature Opcional Programador Chefe Obrigatório Equipe de Feature Obrigatório Equipe de Feature Obrigatório Tabela 5. Tarefas do Processo 5 - Construir por Feature Tarefa Implementar classes métodos e Conduzir uma inspeção de código Fazer Testes Unitários Promover versão para build Detalhamento O desenvolvedor implementa o que é necessário para sua feature. Realiza-se uma nova inspeção. Responsável Equipe de Feature Tipo Obrigatório Equipe de Feature Obrigatório O dono da classe realiza testes unitários. Depois de inspecionado e testado o código é promovido para o build. Equipe de Feature Obrigatório Equipe de Feature e Programador Chefe Obrigatório 7. Conclusão Após a análise e levantamento dos principais pontos da metodologia Feature Driven Development, pode-se dizer que a mesma é aplicável para projetos de pequeno, médio e grande porte. Demonstra ser uma solução viável para aquelas organizações que não dispõe de facilidade de se manter o cliente sempre por perto como requer, por exemplo, o XP. A FDD parece amenizar ou resolver impasses entre desenvolvedores e gerentes e também entre cliente e equipe contratada para desenvolvimento de algum produto. A natureza iterativa, com momentos que incentivam a transparência e a comunicação levam a um melhor relacionamento entre os envolvidos em todo o processo. Pode-se dizer que parece ser bastante razoável de ser implementada naquelas organizações onde se percebe um caráter bastante conservador, com papéis e responsabilidades bastante definidas. O motivo pelo qual leva ainda muitos projetos serem desenvolvidos utilizando o modelo cascata que é tentar ter-se uma melhor previsibilidade do andamento das atividades pode ser resolvido com todos os recursos que a FDD propõe de relatórios de fácil entendimento para a gestão e para o cliente. Esses recursos deixam muito transparentes os pontos onde se tem “gaps” ou onde tudo ocorre conforme esperado. 8
  • 10. Um ponto que parece ser negativo em algum dado momento é o fato da propriedade única de código. Essa questão se utilizada com muito rigor não se permitindo a quebra dessa regra, pode levar até a paralisia nas atividades impactando o bom andamento do projeto. Para concluir a FDD é uma boa opção para se introduzir metodologias ágeis por todos os seus aspectos que não levam nenhuma questão ao extremo e ainda garante um alto nível de qualidade na entrega de novos produtos de software. Referências COAD, Peter, LEFEBVRE, Eric, DE LUCCA, Jeff. “Java modeling in Color with UML”, Prentice Hall PTR, 1999 Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software. Disponível em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 14 de abril de 2013. Nebulon PTy Ltd (2012). Consultoria de Jeff De Luca. Disponível em: <http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf>. Acesso em: 28 de abril de 2013 BARKER, Gavin(2003). The Agile Umbrella. Feature Driven Development. Disponível em: <http://www.featuredrivendevelopment.com/node/531>. Acesso em: 14 abril 2013. PALMER , Stephen R.; FELSING, John M. “A Practical Guide to Feature-Driven Development”, Prentice-Hall, 2002, p.35-54. GOYAL, Sadhna. Major Seminar On Feature Driven Development Agile Techniques for Project Management and Software Engineering. Munich, 2008. Disponível em: <http://csis.pace.edu/~marchese/CS616/Agile/FDD/fdd.pdf>. Acesso em: 22 abril 2013 FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005 9