Gestão de Processos Ágeis de

Desenvolvimento de Software
Aula 05
Feature Driven Development (FDD)

Objetivos Específicos
• Compreender os conceitos relacionados com o desenvolvimento guiado por
funcionalidade, ou Feature Driven Development(FDD).

Temas

Introdução
1 Feature Driven Development (FDD)
Considerações finais
Referências

Professor Autor
Everton Michels
 Gestão de Processos Ágeis de Desenvolvimento de Software

Introdução
Nesta aula, abordaremos o tema Feature Driven Development(FDD), ou desenvolvimento
guiado por funcionalidade. Primeiramente, veremos um breve histórico do FDD e em que
ponto ele se encontra com o “Manifesto ágil”.

Depois verificaremos qual é o conceito de feature ou funcionalidade segundo o FDD,

além de explicitar os níveis de granularidade e funcionalidade versus caso de uso.

Logo após, abordaremos os papéis da equipe para o FDD e quais as suas funções.

Ainda estudaremos os 5 processos abordados pelo FDD, detalhando-os de forma que

fiquem claros os seus conceitos.

Por fim, veremos quais são as práticas fundamentais que o FDD preconiza para garantir
a melhor qualidade do produto e do processo.

1 Feature Driven Development (FDD)

O Feature Driven Development (FDD), ou desenvolvimento dirigido por funcionalidade,
é um dos métodos ágeis que preconizaram o “Manifesto ágil” mesmo sem a participação de
um dos principais autores do método (Peter Coad), que foi representado na ocasião por Jon
Kern. O FDD foi desenvolvido por Jeff de Luca, Peter Coad e Stephen Palmer por meio de um
projeto em Cingapura, desenvolvido entre 1997 e 1999 a pedido do banco United Overseas
Bank (UOB).

Após 15 meses de projeto, foram entregues aproximadamente 2.000 funcionalidades

desenvolvidas por um time de 50 pessoas. O projeto foi concluído antes do prazo e abaixo do
orçamento. Nascia então o FDD. (PRIKLADNICKI; WILLI; MILANI, 2014).

Para melhor contemplar todos os conceitos do FDD, dividimos a aula em 4 tópicos que
serão abordados a seguir: funcionalidade, equipe, processo e práticas.

1.1 Funcionalidade
Para o FDD, feature é uma funcionalidade pequena. A feature deve gerar valor para o
cliente no seu ambiente de negócio e não poderá ocupar mais do que uma iteração, logo,
não deverá ultrapassar 80 horas, ou 2 semanas, de desenvolvimento. No entanto, com base
nos relatos, as features não demoram mais do que algumas horas para serem desenvolvidas
(PRIKLADNICKI; WILLI; MILANI, 2014).

Senac São Paulo - Todos os Direitos Reservados 2

 Gestão de Processos Ágeis de Desenvolvimento de Software

Para identificar uma funcionalidade, o método adota a técnica de decomposição

juntamente com a teoria de processos. Assim, o projeto se inicia a partir do negócio e chega
até as tarefas envolvidas nos processos da empresa, identificando de forma mais fácil as
funcionalidades que devem ser trabalhadas. A figura 1, a seguir, detalha essa decomposição
do processo em partes menores.

Figura 1 – Mapeamento de processo de negócio

Gestão de Gestão de Value-Added Chain (VAC)

Compras Vendas

Definir itens Receber

para compra produtos
Fazer cotações Enviar pedidos
Selecionar Realizar
forncedores pagamentos

Rastrear Status dos

pedidos pedidos
Enviar
Cotações Pedidos V
pedidos
vencedoras enviados
eletrônicos

Plano de
Realizar
recepção
recepção
criado
Event-Driven Process Chain (EPC)

Fonte: Prikladnicki, Willi e Milani (2014, p. 69).

Como mostra a Figura 1, é feita uma decomposição dos processos em 3 níveis menores.
No nível mais baixo, é possível destacar as tarefas do processo- a automatização dessas tarefas
é mais usual e facilitada, e é nesse ponto que o FDD atua de forma mais eficiente.

No FDD, existe uma abreviatura que fornece a base para a escrita de funcionalidades.
Essa abreviatura é conhecida por ARO, a qual significa: Ação, Resultado e Objeto. Com base
nesse conceito, são criadas ou elaboradas as funcionalidades, facilitando assim tanto a escrita
quanto a leitura, além de auxiliar na alocação das responsabilidades e no estabelecimento de
alguns parâmetros para as operações (PRIKLADNICKI; WILLI; MILANI, 2014).

Na prática, também vemos as empresas inverterem a sequência das letras ARO para
AOR na construção das features. Embora não seja o adequado ou sugerido pelo método, na
prática essa inversão também se mostra funcional (PRIKLADNICKI; WILLI; MILANI, 2014).

Prikladnicki, Willi e Milani explicitam alguns motivos pelos quais os clientes classificam
as funcionalidades como boas:

Senac São Paulo - Todos os Direitos Reservados 3

 Gestão de Processos Ágeis de Desenvolvimento de Software

• Coisas pelas quais somos pagos (valorizadas pelo cliente).

• Coisas que podem ter futuras melhorias.

• Coisas que podem conter defeitos.

• Um acordo para futura conversação.

• Você pode escrever um teste de aceitação para cada uma delas (PRIKLADNICKI; WILLI;
MILANI, 2014, p. 70).

Para os autores, o nível de detalhe de uma funcionalidade pode ser identificado pela
resposta às seguintes situações:

• O desenvolvedor deve ser capaz de fornecer uma estimativa razoavelmente precisa

para implementação.

• O testador deve se sentir seguro para escrever um teste que prove que a funcionalidade
funciona (PRIKLADNICKI; WILLI; MILANI, 2014, p. 70).

1.2 Equipe
Para o FDD, a equipe é o ponto fundamental que sustenta e dá a forma final ao produto
que será entregue pelo projeto. A equipe é quem faz acontecer, por meio de processos bem
estabelecidos ou não, principalmente pela interação entre pessoas, processos e tecnologias,
abordando tudo isso de forma sistêmica (PRIKLADNICKI; WILLI; MILANI, 2014).

Prikladnicki, Willi e Milani explicitam os seguintes papéis principais que definem a

estrutura do FDD:

Gerente de projeto – é o responsável pelo gerenciamento geral administrativo do

projeto, coordenando e alavancando as ações da equipe e reportando o progresso
para a alta gerência, clientes e demais interessados. A possibilidade de ter um
assistente administrativo é altamente desejável e pode contribuir significativamente
para a maior eficácia e eficiência da sua atuação.

Gerente de desenvolvimento – possui habilidades técnicas, gerenciais e de

liderança necessárias para orquestrar as ações da equipe de desenvolvimento,
operacionalizando as orientações fornecidas pelo gerente de projetos. Em equipes
pequenas, o gerente de projetos assume esse papel.

Especialistas no domínio de negócio – compreendem as regras e a dinâmica

do domínio do negócio sendo considerado. São os responsáveis por informar e
esclarecer a equipe do projeto sobre o que deve ser feito para que o produto
seja adequado às necessidades dos usuários. Pode incluir usuários e consultores
externos.

Senac São Paulo - Todos os Direitos Reservados 4

 Gestão de Processos Ágeis de Desenvolvimento de Software

Arquiteto líder – profissional com experiência em análise e modelagem de sistemas,

capaz de liderar a equipe no desenvolvimento do modelo que será construído e
refinado para implementar as funcionalidades identificadas. Em equipes pequenas
um dos desenvolvedores mais experientes, que possui a melhor visão sistêmica,
pode possuir também esse papel. Também pode ser um consultor externo, para
fornecer novas ideias e trazer experiências de forma rápida.

Programadores líderes – são os desenvolvedores mais experientes, reconhecidos

como líderes pela equipe. Coordenam o desenvolvimento, montam as equipes
de funcionalidades e participam das definições técnicas, além de serem também
proprietários de classes. Cada programador líder costuma cuidar de uma subequipe
de 2 a 5 pessoas, número esse adaptável a cada contexto.

Proprietários de classes – são os demais desenvolvedores da equipe, aos quais

foram atribuídas certas classes do modelo. Sempre que uma funcionalidade for
escolhida para ser implementada e necessitar dos serviços oferecidos por algumas
das classes que estão sob sua “custódia”, o proprietário de classe será escalado para
participar de uma das equipes de funcionalidades naquela iteração (PRIKLADNICKI;
WILLI; MILANI, 2014, p. 72).

Além destes, existem ainda os papéis de apoio, que, embora não façam parte da estrutura
principal, são peças fundamentais para o desenvolvimento dos projetos (PRIKLADNICKI;
WILLI; MILANI, 2014):

Assistente de projeto – é o responsável pela parte operacional do projeto, possibilitando

que o tempo do gerente de projeto esteja concentrado na parte estratégica.

Testadores – são os responsáveis pela qualidade final do produto por meio de testes,
sejam eles de integração, aceitação ou regressão.

Gerente de versão (ou de produto) – é o responsável pelo ciclo de vida do produto,

desde a definição das features que estarão dentro de uma versão, até a sua disponibilização.

Gerente de configuração – é o papel responsável pela base de conhecimento, a qual

poderá possuir artefatos entre outros itens, além de ser o responsável pela segurança dessa
base. Outra responsabilidade desse papel poderá ser a compilação e montagem do produto.

Guru da linguagem/plataforma/tecnologia – papel que fornecerá de forma rápida e

pontual o conhecimento e a experiência necessários por meio de mentoria aos desenvolvedores
que necessitarem, para que o processo não pare.

Produtor de ferramentas, utilitários e bibliotecas – fornece produtos de forma

abrangente e robusta para que os proprietários de classe foquem no seu objetivo e, assim,
possibilitarem o desenvolvimento de produtos de forma padrão e que possibilitem o reúso.

Senac São Paulo - Todos os Direitos Reservados 5

 Gestão de Processos Ágeis de Desenvolvimento de Software

Administrador de sistemas – cuida da parte de infraestrutura em geral, desde redes,

hardware, até os aplicativos necessários.

Implantadores – responsáveis por fazer a implantação do produto no cliente e garantir

que esteja adequada ao uso.

Escritores técnicos – são os responsáveis pela escrita tanto dos manuais do produto
quanto dos materiais de treinamento do mesmo, podendo ou não obter auxílio de profissionais
desse ramo.

Agora que vimos todos os papéis para o desenvolvimento de software segundo o FDD, o
próximo passo é conhecer o processo. Vamos ao próximo tópico.

1.3 Processo
O FDD é baseado em 5 processos principais, os quais estão distribuídos em 2 grandes
fases. A figura 2 detalha essas 2 fases e esses 5 processos, as quais compõem o ciclo de vida
do FDD.

Figura 2 – Ciclo de vida do FDD

Requisitos
Inicialização
Mais forma que conteúdo Desenvolver Construir a Planejar
1 um modelo 2 lista de 3 por
abrangente funcionalidades funcionalidades

Plano de desenvolvimento
Construção
Modelo do
domínio

Progresso
Detalhar por Construir por
funcionalidade funcionalidade

Mais conteúdo na forma 4 5

Produtos

Pacotes de trabalho

Fonte: Prikladnicki, Willi e Milani (2014, p. 75).

Conforme apresentado na figura 2, podemos ver as duas fases do método, são elas:

Inicialização – Esta fase tem como objetivos principais o entendimento geral do projeto,

Senac São Paulo - Todos os Direitos Reservados 6

 Gestão de Processos Ágeis de Desenvolvimento de Software

por meio de uma visão genérica do que irá entregar e das suas funcionalidades, bem como a
elaboração do plano inicial de como serão entregues tais funcionalidades ao longo do tempo.
Dura de 2 a 4 semanas, dependendo do tamanho do projeto. Em outros métodos, essa fase
pode ser denominada como “iteração 0 (zero)”. Essa fase se inicia geralmente antes do início
do desenvolvimento, para o fornecedor ter claro o que deverá ser feito, para daí tomar uma
decisão de prosseguir ou não com o projeto.

Construção – Esta fase tem como o objetivo principal entregar as funcionalidades ao

cliente de forma iterativa, constante e podendo ser utilizadas quando o cliente assim desejar.
Geralmente essas iterações duram 2 semanas, porém este não é um número fixo, podendo
ser modificado inclusive durante o projeto.

Agora é a vez de vermos os 5 processos que são trabalhados no FDD.

1.3.1 DMA – Desenvolver um modelo abrangente

Tem por objetivo a criação de um modelo abrangente de requisitos, para sua posterior
análise e síntese. Neste processo, os profissionais mais envolvidos são especialistas do domínio
do negócio, desenvolvedores e um modelador de objetos na figura de arquiteto-líder.

A função dos especialistas de domínio é realizar estudos com a equipe, a fim de melhor
compreender e detalhar o escopo do sistema e o contexto onde está inserido, seja para
obter o conhecimento tácito – que está nas mentes das pessoas -, seja para socializar o
conhecimento explícito – que é aquele distribuído por meio de documentos ou bases de
dados (PRIKLADNICKI; WILLI; MILANI, 2014). Assim, são realizados eventos para detalhar o
domínio de negócio, para compreender melhor cada área que será modelada. Também são
criados grupos menores de especialistas dos negócios e desenvolvedores, os quais detalharão
cada domínio para que as partes gerem um todo de forma sistêmica.

O processo de desenvolvimento de um modelo abrangente passa por 7 atividades bem

definidas, com seus respectivos papéis, são elas:

1. formar a equipe de montagem (responsabilidade do gerente do projeto);

2. conduzir um estudo dirigido sobre o domínio do negócio (gerente do projeto e

especialistas);

3. estudar documentos (equipe de modelagem);

4. desenvolver modelos em pequenos grupos (equipe de modelagem, em pequenos

grupos);

5. desenvolver um modelo como equipe (equipe de modelagem);

6. refinar o modelo completo de objetos (arquiteto-líder e equipe de modelagem);

Senac São Paulo - Todos os Direitos Reservados 7

 Gestão de Processos Ágeis de Desenvolvimento de Software

7. escrever comentários sobre o modelo (arquiteto-líder e programador-líder)

(PRIKLADNICKI; WILLI; MILANI, 2014).

No final do processo, os grupos se reúnem para apresentar os modelos desenvolvidos

e/ou escolher um deles, ou ainda agrupar partes de cada um para formar um novo modelo.
Após selecionado, o modelo de domínio é ajustado ao modelo abrangente, e este ainda
conterá outros modelos de outros domínios de negócio. É importante registrar os modelos
desenvolvidos e mesmo os escolhidos, para que haja uma base de conhecimento para
recuperar facilmente as informações caso alguma modificação precise ser feita.

O modelo abrangente será atualizado de forma iterativa tanto no conteúdo quanto na

forma pelo processo 4: DFP - Detalhar por funcionalidade.

1.3.2 CLF – Construir a lista de funcionalidades

Após o modelo abrangente definido, o próximo passo é o detalhamento dos requisitos em

funcionalidades. Assim, será possível identificar quais serão as funcionalidades que atenderão
aos requisitos levantados. Aqui ocorre a decomposição para detalhar o domínio de negócio,
com seus processos, suas atividades e suas tarefas, os quais poderão ser automatizados
posteriormente.

Este processo contempla duas atividades, e seus devidos papéis, são elas:

1. formar a equipe de listas de funcionalidades (gerente do projeto e gerente de

desenvolvimento);

2. construir a lista de funcionalidades (equipe de lista de funcionalidades) (PRIKLADNICKI;

WILLI; MILANI, 2014).

Segundo Prikladnicki, Willi e Milani (2014, p. 80), a lista de funcionalidades pode ser
categorizada em 3 níveis: área de negócio, atividades de negócio e passos da atividade de
negócio.

A categorização das áreas de negócio é feita pelos especialistas de domínio no processo

de desenvolvimento de um modelo abrangente (DMA), visto anteriormente. Conforme os
níveis vão se decompondo, acontece o que o FDD chama de Feature Breakdown Structure
(FBS), ou estrutura de desmembramento de funcionalidades, que nada mais é do que o mapa
do produto (PRIKLADNICKI; WILLI; MILANI, 2014).

Prikladnicki, Willi e Milani (2014, p. 81) explicitam também que existe uma nomenclatura
para cada nível de funcionalidade:

• área de negócio: “gestão de...”, por exemplo: gestão de suprimentos;

• atividade de negócio: <verbo> + <substantivo>, por exemplo: repor estoque, dar

Senac São Paulo - Todos os Direitos Reservados 8
 Gestão de Processos Ágeis de Desenvolvimento de Software

entrada de veículo, registrar hóspedes;

• passo da atividade de negócio: <verbo> + <resultado> + <objeto>, por exemplo:

calcular quantidade disponível de um produto.

Para documentar a lista de funcionalidades, uma alternativa que os autores citam é

o mapa mental. Dependendo da ferramenta utilizada, é possível fazer anotações em cada
entidade do mapa.

Por fim, é importante ressaltar que este processo não tem o objetivo de priorizar as
funcionalidades nem mesmo categorizá-las se são necessárias ou desejáveis.

1.3.3 PPF – Planejar por funcionalidade

Tem por finalidade o planejamento das funcionalidades para seu posterior

desenvolvimento. Com base na decisão do gerente de projetos, do gerente de desenvolvimento
e dos programadores-líderes - os quais irão analisar dependências e complexidades das
funcionalidades, bem como a carga de trabalho da equipe -, as funcionalidades serão
priorizadas, categorizadas e desenvolvidas posteriormente.

Este processo possui 4 atividades bem definidas e seus respectivos papéis:

1. formar a equipe de planejamento (gerente do projeto);

2. determinar a sequência de desenvolvimento (equipe de planejamento);

3. atribuir conjuntos de funcionalidades para programadores-líderes (equipe de

planejamento);

4. atribuir classes para desenvolvedores (equipe de planejamento).

Como resultado deste processo, tem-se o plano de desenvolvimento no FDD, que,

segundo Prikladnicki, Willi e Milani (2014, p. 83), pode se assemelhar à figura 3.

Senac São Paulo - Todos os Direitos Reservados 9

 Gestão de Processos Ágeis de Desenvolvimento de Software

Figura 3 – Plano de Desenvolvimento

Inspeção de código
Inspeção desenho

Desenvolvimento
Funcionalidade

Estudo dirigido

Promoção
Atividade

Desenho
Área

P.L
A’rea
A1 Ativ. 1.1 F.1.1.1 AB dd/mm dd/mm dd/mm dd/mm dd/mm dd/mm

A1 Ativ. 1.1 F.1.1.2 AB dd/mm dd/mm dd/mm dd/mm dd/mm dd/mm

A1 Ativ. 1.2 F.1.2.1 AB dd/mm dd/mm dd/mm dd/mm dd/mm dd/mm

A2 Ativ. 2.1 F.2.1.1 CD dd/mm dd/mm dd/mm dd/mm dd/mm dd/mm

A3 Ativ. 3.1 F.3.1.1 EF dd/mm dd/mm dd/mm dd/mm dd/mm dd/mm

Fonte: Prikladnicki, Willi e Milani (2014, p. 83).

O plano de desenvolvimento apresentado na figura 3 é detalhado da seguinte forma:

as três primeiras colunas são oriundas do processo CLF, o qual já conhecemos. A coluna P.L.
remete ao programador-líder, e é ele o responsável pela respectiva atividade de negócio. As
próximas 6 colunas são os marcos ou estágios por quais a funcionalidade irá passar até o seu
término: os três primeiros são marcos do processo DPF e os três últimos, do processo CPF
(PRIKLADNICKI; WILLI; MILANI, 2014).

A equipe tem a possibilidade de definir ou não as datas dos marcos. Pode trabalhar
apenas com as datas das iterações ou das entregas das atividades de negócio. Além disso,
diferentemente de outros métodos ágeis, o FDD não estabelece um time box para uma
iteração. Este também fica a critério da equipe em conjunto com gerente do projeto e gerente
do desenvolvimento, que definem a melhor opção para cada equipe (o time box comum são
2 semanas) (PRIKLADNICKI; WILLI; MILANI, 2014).

1.3.4 DPF – Detalhar por funcionalidade

Após a definição do plano de desenvolvimento, o processo DPF – Detalhar por

funcionalidade tem como objetivo detalhar um conjunto de funcionalidades que será
desenvolvido, para que a equipe de desenvolvimento tenha as informações necessárias para
trabalhar de forma mais eficiente.

As 7 atividades deste processo são:

1. formar a equipe de desenvolvimento de funcionalidades (programador-líder);

2. conduzir um estudo dirigido sobre o domínio de negócio (especialista no domínio);

Senac São Paulo - Todos os Direitos Reservados 10

 Gestão de Processos Ágeis de Desenvolvimento de Software

3. estudar documentos de referência (equipe de funcionalidades);

4. desenvolver os diagramas de sequência (equipe de funcionalidades);

5. refinar o modelo de objetos (programador-líder);

6. escrever prólogos de classes e métodos (equipe de funcionalidades);

7. inspecionar o projeto/design (equipe de funcionalidades) (PRIKLADNICKI; WILLI;

MILANI, 2014).

Assim, neste processo poderão ser gerados alguns diagramas definidos pela Unified
Modeling Language (UML), como o diagrama de sequência, de máquina de estado, entre
outros. Além disso, inspeções ou reuniões para revisar funcionalidades geradas também
poderão ocorrer a fim de garantir maior qualidade por meio da detecção antecipada de
problemas.

1.3.5 CPF – Construir por funcionalidade

Neste processo se dará a execução do que foi detalhado no processo anterior. Aqui
os proprietários de classes irão desenvolver suas respectivas classes para que atendam às
funcionalidades requisitadas. O código implementado passará pelos testes, sejam eles
unitários, funcionais, de comportamento ou outros, e pela inspeção, determinada pelo
programador-líder. Após a inspeção, o código é levado à compilação, também chamada de
build.

As 4 atividades deste processo e seus respectivos envolvidos são:

1. implementar classes e métodos (equipe de funcionalidades);

2. fazer testes unitários (equipe de funcionalidades);

3. conduzir uma inspeção no código (equipe de funcionalidades);

4. promover o código para o build (programador-líder e equipe de funcionalidades)

(PRIKLADNICKI; WILLI; MILANI, 2014).

1.4 Práticas fundamentais

Para o FDD, existem 8 práticas essenciais que ajudam a garantir a qualidade do processo
e do produto. Essas práticas, em menor ou maior número, são utilizadas pelos 5 processos do
método e são reflexo do mais atual estudo na área de engenharia de software (PRIKLADNICKI;
WILLI; MILANI, 2014). Então, vamos a elas.

Senac São Paulo - Todos os Direitos Reservados 11

 Gestão de Processos Ágeis de Desenvolvimento de Software

Modelagem de objetos do domínio – Muito usada no primeiro processo, para analisar

o modelo do domínio de negócios, determinando assim as funcionalidades do software, além
de fomentar o conhecimento entre os envolvidos, auxiliando na elicitação dos requisitos
(PRIKLADNICKI; WILLI; MILANI, 2014).

Para Prikladnicki, Willi e Milani (2014, p. 90), o modelo de objetos de domínio:

• é o mapa da estrada, que guiará a equipe durante a jornada;

• fornece uma estrutura abrangente na qual adiciona funcionalidades;

• ajuda a manter a integridade conceitual do sistema;

• reduz a necessidade e a quantidade de refatoração (refactoring);

• é uma forma de armazenamento e comunicação concisa, relativamente acessível e

reutilizável, para todos os envolvidos no projeto.

Desenvolvimento por funcionalidades – Para o FDD, faz muito sentido o projeto ser
direcionado por funcionalidades, já que são elas que o cliente compra e utiliza. É por meio
delas que o cliente enxergará o valor, entenderá os termos e compreenderá o progresso,
além de poder facilmente priorizá-las. Somado a isso tudo, fica mais fácil os testes funcionais,
pois o resultado será 0 ou 1, ou se funciona ou não.

Posse individual de classe/código – Esta prática ajuda a identificar o responsável pelas

classes ou por trechos de códigos específicos. Fornece um especialista para uma ou mais
classes, ou mesmo para um trecho de código. Como responsável, o especialista poderá
efetuar mudanças de forma rápida e objetiva. É importante salientar que o termo utilizado
aqui é “responsabilidade”, e não “posse”, assim o responsável poderá delegar uma alteração
para outra pessoa (no entanto, sabe-se quem é o responsável).

Equipes de funcionalidades – São compostas pelos proprietários de classes e coordenadas

pelos programadores-líderes. Tais equipes são formadas dinamicamente durante as iterações,
a fim de desenvolver as funcionalidades do sistema e ainda manter a posse do código. Aqui,
o que manda é justamente o trabalho em equipe, já que nada termina enquanto todos não
entregarem seus compromissos.

Inspeções – A inspeção faz parte do FDD tanto no processo DPF, que inspeciona o desenho
das features, quanto no processo CPF, que inspeciona o código gerado. Enquanto os testes
se concentram nos estágios finais e detectam apenas os sintomas do defeito, as inspeções já
atuam no início do desenvolvimento e são capazes de detectar não só os sintomas do defeito,
mas também a sua causa, além de detectar mais defeitos e de forma antecipada, o que gera
benefícios para o cronograma do projeto. A inspeção também permite o compartilhamento
de conhecimento, no que tange às melhores práticas, entre os desenvolvedores.

Senac São Paulo - Todos os Direitos Reservados 12

 Gestão de Processos Ágeis de Desenvolvimento de Software

Montagens (builds) frequentes – A compilação frequente, seja ela qual for, com as
funcionalidades desenvolvidas até o momento ajuda a identificar erros de integração de
forma precoce, além de ter o que disponibilizar ao cliente. Além disso, é um bom momento
para os documentos serem gerados, bem como para realizar auditorias, testes de integração
e regressão.

Gestão de configuração – Para que haja um melhor versionamento e para que este não
gere problemas na versão atual, este trabalho é feito em um ambiente diferente do utilizado
em produção, justamente para que não ocasione problemas.

Segundo Prikladnicki, Willi e Milani (2014, p. 92), os principais objetivos da gestão de

configuração são:

• facilitar o desenvolvimento de software, especialmente em equipes que utilizam

código comum;

• garantir a integridade dos artefatos;

• controlar efetivamente as modificações, com a condição de voltar no tempo e também

de realizar auditorias.

Relatório e visibilidade de resultados – Para que haja um melhor acompanhamento do

estado do projeto tanto por parte dos clientes quanto por parte do fornecedor, é importante
que se gerem informações simples e acuradas a respeito do projeto, e com isso a tomada
de decisão se torna mais eficaz. Para o FDD, 2 relatórios objetivos e simples gerados nessas
condições são os relatórios de progressos (parking lot) e o diagrama de fluxo acumulado, que
mostra 3 informações simples: quantidade de funcionalidades não iniciadas, funcionalidades
em andamento e funcionalidades concluídas.

Considerações finais
Nesta aula, vimos primeiramente um breve resumo da história do FDD, quando surgiu,
quem o desenvolveu e onde foi desenvolvido.

Depois, detalhamos um pouco o conceito de funcionalidade ou feature que o método

FDD preconiza.

Logo após, vimos que, para desenvolver funcionalidades segundo o método, é

fundamental ter uma equipe. Também especificamos o papel de cada responsável que o FDD
contempla.

Estudamos ainda os 5 processos trabalhados no FDD, sem os quais as funcionalidades

não conseguiriam ser entregues efetivamente e, dentro de cada processo, vimos as principais
atividades realizadas.

Senac São Paulo - Todos os Direitos Reservados 13

 Gestão de Processos Ágeis de Desenvolvimento de Software

Por fim, apresentamos as práticas fundamentais de que FDD faz uso para que as
funcionalidades sejam devidamente desenvolvidas, inspecionadas, testadas, compiladas,
acompanhadas e entregues ao cliente, fornecendo e gerando valor.

Referências
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software.
Porto Alegre: Bookman, 2014.

Senac São Paulo - Todos os Direitos Reservados 14