A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

1 Extreme Programming. 2 2 Manifesto do Desenvolvimento Ágil www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular.

Apresentações semelhantes


Apresentação em tema: "1 Extreme Programming. 2 2 Manifesto do Desenvolvimento Ágil www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular."— Transcrição da apresentação:

1 1 Extreme Programming

2 2 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 3 3 O que é XP? Processo de desenvolvimento de software Projetos com requisitos muito voláteis Equipes pequenas (até ~10 pessoas ) Desenvolvimento incremental

4 4 4 O que é um projeto de sucesso? Cumpre o orçamento Cumpre o prazo Cliente fica feliz Equipe fica feliz

5 5 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 6 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 7 7 Motivação: custo de uma alteração Tempo de Projeto Custo $ 1 Requisitos $ 10 Análise $ 100 Design $ Implem. $ Testes

8 8 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 9 9 Por que software falha?

10 10 Problemas desta premissa Premissa é irreal em vários casos O cliente não é capaz de especificar o software previamente Grande problema: DETALHE

11 11 Premissa do desenvolvimento ágil APRENDIZADO FEEDBACK DESENVOLVIMENTO ITERATIVO

12 12 Aprendizado O cliente aprende durante o desenvolvimento Descobre novas possibilidades Muda as prioridades

13 13 Trabalho intelectual Retrabalho é uma característica do trabalho intelectual Experimentação Criação Revisão Experimentação...

14 14 Premissa: custo de uma alteração Tempo de Projeto Custo

15 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 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 17 As 4 Variáveis do Desenvolvimento de Software Tempo Custo Qualidade Escopo (foco principal de XP)

18 18 Valores Feedback Comunicação Simplicidade Coragem

19 19 User Stories Funcionalidades são informadas através de user stories Estórias devem ser simples Desenvolvedores estimam tempo

20 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 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 22 Release e Iteração R1R1 R2R2 R3R3 R4R4 I1I1 S1S1 8 Sem. I2I2 I3I3 I4I4 2 Sem. 1 Sem. S2S2 Projeto: 8 meses = 32 semanas

23 23 Release Planning 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 R1R1 R2R2 R3R3 R4R4 8 Sem.

24 24 Iteration Planning 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 I1I1 I2I2 I3I3 I4I4 2 Sem.

25 25 Stand-up meeting Reunião rápida Diária Usada para atualização da equipe

26 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 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 28 Test Driven Design No XP, primeiro se especifica o teste Depois se constrói a peça

29 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

30 30

31 31

32 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 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 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 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 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 37 Desenvolvimento em equipe Como conciliar diversos desenvolvedores? Estrutura de diretórios Atualização do código por várias pessoas diferentes

38 38 CVS – Repositório de fontes Check out Add Commit Update Conflict Remove

39 39 CVS

40 40 40 hour week Desenvolvimento de software é um trabalho intelectual intenso Não é produtivo trabalhar além do limite

41 41 Customer onsite Fator mais importante no XP: Comunicação Feedback Viabiliza a simplicidade da metodologia War room c / quadro branco

42 42 Feedback constante Permite que pequenas mudanças sejam feitas Evita a necessidade de mudanças bruscas Mantém o projeto em curso

43 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 44 Ambientes para deployment Como lidar com diferentes ambientes? Exemplo: Desenvolvimento Aceitação Produção

45 45 Ambientes para deployment Desenvolvimento Aceitação Produção

46 46 Problemas de ter vários ambientes Possíveis erros devido a tarefas manuais repetitivas Gasto de tempo

47 47 Automatização do deployment Agiliza as integrações Evita erros

48 48 Ant

49 49 Exemplo simples target tasks

50 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 51 Exemplos

52 52 Importância da IDE para o XP Ganho de tempo Automação Facilidade de uso Verificação permanente do código

53 53 Importância da IDE para o XP

54 54 Steering Pequenas mudanças Ajustes simples ao longo do tempo X

55 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 56 XP e RUP XPRUP Foco nas práticas da equipeFoco nos artefatos ComportamentalPrescritivo Projetos de determinados tamanhos Qualquer projeto

57 57 Negociação Venda técnica Venda focada em negócio Duas propostas: Escopo fechado Escopo variável

58 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 59 Ambiente de desenvolvimento Sala dedicada unicamente ao projeto Mural Quadros brancos Mesas que suportam programação em par Equipamentos com bom desempenho

60 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 61 Referências Site Xispê XP Rio Lista Xpers


Carregar ppt "1 Extreme Programming. 2 2 Manifesto do Desenvolvimento Ágil www.agilealliance.org Aplicar os ideais do desenvolvimento ágil ao nosso processo particular."

Apresentações semelhantes


Anúncios Google