Aula Fdd Cesar.Edu 2017

DESENVOLVIMENTO
DIRIGIDO A
FUNCIONALIDADES
Prof. Esp. Jorge Luis Bublitz

DESENVOLVIMENTO DIRIGIDO A
FUNCIONALIDADES
"A FDD disciplina as equipes a pensarem um pouco antes de sair
fazendo e a fazer aos poucos enquanto continuam aprendendo,
demonstrando claramente o que vão fazer e o que estão fazendo."

Agenda
• Contexto
• Metodologias
• Agilidade e Metodologias Ágeis
• Mudanças
• FDD

O que é Desenvolvimento
de Software?
“É o ato de elaborar e implementar um sistema
computacional, isto é, transformar a necessidade de
um utilizador ou de um mercado em um produto de
software.”
Nick Birrell
A Practical Handbook for Software
Development, 1985

Características
• Caótica
• Eterno ciclo “programar e depurar”
• Sem planejamento claramente definido
• Dificuldade em adicionar novos recursos
(funcionalidades)
• Fase de testes e depuração na produção
• Estimativa de Tempo/Custo difícil de ser determinada

The Chaos Report - 1995
Standish Group – www.standishgroup.com

Vamos Analisar
Sucesso Alterações Falharam

Funcionalidades/Funções
Utilizadas em um Sistema

Culpado(s)???
Clientes
Analistas
Desenvolvedores
Processo
Ferramentas

Como você quer o seu
projeto?
Rápido
Qualidade
Barato
$$$
Mal
Feito
Não pode
ser rápido
UTOPIA

A Solução é...
Não existe uma solução mágica e
única, mas sim um conjunto de
práticas reconhecidamente
eﬁcientes: as Práticas e os
Princípios do Movimento Ágil

A Solução é...
• Melhorar a qualidade do software implica na melhoria
do processo pelo qual o mesmo é produzido.
• Assumir práticas de sucesso
• Garantir que estas práticas serão seguidas durante
o desenvolvimento
• Ser fácil de seguir
• Evoluir com o aprendizado do grupo

A Solução utilizada até
hoje:
• Adoção de Metodologias
• Objetivo: tornar o desenvolvimento mais previsível
e mais eficiente
• Impõe disciplinas rígidas
• Processos detalhados
• Planejamento é a ênfase
• Passam a impressão de serem uma PANACÉIA

Levantamento
de Requisitos
Projeto
Implementação
Testes
Implantação
Modelo Tradicional

Modelo Tradicional
• Também chamado de Modelo em Cascata
(Waterfall)
• Proposto por Winston W. Royce - 1970!!!
• Orientado para documentação
• Ênfase em planejamento, horários, prazos,
orçamentos e implementação de sistemas inteiros
• Há variantes: Incremental, Evolucionário, ...

Agilidade e  
Metodologias Ágeis

Agilidade
• a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil
2. Desembaraço, ligeireza, presteza de
movimentos
3. Mobilidade, perspicácia, vivacidade
• Geralmente associa-se AGILIDADE com
Rapidez, Flexibilidade, Leveza

“Papa Léguas”
Road Runner

Agilidade - Software
“Agilidade é a habilidade para criar e responder às
mudanças, para lucrar num ambiente turbulento
de negócios, para equilibrar flexibilidade e
estabilidade.”
Jim Highsmith
Agile Software Development Ecosystems
2002

Metodologias Ágeis
• Antes chamadas de “Metodologias Leves”
• Tornou-se popular no ano de 2001
• 17 grandes pensadores em processo de desenvolvimento de software
• Se encontraram para que cada um explicasse a maneira como
desenvolviam projetos de software
• E como trabalhavam para que a equipe respondesse rapidamente às
mudanças
• A partir deste encontro foi criada a “Aliança Ágil”
• Estabelecimento dos valores do “Manifesto Ágil”

Manifesto para o  
Desenvolvimento Ágil de Software
Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e
ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas.
Software que funciona mais que documentação detalhada.
Colaboração do cliente mais que negociações contratuais.
Responder às mudanças mais que seguir um plano.
Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do
lado esquerdo.
www.agilemanifesto.org

Princípios Ágeis
• Satisfação do Cliente
• Responder às Mudanças
• Entrega Freqüente
• Motivação
• Software que Funciona
• Ritmo Constante
• Simplicidade

Cuidado com o Manifesto
Radical
O Manifesto Ágil não pode ser interpretado como indicando que
ferramentas, processo, documentos, contratos ou planos são
desprezíveis.
• Ferramentas são críticas para acelerar o desenvolvimento e
reduzir custos
• Contratos são vitais para iniciar as relações desenvolvedor-
cliente
• Documentação auxilia a comunicação
• Entretanto, os itens à esquerda são os mais cruciais
• Sem indivíduos hábeis, software funcionando, interações fortes
com clientes e rapidez de resposta às mudanças, a entrega do
produto será quase impossível

O Sucesso das Metodologias
Ágeis
Já é um movimento de grande sucesso
• Centenas (milhares?) de instituições já usam
• Milhares de projetos já foram completados
• Opinião geral dos que tentaram é positiva
• Alguns estudos científicos começam a aparecer

Quem Adotou ou Está
Adotando?

Mas...
• Proporcionalmente, as metodologias
tradicionais ainda dominam
• Metodologias Ágeis exigem uma mudança
cultural, o que não é nada fácil
• Metodologias Ágeis foram criadas por
especialistas em Desenvolvimento de
Software
• Em geral o poder de decisão não está nas mãos
desses especialistas

Maiores Dificuldades
• Apoio das instâncias superiores
• Gerenciamento de equipes
• Problemas técnicos
• Interação com outros departamentos
• Interação com clientes

Levantamento
de Requisitos
Projeto
Implementação
Testes
Implantação
Métodos Pseudo-Ágeis
XP, Scrum, ...
Implantação
com Testes

Mitos sobre as Metodologias
Ágeis

Programação Radical
“Extreme Programming (XP) é um processo de
desenvolvimento que possibilita a criação de
software de alta qualidade, de maneira ágil,
econômica e flexível.“ - Vinícius M. Teles
• Valores: ■ Princípios:
• Comunicação ■ Feedback rápido
• Simplicidade ■ Presumir simplicidade
• Feedback ■ Mudanças incrementais
• Coragem ■ Abraçar mudanças
■ Trabalho de Qualidade

Principal Mito
• Agilidade = XP
• É apenas um processo ágil, centrado no
desenvolvedor
• Fatos:
• Há vários outros processos e metodologias, como
FDD, Scrum, Lean, Crystal, MSF for Agile, ASD,
DSDM, RAD, etc.
• Agilidade é mais habilidade e atitude do que a
adoção de um processo
• O Projeto C3, que deu origem à XP foi
cancelado!

A “MÁ” Agilidade
• “Foco em datas na pior forma possível: ciclos
curtos, entregas rápidas, estimativas e re-
estimativas freqüentes”
• Esse foco agressivo na entrega fere a base geral
de código, porque as pessoas não dão a mão
para ajudar uns aos outros, e as tarefas
“domésticas” são negligenciadas
• Eles ficam exaustos por causa do ritmo invariante
e das horas anti-naturalmente regulares

A “MÁ” Agilidade
• “São todos novos, com medo de falar, e nenhum
deles têm mesmo certeza se é a Agilidade que
está causando o problema”
• Esse pessoal Ágil é evasivo: “esquivando-se da
crítica ao abraçar qualquer coisa boa e
repudiando qualquer coisa má”

A “BOA” Agilidade
• A estrutura da organização contém hierarquia, mas
na prática ela parece bastante “plana” (código dos
gerentes)
• As pessoas evoluem os processos quando
necessário (em vez dos processos oprimirem as
pessoas)
• Grande disciplina é praticada com relação à base
de código
• A “folga” está embutida no sistema

A “BOA” Agilidade
• Permitir aos desenvolvedores explorar outras idéias que
os interessem
• Os incentivos são ligados ao valor de negócio de cada
projeto
• A organização facilita o foco na codificação
• Por exemplo, fornecendo boas ferramentas e lanches
gratuitos ☺
• As pessoas são tratadas com respeito
• As requisições são simplesmente enfileiradas e
priorizadas

Mudanças
Projetos e Processos

Porque mudar??
• Única constante do universo:
MUDANÇA
• Para melhorar
• Para motivar
• Para nos tornarmos mais eficientes e eficazes
• Para nos tornarmos mais ágeis

Além disso...
• Para 88% dos 1.150 CEOs de todo mundo
ouvidos no início de 2009 pela consultoria
americana Pricewaterhouse-Coopers a
competência mais importante para um
executivo atualmente é a flexibilidade
para se adaptar a mudanças
• “E não basta ter facilidade para aceitar o
novo. O profissional deve ser um
provocador de mudanças e levar as
pessoas junto com ele”, José Aurélio
Drummond Jr., presidente da Whirlpool

Tradicional
• Ser capaz de controlar / eliminar
a incerteza
• Planejamento e controle de
progresso através do Caminho
Crítico / EVA
• Replanejar deve ser a exceção
sempre
• Controle rígido do escopo do
projeto
• Teorias básicas: Gerenciamento
Total da Qualidade 
Controle Estatístico de Processos
Ágil
• Ser capaz de lidar com a
incerteza
• Planejamento e controle de
progresso através da
Corrente Crítica / Buffers
• Replanejar deve ser a regra
(há limites práticos)
• Controle do escopo das
iterações
• Teorias básicas:  
Teoria do Caos 
Teoria das Restrições (TOC)
Produção Enxuta (Lean)

7 Hábitos das Equipes
Altamente Ágeis
1.Seja proativo
2.Comece com o objetivo em
mente
3.Primeiro o mais importante
4.Pense Ganha/Ganha
5.Procure primeiro
compreender, depois ser
compreendido
6.Crie sinergia
7.Aﬁne o instrumento

Matriz do Tempo
Urgente
Não
Urgente
Importante
Não
Importante
✓Crises
✓Prazos
✓Clientes zangados
✓Alterações na
legislação
✓Planejamento e
Preparação
✓Educação
✓Treinamento
✓Desenvolvimento
✓E-mails (alguns deles)
✓Reuniões
desnecessárias
✓Reuniões mal
preparadas
✓Jogos de Computador
✓E-mails em excesso
✓Navegar na internet
sem objetivo
✓WhatsApp e Redes
Sociais

Para que serve um
Processo?
• O propósito de um processo de
desenvolvimento de software é:
• capacitar e reforçar a entrega
repetível de software que funciona...
• no prazo adequado e eficiente em
relação ao seu custo...
• fornecendo informação precisa e
significativa a todos os papéis
principais, dentro e fora de um
projeto...
• com o mínimo de interrupção para os
desenvolvedores
Peter Coad, Jeff de Luca (JMCU)

Características de um bom
Processo
• É bem delimitado
• Claramente define tarefas, que são focadas nos
resultados
• Produz progresso e informação de status precisos
• Rapidamente torna-se uma questão de hábito
• Ajuda a equipe a manter a qualidade e administrar a
complexidade
• Otimiza comunicação dentro e fora da equipe

O Processo Ágil...
• Capacita a organização a responder facilmente à
mudança
• Entrega código funcionando ao mercado mais
rapidamente (do que com outros métodos – atuais ou
anteriores)
• Produz código funcionando de alta qualidade
• Aumenta a produtividade
• Aumenta a satisfação do cliente
• Fornece um ambiente de alta satisfação com o trabalho
para uma equipe bem motivada

Desenvolvimento Dirigido
a Funcionalidades

Definição
• “FDD é uma metodologia iterativa e incremental
de gerenciamento e engenharia de software, que
combina as melhores práticas de outras
abordagens ágeis com técnicas centradas no
modelo, que podem escalar para equipes e
projetos maiores.
• É caracterizada por uma ênfase na qualidade em
todo o processo e um monitoramento de
progresso direto, preciso, intuitivo e acurado.
• Sua principal finalidade é a entrega tangível e
frequente de software funcional.”
Autor: Jorge L. Bublitz
Revisão: Adail Muniz

Onde nasceu a
FDD
•1997-1998, Singapura
•Contexto: Desenvolvimento de um grande
sistema de empréstimos para o United
Overseas Bank
•Anteriormente, após 2 anos de consultoria,
3.500 páginas de casos de (in)uso e um
modelo de objetos com centenas de classes,
foi avaliado como impossível

Decisão x Resultado
• Decisão: Implantação das
metodologias de OOAD de Peter
Coad e de PM de Jeff De Luca
• Resultado: 2.000 Features
entregues por uma equipe de 50
pessoas, 15 meses após a
contratação da dupla

Os “Culpados”
Jeff De Luca Peter Coad
Stephen R. Palmer .
John M. Felsing

Sede do United Overseas Bank David Anderson, o GUI-Man
Peter Coad e a
Equipe de Modelagem
Paul Szego e
Stephen Palmer
Jeff De Luca e os 
Programadores
O Berço da FDD

O que a FDD pode
proporcionar??
• Inovação Contínua
• Adaptabilidade do Produto
• Cronogramas Reduzidos de Entrega
• Adaptabilidade das Pessoas e Processos
• Resultados Confiáveis

Características da FDD
• Fornece a estrutura suficiente para equipes maiores
• Enfatiza a produção de software de qualidade
• Entrega resultados freqüentes, tangíveis e
funcionais
• Realiza trabalho significativo desde o início, antes
de tornar-se altamente iterativa
• Fornece informação de estado e progresso de
forma simples e compreensível
• Agrada a clientes, gerentes e desenvolvedores

O que é Feature?
• Característica ou funcionalidade
• Pequena o suficiente para ser implementada no
máximo em 2 semanas
• Oferece valor para o cliente
• Mapeia passos em uma atividade de negócio
• Pode ser um passo de um caso de uso, podendo ser às
vezes o próprio caso de uso
• Conceito muito próximo de requisito funcional

MODELO
• <A><R><O>
• <Ação> <Resultado> <Objeto(s)>
• Calcular o Total do Salário do Auxiliar

Outros Exemplos
• Calcular o total das Faturas do Cliente
• Autorizar a entrada fora do horário do expediente do
colaborador
• Assinar digitalmente o documento do processo digital
• Calcular o total de horas extras do colaborador
• Listar os colaboradores ativos
• Destacar os colaboradores com horas extras
• Imprimir o total das vendas do período
• Validar a senha de um usuário

Exercício
• Coloque as seguintes funcionalidades no
modelo sugerido (<A><R><O>):
• O usuário é validado antes de entrar no sistema
• Ao entregar um material, seu estoque é atualizado
• O sistema notifica o usuário sobre o envio do seu
pedido
• A recepcionista escolhe o quarto do hóspede a
partir de uma lista de unidades disponíveis
• O médico verifica sua agenda para marcar a
próxima consulta do paciente
• Ao parir sua cria, a vaca deve ser registrada como
não estando mais prenha

Melhores Práticas da
FDD
• Modelagem de Objetos do Domínio
• Desenvolvimento por Feature
• Posse individual de classe (código)
• Equipes de Features
• Inspeções
• Builds regulares
• Gerenciamento de configuração
• Relatório/visibilidade de resultados

1) Modelagem de Objetos
do Domínio
• Diagramas de classes com os principais tipos de 
objetos no domínio do problema e suas relações
• Auxilia na captura e esclarecimento dos requisitos
• Possibilita um entendimento comum e mais completo 
sobre o domínio do problema
• O modelo de objetos do domínio
• É o mapa da estrada, que guiará a jornada
• Fornece uma estrutura abrangente na qual adicionar funcionalidade
• Ajuda a manter a integridade conceitual do sistema
• Reduz a quantidade de refactoring
• É uma forma de armazenamento e comunicação concisa, relativamente
acessível e reutilizável, para todos os envolvidos no projeto

2) Desenvolvimento por
Funcionalidade
• Pensamento sistêmico, processual, 
visando o resultado final
• As features são o que o cliente realmente usará
• Ele entende os termos, o valor e o progresso
• Ele pode priorizar pela importância para o negócio
• O teste é objetivo (funciona ou não funciona)
• É fácil de se determinar quando está pronta
• Garante a distribuição organizada de responsabilidades
através das classes/módulos
• É comum a várias abordagens de desenvolvimento
(funcional, estruturada, orientada por objetos, etc.)

Área 1
Atividade 1.1
Feature 1.1.1
Feature 1.1.2
Atividade 1.2
Feature 1.2.1
Feature 1.2.2
Área 2
Atividade 2.1
Feature 2.1.1
Feature 2.1.2
Atividade 2.2
Feature 2.2.1
ClasseA
ClasseB
ClasseC
!
!
!
!
!
!
!
As Features Preenchem o 
Modelo de Domínio

3) Posse individual de
classe (código)
• Estipula quem (pessoa ou papel) é o 
responsável final pelo conteúdo de uma 
classe (pedaço de código)
• O dono garante que o propósito da classe é mantido e que
as alterações são apropriadas
• Há um especialista disponível para explicar como um
trecho particular do código funciona, especialmente para
classes complexas ou críticas para o negócio
• O dono pode implementar uma melhoria mais
rapidamente do que outro desenvolvedor
• O dono, pessoalmente, possui algo do que se orgulhar por
ter feito bem

4) Equipes de Features
• Formadas dinamicamente
• Única forma de desenvolver por 
feature e manter a posse de código
• Sob a coordenação de um 
Programador Líder
• Múltiplas mentes projetando
• Comparação entre alternativas e escolha da mais apropriada
• Membros são os Proprietários de Classes relevantes
• Benefício da Posse de Código
• Enfatiza o trabalho em equipe
• Ninguém termina enquanto a equipe de features não
terminar

Dinâmica: Letras Prá
Todos
• Objetivo
• Demonstrar como funciona a posse coletiva
• Atividades
• Formar grupos de 3 a 5 pessoas
• Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes
• Todos podem mexer em quaisquer letras
• O instrutor mostrará uma palavra
• Cada grupo deverá montar a palavra rapidamente sobre a mesa
• O grupo que montar a palavra corretamente primeiro ganha 1 ponto
• O grupo terá 1 minuto para discutir como melhorar seu desempenho
• Repetir o processo para 5 palavras
• Ganha o grupo que fizer mais pontos O B A

Dinâmica: Equipe de
Palavras
• Objetivo
• Demonstrar como funciona uma equipe de features
• Atividades
• Formar grupos de 3 a 5 pessoas
• Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes
• Cada pessoa no grupo será dona de um conjunto de letras
• Apenas o “dono” das letras poderá mexer nelas
• O instrutor mostrará uma palavra
• Cada grupo deverá montar a palavra rapidamente sobre a mesa
• O grupo que montar a palavra corretamente primeiro ganha 1 ponto
• O grupo terá 1 minuto para discutir como melhorar seu desempenho
• Repetir o processo para 5 palavras
• Ganha o grupo que fizer mais pontos O B A

5) Inspeções
• Quando bem feitas, são muito úteis na melhoria da qualidade
do design e do código
• São recomendadas desde 1970 e a evidência pesa fortemente
a seu favor
• Numa experiência com 11 programas, o erro médio por 100
linhas de código caiu de 4,5 para 0,82
• Inspeções cortam erros em mais de 80%
• 1 hora de inspeção pode evitar 
de 5 a 30 horas de correções
• Benefícios secundários
• Transferência de conhecimento
• Conformidade com padrões

5) Inspeções
Teste Unitário
Teste Funcional
Teste de Integração
Inspeção de Design
Inspeção de Código
Jones, C.L. “A Process-Integrated Approach to
Defect Prevention”, IBM Systems Journal

6) Montagens
Freqüentes
• Em intervalos regulares, compilar o sistema com 
todas as features completadas até o momento
• Semanalmente, diariamente ou continuamente
• Ajuda a antecipar erros de integração
• Garante que sempre haverá alguma coisa para 
mostrar ao cliente
• Oportunidades
• Geração de documentação
• Execução de scripts de auditorias e métricas
• Testes de regressão
• Notas da versão (novas features, defeitos corrigidos, etc.)
• Os resultados podem ser publicados na intranet do projeto

7) Gerenciamento de
Configuração
• Disciplina que suporta e controla as evoluções e
modificações em artefatos-chave dentro do ciclo de
desenvolvimento de um software
• Objetivos
• Facilitar o desenvolvimento de software
• Garantir a integridade dos produtos
• Controlar efetivamente as modificações
• Itens de Configuração: Artefatos gerados ou 
manipulados durante o ciclo de vida da aplicação
• Arquivos, Requisitos, Documentos, Modelos,
Testes
• Processos, Contratos, Regulamentações
• Solicitações de Mudança, Defeitos, Tarefas
Principais
Artefatos de
Desenvolvimento
Desenvolvimento 
do Produto
Gerenciamento

Tarefas Rotineiras do 
Gerenciamento de Configuração
• Versionamento
• Check out/check in
• Histórico de revisões
• Branching & Merging
• Visões de Projeto
• Gestão de Mudanças
• Acompanhamento de defeitos
• Listas de Melhoria
• Associações
• Rastreabilidade
• Gestão de Tarefas
• Criação e Acompanhamento
• Ficha de tempo
! Gerenciamento de Processo
" Definição de Workflow
" Critérios de Entrada/Saída
" Notificações
" Garantia de Segurança
! Gerenciamento de Montagem
" Identificação de
Dependências
" Controle de Montagens
! Gerenciamento de Liberação
" Rótulos
" Estados Promocionais
" Implantação

8) Relatório/Visibilidade de
Resultados
! Para que o cliente e os gestores possam direcionar o
projeto corretamente é preciso
" Uma figura acurada do estado atual do projeto
" Saber o quão rápido a equipe adiciona funcionalidade
" O resultado geral desejado
! Ter um método simples, de baixa sobrecarga, para
coletar informação de progresso de forma acurada e
confiável
! Formatos de relatórios objetivos e intuitivos, para
todos os interessados no projeto

Principais Papéis
Líder
(Gerente de
Projetos)
Especialista
Domínio do
Negócio
Gerente de
Desenvolvimento
Programador
Líder
Arquiteto
Líder
Proprietário
de Classes

Líder / Gerente de Projeto
• Coordena as ações da equipe do projeto, controla o
progresso e reporta para a alta gerência e interessados no
projeto
• Responsável pelo gerenciamento de: escopo, tempo, custo,
qualidade, riscos, comunicação, recursos humanos,
suprimentos e integração
• Responsável por todos os assuntos administrativos do
projeto, o que inclui o gerenciamento de recursos, orçamento,
equipamentos e outros.
• Principal meta é fornecer subsídios para que nenhum fator
externo atrapalhe a produtividade da equipe do projeto

Gerente de
Desenvolvimento
• Possui habilidades técnicas e gerenciais necessárias
para coordenar as ações da equipe de desenvolvimento,
operacionalizando as decisões tomadas pelo gerente de
projeto
• Responsável por liderar o dia-a-dia do desenvolvimento
do produto.
• Por ser o responsável por resolver qualquer conﬂito
técnico que exista entre programadores- chefes, precisa
possuir boa experiência no desenvolvimento de software
e nas tecnologias que estarão sendo utilizadas no projeto

Especialista no Domínio
de Negócio
• Compreende as regras e a dinâmica do domínio do problema
sendo considerado
• É o responsável por informar a equipe do projeto sobre o que
deve ser feito para que o produto do projeto seja adequado às
necessidades dos usuários
• Usa o seu conhecimento no negócio para apresentar à equipe do
projeto as necessidades para que o software possua valor real
• Deve estar sempre disponível para fornecer aos desenvolvedores
maior detalhamento sobre determinada funcionalidade
• É um um membro ﬁxo da equipe e sempre esta fornecendo
feedback das entregas para todos os envolvidos.

Arquiteto Líder
• É um proﬁssional com experiência em análise e
modelagem orientada a objetos, capaz de liderar a
equipe no desenvolvimento do modelo que será
construído para implementar as features identiﬁcadas
• Possui habilidade para atuar como facilitador na
absorção das regras de negócio
• Será ele o responsável pela última palavra em toda
arquitetura do sistema.

Programador Líder
• Também chamado de Programador-Chefe
• É um proﬁssional mais experiente, que possui reconhecimento
como tal pela equipe
• Coordena o desenvolvimento das features, monta as equipes de
features e participa das deﬁnições técnicas, além de ser também
um Proprietário de Classes
• Normalmente é atribuído a ele a propriedade das classes mais
complexas do sistema
• Possui papel fundamental nas fases de absorção do
conhecimento de negócio e no planejamento das funcionalidades.

Proprietário de Classes
• É um desenvolvedor da equipe, ao qual foram
atribuídas certas classes do modelo
• Sempre que uma feature for escolhida para
desenvolvimento e necessitar dos serviços oferecidos
por algumas das classes que estão sob sua “custódia”,
ele será escalado para participar da equipe de features
nessa iteração
• Programa, diagrama, testa e documenta as
funcionalidades a ele atribuídas pelo Programador-
chefe da equipe.

Gerente de
Versão
Guru da
Linguagem
Engenheiro de
Desenvolvimento
Produtor de
Ferramentas e
Utilitários
Administrador
de Sistemas
Testadores
Implantadores
Escritores
Técnicos
Funções de Apoio

Cuidado para...
Sua equipe não
ficar assim:

Concepção e Planejamento
Construção
Desenvolver
um Modelo
Abrangente
Planejar
por
Feature
Mais conteúdo na forma
Mais forma que conteúdo
Modelo de Objetos
Pacotes de Trabalho
Produto
Plano de 
Desenvolvimento
Progresso
Construir
a Lista de
Features
Fonte: Heptagon – www.heptagon.com.br
Os 5 Processos
Detalhar
por
Feature
Construir
por
Feature

O Porquê de Cada
Processo
! Desenvolver um Modelo Abrangente
" Modelagem dos Processos de Negócio (BPM)
" Captura de Requisitos
" Análise Orientada por Objetos (OOA)
! Construir a Lista de Features
" Decomposição Funcional
! Planejar por Feature
" Plano de Desenvolvimento
" Prioridade, Dependência, Distribuição de Trabalho
! Detalhar por Feature
" Design/Projeto OO (OOD), Estudo Detalhado
! Construir por Feature
" Programação OO (OOP)
" Inspeção, Testes, Integração

Gestão Ágil de Projetos
Construção
Análise OO Planejamento
Decomposição
Funcional
Projeto OO
Programação 
e Teste OO
Engenharia 
de Requisitos
Desenvolvimento
de Requisitos
Gerência 
de Requisitos
Gerência 
de Conﬁguração
Principais Disciplinas
Envolvidas

Análise e Desenho/Projeto 
Orientados por Objetos
! Análise OO
" É um método de análise que examina os requisitos a
partir da perspectiva das classes e objetos encontrados
no vocabulário do domínio do problema
" Enfatiza a construção de modelos do mundo real
usando uma visão de mundo orientada por objetos
! Desenho/Projeto OO
" É um método de projeto que abrange o processo de
decomposição orientado por objetos e uma notação
para descrever os modelos lógicos e físicos, estáticos e
dinâmicos, do sistema sendo projetado
" Enfatiza a estruturação eficaz e apropriada de um
sistema complexo, sem se prender a detalhes de
implementação

Programação e Teste 
Orientados por Objetos
! Programação OO
" É um método de implementação no qual os programas são
organizados como coleções cooperativas de objetos, cada qual
representando uma instância de alguma classe e cujas classes são
todas membros de uma hierarquia de classes unidas por
relacionamentos de herança
" Enfatiza o uso de objetos, e não de algoritmos, como blocos de
construção lógica fundamentais
! Teste OO
" É um método de verificação do comportamento dos objetos em tempo
de execução
" Enfatiza inicialmente o comportamento individual (unitário) de cada
classe de objetos, passando para o relacionamento entre objetos, seu
funcionamento como componente/serviço, e a orquestração entre os
componentes/serviços

Meta
Condição
Necessária
Condição
Necessária
Condição
Necessária
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Objetivo
Intermediário
Estabelecer o Propósito do
Projeto

Mão Na Massa
! É hora de iniciar o projeto!
! O instrutor e a turma decidirão sobre
um domínio de negócio a ser usado
como exemplo
! Descrever o propósito para o sistema
! Criar o mapa estratégico para o projeto
! Usar mapas mentais para capturar e
comunicar os principais conceitos do
domínio de negócio

1. Desenvolver um Modelo
Abrangente
! Também chamada de
“Modelagem de Objetos do
Domínio”
! Preocupa-se mais com a
forma do que com o
conteúdo
! Auxilia na captura e
esclarecimentos dos requisitos
! Possibilita um entendimento
comum e mais completo sobre
o domínio do problema

1. Desenvolver um Modelo
Abrangente
! É uma atividade inicial de estudo, análise e
modelagem do sistema
! Realizada em grupos
! O modelo gerado é suficientemente
abrangente, mas não detalhado
! O objetivo é ter uma definição a priori do
que será feito, para guiar a equipe durante
a fase de construção
! Artefatos produzidos:
" Diagramas de classes, sequência, 
atividades, estados, casos de uso
" Lista preliminar de requisitos
" Anotações nos modelos DPF CPF
DMA CLF PPF

Formar a Equipe 
de Modelagem 
(Gerente do Projeto)
Conduzir um Estudo 
Dirigido Sobre o 
Domínio de Negócio
(Ger. Projeto, Especialistas)
Estudar Documentos
(Equipe de Modelagem)
Desenvolver Modelos 
em Pequenos Grupos
(Equipe de Modelagem 
em pequenos grupos)
Desenvolver um
Modelo como Equipe
(Equipe de Modelagem)
Refinar o Modelo de 
Objetos Completo
(Arquiteto Líder, 
Equipe de Modelagem)
Escrever Comentários 
Sobre o Modelo
(Arquiteto Líder, 
Programador Líder)
opcional
1. Desenvolver um Modelo Abrangente

Apresentação
Negócio – Domínio do Problema
Persistência
Interface com
Outros Sistemas
Foco
Arquitetura em Camadas

UML em Cores
! Padrão de análise e
modelagem desenvolvido
por Peter Coad, na última
metade da década de 1990
! Auxilia tanto na criação quanto na
melhoria de modelos da classes
! Fácil de aprender e explicar
! Propõe a utilização de 4 arquétipos
" arquétipo. s.m. 1 modelo ou padrão passível de ser
reproduzido em simulacros ou objetos semelhantes; 2
idéia que serve de base para a classificação dos objetos
sensíveis; 3 Derivação: por extensão de sentido: qualquer
modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa)

Arquétipo: Momento-
Intervalo
! Representa algo que necessita ser registrado, 
por razões de negócio ou até mesmo legais, que 
ocorre em algum momento no tempo ou durante 
um intervalo de tempo
! São atividades, eventos e serviços
! Um momento-intervalo também pode ter 
“mi-detalhes”, ou seja, ser composto por 
pequenas etapas do evento total
! Exemplos:
" Uma venda é algo que acontece num certo momento
" Uma estada é o período de tempo que o veículo fica sob a
responsabilidade do estacionamento
! Para identificar esse arquétipo usamos a cor rosa e o estereótipo
<<moment-interval>> (também usa-se a sigla <<mi>>). Para os
detalhes, usamos o estereótipo <<mi-detail>>.
! É comum a classe estar acompanhada de um diagrama de máquina
de estados, para definir seu comportamento em tempo de execução

Arquétipo: Pessoa-
Lugar-Coisa
! Representa:
" Uma pessoa (física ou jurídica)
" Um certo local (endereço, casa, privado ou público)
" Algum objeto, geralmente concreto
! São entidades que devem ser registradas no 
sistema por desempenharem papéis nas
atividades (momentos-intervalos)
! Uma mesma pessoa pode participar de
eventos distintos, através de papéis
diferentes
! Identificamos esse arquétipo com a cor
verde e o estereótipo correspondente:
<<party>>, <<place>> ou <<thing>>
! É onde geralmente aparecem os “cadastros”
e “relatórios” simples

Arquétipo: Papel
! É a representação de um papel que é 
desempenhado por pessoa, lugar ou coisa, 
em um determinado evento do negócio 
(momento-intervalo)
! É mais comumente aplicado a pessoas, mas é 
possível utilizá-lo com lugares e até mesmo
com coisas
! Exemplo:
" Um aeroporto pode desempenhar o papel de local de
origem, destino ou escala de um vôo
" Uma pessoa, num hotel, pode ser recepcionista,
gerente, hóspede, vigilante, etc.
! Sua cor é o amarelo e o estereótipo é
<<role>>

Arquétipo: Descrição
! É como um item num catálogo, definindo as 
características de uma determinada coisa, 
lugar ou até mesmo pessoa (menos comum, 
mas possível)
! Usado para concentrar dados comuns a 
diversos objetos, possibilitando perguntas de 
negócio interessantes, como a quantidade de 
objetos de um determinado tipo
! Aparece na cor azul (quase cinza,
dependendo da ferramenta de modelagem) e
usa-se o estereótipo <<description>>
! São as famosas “referências” usadas em
combos e lookups

Domain Neutral Component 
(Componente Genérico de Modelagem)
! Padrão para
análise OO
(Camada de
Negócio)
! Mostra o
relacionamento
entre os arquétipos
! Diminui a variação
no processo de
modelagem
! Padroniza o
entendimento
" Equipe de Negócio
" Equipe de TI

UML Sem Cores
Quarto
ID
Status
Hospede
Score
DtUltVisita
Hotel
Nome
Endereco
Estrelas
PessoaFisica
Nome 
CPF
Estadia
DHInicio
DHTermino
ValorTotal
*
Funcionario
DtAdmissao
CTPS*
*
Servico
Data
Hora
Valor
*
TipoQuarto
Descricao
NumSolt
NumCasal
Fumante?
*

Quarto
ID
Status
Hospede
Score
DtUltVisita
Hotel
Nome
Endereco
Estrelas
PessoaFisica
Nome 
CPF
Estadia
DHInicio
DHTermino
ValorTotal
*
Funcionario
DtAdmissao
CTPS
*
*
Servico
Data
Hora
Valor
*
TipoQuarto
Descricao
NumSolt
NumCasal
Fumante?
*
UML em Cores

Mão Na Massa
! Seguir o processo 1 para criar o modelo de
objetos do domínio de negócio
" Os Especialistas no Domínio farão apresentações
sobre o negócio
" A Equipe de Modelagem fará perguntas e anotações
" Em pequenos grupos, desenvolver alternativas de
modelos (usando os 4 arquétipos e o DNC)
" Obter consenso no grande grupo sobre um modelo
único
" Anotar nesse modelo as razões para as decisões
tomadas

2. Construir a Lista de
Features
! Com o modelo básico criado, deve-se agora criar
uma lista de features
! É uma decomposição funcional do domínio do
negócio
! Categorizada em 3 níveis:
" Áreas de Negócio (Grandes Conjuntos de Features)
" Atividades de Negócio (Conjuntos de Features)
" Passos da Atividade de Negócio (Features)
" Lista de Features
" Requisitos mais detalhados
DPF CPF
PPFCLFDMA

Formar a Equipe 
de Lista de Features 
(Gerente do Projeto, 
Gerente de Desenvolvimento)
Construir a 
Lista de Features
(Equipe de 
Lista de Features)
2. Construir a Lista de
Features

Sistema ou 
Aplicação
Área de Negócio Área de Negócio Área de Negócio
Atividade de Negócio
Atividade de NegócioFuncionalidade
Funcionalidade
Gerenciamento de ...
<Substantivo>
<VerboInﬁnitivo> ...
<Ação> <Resultado> <Objeto>
FBS: Feature Breakdown
Structure

Classe A
Classe B
Classe C
ÁREA N
Atividade X
Feature 1
Feature 2
Atividade Y
Feature 3
Feature 4
Feature 5
...
As Features preenchem o
Modelo

Mão Na Massa
! Seguir o processo 2 para criar a
lista de features
" Se necessário, consultar os Especialistas no
Domínio
" Geralmente são eles quem determinam as
áreas de negócio e até as próprias
atividades de negócio
" Verificar se há redundância entre as
features
" Verificar se as features estão escritas de
acordo com o padrão sugerido

Processo Nº 3: 
Planejar por Feature
! Com a lista e o modelo, deve-se agora planejar a
ordem na qual as funcionalidades serão
implementadas, tendo como base:
" a necessidade do usuário (importância, prioridade)
" as dependências entre elas
" a carga de trabalho da equipe de desenvolvimento
" a complexidade das funcionalidades
! As responsabilidades são distribuídas para a equipe
" Plano de desenvolvimento
" Pacotes de trabalho
" Lista de classes com seus donos
DPF CPF
DMA CLF PPF

Formar a Equipe 
de Planejamento 
(Gerente do Projeto)
Determinar a Sequência 
de Desenvolvimento
(Equipe de Planejamento)
Atribuir Conjuntos de 
Features para 
Programadores Líderes
Atribuir Classes para 
os Desenvolvedores
Processo Nº 3: 
Planejar por Feature

Estimativas
• Truco (ou Poker) da Estimativa
! A Escala de 5 Pontos
Nº Estimado de Classes
na Feature
Complexidade 
da Feature
Esforço 
(Pessoa-Dia)
1 1 0,5
2 2 1
3 3 2
4 4 4
5 5 8 (ou mais)
David Anderson, Agile Management for Software Engineering, 2003

O Plano de
Desenvolvimento
! Com as features devidamente estimadas, o plano de
desenvolvimento é criado a partir da capacidade de
produção
! Com as features na ordem desejada, corta-se a lista em
blocos que caibam nas durações das iterações (1 ou 2
semanas)
" Cuidado para não quebrar em pontos que causem problemas
! Cada pacote de trabalho deve ser atribuído a um
Programador Líder
! Com as “datas” de cada iteração, preencher as “datas”
planejadas de cada um dos 6 milestones (as datas
geralmente são iguais para as features da iteração)
Iteração 1 Iteração 2 Iteração 3 Iteração 4
Pacote 1
(10)
Pacote 2
(8)
Pacote 3
(13)
Pacote 4
(15)

Mão Na Massa
! Seguir o processo 3 para criar o plano de
desenvolvimento
" Estimar as features, de acordo com a escala de 5 pontos ou
pelo Truco da Estimativa
" Consultar um representante do cliente sobre as prioridades
" Determinar a dependência entre as features
" Atribuir classes aos desenvolvedores
" Verificar a distribuição da carga de trabalho entre os
Proprietários de Classes
" Determinar quantas iterações de 2 semanas serão
necessárias
" Criar o plano de desenvolvimento, com as 
datas previstas para cada iteração

4. Detalhar por Feature
! Agora na fase de construção propriamente dita, deve-
se refinar o projeto (design) para cada feature ou
conjunto de features relacionadas
! A equipe de features será formada pelos proprietários
das classes envolvidas
! O resultado será um pacote de trabalho, sob a
responsabilidade de um programador líder
" Modelos detalhados (classes e seqüência)
" Esqueletos de classes com métodos
" Pacote de trabalho detalhado
" Relatório de inspeção do design
" Relatório de progresso atualizado
DPF CPF
DMA CLF PPF

Formar a Equipe 
de Features 
(Programador Líder)
Conduzir um Estudo 
Dirigido Sobre o 
Domínio de Negócio
(Especialista no Domínio)
Estudar Documentos 
de Referência
(Equipe de Features)
Desenvolver os 
Diagramas de Sequência
Reﬁnar o Modelo
de Objetos
(Programador Líder)
Escrever Prólogos de 
Classes e Métodos
Inspecionar o
Projeto (Design)
opcional
opcional
opcional
4. Detalhar por Feature

5. Construir por Feature
! Os proprietários de classes desenvolvem o código
correspondente a cada feature
! Os testes de unidade e as inspeções são
realizados
! O código final (aprovado) é promovido ao build
atual
! O resultado são funções com valor para o cliente
(features)
" Código fonte testado e integrado
" Relatórios de inspeção e testes
" Lista de alterações feitas/necessárias
" Relatório de progresso atualizado DPF CPF
DMA CLF PPF

Implementar Classes 
e Métodos 
Testes Unitários
Conduzir uma Inspeção 
no Código
Promover para o Build
(Programador Líder, 
Equipe de Features)
5. Construir por Feature

Medindo o Progresso
! No ciclo iterativo (processos 4 e 5), o progresso é medido
com base em 6 marcos (milestones) bem definidos
! A cada etapa cumprida, o percentual respectivo é agregado
ao total de progresso da feature
Estudo Dirigido
Sobre o Domínio
1%
Desenho
(Projeto)
40%
Inspeção do
Desenho
3%
Codificação
45%
Inspeção do 
Código
10%
Promoção
ao Build
1%
Nº 4: Detalhar por Feature Nº 5: Construir por Feature
DMA CLF PPF
DPF CPF

Legenda: Atividade em andamento Requer atenção Completada Não iniciada
Id Descrição P.C. D.C.
Est. Dirig. Design Insp. Design Codif. Insp. Cod. Build
Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real.
12 Agendar um serviço para um carro HM AS 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
13
Incluir um novo cliente na lista de
clientes
HM VS 01/02 01/02 04/02 04/02 05/02 05/02 07/02 07/02 08/02 08/02 09/02 09/02
14
Registrar um serviço realizado num
carro
AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
15
Registrar uma lista de peças
utilizadas num serviço
AR
AS
SM
10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
Status: SM ficou doente (previsão de retorno: 01/03
16
Calcular o custo total das peças
usadas num serviço
HM
AS
SM
10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03
18
Receber um pagamento por um
serviço
HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
19
Registrar a opção de pagamento
preferida por um cliente
AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente)
Monitorando as Features

NE
PendentesBacklog
Fulano
Beltrana
Sicrano
Zé
J.J.
Iniciadas Inspeção/Teste Finalizadas
N N I
N
N NE N I
N NN N
N N N
N N I
E
N
N
N
N N
N N I
Quadro de Tarefas

Início: Fim:
ID: Resp.:
Descrição:
Início:
Estimativa de retorno:
ID: Resp.:
Motivo:
RN12 Sic
18/06 09:15
VN: A
Fórmula de cálculo do imposto:
I = ValorBruto * Aliquota
Aliquota -> parâmetro AI3
Classe -> Venda
Tela -> pgVenda
Cartão de tarefa normal (azul) 
ou emergência (amarelo)
Cartão de impedimento (rosa)
Est.: 4
RN12 Sic
19/06 9:00
18/06 11:30
Classe Venda está sendo
alterada 
por outra tarefa
Exemplos de Kanbans

Mês/Ano
Porcentagem Completada:
Prazo de Entrega:
Completada
Mês e Ano para entrega
Status da Atividade:
Barra de Progresso
Em andamento
Requer atenção (ex.: impedimento)
Completada
Nome da
Atividade
de Negócio
(nº features)
75%
Ainda não iniciada
Iniciais PC
Reportando o Progresso

Painel de Progresso
(Parking Lot)
Legenda: Em*andamento Atenção***********************Completada*************************Barra*de*Progresso**** Não*iniciada
Gerenciamento*de*Vendas*de*Produtos*(VP)* 34%
Entrada*de
Pedidos
(33)
Fev$2006
PC*1
Controle*de
Contratos
(13)
Abr$2006
Venda*de
Produtos
(22)
Nov$2005
PC*1
Envio*de
Produtos
(19)
Mar$2006
PC*1
10%
Entrega*de
Produtos
(10)
Abr$2006
PC*3
30%
Relatórios*de
Vendas
(14)
Dez$2005
75%99% 3%
Ger.*Contas*de*Clientes*(CC)* 90%
Análise*de
Propostas*de
Contas
(23)
Nov$2005
95%
Registro*de
Transações
das*Contas
(30)
Dez$2005
82%
Abertura
de*Novas
Contas
(11)
Nov$2005
100%
Gerenciamento*de*Estoque*(GE)* 94%
Definição*de
Unidades*de
Estoque
(26)
Nov$2005
100%
Movimentação
de*Mercadorias
(19)
Jan$2006
82%
PC*3
Aceite*de
Requisições
de*Movimento
(18)
Dez$2005
97%
PC*3
PC*2 PC*1
PC*2 PC*2 PC*2 PC*3
Sistema
Comercial
(238)
Abr$2006
65%

Painel de Progresso
(Parking Lot)

FDD 
Outras Metodologias
Maturidade

Espectro de
Metodologias
UP XPFDD

8. Incremento de Produto 
(pode ser liberado para uso)
6. Dia
5. Iteração 
(2 a 4 sem.)4. Tarefas 
detalhadas 
pela equipe
1. Visão
(RSI, marcos,
versões)
2. Lista de Espera (Backlog) de funcionalidades 
do produto, priorizada pelo Dono do Produto
3. Escopo da Corrida 
(Sprint)
7. Reuniões Diárias
(em pé)
1
DMA
3
PPF
2
CLF
Construção
4 
DPF
5 
CPF
9. Inspeção e 
Adaptação
Scrum e FDD

FDD XP
Certo planejamento inicial
Planejamento durante o
desenvolvimento
Refactoring é exceção Refactoring é a norma
Programadores Líderes e
Proprietários de Classes
Posse coletiva do código
Design formal e 
Inspeções de código e modelo
Programação em pares
FDD e XP: Algumas
Diferenças

OID: Inovação e Implantação Organizacional
CAR: Análise e Prevenção de Defeitos
5 Em 
Otimização
4 Gerenciado
Quantitativam.
3 Definido
2 Gerenciado
Melhoria 
Contínua do 
Processo
Gerência 
Quantitativa
Padronização 
do Processo
Gerência
Básica de
Projetos
QPM: Gerenciamento Quantitativo de Projeto
OPP: Performance do Processo Organizacional
RD: Desenvolvimento de Requisitos
TS: Solução Técnica
PI: Integração de Produtos
VER: Verificação
VAL: Validação
OPF: Foco no Processo Organizacional
OPD: Definição do Processo Organizacional
OT: Treinamento Organizacional
IPM: Gerência Integrada de Projeto
RSKM: Gerência de Riscos
DAR: Análise e Tomada de Decisão
REQM: Gerência de Requisitos
PP: Planejamento de Projeto
PMC: Monitoramento e Controle de Projeto
SAM: Gerência de Acordos com Fornecedores
MA: Medição e Análise
PPQA: Garantia da Qualidade do Processo e do Produto
CM: Gerência de Configuração
1 Inicial
Áreas de ProcessosNível Foco Produtividade
Qualidade
Risco
Retrabalho
FDD
Agile CMMI

FDD & MPS.BR
Níveis F e G
PROCESSO ATENDE PARCIAL NÃO %
Nível G: Processo
Gerência de Projetos
(GPR)
10 5 2 73,5
Nível G: Processo
Gerência de
Requisitos (GRE)
3 1 1 70
Nível F: Gerência de
Conﬁguração (GCO) 5 - 2 71
Nível F: Processo
Garantia da
Qualidade (GQA)
2 2 - 75
Nível F: Processo
Medição (MED) 4 2 1 83

FDD & MPS.BR
Níveis F e G
Atende
Não Atende
Atende Parcial

Aspectos
• A FDD é um meta-processo, que pode ser adaptado e aplicado a
diversos níveis e necessidades de desenvolvimento
• Podemos usá-la para desenvolver aspectos diferentes do produto:
• Infra-estrutura (frameworks, persistência, bibliotecas,
componentes, ...)
• Interface com o usuário
• Integração com outros sistemas
• O segredo é deﬁnir, para cada aspecto, quem é o cliente e derivar
as features a partir desta perspectiva

FFDD: Fractal FDD
• Podemos também aplicar a FDD em 
diferentes níveis do problema ou da 
organização
• Processos de Negócio
• Planejamento Estratégico e Tático dos Sistemas
• Entendimento dos relacionamentos entre produtores e consumidores de
informação
• A analogia com um fractal é devida à reaplicação da FDD em determinada etapa
de outra aplicação da FDD
• Nos Estados Unidos, Mac Felsing está aplicando esse conceito, com o nome de
“Enterprise FDD”, para conseguir escalabilidade e uniformidade de
comunicação

Resumindo, a FDD...
• É um método ágil e altamente adaptativo, que produz
resultados freqüentes, tangíveis e funcionais
• Oferece vantagens dos métodos prescritivos (rigorosos),
pois implementa o conceito importante de planejamento,
mas sem os exageros de documentação e controle
• Oferece vantagens dos métodos ágeis, onde a preocupação
maior é com a produção de código, mas toma o cuidado de
planejar o suﬁciente e controlar o andamento do projeto
• Atende às necessidades dos clientes, gerentes e
desenvolvedores

Dicas para Convencer 
Gerentes e Desenvolvedores
• Geralmente a iniciativa começa nos desenvolvedores
• Mas se o desenvolvimento se tornar ágil e a gerência
continuar tradicional, haverá desgaste
• Assim, a Agilidade deve ser um objetivo comum
• Realize projetos pilotos para experimentar (e errar!)
• Adapte a(s) metodologia(s) e práticas às suas
necessidades

Só para lembrar
• Adotar Gestão Ágil e FDD não é uma panacéia
• Mas é um bom começo para a melhor compreensão
dos caminhos a seguir
• Agilidade e Responsabilidade não são antagônicos,
mas mutuamente necessários

Conclusão
! A adoção da Gestão Ágil de Projetos e FDD,
como qualquer tecnologia, deve ser
acompanhada de uma revisão no
comportamento, nas políticas, nas métricas
e nas regras da organização e das pessoas
! Muitos benefícios estão por vir, mas é
preciso saber plantar e cuidar para poder
colher
! O retorno vale o investimento! ☺
Motivação é a chave para
mudanças!!

Só para lembrar:
Metodologias Ágeis
X
Tradicionais

Waterfall X Ágil
2011-2016

Para saber mais
! Agile Alliance
" www.agilealliance.org
! Agile Project Management Leadership
" www.apln.org
! Agile Management
" www.agilemanagement.net
! FDD
" www.featuredrivendevelopment.com
" www.heptagon.com.br/fdd/
! Grupos de Discussão
" http://groups.yahoo.com/group/AgileProjectManagement
" http://br.groups.yahoo.com/group/Agile-Brasil
" http://br.groups.yahoo.com/group/GUFDD

Jorge Luis Bublitz
• Engenheiro de Sistemas
• Graduação em Administração de Empresas
• Pós-Graduação (Especialização) em Engenharia de Sistemas
• Pós-Graduação (Mestrado) em Engenharia de Sistemas
" UNEATLANTICO - Valência - Espanha (cursando)
• Gerente de Projetos (TRE-MT)
• Coordenador de Projetos Mobile da Justiça Eleitoral
• Consultor em Metodologias Ágeis
• Artigos publicados nas revistas Micro Sistemas, Clube Delphi, MundoPM
e Engenharia de Software Magazine
• Palestrante na Conferência da Borland – Borcon Revolutions 2007
• Palestrante na Conferência Mundial da CodeGear – CodeRage III 2008
• Palestrante no Ágiles 2012 (Buenos Aires) e Agile Brazil 2013
• Assinante do Agile Manifesto
• Membro da Agile Aliance

Frase
"No que diz respeito
ao empenho, ao
compromisso, ao
esforço e à
dedicação, não
existe meio termo.
Ou você faz uma
coisa bem feita ou
não faz."

Um abraço!!!!
Valeu !!!!!
Jorge FDDMan
bublitz@hotmail.com
bublitz@tre-mt.jus.br
Skype: fddman
bublitz.tripod.com
jorge-fdd.blogspot.com

Aula Fdd Cesar.Edu 2017

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Aula Fdd Cesar.Edu 2017

Similar to Aula Fdd Cesar.Edu 2017 (20)

Recently uploaded

Recently uploaded (20)

Aula Fdd Cesar.Edu 2017