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

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

Extreme Programming.

Apresentações semelhantes


Apresentação em tema: "Extreme Programming."— Transcrição da apresentação:

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

30

31

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


Carregar ppt "Extreme Programming."

Apresentações semelhantes


Anúncios Google