Aula FDD CESAR Recife GAP
Upcoming SlideShare
Loading in...5
×
 

Aula FDD CESAR Recife GAP

on

  • 1,506 views

Aula FDD CESAR Recife GAP

Aula FDD CESAR Recife GAP

Statistics

Views

Total Views
1,506
Views on SlideShare
1,506
Embed Views
0

Actions

Likes
1
Downloads
38
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Aula FDD CESAR Recife GAP Aula FDD CESAR Recife GAP Presentation Transcript

    • CESAR - GAP 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." • Engº Jorge Luis Bublitzsexta-feira, 22 de abril de 2011
    • Agenda • Contexto • Metodologias • Agilidade e Metodologias Ágeis • Mudanças • FDDsexta-feira, 22 de abril de 2011
    • Contextosexta-feira, 22 de abril de 2011
    • 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, 1985sexta-feira, 22 de abril de 2011
    • 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 determinadasexta-feira, 22 de abril de 2011
    • The Caos Report - 1995 Concluídos com Sucesso 16% Falharam 31% Concluídos com Alterações 53% Standish Group – www.standishgroup.comsexta-feira, 22 de abril de 2011
    • The Caos Report - 2001 Falharam Concluídos com Sucesso 23% 28% Concluídos com Alterações 49% Standish Group – www.standishgroup.comsexta-feira, 22 de abril de 2011
    • The Caos Report - 2009 Falharam 24% Concluídos com Sucesso 32% Concluídos com Alterações 44% Standish Group – www.standishgroup.comsexta-feira, 22 de abril de 2011
    • Vamos Analisar Sucesso Alterações Falharam 25,00 50,00 75,00 100,00 1994 1996 1998 2000 2002 2004 2006 2009 Standish Group – www.standishgroup.comsexta-feira, 22 de abril de 2011
    • Funcionalidades/Funções Utilizadas em um Sistema Sempre 7% Muito 13% Nunca 45% Algumas Vezes 16% Raramente 19% Standish Group – www.standishgroup.comsexta-feira, 22 de abril de 2011
    • Culpado(s)??? Clientes Desenvolvedores Analistas Ferramentas Processosexta-feira, 22 de abril de 2011
    • A Solução é... • Não existe uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes. • Desenvolvimento Incremental, Refinamento de Requisitos, BONS PROJETISTAS...sexta-feira, 22 de abril de 2011
    • 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 gruposexta-feira, 22 de abril de 2011
    • 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ÉIAsexta-feira, 22 de abril de 2011
    • Metodologiassexta-feira, 22 de abril de 2011
    • Modelo Tradicional Levantamento de Requisitos Projeto Implementação Testes Implantaçãosexta-feira, 22 de abril de 2011
    • 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, ...sexta-feira, 22 de abril de 2011
    • Novos Tempos (??) Menor Tempo Maior Menor Qualidade Custosexta-feira, 22 de abril de 2011
    • Novos Problemas (?) Escopo Qualidade Prazo Custosexta-feira, 22 de abril de 2011
    • Análise OOsexta-feira, 22 de abril de 2011
    • Análise Orientada por Objetos • É 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 objetossexta-feira, 22 de abril de 2011
    • Métodos Orientados a Objetos 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)sexta-feira, 22 de abril de 2011
    • Método Unificado 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 .sexta-feira, 22 de abril de 2011
    • UML • 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)sexta-feira, 22 de abril de 2011
    • Evoluçãosexta-feira, 22 de abril de 2011
    • Diagramas da UML • Estáticos: • Use Cases • Classes • Pacotes • Dinâmicos: • Interação • Sequência • Colaboração • Estado (Statechart) • Atividadesexta-feira, 22 de abril de 2011
    • Caso de Usosexta-feira, 22 de abril de 2011
    • Classesexta-feira, 22 de abril de 2011
    • Seqüênciasexta-feira, 22 de abril de 2011
    • Atividadesexta-feira, 22 de abril de 2011
    • Estadosexta-feira, 22 de abril de 2011
    • A Decepção • 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ê-lasexta-feira, 22 de abril de 2011
    • Agilidade e Metodologias Ágeissexta-feira, 22 de abril de 2011
    • 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, Levezasexta-feira, 22 de abril de 2011
    • 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 2002sexta-feira, 22 de abril de 2011
    • 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”sexta-feira, 22 de abril de 2011
    • 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.orgsexta-feira, 22 de abril de 2011
    • Princípios Ágeis • Satisfação do Cliente • Responder às Mudanças • Entrega Freqüente • Motivação • Software que Funciona • Ritmo Constante • Simplicidadesexta-feira, 22 de abril de 2011
    • 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ívelsexta-feira, 22 de abril de 2011
    • 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 aparecersexta-feira, 22 de abril de 2011
    • Quem Adotou ou Está Adotando?sexta-feira, 22 de abril de 2011
    • Mas... • 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 especialistassexta-feira, 22 de abril de 2011
    • Maiores Dificuldades • Apoio das instâncias superiores • Gerenciamento de equipes • Problemas técnicos • Interação com outros departamentos • Interação com clientessexta-feira, 22 de abril de 2011
    • Pessoas Representam uma grande fonte de problemassexta-feira, 22 de abril de 2011
    • Gerentes Tradicionais • Não é assim que eu sempre fiz • Medo de perder o controle • O chão desabou, como agir? • E a minha autoridade?sexta-feira, 22 de abril de 2011
    • Arquitetos • 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?sexta-feira, 22 de abril de 2011
    • Programadores • 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 responsabilidadesexta-feira, 22 de abril de 2011
    • Testadores • Estão tirando o meu emprego? • Vou ter que aprender a programar?sexta-feira, 22 de abril de 2011
    • DBAs • 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?sexta-feira, 22 de abril de 2011
    • Clientes • 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?sexta-feira, 22 de abril de 2011
    • Coach novato • 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.sexta-feira, 22 de abril de 2011
    • Métodos Pseudo-Ágeis • 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.sexta-feira, 22 de abril de 2011
    • Métodos Pseudo-Ágeis • 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.sexta-feira, 22 de abril de 2011
    • Métodos Pseudo-Ágeis Levantamento de Requisitos XP, Scrum, ... Projeto Implementação Testes Implantação Implantação com Testessexta-feira, 22 de abril de 2011
    • Mitos sobre as Metodologias Ágeissexta-feira, 22 de abril de 2011
    • 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 Qualidadesexta-feira, 22 de abril de 2011
    • 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!sexta-feira, 22 de abril de 2011
    • Consequência #1 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”sexta-feira, 22 de abril de 2011
    • Consequência #2 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...?)sexta-feira, 22 de abril de 2011
    • Consequência #3 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:sexta-feira, 22 de abril de 2011
    • Consequência #4 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)sexta-feira, 22 de abril de 2011
    • Consequência #5 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!sexta-feira, 22 de abril de 2011
    • Richard Feynman: Agilista?? • 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!sexta-feira, 22 de abril de 2011
    • 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 • “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á”sexta-feira, 22 de abril de 2011
    • 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 sistemasexta-feira, 22 de abril de 2011
    • 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 priorizadassexta-feira, 22 de abril de 2011
    • Mudanças Projetos e Processossexta-feira, 22 de abril de 2011
    • Porque mudar?? • Única constante do universo: MUDANÇA • Para melhorar • Para motivar • Para nos tornarmos mais eficientes e eficazes • Para nos tornarmos mais ágeissexta-feira, 22 de abril de 2011
    • 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 Whirlpoolsexta-feira, 22 de abril de 2011
    • O Processo de Mudançasexta-feira, 22 de abril de 2011
    • Diferenças de Paradigmas • Tradicional • Ágil • Ser capaz de controlar / • Ser capaz de lidar com a eliminar a incerteza incerteza • Planejamento e controle de • Planejamento e controle de progresso através do progresso através da Caminho Crítico / EVA Corrente Crítica / Buffers • Replanejar deve ser a • Replanejar deve ser a regra exceção sempre (há limites práticos) • Controle rígido do escopo do projeto • Controle do escopo das iterações • Teorias básicas: Gerenciamento Total da • Teorias básicas: Qualidade Teoria do Caos Controle Estatístico de Teoria das Restrições (TOC) Processos Produção Enxuta (Lean)sexta-feira, 22 de abril de 2011
    • Planejar X Plano “Um plano não é nada... Mas planejar é tudo!” Dwight D. Eisenhower 34º Pres. EUA (1953-1961)sexta-feira, 22 de abril de 2011
    • Para que serve um Processo? • O propósito de um processo de desenvolvimento de software é: • capacitar e reforçar a entrega repetível de software que funciona... • no prazo adequado e eficiente em relação ao seu custo... • fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de um projeto... • com o mínimo de interrupção para os desenvolvedores Coad, De Luca (JMCU)sexta-feira, 22 de abril de 2011
    • 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 equipesexta-feira, 22 de abril de 2011
    • 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 motivadasexta-feira, 22 de abril de 2011
    • Desenvolvimento Dirigido a Funcionalidadessexta-feira, 22 de abril de 2011
    • 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 Munizsexta-feira, 22 de abril de 2011
    • 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ívelsexta-feira, 22 de abril de 2011
    • 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 duplasexta-feira, 22 de abril de 2011
    • Os “Culpados” Jeff De Luca Peter Coad Stephen Palmer John Mac Felsingsexta-feira, 22 de abril de 2011
    • O Berço da FDD Sede do United Overseas Bank David Anderson, o GUI-Man Peter Coad e a Paul Szego e Jeff De Luca e os Equipe de Modelagem Stephen Palmer Programadoressexta-feira, 22 de abril de 2011
    • O que a FDD pode proporcionar?? • Inovação Contínua • Adaptabilidade do Produto • Cronogramas Reduzidos de Entrega • Adaptabilidade das Pessoas e Processos • Resultados Confiáveissexta-feira, 22 de abril de 2011
    • Principais Característicassexta-feira, 22 de abril de 2011
    • 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 desenvolvedoressexta-feira, 22 de abril de 2011
    • 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 funcionalsexta-feira, 22 de abril de 2011
    • MODELO • <A><R><O> • <Ação> <Resultado> <Objeto> • Calcular o Total da Vendasexta-feira, 22 de abril de 2011
    • Outros Exemplos • 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 • Calcular o desconto de uma venda • Listar os clientes ativos da empresa • Destacar os clientes devedores de uma filial • Imprimir a nota fiscal de uma venda • Validar a senha de um usuário • Efetuar a matrícula do aluno no cursosexta-feira, 22 de abril de 2011
    • Exercício • 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 prenhasexta-feira, 22 de abril de 2011
    • 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 resultadossexta-feira, 22 de abril de 2011
    • 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 projetosexta-feira, 22 de abril de 2011
    • Exemplo de Modelo de Domíniosexta-feira, 22 de abril de 2011
    • 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.)sexta-feira, 22 de abril de 2011
    • As Features Preenchem o Modelo de Domínio ClasseA  Área 1   Atividade 1.1  Feature 1.1.1 Feature 1.1.2 ClasseB  Atividade 1.2  Feature 1.2.1 Feature 1.2.2 ClasseC Área 2 Atividade 2.1 Feature 2.1.1 Feature 2.1.2 Atividade 2.2 Feature 2.2.1sexta-feira, 22 de abril de 2011
    • As Features Preenchem o Modelo de Domínio Objeto1 Objeto2 Objeto3 Objeto4 TelaA ClasseB ClasseC ClasseD Usuário 1: feature1 1.1: operacaoC1 1.1.1: operacaoD1 1.2: operacaoA1 2: feature2 2.1: operacaoC2 2.1.1: operacaoD1 2.2: operacaoA2sexta-feira, 22 de abril de 2011
    • 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 bemsexta-feira, 22 de abril de 2011
    • 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 terminarsexta-feira, 22 de abril de 2011
    • 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 Taxa Média de Detecção de Defeitos • Inspeções cortam erros em mais de 80% • 1 hora de inspeção pode evitar 60% 60% de 5 a 30 horas de correções 55% 45% Teste Unitário Teste Funcional 35% 45% • Benefícios secundários Teste de Integração Inspeção de Design Inspeção de Código 24% 30% • Transferência de conhecimento 15% • Conformidade com padrões Técnica 0% Jones, C.L. “A Process-Integrated Approach to Defect Prevention”, IBM Systems Journal, 1985sexta-feira, 22 de abril de 2011
    • Detecção Antecipada de Defeitos Prof. Guilherme Horta, COPPE/UFRJ, 2004sexta-feira, 22 de abril de 2011
    • Como Conduzir Uma Inspeção Artefato 1 Form. Organizador Planejamento Planejamento Form. 2 Relato de Inspetor Detecção Defeitos Form. Ad-Hoc 3 Moderador Relato de Técnicas de Leitura Coleção Inspetor Defeitos Checklists Autor Form. Relato de 4 Defeitos Correção Autor Artefato Prof. Guilherme Horta, COPPE/UFRJ, 2004 Corrigidosexta-feira, 22 de abril de 2011
    • 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 projetosexta-feira, 22 de abril de 2011
    • 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 Principais Artefatos de Desenvolvimento do Produto Desenvolvimento • Objetivos • Facilitar o desenvolvimento de software • Garantir a integridade dos produtos • Controlar efetivamente as modificações Gerenciamento • 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, Tarefassexta-feira, 22 de abril de 2011
    • Tarefas Rotineiras do Gerenciamento de Configuração • Versionamento  Gerenciamento de Processo  Definição de Workflow • Check out/check in  Critérios de Entrada/Saída • Histórico de revisões • Branching & Merging  Notificações • Visões de Projeto  Garantia de Segurança  Gerenciamento de Montagem • Gestão de Mudanças  Identificação de • Acompanhamento de defeitos Dependências • Listas de Melhoria  Controle de Montagens • Associações  Gerenciamento de Liberação • Rastreabilidade  Rótulos  Estados Promocionais • Gestão de Tarefas  Implantação • Criação e Acompanhamento • Ficha de temposexta-feira, 22 de abril de 2011
    • 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 projetosexta-feira, 22 de abril de 2011
    • Os Papéissexta-feira, 22 de abril de 2011
    • Principais Papéis Gerente de Desenvolvimento Especialista Domínio do Programador Negócio Líder GERENTE DE PROJETOS Arquiteto Proprietário Líder de Classessexta-feira, 22 de abril de 2011
    • 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 projetosexta-feira, 22 de abril de 2011
    • 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 projetosexta-feira, 22 de abril de 2011
    • 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.sexta-feira, 22 de abril de 2011
    • 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.sexta-feira, 22 de abril de 2011
    • Programador Líder • Também chamado de Progranador-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.sexta-feira, 22 de abril de 2011
    • 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.sexta-feira, 22 de abril de 2011
    • Funções de Apoio Gerente de Guru da Engenheiro de Versão Linguagem Desenvolvimento Produtor de Administrador Testadores Ferramentas e de Sistemas Utilitários Escritores Implantadores Técnicossexta-feira, 22 de abril de 2011
    • Os 5 Processossexta-feira, 22 de abril de 2011
    • Os 5 Processos Requisitos Concepção e Planejamento Desenvolver Construir Planejar Mais forma que conteúdo um Modelo a Lista de por Abrangente Features Feature Plano de Desenvolvimento Construção Modelo de Objetos Detalhar Construir Progresso Mais conteúdo na forma por por Feature Feature Produto Pacotes de Trabalho Fonte: Heptagon – www.heptagon.com.brsexta-feira, 22 de abril de 2011
    • 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çãosexta-feira, 22 de abril de 2011
    • O Contexto da FDD Discussões Iniciais Sobre Requisitos Obter Patrocínio da Gerência Escolha da Linguagem de Programação Feature-Driven Development Planejamento Geral Desenvolver um Modelo Abrangente Escolha da Plataforma Tecnológica Preparação de Orçamento Construir a Lista de Features Protótipo Técnico Alocação de Pessoal Planejar por Feature Protótipo da Interface com o Usuário Gerenciamento de Recursos Detalhar por Feature Limpeza de Dados Gerenciamento de Problemas Construir por Feature Conversão de Dados Gerenciamento das Alterações nos Requisitos Teste do Sistema Teste de Carga Teste de Aceitação do Usuário Sistema Piloto Desenvolvimento em Fasessexta-feira, 22 de abril de 2011
    • Principais Disciplinas Envolvidas Gestão Ágil de Projetos Engenharia de Requisitos Concepção e Planejamento Desenvolvimento de Requisitos Decomposição Análise OO Planejamento Funcional Gerência de Requisitos Construção Gerência de Configuração Programação Projeto OO e Teste OOsexta-feira, 22 de abril de 2011
    • 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çãosexta-feira, 22 de abril de 2011
    • 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çossexta-feira, 22 de abril de 2011
    • Estabelecer o Propósito do Projeto Meta Condição Condição Condição Necessária Necessária Necessária Objetivo Objetivo Objetivo Intermediário Intermediário Intermediário Objetivo Objetivo Objetivo Intermediário Intermediário Intermediário Objetivo Objetivo Intermediário Intermediáriosexta-feira, 22 de abril de 2011
    • Engenharia de Requisitos Gerenciamento & Governança de TI Operações de TI (Produção) IIT Management & Governance Demanda Estratégica Necessidades de Negócio & Operacional Engenharia de ANÁLISE Requisitos Priorização | Verificação | Riscos | Estimação DESCOBERTA ESPECIFICAÇÃO VALIDAÇÃO Técnicas | Glossário | Detalhar Requisitos | Protótipo | Revisão | Assinatura | Fronteiras do Sistema | Modelo de Cenários de Negócio | Baseline Stakeholders Modelo de Casos de Uso GERENCIAMENTO Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurançasexta-feira, 22 de abril de 2011
    • Tipos de Requisitos Funcionais Não-Funcionais Requisitos de Negócio Documento de Visão e Escopo Regras de Requisitos Negócio de Usuário Atributos de Qualidade Casos de Uso Interfaces Requisitos Externas de Sistema Requisitos Funcionais Restrições Especificação de Karl Wiegers, “Software Requirements” Requisitos de Softwaresexta-feira, 22 de abril de 2011
    • 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 problemasexta-feira, 22 de abril de 2011
    • 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, DMA CLF PPF atividades, estados, casos de uso  Lista preliminar de requisitos DPF CPF  Anotações nos modelossexta-feira, 22 de abril de 2011
    • 1. Desenvolver um Modelo Abrangente Conduzir um Estudo Formar a Equipe Dirigido Sobre o de Modelagem Domínio de Negócio (Gerente do Projeto) (Ger. Projeto, Especialistas) opcional Desenvolver Modelos Estudar Documentos em Pequenos Grupos (Equipe de Modelagem) (Equipe de Modelagem em pequenos grupos) Refinar o Modelo de Desenvolver um Objetos Completo Modelo como Equipe (Arquiteto Líder, (Equipe de Modelagem) Equipe de Modelagem) Escrever Comentários Sobre o Modelo (Arquiteto Líder, Programador Líder)sexta-feira, 22 de abril de 2011
    • Arquitetura em Camadas CO Apresentação O F Negócio – Domínio do Problema Persistência Interface com Outros Sistemassexta-feira, 22 de abril de 2011
    • 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).sexta-feira, 22 de abril de 2011
    • 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çãosexta-feira, 22 de abril de 2011
    • 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” simplessexta-feira, 22 de abril de 2011
    • 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>>sexta-feira, 22 de abril de 2011
    • 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 lookupssexta-feira, 22 de abril de 2011
    • 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 TIsexta-feira, 22 de abril de 2011
    • UML Sem Cores Hotel Funcionario PessoaFisica Nome * DtAdmissao Nome Endereco CTPS CPF Estrelas * TipoQuarto Quarto Estadia Hospede Descricao * ID DHInicio * Score NumSolt Status DHTermino DtUltVisita NumCasal ValorTotal Fumante? * Servico Data Hora Valorsexta-feira, 22 de abril de 2011
    • UML em Cores Hotel Funcionario PessoaFisica Nome * DtAdmissao Nome Endereco CTPS CPF Estrelas * TipoQuarto Quarto Estadia Hospede Descricao * ID DHInicio * Score NumSolt Status DHTermino DtUltVisita NumCasal ValorTotal Fumante? * Servico Data Hora Valorsexta-feira, 22 de abril de 2011
    • 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) DMA CLF PPF  Artefatos produzidos:  Lista de Features DPF CPF  Requisitos mais detalhadossexta-feira, 22 de abril de 2011
    • 2. Construir a Lista de Features Formar a Equipe de Lista de Features (Gerente do Projeto, Gerente de Desenvolvimento) Construir a Lista de Features (Equipe de Lista de Features)sexta-feira, 22 de abril de 2011
    • FBS: Feature Breakdown Structure Sistema ou Gerenciamento de ... 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 Funcionalidade Atividade de Negócio <Substantivo> Funcionalidade <Ação> <Resultado> <Objeto> <VerboInfinitivo> ...sexta-feira, 22 de abril de 2011
    • As Features preenchem o Modelo Área n Atividade X Feature 1 Classe A Feature 2 Atividade Y Feature 3 Feature 4 Classe B Feature 5 ... Classe Csexta-feira, 22 de abril de 2011
    • 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: DMA CLF PPF  Plano de desenvolvimento  Pacotes de trabalho DPF CPF  Lista de classes com seus donossexta-feira, 22 de abril de 2011
    • Processo Nº 3: Planejar por Feature Formar a Equipe Determinar a Sequência de Planejamento de Desenvolvimento (Gerente do Projeto) (Equipe de Planejamento) Atribuir Conjuntos de Atribuir Classes para Features para os Desenvolvedores Programadores Líderes (Equipe de Planejamento) (Equipe de Planejamento)sexta-feira, 22 de abril de 2011
    • Estimativas  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 (ou Poker) da Estimativa  A Escala de 5 Pontos Nº Estimado de Classes na Complexidade Esforço Feature da Feature (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, 2003sexta-feira, 22 de abril de 2011
    • 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 Pacote 2 Pacote 3 Pacote 4 (10) (8) (13) (15)sexta-feira, 22 de abril de 2011
    • 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 DMA CLF PPF  Relatório de inspeção do design  Relatório de progresso atualizado DPF CPFsexta-feira, 22 de abril de 2011
    • 4. Detalhar por Feature opcional Conduzir um Estudo Formar a Equipe Dirigido Sobre o de Features Domínio de Negócio (Programador Líder) (Especialista no Domínio) opcional opcional Estudar Documentos Desenvolver os de Referência Diagramas de Sequência (Equipe de Features) (Equipe de Features) Refinar o Modelo Escrever Prólogos de de Objetos Classes e Métodos (Programador Líder) (Equipe de Features) Inspecionar o Projeto (Design) (Equipe de Features)sexta-feira, 22 de abril de 2011
    • 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 DMA CLF PPF  Relatórios de inspeção e testes  Lista de alterações feitas/necessárias  Relatório de progresso atualizado DPF CPFsexta-feira, 22 de abril de 2011
    • 5. Construir por Feature Implementar Classes Testes Unitários e Métodos (Equipe de Features) (Equipe de Features) Conduzir uma Inspeção Promover para o Build no Código (Programador Líder, (Equipe de Features) Equipe de Features)sexta-feira, 22 de abril de 2011
    • Gerenciamento do Projetosexta-feira, 22 de abril de 2011
    • Medindo o Progresso DMA CLF PPF DPF CPF Nº 4: Detalhar por Feature Nº 5: Construir por Feature Estudo Dirigido Desenho Inspeção do Codificação Inspeção do Promoção Sobre o Domínio (Projeto) Desenho Código ao Build 1% 40% 3% 45% 10% 1%  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 featuresexta-feira, 22 de abril de 2011
    • Monitorando as Features Est. Dirig. Design Insp. Design Codif. Insp. Cod. Build Id Descrição P.C. D.C. 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 Incluir um novo cliente na lista de 13 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 clientes Registrar um serviço realizado num 14 AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 carro 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 Registrar uma lista de peças AS 15 AR utilizadas num serviço SM Status: SM ficou doente (previsão de retorno: 01/03 Calcular o custo total das peças AS 16 HM 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 usadas num serviço SM 17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03 Receber um pagamento por um 18 HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 serviço Registrar a opção de pagamento 19 AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente) preferida por um cliente Legenda: Atividade em andamento Requer atenção Completada Não iniciadasexta-feira, 22 de abril de 2011
    • Quadro de Tarefas Backlog Pendentes Iniciadas Inspeção/Teste Finalizadas Fulano E N N N I N N Beltrana N N N I N Sicrano N N N E N I N N E N Zé N N N N J.J. N N I Nsexta-feira, 22 de abril de 2011
    • Exemplos de Kanbans ID: RN12 VN: A Est.: 4 Resp.: Sic Descrição: Fórmula de cálculo do imposto: I = ValorBruto * Aliquota Aliquota -> parâmetro AI3 Cartão de impedimento (rosa) Classe -> Venda Tela -> pgVenda ID: RN12 Resp.: Sic Início: 18/06 09:15 Fim: Motivo: Cartão de tarefa normal (azul) Classe Venda está sendo ou emergência (amarelo) alterada por outra tarefa Início: 18/06 11:30 Estimativa de retorno: 19/06 9:00sexta-feira, 22 de abril de 2011
    • Reportando o Progresso Iniciais PC Status da Atividade: Em andamento Nome da Requer atenção (ex.: impedimento) Atividade de Negócio Completada (nº features) Ainda não iniciada 75% Porcentagem Completada: Barra de Progresso Prazo de Entrega: Mês/Ano Completada Mês e Ano para entregasexta-feira, 22 de abril de 2011
    • Painel de Progresso (Parking Lot) :"4"$98&)"$+,*%"*;"$%&6*%"*54,%<+,6*=;5>* ?@A ()*+ ()*+ ()*4 ()*+ ()*% ()*+ ;"$%&*%" ($D8,*%" ($+4"#&*%" ($+4&%&*%" 0,$+4,2"*%" G"2&+H48,6*%" 54,%<+,6 54,%<+,6 54,%<+,6 5"%8%,6 0,$+4&+,6 ;"$%&6 =CC> =BE> =BF> =??> =B?> =B@> EEA BFA ?FA ?A IJA W86+")& 0,)"498&2 /0#$%&&1 23.$%&& ,-.$%&& !"#$%&& ,-.$%&& 5"6$%&&1 =C?O> UJA :"4K*0,$+&6*%"*028"$+"6*=00>* EFA :"4"$98&)"$+,*%"*(6+,Q<"*=:(>* E@A ,-.$%&& ()*% ()*% ()*% ()*4 ()*4 ()*4 -$L286"*%" -P"4+<4& G"#86+4,*%" R"S8$8./,*%" -9"8+"*%" V,D8)"$+&./, 54,1,6+&6*%" %"*7,D&6 M4&$6&.N"6 T$8%&%"6*%" G"Q<868.N"6 %"*V"49&%,48&6 0,$+&6 0,$+&6 %&6*0,$+&6 (6+,Q<" %"*V,D8)"$+, =C?> =BB> =?F> =CU> =BO> =BE> EJA BFFA OCA BFFA EIA OCA /0#$%&&1 /0#$%&&1 5"6$%&&1 /0#$%&&1 5"6$%&&1 738$%&& !"#"$%& ()*&$%&)"$+, -+"$./,***********************0,)12"+&%&*************************3&44&*%"*54,#4"66,**** 7/,*8$898&%&sexta-feira, 22 de abril de 2011
    • Controle de Produção Diagrama de Fluxo Acumulado Legenda: g lo Features k ac Não iniciada tB uc Em andamento od Pr Estoque Intermediário Completada (Work in Progress) Prazo de Entrega Tempo (semanas) (Lead Time)sexta-feira, 22 de abril de 2011
    • FDD e Outras Metodologiassexta-feira, 22 de abril de 2011
    • Espectro de Metodologias UP FDD XPsexta-feira, 22 de abril de 2011
    • FDD x SCRUM x XP FDD SCRUM XPsexta-feira, 22 de abril de 2011
    • Scrum e FDD Construção 7. Reuniões Diárias 6. Dia 4 5 DPF CPF (em pé) 5. Iteração 4. Tarefas (2 a 4 sem.) 3. Escopo da Corrida detalhadas 8. Incremento de Produto (pode ser liberado para uso) (Sprint) pela equipe 1. Visão 2. Lista de Espera (Backlog) de funcionalidades (RSI, marcos, do produto, priorizada pelo Dono do Produto versões) Concepção e Planejamento 9. Inspeção e 1 2 3 Adaptação DMA CLF PPFsexta-feira, 22 de abril de 2011
    • FDD e XP: Algumas Diferenças FDD XP Planejamento durante o Certo planejamento inicial desenvolvimento Refactoring é exceção Refactoring é a norma Programadores Líderes e Posse coletiva do código Proprietários de Classes Design formal e Programação em pares Inspeções de código e modelosexta-feira, 22 de abril de 2011
    • UP, FDD, XP: Proposta de Uso Combinado Processo Unificado Iniciação Elaboração Construção Transição FDD DMA CLF PPF DPF CPF XPsexta-feira, 22 de abril de 2011
    • Agile CMMI Nível Foco Áreas de Processos Produtividade Qualidade Melhoria OID: Inovação e Implantação Organizacional 5 Em Contínua do Otimização CAR: Análise e Prevenção de Defeitos Processo 4 Gerenciado Gerência QPM: Gerenciamento Quantitativo de Projeto Quantitativam. Quantitativa 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 FDD OPF: Foco no Processo Organizacional Padronização OPD: Definição do Processo Organizacional 3 Definido do Processo 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 Gerência SAM: Gerência de Acordos com Fornecedores Básica de MA: Medição e Análise 2 Gerenciado Projetos PPQA: Garantia da Qualidade do Processo e do Produto CM: Gerência de Configuração Risco Retrabalho 1 Inicialsexta-feira, 22 de abril de 2011
    • 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 desenvolvedoressexta-feira, 22 de abril de 2011
    • Dicas para Convencer Gerentes e Desenvolvedores • 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 necessidadessexta-feira, 22 de abril de 2011
    • 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áriossexta-feira, 22 de abril de 2011
    • 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 muitas vezes o investimento!  Motivação é a chave para mudanças!!sexta-feira, 22 de abril de 2011
    • Para saber mais  Agile Alliance  www.agilealliance.org  Agile Project Management Leadership  www.apln.org  Agile Management  www.agilemanagement.net  FDD  www.featuredrivendevelopment.com  www.heptagon.com.br/fdd/  Grupos de Discussão  http://groups.yahoo.com/group/AgileProjectManagement  http://br.groups.yahoo.com/group/Agile-Brasil  http://br.groups.yahoo.com/group/GUFDDsexta-feira, 22 de abril de 2011
    • Literatura Recomendadasexta-feira, 22 de abril de 2011
    • Agradecimento  Adail Muniz Retamal  Heptamansexta-feira, 22 de abril de 2011
    • Eng. Jorge Luis Bublitz  Engenheiro de Sistemas  Administração de Empresas  MBA em Planejamento Estratégico  Chefe da Seção de Análise e Desenvolvimento (TRE-MT)  Certificação Delphi e JBuilder  Artigos publicados nas revistas Micro Sistemas (!?), Clube Delphi e MundoPM  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 Aliancesexta-feira, 22 de abril de 2011
    • 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."sexta-feira, 22 de abril de 2011
    • Um abraço!!!! Valeu !!!!! Jorge FDDMan Email  e  MSN: bublitz@hotmail.com Páginas: h:p://bublitz.tripod.com h:p://jorge-­‐fdd.blogspot.comsexta-feira, 22 de abril de 2011