Extreme Programming. Projeto de. Desenvolvimento. Software. Prof.: Ari Oliveira

Transcrição

1 Projeto de Desenvolvimento Software Extreme Programming Prof.: Ari Oliveira

2 O Extreme Programming (XP) é uma metodologia de desenvolvimento de software que auxilia na produção de sistemas de maior qualidade, em menos tempo e de forma econômica; O XP se baseia nos princípios dos métodos ágeis: Desenvolvimento incremental; Envolvimento do cliente. Criada por Kent Beck Projeto da Daimler-Chrysler (de 1997 a 1999), dona da Mercedes-Benz. Desenvolvida para: Equipes médias e pequenas (2 a 12 pessoas) Requisitos vagos e em constante evolução Possui um conjunto de valores e práticas para nortear o desenvolvimento de software 2

3 Scrum é interessante porque fornece um mecanismo de informação de status que é atualizado continuamente, e porque utiliza a divisão de tarefas dentro da equipe de forma explicita. Scrum e XP são complementares pois Scrum provê práticas ágeis de gerenciamento enquanto XP provê práticas integradas de engenharia de software. 3

4 Extreme Programming Aplicação das boas práticas de desenvolvimento de software levadas ao extremo Foca em Código

5 Princípios Básicos Comunicação Simplicidade Feedback Coragem Retorno Respeito 5 5

6 Comunicação Os membros da equipe (clientes, gerentes, programadores) devem interagir ao máximo pessoalmente. Devem trabalhar na mesma sala, conversar pessoalmente ou através de chats, etc. Simplicidade Projeto do SW é simplificado continuamente Processo adaptado, caso algo não esteja funcionando 6

7 Feedback Cliente está sempre participando do desenvolvimento do sistema Testes de unidade e de aceitação fornecem feedback sobre o sistema Oportunidades e problemas são identificados o mais rápido possível 7

8 Coragem Indicar problemas no projeto, parar quando está cansado, pedir ajuda quando necessário Simplificar código que está funcionado, dizer ao cliente que não será possível implementar um requisito no prazo estimado Seguir o XP como deve ser Respeito Evite complicar o trabalho dos demais. Preserve a qualidade do código, do design. 8

9 9

10 Planejamento Estórias Iterações Velocidade Jogo do Planejamento Versões pequenas e frequentes 10

11 Estórias de uso Usadas como requisitos do sistema Mesmo propósito dos casos de uso (de UML), porém menores e mais simples Escritos na linguagem do cliente com o mínimo de detalhes para a estimativa de custos 11

12 12 Extreme Programming

13 Iterações Desenvolvimento dividido em iterações Possuem duração entre 1 e 3 semanas Funcionalidades são entregues no final de cada iteração Prazos devem ser levados a sério, negocie o escopo se for necessário 13

14 Medida da velocidade de projeto Indica a produtividade da equipe no projeto Razão entre o que foi produzido e o que foi estimado a cada iteração Pode ser medido durante uma iteração Variações dramáticas em mais de uma iteração sugerem renegociação de prazo e escopo das versões 14

15 Jogo do planejamento Planejamento de versões (Releases) No início do projeto especifica-se que estórias de uso serão implementadas em cada versão Define-se as datas de liberação das versões Geralmente de 2 a 3 meses. Uma release possui diversas iterações curtas 15

16 Jogo do planejamento Planejamento das iterações: Feito no início de cada iteração Estórias de uso são escolhidas de acordo com a importância pro cliente e o risco pro projeto Estórias são divididas em tarefas de 1 a 3 dias Tarefas são distribuídas entre programadores e estimadas pelos próprios executores Estimativa preferencialmente baseada no passado Leva-se em conta a programação em pares Estórias são adicionadas ou removidas para completar o tempo da iteração 16

17 Versões frequentes e pequenas Funcionalidades implementadas são rapidamente entregues ao cliente Permite um feedback mais rápido do cliente reduzindo o impacto de mudanças de requisitos Versão pode ter inclusive uma única iteração 17

18 Reuniões rápidas (stand-up meeting) Faz a comunicação entre toda a equipe para comunicar problemas, soluções, etc. Reunião feita em pé com poucos minutos de fala para cada integrante 18

19 Projeto Simplicidade Metáforas Spike Não adicionar Funcionalidades previamente Contato constante com Cliente 19

20 Simplicidade Projetos simples tomam menos tempo que os complexos Evitar generalizações e abstrações desnecessárias no momento Um bom projeto deve conter o menor número possível de classes e métodos É mais rápido e barato Requisitos mudam frequentemente 20

21 Metáfora Tem a intenção de oferecer uma visão geral do sistema, em um formato simples, que possa ser compartilhada por clientes e programadores. Faz-se uma analogia entre o sistema e um outro sistema não necessariamente de software que seja de fácil entendimento para todos Corresponde mais ou menos à Arquitetura do sistema Não tem sido muito usada 21

22 Criar spike solutions para reduzir riscos Programas muito simples (protótipos) utilizados para verificar o uso determinadas soluções e tecnologias Utilizados para reduzir os riscos técnicos do projeto ou validar as estimativas realizadas 22

23 Não adicionar funcionalidades antecipadamente Requisitos mudam rapidamente Mantém o código limpo de adivinhações sobre o que pode ser usado no futuro Mantém a produtividade 23

24 O cliente está sempre disponível Não deve só ajudar a equipe de desenvolvimento Deve ser parte da equipe Comunicação com o cliente é feita em todas as fases de um projeto XP Estórias de uso, planejamento de versões, feedback do sistema, testes de aceitação, etc. 24

25 Codificação Em pares Rotação de Pares Padrão de Nomenclatura Horas Semanais Integração Contínua Refatorar sempre que possível 25

26 Programação em pares Duas pessoas programando em um mesmo computador pensam melhor que uma Revezamento: um programa enquanto o outro projeta e faz revisão on-line do código digitado Ganho de qualidade compensa o uso de duplas Auxilia a difusão de conhecimento 26

27 Rotação de pares de programadores Ajuda ainda mais a eliminar as pessoas consideradas ilhas de conhecimento Cada um da equipe passa a conhecer todas as partes do sistema Os pares devem sempre ser encorajados a trabalhar em partes do sistema desconhecidas por eles 27

28 Propriedade coletiva do código Todos são responsáveis por todo código Permite que pessoas forneçam idéias para toda parte do sistema Diminui o risco de possuir pessoas insubstituíveis no projeto 28

29 Código tem sempre que seguir um padrão Mantém o código consistente e uniforme Facilita a leitura e entendimento por outros programadores 29

30 40 horas semanais Não se deve trabalhar mais de 60 h por 2 ou mais semanas consecutivas Horas extras não remuneradas prejudicam motivação da equipe A insatisfação de se trabalhar horas extras pode contribuir para a queda de qualidade e aumento de defeitos Ao invés disto, modifique o escopo ou o prazo do projeto 30

31 Integração contínua Módulos do sistema são integrados diversas vezes ao dia Todos os testes de unidade definidos são executados Identificação rápida de bugs inseridos Programador sabe que trechos de código foram alterados nas últimas horas 31

32 Fazer refactoring sempre que possível Reestruturação sem acrescentar funcionalidade Remove redundâncias e melhora a qualidade do projeto Retira códigos não utilizados Testes unitários garantem que código mantém mesmo comportamento 32

33 Testes Unitários Testes antes da codificação Testes de aceitação 33

34 Testes unitários Teste das menores unidades (classes, métodos,...) Identifica bugs no código Protege o código de manutenções indevidas De responsabilidade do programador. São automatizados (JUnit) Automação dos testes paga o custo da criação dos testes 34

35 Testes unitários são escritos para detectar bugs identificados Criação do teste unitário que identifique o bug antes de corrigi-lo Bugs têm tendência de ressurgir posteriormente 35

36 Testes antes da codificação Limita o escopo da solução a ser implementada Serve de especificação do código testado Facilita o entendimento do código a ser criado Garante que os testes vão ser criados 36

37 Execução periódica de testes de aceitação (testes funcionais) Procuram testar uma funcionalidade como um todo (Ex: Venda). Criados a partir das estórias de uso a serem implementadas na iteração Clientes verificam a corretude dos testes escritos Devem ser automatizados e regressivos 37

38 Dono da grana (GoldOwner) Patrocinador (quem paga pelo software) Dono dos objetivos (GoalOwner) Quem define os requisitos (em geral, um usuário) Gerente Facilitador do projeto Testador de aceitação Define os critérios de aceitação junto ao cliente Programador Responsável pela implementação Rastreador Coleta sinais do projeto (métricas). Avalia desempenho Técnico Especialista do processo. Dá suporte à equipe que está mudando. 38

39 Planejar Iteração Detalhar Estórias (criar tarefas) Descrever Prioridades Estimar Tarefas Estimar por Comparação Estimar por Intuição Spike Solutions Distribuir Estórias Construir Testes de Aceitação Programar Fazer Teste Unitário Implementar Stand-up meetings Executar Testes de Aceitação Disponibilizar Iteração 39

40 40 Extreme Programming

41 41 Extreme Programming

42 Estórias Iterações Velocidade Jogo do Planejamento Versões pequenas e frequentes Simplicidade Metáforas Spike Não adicionar Funcionalidades previamente Contato constante com Cliente Em pares Rotação de Pares Padrão de Nomenclatura Horas Semanais Integração Contínua Refatorar sempre que possível Unitários Testes antes da codificação Testes de aceitação Extreme Programming Princípios Básicos Comunicação Simplicidade Feedback Coragem Retorno Respeito Planejamento Projeto Codificação Testes 42

43 Projeto de Desenvolvimento Software Extreme Programming Prof.: Ari Oliveira