Conteúdo

 Mudanças
 Projeto
 Processo
 Gerenciamento
 FDD
 UML em Cores
 Um pequeno exemplo
 Comparações
Porque mudar??
 Única constante do universo:
MUDANÇA

 Para melhorar
 Para motivar
 Para nos tornarmos mais eficientes e eficazes
 Para nos tornarmos mais ágeis
É possível??
Mais Ágil

Maior Menor
Qualidade Custo
Conflito??

Agilidade Responsabilidade
O Manifesto Ágil
“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
Projeto (PMBOK)
 É um empreendimento não repetitivo, que possui as
seguintes características:
 É temporário
 Resulta em produto(s) que não existia(m) antes, ou
existirá(ão) de forma diferente (exclusividade)
 Possui restrições em custo, prazo, qualidade, recursos
 Exige uma coordenação para ser executado (isto é,
possui certo grau de complexidade)
 Conduzido por pessoas
PMBOK
Ciclo de Vida de um Projeto

Iniciação Planejamento Execução

Conclusão Controle
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
Coad, 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
Gerenciamento Tradicional

Requisitos Análise Projeto Construção Teste Entrega

Diferenças
Gerenciamento 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
• Controle rígido do escopo do
projeto
• Teorias básicas:
• Gerenciamento Total da
Qualidade
• Controle Estatístico de
Processos
Gerenciamento Á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
• Pensamento Sistêmico
• TOC
• Produção Enxuta (Lean)
Onde nasceu a
 1997-1998, Cingapura
FDD  Contexto: Desenvolvimento de um
grande sistema de empréstimos para
um banco internacional
 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: Implantação das
metodologias de OOAD de Peter
Coad e de Gerência de Projetos de
Jeff De Luca
 Resultado: 15 meses após a
contratação da dupla, 2.000 features
entregues por uma equipe de 50
pessoas
O que a FDD pode proporcionar??
 Inovação Contínua
 Adaptabilidade do Produto
 Adaptabilidade das Pessoas e Processos
 Cronogramas Reduzidos de Entrega
 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
 Não é uma metodologia de Gerenciamento de Projetos,
pois o seu foco é na Engenharia de Software
 Não é uma panacéia, mas a FDD o auxiliará a tornar o
processo de engenharia de software mais eficiente
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
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
 Às vezes pode ser o próprio caso de uso
 Conceito muito próximo ao de um requisito funcional

 Modelo: <ação> <resultado> <objeto>

 Calcular o total do salário
 Autorizar a entrada fora do horário do expediente do funcionário
 Assinar digitalmente o documento PDF
 Calcular o total de compras de um cliente
 Estimar o tempo de entrega de uma venda
 Calcular a taxa de uma venda
Desenvolvimento por Feature
 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
 É fácil de determinar quando está pronta
Principais Papéis
Gerente de
Desenvolvimento

Especialistas no
Programadores-
Domínio de
Chefes
Negócio

Gerente
Proprietários de
Arquiteto-Chefe de Classes
Projeto
Funções de Apoio
Gerente de Guru da Engenheiro de
Versão Linguagem Desenvolvimento

Produtor de
Administrador de
Ferramentas e Testadores
Sistemas
Utilitários

Escritores
Implantadores
Técnicos
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-
Chefe
 Múltiplas mentes projetando
 Comparação entre alternativas e escolha da
mais apropriada
 Membros são os Donos 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
Como é a FDD?
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
Artefatos Produzidos
 Diagrama de:
 Classes *
 Seqüência
 Estados
 Casos de Uso
 Lista preliminar de
Features
 Anotações nos Modelos

Jeff De Luca
Arquitetura em Camadas
Apresentação

Negócio – Domínio do Problema

Interface com
Persistência
Outros Sistemas
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 simulacros ou
objetos semelhantes
Momento-Intervalo
 Representa algo que  Cor Rosa
necessita ser registrado,
que ocorre em algum
momento ou durante ou
intervalo de tempo
 São atividades, eventos e
serviços
 Exemplos:
 Uma venda é algo que
acontece num certo
momento
 Uma estada (período de
tempo)
Pessoa-Coisa-Lugar
 Representa:  Cor Verde
 Uma Pessoa
 Um certo local
 Algo objeto
(normalmente
concreto)
 Desempenham papéis
nos Eventos
 É onde aparecem os
“cadastros” e “relatórios”
simples
Papel
 É a representação de um  Cor Amarelo
papel que é
desempenhado pelo
“Pessoa-Coisa-Lugar”
 Exemplos:
 Uma pessoa, num hotel,
pode ser funcionário,
hóspede, terceirizado, ...
 Um aeroporto pode ser
local de origem, destino
ou escala de um vôo
Descrição
 É como um item num  Cor Azul
catálogo
 Usado para concentrar
dados comuns a diversos
objetos
 São as famosas
“referências” usadas em
combos e lookups
2. Construir Lista de Features
 É uma decomposição funcional do domínio do negócio
 Categorizada em 3 níveis:
1. Áreas de Negócio
2. Atividades de Negócio (Conjunto de Features)
3. Passos (Features)
 Artefatos produzidos:
 Lista de Features
 Requisitos mais detalhados
Apenas 3 Níveis de Decomposição
Funcional
Área de Negócio 1 Gerenciamento de
(Gerenciamento/Administração de...) Contas de Clientes
Atividade 1 Atividade 2 Atividade 3 Análise de Abertura de Novas
(<Verbo Infinitivo> ...)
• Feature 4 • Feature 9 Propostas Contas
• Feature 1 • Feature 5 • Feature 10 • Cadastrar proposta do • ...
cliente
• Feature 2 • Feature 6 • Feature 11 • ...
• ... • ...
• Feature 7
• Feature 3
• ...
• Feature 8
As Features preenchem o Modelo
Área ...
Atividade ...
Feature 1
Feature 2
Atividade ...
Feature 3
Feature 4
Feature ...
...
3. Planejar por Feature
 Com a Lista e o Modelo, deve-se agora planejar a ordem na
qual as funcionalidades serão implementadas, tendo com
base:
 A necessidade do usuário
 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
 Artefatos produzidos:
 Plano de Desenvolvimento
 Pacotes de Trabalho
 Lista de Classes com seus “donos”
Estimativas
 Regra Empírica da FDD
 Cada semana de modelagem resulta em 12 semanas de
construção (Processos 4 e 5)
 Pressuposto: a equipe usa UML em cores e arquétipos
 A Escala de 5 Pontos

Nº Estimado de Complexidade da Esforço

Classes na Feature Feature (Pessoa-Dia)

1 1 0,5
2 2 1
3 3 2
4 4 4
5 5 8 (ou mais)
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 interações
 Cuidado para não quebrar em pontos que causem
problemas

Interação Interação Interação Interação

1 2 3 n
• Pacote 1 • Pacote 2 (y) • Pacote 3 (z) • Pacote .. (k)
(x Features)
4. Detalhar por Feature
 Deve-se refinar o projeto para cada Feature ou
Conjunto de Features relacionadas
 Artefatos produzidos:
 Modelos detalhados (Classes e Seqüência)
 Esqueletos de Classes com métodos
 Pacote de Trabalho detalhado
 Relatório de progresso atualizado

DMA CLF PPF

DPF CPF
5. Construir por Feature
 Os proprietários de classes desenvolvem o código
correspondente a cada Feature
 Testes e Inspeções são realizados
 O código final – o aprovado – é promovido

DMA CLF PPF

DPF CPF
Medindo o Progresso
4. Detalhar 5. Construir
por Feature por Feature

Estudo
Dirigido Desenho Inspeção do Inspeção do Promoção
Codificação
Sobre o Projeto Desenho Código ao Build
(45%)
Domínio (40%) (3%) (10%) (1%)
(1%)
Reportando o Progresso
Status
Nome da Atividade
Em andamento de Negócio
(nº de features)
Requer Atenção
75%
Completada

Não iniciada Mês/Ano

Painel de Progresso
Parking Lot
Controle de Produção
Um pequeno exemplo
 Autorização para Entrada fora do Horário do
Expediente
 Como funciona hoje:
1. Servidor preenche Requerimento
2. Chefia imediata autoriza
3. Chefia Superior autoriza
4. Encaminha requerimento a Seção de Segurança
5. Encaminha Requerimentos Autorizados a guarita
Como gostaria que funcionasse
1. Servidor preenche requerimento em uma página da
Intranet, acessada através de senha
2. Chefia imediata recebe e-mail com a solicitação e ali
mesmo clica em “link” para acessar o sistema, que pode
autorizar ou não
3. Sendo autorizada, é enviada e-mail para Chefia Superior,
que também pode autorizar ou não
4. Chefe da Segurança recebe e-mail informando da
autorização
5. O sistema gera uma página automaticamente a cada dia
com os requerimentos autorizados
Modelo
Lista de Funcionalidades
 Autenticar usuário no sistema
 Preencher o requerimento de autorização
 Enviar e-mail a Chefia Imediata
 Autorizar/Recusar o requerimento pela Chefia
Imediata
 Enviar e-mail a Chefia Superior
 Autorizar/Recusar o requerimento pela Chefia
Superior
 Enviar e-mail ao Chefe da Segurança
 Gerar listagem de requerimentos autorizados
Planejamento
1ª Semana 2ª Semana 3ª Semana

• Autenticar usuário • Autorizar/Recusar • Enviar e-mail a

no sistema o requerimento Chefia Imediata
• Preencher o pela Chefia • Enviar e-mail a
requerimento de Imediata Chefia Superior
autorização • Autorizar/Recusar • Enviar e-mail ao
o requerimento Chefe da
pela Chefia Segurança
Superior
• Gerar listagem de
requerimentos
autorizados
Espectro de Metodologias

UP XP / SCRUM
• Rigorosidade Quero apenas o
• Agilidade
Processo Suficiente
• Controle • Liberdade
• Equipes grandes Escalável para Equipes
• Equipes pequenas
Pequenas, Médias e Grandes
FDD e CMMI
• Gerência de Requisitos
• Planejamento de Projeto
Nível 2 – • Monitoramento e Controle de Projeto
Gerenciado • Gerência de Acordos Com Fornecedores
– Gerência de Subcontratação
Foco: Gerência • Medição e Análise
Básica de • Garantia da Qualidade do Processo e do
Projetos Produto
• Gerência de Configuração
FDD e CMMI
• Desenvolvimento de Requisitos
• Solução Técnica
Nível 3 – • Integração do Produto
• Verificação
Definido • Validação
• Foco no Processo Organizacional
Foco: • Definição do Processo Organizacional
Padronização • Treinamento Organizacional
do Processo • Gerenciamento de Risco
• Análise e Tomada de Decisão
• Ambiente Organizacional para Integração
Conclusão
 A adoção da Gestão Ágil de Projetos, 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 muitas vezes o investimento! 
 Motivação é a chave para mudanças
Para saber mais
 Site Oficial da FDD
 http://www.featuredrivendevelopment.com
 Grupo de Discussão
 http://br.groups.yahoo.com/group/gufdd
 Java Modeling in Color with UML

A Practical Guide to Feature-Driven Development

Agile Management for Software Engineering

Agradecimento
Principal divulgador da
FDD no Brasil

Adail Muniz – Heptaman

www.heptagon.com.br
Obrigado!!
 Jorge Luis Bublitz jorge.bublitz@yahoo.com.br

 Formado em Administração de Empresas

 MBA em Planejamento Estratégico
 cursando Pós-Graduação em Engenharia de Sistemas
 Chefe da Seção de Análise e Desenvolvimento do TRE-MT
 Certificação Borland/CodeGear Delphi e JBuilder
 Artigos publicados nas revistas Micro Sistemas (!!) e Clube
Delphi
 Palestrante na Borland Conference Revolutions 2007
 Palestrante no 12º Congresso MT Digital - 2008