• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Extreme Programming
 

Extreme Programming

on

  • 6,216 views

 

Statistics

Views

Total Views
6,216
Views on SlideShare
5,891
Embed Views
325

Actions

Likes
4
Downloads
242
Comments
0

3 Embeds 325

http://www.milfont.org 303
http://www.slideshare.net 21
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Extreme Programming Extreme Programming Presentation Transcript

    • Extreme Programming Princípios, valores e práticas
        • CHRISTIANO MILFONT - cmilfont@gmail.com Fortaleza, Ceará. 26/05/2006
      SEAD 2006
        • ROTEIRO
        • HISTÓRICO.
        • AGILE SOFTWARE DEVELOPMENT.
        • EXTREME PROGRAMMING.
        • A METODOLOGIA.
        • DESENVOLVIMENTO.
        • CONCLUSÃO.
    • 1. HISTÓRICO
    • ANOS 80
      • Anos 80 - década Code-and-Fix.
      • Ausência de metodologias de desenvolvimento.
      • Programação procedural e estruturada.
      • Evolução da programação linear.
      • Programas são: sequência, decisão e iteração.
      • Dificuldade de simular relações entre entidades em processos de negócios.
    • ANOS 90
      • Linguagem UML.
      • Processos unificados (UP).
      • Metodologias Orientadas a Objetos.
      • Fases bem definidas e controladas.
      • Analogia com a Engenharia Civil.
      • Concepção, Elaboração, Construção e Transição.
    • 1. HISTÓRICO
        • Os aspectos que destinguem o processo unificado são três conceitos chaves, as saber:
            • Direcionados a casos de usos;
      PROCESSOS UNIFICADOS
        • Centrado na arquitetura;
        • Iterativo e incremental.
    • PROCESSOS UNIFICADOS
        • Rational Unified Process (RUP).
        • Basic Unified Process (BUP).
        • Enterprise Unified Process (EUP).
        • Microsoft Solution Framework (MSF).
    • PROJETOS COM PROCESSOS UNIFICADOS
        • Código complexo.
        • Manutenção difícil.
        • Baixa produtividade.
        • Cronograma sempre atrasado.
        • Insatisfação de todos.
        • Design degradado.
        • Documentação defasada, excessiva e ilegível.
        • Fracasso no projeto.
    • 2. AGILE SOFTWARE DEVELOPMENT
    • ORIGENS DOS METODOS AGEIS
      • Lendário Projeto C3 - Comprehensive Compensation project – Payroll system (Chrysler).
      • Melhores práticas (Design patterns).
      • Análise Orientada a Objetos.
      • Manifesto ágil.
      • Agile Alliance (http://www.agilealliance.org/).
      Ron Jeffries Kent Beck Ward Cunningham
    • MANIFESTO AGIL
      • “ Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
        • Software em funcionamento MAIS QUE documentação abrangente;
        • Indivíduos e interação MAIS QUE processos e ferramentas;
        • Colaboração com o cliente MAIS QUE negociação de contratos;
        • Responder a mudanças MAIS QUE seguir um plano.
      • Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.”
    • METODOS AGEIS
      • Extreme Programming
      • Scrum
      • Pragmatic Programming
      • Feature Driven Development (FDD)
      • Crystal
      • Adaptive Software Development
      • Dynamic Systems Development Method (DSDM)
      • Agile Lean Development (LD)
    • 3. EXTREME PROGRAMMING
    • EXTREME PROGRAMMING O XP é formado por um conjunto de valores, princípios e práticas. Os princípios conectam os valores (crenças fundamentais dos processos) às práticas (atividades concretas do cotidiano). O XP é uma metodologia rigorosa e disciplinada que requer o cumprimento de suas práticas para o sucesso na adoção. Ao contrário do que os gurus pregam, o XP pode ser usado com CMM e UPs como atestam alguns estudos especificos nos últimos anos. A preocupação não é com qualidade (que deve natural) e sim com a saúde do sistema (segundo Kent Beck).
      • VALORES
        • Communication (Comunicação)
        • Simplicity (Simplicidade)
        • Feedback
        • Courage (Coragem)
        • Respect (Respeito)
      • PRINCÍPIOS
        • Humanity (Humanidade)
        • Economics (Economia)
        • Mutual Benefit (Benefício mútuo)
        • Self-Similarity (Similaridade própria)
        • Improvement (Progresso)
        • Diversity (Diversidade)
        • Reflection (Reflexão)
        • Flow (Fluxo)
        • Opportunity (Oportunidade)
        • Redundancy (Redundância)
        • Failure (Falha)
        • Quality (Qualidade)
        • Babe Steps (Passo-de-bêbê)
        • Acceptance (Aceite)
        • Responsibility (Responsabilidade)
    • Sit Together (Sentem-se juntos) Whole Team (Equipe completa) Energized Work (Trabalho energizado) Pair Programming (Programação em par) Move People Around (Mova as equipes) Stories (Histórias) Weekly Cycle (Ciclo semanal) Quarterly Cycle (Ciclo trimestral) Slack (Folga) Ten-Minute Build (Construir em 10 minutos) Continuous Integration (Integração contínua) Test-First Integration (Teste primeiro) Incremental Design (Design incremental) Informative Workspace (Ambiente informatizado) PRÁTICAS PRIMÁRIAS
    • Real Customer Involvement (Envolvimento real do cliente) Incremental Deployment (Disponibilização incremental) Team Continuity (Continuidade da equipe) Shrinking Teams (Diminuição de equipes) Root-Cause Analysis (Análise da causa-origem) Daily Deployment (Disponibilização (entrega) diária) Negotiated Scope Contract (Contrato com escopo negociável) Shared Code (Código compartilhado) Code and Tests (Código e testes) Single Code Base (Código único) Metaphor (Metáforas) Refactoring (Refatoração)
      • PRÁTICAS COROLÁRIAS (CONSEQUÊNCIA)
      Pay-per-Use (Pague-por-uso) Design Patterns (Padrões de projeto) 40 Hour Week (40 horas semanais) Planning Game (Jogo do planejamento) Stand Up Meetings (Reuniões em pé) Coding Standards (Padrões de codificação)
    •  
    •  
    • 4. METODOLOGIA
        • Fase de exploração;
            • Compreender e estimar o possível
        • Fase de planejamento;
            • Comprometimento das escolhas.
        • Fase de gerenciamento;
            • Gerenciamento do progresso na construção.
        • O jogo do planejamento é um processo circular e iterativo com objetivos, partes jogadas, jogadores e regras para os movimentos permitidos. Cada fluxo circular contínuo apresenta as fases:
      JOGO DO PLANEJAMENTO
    • JOGO DO PLANEJAMENTO
        • Definição de Releases e marcos.
        • Iterações com os clientes em ciclos semanais (marcos). Não permite mudanças nessas versões.
        • Ciclo mensais para funcionalidades produtivas (Releases). Versões funcionais e correções de erros.
        • Ciclos trimestrais para sistemas ou módulos em produção.
        • Mudanças no escopo de forma simples.
        • Feedback rápido.
        • Agilidade no gerenciamento de mudanças.
      ITERAÇÕES
    • ITERAÇÕES
        • Presença constante do cliente.
        • Histórias dos usuários em torno dos requisitos.
        • Definição entre processos, casos e funções.
        • História definida a partir de um pedaço de negócio que possa ser testada, executada e entregue.
        • Divisão de Stories em Tasks caso necessário.
        • Documentação simplificada, clara e objetiva.
        • Definição de metáforas para claro entendimento.
      USER STORY (HISTÓRIAS DOS USUÁRIOS)
    • Real Customer Involvement (Envolvimento Real do Cliente)
        • ID# 005 Usuario Fulano de tal
        • <Story name> Correlação de atos
        • Source:__________________________________________ _________
        • <Story texto>
        • Os atos após serem identificados e filtrados na consulta ao acervo do Diário Oficial devem ser correlacionados de forma que se identifique ...
        • Data início 01/02/2006 Data Fim 08/02/2006
        • Teste de Aceitação: ID# 011
      USER STORY CARD
    • USER STORY CARD
    • USER STORY CARD
    • INFORMATIVE WORKSPACE AMBIENTE INFORMATIZADO
    • 5. DESENVOLVIMENTO
    • RELEASE PLAN
    • ITERATION PLAN
    • INTEGRAÇÃO CONTÍNUA
    • INTEGRAÇÃO CONTÍNUA
        • Condutor e navegador.
        • Condutor cria testes e refatora.
        • Navegador avalia atrás de bugs.
        • Navegador critica código.
        • Sit Together (sentam-se juntos)
        • Parceiro força boas práticas.
        • Parceiro evita dispersão.
        • Menos prospecção a erros.
        • Disseminação dos conhecimentos e nivelamento.
        • Stand up meeting (Reuniões breves em pé).
        • Confiança no desenvolvimento.
      PAIR PROGRAMMING PROGRAMAÇÃO EM PAR
    • MOVE PEOPLE AROUND MOVA AS PESSOAS PELO PROJETO
        • Revezamento de pares entre as histórias e iterações.
        • Maior revisão de códigos e disseminação.
        • Desenvolvedores podem alterar qualquer código.
    • MOVE PEOPLE AROUND MOVA AS PESSOAS PELO PROJETO
        • Todos desenvolvedores são responsáveis pelo código.
        • Utiliza-se SCM (Source Control Management).
        • SCM versionam, arquivam e controlam o projeto.
        • Versões continuam em paralelo sem interromper a evolução do sistema.
      SHARED CODE CÓDIGO COMPARTILHADO
    • SHARED CODE CÓDIGO COMPARTILHADO
    • SHARED CODE CÓDIGO COMPARTILHADO
    • EXPLORAÇÃO DO DOMÍNIO DA RELEASE EM CRC CARDS
        • Objetos que conhecem seus dados e comportamentos
        • Colaboram entre si e não pulam entre funções.
        • Só expõem o necessário.
        • Objetos ativos, e não passivos como tabelas.
        • Design simples
        • Implementam estritamente o que o processo define.
        • Representam os processos de negócios do cliente.
        • Não se preocupam com arquitetura do sistema.
      DOMAIN MODEL
      • Usando C#
        • using System;
        • using System.IO;
        • public class RemoveArquivosVelhos {
        • public static void Main(string[] args) {
        • foreach (FileInfo fi in (new DirectoryInfo (@“ empackup”)).GetFiles()) {
        • if (((TimeSpan) (DateTime.Now - fi.LastWriteTime)).Days > 7) {
        • fi.Delete();
        • }
        • }
        • }
        • }
      Usando BASH do sistema operacional LINUX -> find /usr -atime + 6 -exec rm -f “ {} ” “;” SIMPLICIDADE
    • DOMAIN MODEL EXEMPLO
        • FUNCTIONAL TESTS (TESTES FUNCIONAIS)
        • ACCEPTANCE TESTS (TESTES DE ACEITAÇÃO).
              • Os testes de aceitação descrevem as ações e definem o domínio dos processos que são necessários para validar a história.
        • UNIT TESTS (TESTES DE UNIDADE).
              • Os testes de unidade avaliam cada entidade participante no teste de aceitação usando refactoring para criar o código funcional.
      TEST-DRIVEN DEVELOPMENT
        • Testes que cruzam os limites de uma classe, invariavelmente são testes que descrevem e definem processos.
      ACCEPTANCE TESTS TESTES DE ACEITAÇÃO
    • UNIT TESTS TESTES UNITÁRIOS
    • REFACTORINGS
    • 6. CONCLUSÃO
        • Problemas:
            • Saída de pessoal (Risco na implementação).
            • Dificuldade cultural.
            • Indisciplina nas práticas da metodologia podem comprometer o sucesso.
            • Problemas estruturais na empresa.
        • Soluções:
            • . Projeto saudável.
            • Agilidade nas mudanças.
            • Menos pontos de manutenção.
            • Produtividade no ciclo de vida do produto.
            • Menor incidência de falhas.
    • REFLEXÃO: MOÇOS BONITOS COMO NÓS DESENVOLVEM EM JAVA. DUVIDAS?
        • Extreme Programming Explained - Kent Beck
        • Planning Extreme Programming - Kent Beck and Martin Fowler
        • Extreme Programming Installed - Ron Jeffries
        • Extreme Programming Explored - William C. Wake
        • Agile Software Development - Evaluating the Methods for Your Organization - Alan S. Koch
        • Agile Software Development - Alistair Cockburn
        • Agile Software Development Ecosystems - Jim Highsmith
        • Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd) - Craig Larman
        • Test-Driven Development By Example - Kent Beck
        • Martin Fowler - Refactoring-Improving the Design of Existing Code
        • Domain-Driven Design - Tackling Complexity in the Heart of Software - Eric Evans
      APÊNDICE BIBLIOGRAFIA