2.
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."
5. 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
6. 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
13. Como você quer o seu
projeto?
Rápido
Qualidade
Barato
$$$
Mal
Feito
Não pode
ser rápido
UTOPIA
14. A Solução é...
Não existe uma solução mágica e
única, mas sim um conjunto de
práticas reconhecidamente
eficientes: as Práticas e os
Princípios do Movimento Ágil
15. 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
16. 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
20. 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, ...
23. 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
25. 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
26. 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”
27. 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
28. Princípios Ágeis
• Satisfação do Cliente
• Responder às Mudanças
• Entrega Freqüente
• Motivação
• Software que Funciona
• Ritmo Constante
• Simplicidade
29. 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
30. 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
32. 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
33. Maiores Dificuldades
• Apoio das instâncias superiores
• Gerenciamento de equipes
• Problemas técnicos
• Interação com outros departamentos
• Interação com clientes
36. 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
37. 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!
38. 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
39. 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á”
40. 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
41. 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
43. Porque mudar??
• Única constante do universo:
MUDANÇA
• Para melhorar
• Para motivar
• Para nos tornarmos mais eficientes e eficazes
• Para nos tornarmos mais ágeis
44. 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
46. 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)
47. 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.Afine o instrumento
48. 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
49. 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)
50. 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
51. 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
53. 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
54. 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
55. 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
57. 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
58. 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
60. 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
61. 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
63. 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
64. 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
65. 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
66. 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
68. 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.)
69. Á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
70. 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
71. 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
72. 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
73. 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
74. 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
75. 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
76. 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
77. 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
78. 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
79. 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
82. 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
83. 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 conflito
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
84. 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 fixo da equipe e sempre esta fornecendo
feedback das entregas para todos os envolvidos.
85. Arquiteto Líder
• É um profissional 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 identificadas
• 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.
86. Programador Líder
• Também chamado de Programador-Chefe
• É um profissional mais experiente, que possui reconhecimento
como tal pela equipe
• Coordena o desenvolvimento das features, monta as equipes de
features e participa das definiçõ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.
87. 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.
88. 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
91. 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
92. 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
93. Gestão Ágil de Projetos
Concepção e Planejamento
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 Configuração
Principais Disciplinas
Envolvidas
94. 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
95. 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
97. 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
98. 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
99. 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
100. 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
102. 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)
103. 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
104. 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
105. 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>>
106. 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
107. 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
110. 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
111. 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)
! Artefatos produzidos:
" Lista de Features
" Requisitos mais detalhados
DPF CPF
PPFCLFDMA
112. 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
113. Sistema ou
Aplicação
Área de Negócio Área de Negócio Área de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de NegócioFuncionalidade
Funcionalidade
Gerenciamento de ...
<Substantivo>
<VerboInfinitivo> ...
<Ação> <Resultado> <Objeto>
FBS: Feature Breakdown
Structure
114. 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
115. 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
116. 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
! Artefatos produzidos:
" Plano de desenvolvimento
" Pacotes de trabalho
" Lista de classes com seus donos
DPF CPF
DMA CLF PPF
117. 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
(Equipe de Planejamento)
Atribuir Classes para
os Desenvolvedores
(Equipe de Planejamento)
Processo Nº 3:
Planejar por Feature
118. 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
119. 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)
120. 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
121. 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
! Artefatos produzidos:
" 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
122. 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
(Equipe de Features)
Refinar o Modelo
de Objetos
(Programador Líder)
Escrever Prólogos de
Classes e Métodos
(Equipe de Features)
Inspecionar o
Projeto (Design)
(Equipe de Features)
opcional
opcional
opcional
4. Detalhar por Feature
123. 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)
! Artefatos produzidos:
" 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
124. Implementar Classes
e Métodos
(Equipe de Features)
Testes Unitários
(Equipe de Features)
Conduzir uma Inspeção
no Código
(Equipe de Features)
Promover para o Build
(Programador Líder,
Equipe de Features)
5. Construir por Feature
126. 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
127. 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
129. 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
130. 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
137. 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é)
Concepção e Planejamento
1
DMA
3
PPF
2
CLF
Construção
4
DPF
5
CPF
9. Inspeção e
Adaptação
Scrum e FDD
138. 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
139. 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
140. 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
Configuraçã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
143. 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 é definir, para cada aspecto, quem é o cliente e derivar
as features a partir desta perspectiva
144. 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
145. 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 suficiente e controlar o andamento do projeto
• Atende às necessidades dos clientes, gerentes e
desenvolvedores
146. 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
147. 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
148. 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!!
153. 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
154. 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."