Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Extreme Programming
2
Manifesto do Desenvolvimento Ágil
Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP. Indivíduos e interações mais que processos e ferramentas. Trabalhar no software mais que documentação abrangente. Colaboração do cliente mais que negociação contratual. Responder às mudanças mais que seguir um plano.
3
O que é XP? Processo de desenvolvimento de software
Projetos com requisitos muito voláteis Equipes pequenas (até ~10 pessoas) Desenvolvimento incremental
4
O que é um projeto de sucesso?
Cumpre o orçamento Cumpre o prazo Cliente fica feliz Equipe fica feliz
5
Premissas do desenvolvimento
Cliente é capaz de especificar um software antes de iniciar o desenvolvimento Equipe de desenvolvimento é capaz de quantificar o esforço Equipe é capaz de criar o software imaginado pelo cliente Cliente ficará feliz
6
Resumo Divisão nítida entre “produção” e “consumo”
Cliente produz uma especificação que é consumida pela equipe de desenvolvimento Equipe de desenvolvimento produz o software que é consumido pelo cliente
7
Motivação: custo de uma alteração
Tempo de Projeto Custo $ 1 Requisitos $ 10 Análise $ 100 Design $ 1.000 Implem. $ Testes
8
Premissas Básicas do Modelo Tradicional
É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. É necessário testar o sistema completamente antes de mandar a versão final para o cliente.
9
Por que software falha?
10
Problemas desta premissa
Premissa é irreal em vários casos O cliente não é capaz de especificar o software previamente Grande problema: DETALHE
11
Premissa do desenvolvimento ágil
APRENDIZADO FEEDBACK DESENVOLVIMENTO ITERATIVO
12
Aprendizado O cliente aprende durante o desenvolvimento
Descobre novas possibilidades Muda as prioridades
13
Trabalho intelectual Retrabalho é uma característica do trabalho intelectual Experimentação Criação Revisão Experimentação ...
14
Premissa: custo de uma alteração
Tempo de Projeto Custo Mudanças nas últimas 3 décadas: Computadores 1000 vezes mais rápidos Computadores 1000 vezes mais baratos Ciclo de compilação e testes baixou de dias para segundos DBMS CM Tools CASE Tools Sobretudo OO
15
E se essa fosse a realidade?
A atitude dos desenvolvedores de software seria completamente diferente: Tomaríamos as grandes decisões o mais tarde possível. Implementaríamos agora somente o que precisamos agora. Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).
16
E essa é a nova realidade ! (pelo menos em muitos casos)
Orientação a Objetos facilita e cria oportunidades para mudanças Técnicas de Refatoramento possibilita melhorar continuamente a implementação aumentando constantemente a qualidade do código produzido Testes automatizados nos dão segurança quando fazemos mudanças Prática / cultura de mudanças aprendemos técnicas e adquirimos experiência em lidar com código mutante
17
As 4 Variáveis do Desenvolvimento de Software
Tempo Custo Qualidade Escopo (foco principal de XP)
18
Valores Feedback Comunicação Simplicidade Coragem
19
User Stories Funcionalidades são informadas através de user stories
Estórias devem ser simples Desenvolvedores estimam tempo
20
Planejamento De posse das estimativas, é possível priorizar
Cliente entrega as estórias priorizadas para serem implementadas Desenvolvedores respeitam as prioridades dos clientes Projeto é dividido em partes: releases e iterações
21
Priorização Cliente deve priorizar as estórias
Para obter o máximo de valor rapidamente Se baseia nas suas necessidades e nas estimativas dos desenvolvedores
22
Release e Iteração Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4
No início do projeto, deve-se determinar o número máximo de estórias e estimá-las. A estimativa é sempre feita pelos programadores. Ao mostrar os releases, dizer que no início de cada um se faz o release planning. Nele, o cliente indica as estórias que devem ser feitas. Esta estórias podem mudar ao longo do release, de acordo com as priridades do cliente. No início de cada iteração, ocorre o iteration planning. O cliente decide o que será feito na iteração. Ao contrário do release planning, o cliente não pode alterar as estórias que serão executadas em uma iteração. Elas ficam completamente congeladas. No início de cada semana, a equipe planeja as tarefas que serão executadas ao longo da semana. No início de cada manhã, a equipe faz um stand up meeting. 1 Sem. S1 S2
23
Release Planning Cliente recebe um “orçamento” dos desenvolvedores
8 Sem. Cliente recebe um “orçamento” dos desenvolvedores Seleciona as estórias prioritárias que possam ser implementadas dentro do orçamento Pode trocar estórias durante o release
24
Iteration Planning Cliente recebe um “orçamento”
2 Sem. Cliente recebe um “orçamento” Não pode haver troca de funcionalidades durante uma iteração Velocidade: quantidade de estórias que a equipe consegue implementar em uma iteração
25
Stand-up meeting Reunião rápida Diária
Usada para atualização da equipe
26
Desenvolvimento: orientação a objetos
Sistema é composto por pequenas peças Peças têm objetivos específicos Facilita construção Facilita evolução
27
Buscando bugs Sistemas podem ter defeitos
É difícil descobrir qual é a peça defeituosa É mais fácil se o problema for detectado logo após a adoção da peça
28
Test Driven Design No XP, primeiro se especifica o teste
Depois se constrói a peça
29
Unit Test Nome dado à verificação feita sobre cada peça
Cada peça possui um unit test associado a ela Testes são automatizados Quando uma nova peça entra no sistema, todos os testes são executados
32
Acceptance Test Cliente deve especificar testes de aceitação para cada funcionalidade de uma iteração Sistema deve passar nestes testes ao término da iteração
33
Pair Programming Todo código é escrito em par
Duas pessoas trabalham em um único computador Uma digita, enquanto a outra revisa, corrige e sugere
34
Collective code ownership
Todos são responsáveis por todas as partes do sistema Código tem que estar sempre “limpo” Todos são capazes de modificá-lo
35
Refactoring Uma [pequena] modificação no sistema que não altera o seu comportamento funcional mas que melhora alguma qualidade não-funcional: simplicidade flexibilidade clareza desempenho
36
Exemplos de Refactoring
Mudança do nome de variáveis Mudanças nas interfaces dos objetos Pequenas mudanças arquiteturais Encapsular código repetido em um novo método Generalização de métodos raizQuadrada(float x) raiz(float x, int n)
37
Desenvolvimento em equipe
Como conciliar diversos desenvolvedores? Estrutura de diretórios Atualização do código por várias pessoas diferentes
38
CVS – Repositório de fontes
Check out Add Commit Update Conflict Remove
39
CVS
40
40 hour week Desenvolvimento de software é um trabalho intelectual intenso Não é produtivo trabalhar além do limite
41
Customer onsite Fator mais importante no XP:
Comunicação Feedback Viabiliza a simplicidade da metodologia War room c / quadro branco
42
Feedback constante Permite que pequenas mudanças sejam feitas
Evita a necessidade de mudanças bruscas Mantém o projeto em curso
43
Integração contínua Máquina destacada para a integração
Integração ocorre diversas vezes ao dia Os testes são executados em cada integração Correções são feitas imediatamente
44
Ambientes para deployment
Como lidar com diferentes ambientes? Exemplo: Desenvolvimento Aceitação Produção
45
Ambientes para deployment
Desenvolvimento Aceitação Produção
46
Problemas de ter vários ambientes
Possíveis erros devido a tarefas manuais repetitivas Gasto de tempo
47
Automatização do deployment
Agiliza as integrações Evita erros
48
Ant
49
Exemplo simples <project name="projeto" default="desenvolvimento"> <target name="desenvolvimento"> <mkdir dir="build"/> <javac srcdir="src" destdir="build"/> <junit> <test name="test.SystemTester"/> </junit> </target> </project> tasks target
50
Ambiente de Desenvolvimento
Desejável que tenha: Code completion Validação on-line Suporte à depuração Suporte a Refactoring Integração com jUnit Integração com CVS Integração com Ant
51
Exemplos
52
Importância da IDE para o XP
Ganho de tempo Automação Facilidade de uso Verificação permanente do código
53
Importância da IDE para o XP
54
Steering Pequenas mudanças Ajustes simples ao longo do tempo X
55
Segredo do sucesso O conjunto é o que faz a diferença
A ausência de uma prática mostra a deficiência de outras Metáfora do time de futebol
56
XP e RUP XP RUP Foco nas práticas da equipe Foco nos artefatos
Comportamental Prescritivo Projetos de determinados tamanhos Qualquer projeto
57
Negociação Venda técnica Venda focada em negócio Duas propostas:
Escopo fechado Escopo variável
58
Resistências Dificuldades com a área de TI
Grande resistência dos desenvolvedores Pouca resistência na área usuária do cliente Estratégia: pedido de tempo
59
Ambiente de desenvolvimento
Sala dedicada unicamente ao projeto Mural Quadros brancos Mesas que suportam programação em par Equipamentos com bom desempenho
60
XP no Brasil 2000: algumas práticas começam a ser usadas em projetos no Sul Dez/2002: primeiro XP Brasil Jan/2003: fundação do XP Rio Fev/2003: primeiro projeto full-XP em uma grande empresa brasileira (em andamento) Nov/2003: lançamento previsto do primeiro livro brasileiro sobre XP
61
Referências Site Xispê http://www.xispe.com.br XP Rio
Lista Xpers
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.