Baixado 277 vezes
![Usando C# using System; using System.IO; public class RemoveArquivosVelhos { public static void Main(string[] args) { foreach (FileInfo fi in (new DirectoryInfo (@“\temp\backup”)).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](https://image.slidesharecdn.com/extreme-programming-1193657103358699-3/75/Extreme-Programming-44-2048.jpg)
Carregado porMilfont Consulting
Extreme Programming
O documento descreve os princípios e práticas da metodologia de desenvolvimento de software Extreme Programming (XP). Apresenta os valores, princípios e práticas primárias e secundárias do XP, como programação em pares, integração contínua, testes de unidade e aceitação. Também explica como o XP usa histórias de usuário, planejamento iterativo e feedback constante do cliente para entregar software de forma ágil.
Mais conteúdo relacionado
Extreme Programming
- 1. Extreme Programming Princípios,valores e práticas CHRISTIANO MILFONT - [email protected] Fortaleza, Ceará. 26/05/2006 SEAD 2006
- 2. ROTEIRO HISTÓRICO. AGILESOFTWARE DEVELOPMENT. EXTREME PROGRAMMING. A METODOLOGIA. DESENVOLVIMENTO. CONCLUSÃO.
- 3.
- 4. ANOS 80 Anos80 - 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.
- 5. ANOS 90 LinguagemUML. 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.
- 6. 1. HISTÓRICO Osaspectos 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.
- 7. PROCESSOS UNIFICADOS RationalUnified Process (RUP). Basic Unified Process (BUP). Enterprise Unified Process (EUP). Microsoft Solution Framework (MSF).
- 8. PROJETOS COM PROCESSOSUNIFICADOS 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.
- 9. 2. AGILE SOFTWAREDEVELOPMENT
- 10. ORIGENS DOS METODOSAGEIS 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
- 11. 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.”
- 12. METODOS AGEIS ExtremeProgramming Scrum Pragmatic Programming Feature Driven Development (FDD) Crystal Adaptive Software Development Dynamic Systems Development Method (DSDM) Agile Lean Development (LD)
- 13.
- 14. EXTREME PROGRAMMING OXP é 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).
- 15. 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)
- 16. Sit Together (Sentem-sejuntos) 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
- 17. 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)
- 18.
- 19.
- 20.
- 21. 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
- 22.
- 23. Definição de Releasese 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
- 24.
- 25. Presença constante docliente. 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)
- 26. Real Customer Involvement(Envolvimento Real do Cliente)
- 27. 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
- 28.
- 29.
- 30. INFORMATIVE WORKSPACE AMBIENTEINFORMATIZADO
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. 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
- 37. MOVE PEOPLE AROUNDMOVA 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.
- 38. MOVE PEOPLE AROUNDMOVA AS PESSOAS PELO PROJETO
- 39. Todos desenvolvedores sãoresponsá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
- 40. SHARED CODE CÓDIGOCOMPARTILHADO
- 41. SHARED CODE CÓDIGOCOMPARTILHADO
- 42. EXPLORAÇÃO DO DOMÍNIODA RELEASE EM CRC CARDS
- 43. Objetos que conhecemseus 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
- 44. Usando C# usingSystem; using System.IO; public class RemoveArquivosVelhos { public static void Main(string[] args) { foreach (FileInfo fi in (new DirectoryInfo (@“\temp\backup”)).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
- 45.
- 46. FUNCTIONAL TESTS (TESTESFUNCIONAIS) 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
- 47. Testes que cruzamos limites de uma classe, invariavelmente são testes que descrevem e definem processos. ACCEPTANCE TESTS TESTES DE ACEITAÇÃO
- 48. UNIT TESTS TESTESUNITÁRIOS
- 49.
- 50.
- 51. Problemas: Saída depessoal (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.
- 52. REFLEXÃO: MOÇOSBONITOS COMO NÓS DESENVOLVEM EM JAVA. DUVIDAS?
- 53. 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