Jorge Luis Bublitz
Contexto Metodologias Orientação a Objetos Agilidade e Metodologias Ágeis Gestão Ágil de Projetos Mitos Mudanças FDD
“É 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 BirrellA Practical Handbook for Software
Development, 1985
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
“O limite do caos é definido como um estado natural entre ordem e caos, um amplo
compromisso entre estrutura e surpresa. O limite do caos pode ser visualizado como um
estado instável, parcialmente estruturado (...). É instável porque é constantemente atraído para
o caos ou para a ordem absoluta.”
Juan Nogueira, Surfing the Edge of Chaos: Applications to Software Engineering, 2000
Falharam
23%
Concluídos com Sucesso
28%
Completadoscom Alterações
49%
Projetos de Software
Standish Group – www.standishgroup.com
“Para aqueles que ficam imaginando por que o software da Microsoft está sempre um pouco
aquém do esperado, aqui está uma grande parte da razão: há pessoas apenas o suficiente
para implementar as características que absolutamente devem ser incluídas e só há tempo disponível para implementar cada
característica da maneira mais rápida aceitável. E há tempo e pessoas somente o
necessário para testar o produto até o ponto em que o mercado o aceitará marginalmente;
não mais.”
The 12 Simple Secrets ofMicrosoft Management
David Thielen
“Nenhum floco de neve em uma
avalanche se sente responsável por ela”
Stanislaw Lecescritor polonês
Não existe uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes. Desenvolvimento Incremental, Refinamento de Requisitos
e Prototipação Rápida, BONS PROJETISTAS...
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
Adoção de Metodologias Objetivo: tornar o desenvolvimento mais
previsível e mais eficiente Impõe disciplinas rígidas Processos detalhados = Documentação Planejamento é a ênfase
Passam a impressão de serem uma PANACÉIA – cura para todos os males
Também chamado de Modelo em Cascata (Waterfall)
Proposto por Winston W. Royce em 1970 Orientado para documentação Ênfase em planejamento, horários, prazos,
orçamentos e implementação de sistemas inteiros
Há variantes: Incremental, Evolucionário, ...
Qualidade
Prazo
Custo
Escopo
É 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
Oferece uma visão “holística” do assunto sendo analisado
Em meados dos anos 70 e início dos anos 80 (1989 a 1994) vários métodos de modelagem
orientada a objetos surgiram, sendo que os principais foram:
Booch (Grady Booch) OMT (Rumbaugh) OOSE (Jacobson) Shlaer/Mellor (Sally Shlaer e Stephen Mellor) Coad/Yourdon (Peter Coad e Ed Yourdon)
Neste cenário Grady Booch e James Rumbaugh juntaram forças através da Rational
Corporation para unificar os métodos Booch e OMT que resultou na versão 0.8 do Método
Unificado, lançado em outubro de 1995.
Grady Booch James Rumbaugh
No final de 1995, Ivar Jacobson juntou-se a equipe fundindo o método OOSE (Object-Oriented Software Engineering)
Booch, Rumbaugh e Jacobson estavam motivados a criar uma linguagem unificada para modelar sistemas complexos de qualquer tipo: missão crítica tempo real cliente/servidor
Após o apoio de parceiros importantes como Microsoft, Hewlett-Packard, Oracle, IBM, dentre outras em janeiro de 1997 foi lançado a UML 1.0 (Unified Modeling Language)
Estáticos: Use Cases Classes Pacotes
Dinâmicos: Interação
▪ Sequência▪ Colaboração
Estado (Statechart) Atividade
Análise Essencial dizia O QUE fazer e QUANDO
Quando surge a UML, o mercado queria uma um substituto para a Análise Essencial
UML é uma Linguagem e não um Processo Ela fornece os elementos, mas não define
QUANDO usar O mercado rejeitou a UML por não
compreendê-la
a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil2. Desembaraço, ligeireza, presteza de
movimentos3. Mobilidade, perspicácia, vivacidade
Geralmente associa-se AGILIDADE com Rapidez, Flexibilidade, Leveza
“Agilidade é a habilidade para criar e responder às mudanças, para lucrar num ambiente turbulento de negócios, para equilibrar
flexibilidade e estabilidade.”
Jim HighsmithAgile Software
Development Ecosystems2002
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”
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 frequente
MotivaçãoSoftware
que Funciona
Ritmo Constante
Simplicidade
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
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
Proporcionalmente, as metodologias tradicionais ainda dominam
Metodologias Ágeis exigem 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
Apoio das instâncias superiores
Gerenciamento de equipes
Problemas técnicos
Interação com outros departamentos
Interação com clientes
Representam uma grande fonte de problemas
Não é assim que eu sempre fiz
Medo de perder o controle
O chão desabou, como agir?
E a minha autoridade?
Peões que não sabem de nada vão mexer na minha arquitetura?
Não quero olhar para código, isso é coisa para programadores...
E a minha autoridade?
Quebra da rotina Sempre fiz assim, por que tenho que fazer
diferente agora? Especificação incompleta, testes, código
limpo? Isso não é tudo desperdício? Não quero a responsabilidade
Estão tirando o meu emprego?
Vou ter que aprender a programar?
Onde está a especificação completa? Se vocês não sabem ainda o que querem, não
venham me pedir para implementar agora coisas que vou ter que mudar depois.
Eu é quem modelo o Banco, vocês apenas escrevem o código.
Nós sempre fizemos assim e sempre deu certo, por que mudar agora?
Onde estão as minhas garantias?
Qual é o preço final?
Se eu pagar tudo, quero todas as funcionalidades!
Estou pagando para você fazer o trabalho, por que eu devo estar presente? Você quer que eu faça o seu trabalho?
Eu li o livro ____ mas não sei ainda como começar
Eu li o livro ____ mas fiz tudo e não deu certo
Eu li bastante o livro ____, pratiquei escondido, sei como fazer mas não consigo convencer o meu gerente a
experimentar.
Métodos Ágeis é muito bom, sou a favor mas vamos incluir estes 113 formulários e 184
procedimentos para tornar o resultado de melhor qualidade
Métodos Ágeis é muito bom, sou a favor mas vamos usar essa ferramenta que compramos para
controlar todos os passos do desenvolvimento para atingirmos a qualidade total
Métodos Ágeis é muito bom, sou a favor mas precisamos fazer uma coleta de requisitos detalhada
e um planejamento completo antes de começar a implementar, caso contrário vamos fazer besteira.
Métodos Ágeis é muito bom, sou a favor mas nós é quem vamos implementar o sistema, então
vamos explicar ao cliente quais são as funcionalidades mais importantes.
Métodos Ágeis é muito bom, sou a favor mas como nós estamos pagando, vamos definir as
ferramentas e as tecnologias que os programadores irão utilizar para que eles não façam bobagem.
Métodos Ágeis é muito bom, sou a favor mas infelizmente, não podemos nos dar ao luxo de
escrever testes para tudo, isso é radicalismo.
“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
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!
Documentação não é necessária!
Fatos: Empresas passam por auditorias (Fiscal, SOX, ISO) Processos definidos precisam de um nível razoável de
documentação (CMMI, MPS.BR...) A documentação deve ser apropriada para o propósito em
questão (quantidade, qualidade, profundidade, abrangência, etc.)
Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de A documentação deve ser apropriada para o propósito em questão (quantidade, qualidade, profundidade, abrangência, etc.)
Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de “documentabilidade”
Modelagem?? Nem pensar!
Fatos: Scott Ambler demonstrou o valor da Modelagem Ágil Metodologias ágeis, como a FDD, utilizam a modelagem como
vantagem e não como carga inútil “Uma imagem vale mais do que mil palavras” (ou, talvez, linhas
de código?) A geração automática de código, proporcionada por várias
ferramentas (Borland Together, ECO e outros), é um fator para aumento de produtividade, padronização e diminuição de defeitos
A capacidade de entender, memorizar e comunicar é muito maior com imagens do que com textos apenas (alguém aí é da época dos terminais verdes, CP/M, MS-DOS...?)
Ferramentas?? Não, obrigado! Talvez as gratuitas...
Fatos: Ferramentas adequadas aumentam a produtividade A automação ajuda a padronizar e reforçar o processo,
facilitando a adoção e institucionalização O problema não é tanto a ferramenta, mas principalmente
os hábitos:
Os testes são os requisitos, por isso os requisitos são desnecessários!
Fatos: Existem vários tipos de requisitos: de negócio, de usuário,
funcionais, não-funcionais, infra-estrutura, ... Existem vários tipos de testes: unitários, de integração, de
usabilidade, de regressão, de carga, de stress, etc. Os testes são derivados dos requisitos, geralmente os de
usuário (cenários de casos de uso) e funcionais Há uma relação N-N entre testes e requisitos
▪ A rastreabilidade ajuda na sincronização entre eles
Os testes manuais continuarão existindo (100% de automação é 99% improvável)
Agilidade é coisa nova, de 2000 prá cá...
Fatos: Os valores, conceitos e práticas são antigos
(conhecidos e praticados a mais de 15 anos) Algumas metodologias e processos já existiam antes
de 2000:▪ FDD (1997), mas várias práticas são anteriores a 1990▪ Scrum (1993), mas as bases vêm de meados da década de
1980▪ RAD (década de 1980 e início de 1990)
Agilidade, como conceito, faz parte da natureza!
Prêmio Nobel de Física em 1965 QED - Eletrodinâmica Quântica
Trabalhou no projeto Manhattan (1942- 1946)
Enquanto os mainframes não chegavam, simulou algoritmos de cálculos com papel, calculadoras manuais e pessoas (um exército de secretárias!)
Foi capaz de depurar, descobrir erros nos algoritmos e fazer otimizações para acelerar os cálculos!
Quando as máquinas chegaram, foi só codificar e rodar!
“Foco em datas na pior forma possível: ciclos curtos, entregas rápidas, estimativas e re-estimativas frequentes”
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
“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 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
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
Projetos e Processos
Única constante do universo:MUDANÇA
Para melhorar
Para motivar
Para nos tornarmos mais eficientes e eficazes
Para nos tornarmos mais ágeis
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)
“Um plano não é nada... Mas planejar é tudo!”
Dwight D. Eisenhower34º Pres. EUA
(1953-1961)
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)
É 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
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
“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.”
Jorge L. Bublitz
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: Implantação das metodologias de OOAD de Peter Coad e de Gerência de Projetos de Jeff De Luca
Resultado: 2.000 Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla
Jeff De Luca Peter Coad
Stephen Palmer John Mac Felsing
Sede do United Overseas Bank David Anderson, o GUI-Man
Peter Coad e aEquipe de Modelagem
Paul Szego eStephen Palmer
Jeff De Luca e osProgramadores
Inovação Contínua
Adaptabilidade do Produto
Cronogramas Reduzidos de Entrega
Adaptabilidade das Pessoas e Processos
Resultados Confiáveis
Fornece a estrutura suficiente para equipes maiores
Enfatiza a produção de software de qualidade Entrega resultados frequentes, 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
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
<ação> <resultado> <objeto>
Calcular o total da venda
ação objeto resultado
Novidade? Nunca viu algo parecido?
ENTRADA PROCESSAMENTOPROCESSAMENTO SAÍDA
Calcular o total do salário
Autorizar a entrada fora do horário do expediente do funcionário
Assinar digitalmente o documento PDF
Autorizar a transação com o cartão do cliente
Coloque as seguintes funcionalidades no modelo sugerido (<a><r><o>): O usuário é validado antes de entrar no sistema Ao vender um produto, seu estoque é atualizado A compra será paga com cartão de crédito O sistema notifica o cliente 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
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
Diagramas de classes com os principais tipos deobjetos 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
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.)
OA
R
Área 1
Atividade 1.1Feature 1.1.1
Feature 1.1.2
Atividade 1.2Feature 1.2.1
Feature 1.2.2
Área 2Atividade 2.1
Feature 2.1.1
Feature 2.1.2
Atividade 2.2Feature 2.2.1
ClasseA
ClasseB
ClasseC
Objeto1
TelaA
Objeto2
ClasseB
Objeto3
ClasseC
Objeto4
ClasseD
Usuário
1: feature11.1: operacaoC1
1.2: operacaoA1
2.1.1: operacaoD1
2.1: operacaoC2
2.2: operacaoA2
2: feature2
1.1.1: operacaoD1
Estipula quem (pessoa ou papel) é oresponsável final pelo conteúdo de umaclasse (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
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
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
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
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 evitarde 5 a 30 horas de correções
Benefícios secundários Transferência de conhecimento
Conformidade com padrões24%
35%
45%
55%
60%
0%
10%
20%
30%
40%
50%
60%
Técnica
Taxa Média de Detecção de Defeitos
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, 1985
Pro
f. Gu
ilhe
rme
Ho
rta, C
OP
PE
/UF
RJ, 2
00
4
1
Planejamento
2
Detecção
3
Coleção
4
Correção
Artefato
Form.
Planejamento
Form.
Relato de
Defeitos
Form.
Relato de
Defeitos
Form.
Relato de
Defeitos
Artefato
Corrigido
Organizador
Inspetor
Moderador
Inspetor
Autor
Autor
Ad-Hoc
Técnicas de Leitura
Checklists
Prof. Guilherme Horta, COPPE/UFRJ, 2004
Em intervalos regulares, compilar o sistema comtodas 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
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 oumanipulados 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
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
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
Ger. Contas de Clientes (CC) – 90%
Análise dePropostas de
Contas(23)
Nov 2005
95%
Registro deTransaçõesdas Contas
(30)
Dez 2005
82%
Aberturade NovasContas
(11)
Nov 2005
100%
PC-2 PC-2 PC-2
23-24/01/2009
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
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
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
109
Arquiteto Líder É um profissional com experiência em análise e modelagem, capaz de liderar a
equipe no desenvolvimento do modelo que será construído para implementar as features identificadas
Programador Líder É 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
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.
Sua equipe não ficar assim:
Concepção e Planejamento
Construção
Desenvolver
um Modelo
Abrangente
Planejar
por
Feature
Detalhar
por
Feature
Construir
por
FeatureMais conteúdo na forma
Mais forma que conteúdo
Modelo de Objetos
Pacotes de Trabalho
Requisitos
Produto
Plano de
Desenvolvimento
Progresso
Construir
a Lista de
Features
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
Feature-Driven Development
Discussões Iniciais Sobre RequisitosObter Patrocínio da Gerência
Escolha da Linguagem de Programação
Escolha da Plataforma Tecnológica
Protótipo Técnico
Protótipo da Interface com o Usuário
Limpeza de Dados
Conversão de Dados
Teste de Carga
Sistema Piloto
Desenvolvimento em Fases
Teste de Aceitação do Usuário
Teste do SistemaGerenciamento das Alterações nos Requisitos
Gerenciamento de Problemas
Gerenciamento de Recursos
Alocação de Pessoal
Preparação de Orçamento
Planejamento Geral
Desenvolver um Modelo Abrangente
Construir a Lista de Features
Planejar por Feature
Detalhar por Feature
Construir por Feature
Gestão Ágil de Projetos
Concepção e Planejamento
Construção
Análise OO PlanejamentoDecomposição
Funcional
Projeto OOProgramação
e Teste OO
Engenharia
de Requisitos
Desenvolvimento
de Requisitos
Gerência
de Requisitos
Gerência
de Configuração
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 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
Engenharia deRequisitos
IIT Management & Governance
Gerenciamento & Governança de TI
Demanda Estratégica & Operacional
Necessid
ades d
e N
egócio
Necessid
ades d
e N
egócio
Opera
ções d
e T
I (Pro
dução)
Opera
ções d
e T
I (Pro
dução)
ANÁLISE
Priorização | Verificação |Riscos | Estimação
DESCOBERTA
Técnicas | Glossário |Fronteiras do Sistema |
Stakeholders
ESPECIFICAÇÃO
Detalhar Requisitos | Protótipo |Modelo de Cenários de Negócio |
Modelo de Casos de Uso
VALIDAÇÃO
Revisão | Assinatura |Baseline
GERENCIAMENTO
Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança
Karl Wiegers, “Software Requirements”
Requisitosde Negócio
Requisitosde Usuário
Requisitosde Sistema
RequisitosFuncionais
Regras deNegócio
Atributosde Qualidade
InterfacesExternas
Restrições
Documento de Visão e Escopo
Casos de Uso
Especificação deRequisitos de Software
Funcionais Não-Funcionais
23-24/01/2009 “Mapas Mentais: Enriquecendo Inteligências”, Walther Hermann & Viviani Bovo
É 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
Também chamada de “Modelagem de Objetos do Domínio”
Preocupa-se mais com a formado 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
É 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
DMA CLF PPF
DPF CPF
Formar a Equipede Modelagem
(Gerente do Projeto)
Conduzir um EstudoDirigido Sobre o
Domínio de Negócio(Ger. Projeto, Especialistas)
Estudar Documentos(Equipe de Modelagem)
Desenvolver Modelosem Pequenos Grupos(Equipe de Modelagemem pequenos grupos)
Desenvolver umModelo como Equipe
(Equipe de Modelagem)
Refinar o Modelo deObjetos Completo
(Arquiteto Líder,Equipe de Modelagem)
Escrever ComentáriosSobre o Modelo(Arquiteto Líder,
Programador Líder)
opcional
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).
Representa algo que necessita ser registrado,por razões de negócio ou até mesmo legais, queocorre em algum momento no tempo ou duranteum intervalo de tempo
São atividades, eventos e serviços Um momento-intervalo também pode ter
“mi-detalhes”, ou seja, ser composto porpequenas 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
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
É 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>>
É como um item num catálogo, definindo ascaracterísticas de uma determinada coisa,lugar ou até mesmo pessoa (menos comum,mas possível)
Usado para concentrar dados comuns adiversos objetos, possibilitando perguntas denegócio interessantes, como a quantidade deobjetos 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
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
Quarto
IDStatus
Hospede
ScoreDtUltVisita
Hotel
NomeEnderecoEstrelas
PessoaFisica
NomeCPF
Estadia
DHInicioDHTerminoValorTotal
*
Funcionario
DtAdmissaoCTPS
*
*
Servico
DataHoraValor
*
TipoQuarto
DescricaoNumSoltNumCasalFumante?
*
Quarto
IDStatus
Hospede
ScoreDtUltVisita
Hotel
NomeEnderecoEstrelas
PessoaFisica
NomeCPF
Estadia
DHInicioDHTerminoValorTotal
*
Funcionario
DtAdmissaoCTPS
*
*
Servico
DataHoraValor
*
TipoQuarto
DescricaoNumSoltNumCasalFumante?
*
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
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
DMA CLF PPF
DPF CPF
Formar a Equipe
de Lista de Features
(Gerente do Projeto,
Gerente de Desenvolvimento)
Construir a
Lista de Features
(Equipe de
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ó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>
Classe A
Classe B
Classe C
Área n
Atividade X
Feature 1
Feature 2
Atividade Y
Feature 3
Feature 4
Feature 5
...
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
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
DMA CLF PPF
DPF CPF
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)
Regra Empírica da FDD
Cada semana de modelagem resulta em 12 semanas de construção
Pressuposto: a equipe usa UML em Cores, arquétipos e DNC
Truco da Estimativa A Escala de 5 Pontos
Nº Estimado de Classes na Feature
Complexidadeda Feature
Esforço(Pessoa-Dia)
1 1 1
2 2 2
3 3 3
4 4 5
5 5 8 (ou mais)
David Anderson, Agile Management for Software Engineering, 2003
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)
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 asdatas previstas para cada iteração
Agora na fase de construção propriamente dita, deve-se refinar o projeto (design) para cada featureou 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
DMA CLF PPF
DPF CPF
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
Seguir o processo 4 para detalhar um pacote de trabalho Com o pacote de trabalho para a iteração, detalhe os requisitos
para cada feature, se necessário, consultando os Especialistas no Domínio
Para features mais complexas, desenhar um diagrama de seqüência ou de atividades
Caso algum atributo, método, relacionamento ou classe seja incluído/excluído/alterado, atualizar o modelo de objetos
Anotar as decisões tomadas no modelo Preparar o código fonte das classes (esqueleto) Realizar uma inspeção de qualidade no trabalho
realizado
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
DMA CLF PPF
DPF CPF
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)
Seguir o processo 5 para construir as features Para cada feature do pacote de trabalho, siga as
instruções do diagrama de seqüência (se houver) e implemente as alterações propostas nas classes (lembre-se da posse individual de classe!)
Realize testes unitários em cada feature, relatando os resultados para a equipe
Realize uma inspeção no código gerado Se houver erros, corrigir e testar novamente Integre a porção de código trabalhado no produto
final Realize testes de integração
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
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
13Incluir um novo cliente na lista de
clientesHM 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
14Registrar um serviço realizado num
carroAR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
15Registrar uma lista de peças
utilizadas num serviçoAR
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
16Calcular o custo total das peças
usadas num serviçoHM
AS
SM10/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
18Receber um pagamento por um
serviçoHM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
19Registrar a opção de pagamento
preferida por um clienteAR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente)
NNEE
PendentesBacklog
Fulano
Beltrana
Sicrano
Zé
J.J.
Iniciadas Inspeção/Teste Finalizadas
NN NN II
NN
NN NNEE NN II
NN NNNN NN
NN NN NN
NN NN II
EE
NN
NN
NN
NN NN
NN NN II
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 AI3Classe -> VendaTela -> 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 alteradapor outra tarefa
Mês/Ano
Porcentagem Completada:
Prazo de Entrega:
Completada
Mês e Ano para entrega
Status da Atividade:
MA
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
Legenda: Em andamento Atenção Completada Barra de Progresso Não iniciada
Gerenciamento de Vendas de Produtos (VP) – 34%
Entrada dePedidos
(33)
Fev 2006
PC-1
Controle deContratos
(13)
Abr 2006
Venda deProdutos
(22)
Nov 2005
PC-1
Envio deProdutos
(19)
Mar 2006
PC-1
10%
Entrega deProdutos
(10)
Abr 2006
PC-3
30%
Relatórios deVendas
(14)
Dez 2005
75%99% 3%
Ger. Contas de Clientes (CC) – 90%
Análise dePropostas de
Contas(23)
Nov 2005
95%
Registro deTransaçõesdas Contas
(30)
Dez 2005
82%
Aberturade NovasContas
(11)
Nov 2005
100%
Gerenciamento de Estoque (GE) – 94%
Definição deUnidades de
Estoque(26)
Nov 2005
100%
Movimentaçãode Mercadorias
(19)
Jan 2006
82%
PC-3
Aceite deRequisições
de Movimento(18)
Dez 2005
97%
PC-3
PC-2 PC-1
PC-2 PC-2 PC-2 PC-3
SistemaComercial
(238)
Abr 2006
65%
Diagrama de Fluxo Acumulado
Legenda:
Não iniciada
Em andamento
Completada
Tempo (semanas)
Fe
atu
res
Prazo de Entrega
(Lead Time)
Estoque Intermediário
(Work in Progress)
Fecham
ento
Execução, Monitoramento & Controle
Planejamento e Lançamento
Escopo
Definir o
escopo da
solução
Modelar
a solução
Construir a
Lista de
Features
Montar os
Conjuntos
de Features
Desenvolver
o Plano de
Features
Detalhar um
Conjunto de
Features
Construir um
Conjunto de
Features
Teste de
Integração
Implantar?Detalhar um
Conjunto de
Features
Construir um
Conjunto de
Features
Teste de
Integração
Implantar?
UP
• Rigorosidade
• Controle
• Equipes grandes
XP / SCRUM
• Agilidade
• Liberdade
• Equipes pequenas
Quero apenas oProcesso Suficiente
Escalável para Equipes Pequenas, Médias e Grandes
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
FDD XP
Certo planejamento inicialPlanejamento durante o
desenvolvimento
Refactoring é exceção Refactoring é a norma
Programadores Líderes e Proprietários de Classes
Posse coletiva do código
Design formal eInspeções de código e modelo
Programação em pares
Iniciação Elaboração Construção Transição
Processo UnificadoProcesso Unificado
FDDDMA CLF PPF
DPF CPF
XP
OID: Inovação e Implantação Organizacional
CAR: Análise e Prevenção de Defeitos
5 EmOtimização
4 GerenciadoQuantitativam.
3 Definido
2 Gerenciado
MelhoriaContínua do
Processo
GerênciaQuantitativa
Padronizaçãodo Processo
GerênciaBásica deProjetos
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
FD
D
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
Podemos também aplicar a FDD emdiferentes níveis do problema ou daorganizaçã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
A Gestão de Projetos pela Corrente Crítica (CCPM -Critical Chain Project Management) é a aplicação da Teoria das Restrições (TOC – Theory of Constraints) à gestão de projetos
23-24/01/2009 173
CF A
10d
CF B
15d
CF C
13d
Pulmão
11d
CF D
25d
CF E
32d
CF F
17d
CF G
8d
CF H
23d
CF I
19d
Pulm.
16d
Integr.
10d
Testes
20d
Pulmão Projeto
30d
Pulm.
10d
Conc.
10d
Concepção e Planejamento
Desenvolver
um Modelo
Abrangente
Planejar
por
Feature
Construir
a Lista de
Features
Construção
Detalhar
por
Feature
Construir
por
Feature
É conhecida por diminuir drasticamente a duração dos projetos (em 30% a 50%, em média), com maior qualidade e com o escopo contratado
A CCPM oferece técnicas para ajudar no planejamento e na execução do projeto
23-24/01/2009
É 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
174
23-24/01/2009 175
Geralmente a iniciativa começa nos desenvolvedores Uma das boas contribuições da XP
Mas se o desenvolvimento se tornar ágil e a gerência continuar tradicional, haverá desgaste A diferença de impedância causa perdas
Assim, a Agilidade deve ser um objetivo comum Gerência e Desenvolvedores devem responder:
1) O que mudar?
2) Para o que mudar?
3) Como causar a mudança? A escolha da(s) metodologia(s) será resultado do passo 3! Não faça isso
antes! Realize projetos pilotos para experimentar (e errar!) Adapte a metodologia às suas necessidades
Status da Atividade:
Em andamentoRequer atençãoCompletadaNão iniciada
Nome da Atividade
de Negócio
(nº de features)
75%
Mês/Ano
0
20
40
60
80
100
120
140
160
180
200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Features
Iniciadas
Concluídas
Autorização para Entrada fora do Horário do Expediente
Como funciona hoje:1. Servidor preenche Requerimento2. Chefia imediata autoriza3. Chefia Superior (Secretário, Assessor, Diretor,
...) Autoriza4. Encaminha requerimento a Seção de
Segurança5. Encaminha Requerimentos Autorizados a
guarita
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
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
1ª Entrega
• Autenticar usuário no sistema
• Preencher o requerimento de autorização
2ª Entrega
• Autorizar/Recusar o requerimento pela Chefia Imediata
• Autorizar/Recusar o requerimento pela Chefia Superior
• Gerar listagem de requerimentos autorizados
3ª Entrega
• Enviar e-mail a Chefia Imediata
• Enviar e-mail a Chefia Superior
• Enviar e-mail ao Chefe da Segurança
• Gerência de Requisitos
• Planejamento de Projeto
• Monitoramento e Controle de Projeto
• Gerência de Acordos Com Fornecedores –Gerência de Subcontratação
• Medição e Análise
• Garantia da Qualidade do Processo e do Produto
• Gerência de Configuração
Nível 2 –Gerenciado
Foco: Gerência Básica de Projetos
• Desenvolvimento de Requisitos
• Solução Técnica
• Integração do Produto
• Verificação
• Validação
• Foco no Processo Organizacional
• Definição do Processo Organizacional
• Treinamento Organizacional
• Gerenciamento de Risco
• Análise e Tomada de Decisão
• Ambiente Organizacional para Integração
Nível 3 –Definido
Foco: Padronização do
Processo
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
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 muitas vezes o investimento!
Motivação é a chave para mudanças!!
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
Principal divulgador da FDD no Brasil
Adail Muniz Retamal Heptaman
www.heptagon.com.br
Jorge Luis Bublitz
Formado em Administração de Empresas MBA em Planejamento Estratégico Pós-Graduação em Engenharia de Sistemas
Chefe da Seção de Análise e Desenvolvimento (TRE-MT) Certificação Delphi e JBuilder Artigos publicados nas revistas Micro Sistemas (!?) e Clube Delphi
Palestrante no 12º Congresso MT Digital - 2008 Palestrante na Conferência da Borland – Borcon Revolutions 2007 Palestrante na Conferência Mundial da CodeGear – CodeRage III 2008
Assinante do Agile Manifesto Membro da Agile Aliance
"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."
Valeu !!!!!
Jorge FDDMan
Email e MSN:[email protected]
Páginas:http://bublitz.tripod.com
http://jorge-fdd.blogspot.com