EXtreme Programming Eduardo Aranha.

Apresentação em tema: "EXtreme Programming Eduardo Aranha."— Transcrição da apresentação:

1 eXtreme Programming Eduardo Aranha

2 O surgimento de XP Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software Identificou o que tornava simples e o que dificultava o desenvolvimento de software Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia eXtreme Programming

3 O que é eXtreme Programming?
Metodologia ágil, leve Desenvolvido para: Equipes médias e pequenas (2 a 12 pessoas) Requisitos vagos e em constante evolução Possui um conjunto de valores para nortear desenvolvimento Conjunto de práticas mostra sua estrutura

4 Foco na satisfação do cliente
Desenvolver o que o cliente precisa no momento que é necessário

5 Manifesto ágil Valorização de:
Indivíduos e interação MAIS QUE processos e ferramentas Software em funcionamento MAIS QUE documentação abrangente Colaboração com o cliente MAIS QUE negociação de contratos Responder a mudanças MAIS QUE seguir um plano

6 Princípios básicos Comunicação Simplicidade
Programadores comunicam-se frequentemente entre si e com os clientes 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 funcionado

7 Princípios básicos 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

8 Princípios básicos 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

9 Práticas e Regras de XP: Planejamento
Estórias de uso Usados como requisitos do sistema Mesmo propósito dos casos de uso, porém menores e mais simples Escritos na linguagem do cliente com o mínimo de detalhes para a estimativa de custos São estimados em “tempo ideal de trabalho” Deve custar entre 1 e 3 semanas de desenvolvimento

10 Práticas e Regras de XP: Planejamento
Jogo do planejamento Planejamento de versões 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 Versões são divididas em iterações

11 Práticas e Regras de XP: Planejamento
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

12 Práticas e Regras de XP: Planejamento
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 Práticas e Regras de XP: Planejamento
Planejamento de 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 do 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

14 Práticas e Regras de XP: Planejamento
Planejamento de Iterações (cont.) Estórias são adicionadas ou removidas para completar o tempo da iteração Usa a velocidade do projeto para transformar estimativas em tempo ideal para tempo real

15 Práticas e Regras de XP: Planejamento
Medida da velocidade de projeto Indica a produtividade da equipe no projeto Razão entre a 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

16 Práticas e Regras de XP: Planejamento
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

17 Práticas e Regras de XP: Projeto
Simplicidade Projetos simples tomam menos tempo que os complexos Evitar generalizações e abstrações desnecessárias no momento É mais rápido e barato Requisitos mudam frequentemente

18 Práticas e Regras de XP: Codificação
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.

19 Práticas e Regras de XP: Projeto
Cartões CRC Class, Responsibilities, and Collaboration Descrevem as classes e métodos do sistema Permitem a simulação da execução do sistema através da invocação dos métodos das classes

20 Práticas e Regras de XP: Codificação
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

21 Práticas e Regras de XP: Planejamento
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

22 Práticas e Regras de XP: Codificação
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

23 Práticas e Regras de XP: Projeto
Criar spike solutions para reduzir riscos Programas muito simples utilizados para verificar o uso determinadas soluções e tecnologias Utilizados para reduzir os riscos técnicos do projeto ou validar as estimativas realizadas

24 Práticas e Regras de XP: Projeto
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

25 Práticas e Regras de XP: Codificação
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

26 Práticas e Regras de XP: Codificação
40 horas semanais Horas extras não remuneradas prejudicam motivação da equipe Ao invés disto, modifique o escopo ou o prazo do projeto

27 Práticas e Regras de XP: Testes
Testes unitários Teste das menores unidades (classes, métodos, ...) Identifica bugs no código Protege o código de manutenções indevidas Automação dos testes paga o custo da criação dos testes

28 Práticas e Regras de XP: Testes
Testes unitários são escritos para detectar bugs identificados Criação do teste unitário que identifique o bug antes de corrigí-lo Bugs tem tendência de ressurgir posteriormente

29 Práticas e Regras de XP: Codificação
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

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

31 Práticas e Regras de XP: Projeto
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 Práticas e Regras de XP: Testes
Execução periódica de testes de aceitação e publicação de score Testes de aceitação 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

33 Dependência entre práticas
Algumas práticas possuem inter-dependências Refactoring: Testes unitários Rotação de pessoas: programação em pares Propriedade coletiva de código: refactoring, testes unitários, integração contínua 40h semanais: planejamento junto ao cliente Etc.

34 Modelagem de XP Site oficial não tem modelo preciso do processo
Trabalho realizado por Américo no CIn modela XP usando a meta-linguagem SPEM

35 Meta-linguagem SPEM Software Process Engeneering Metamodel
Padrão formal da OMG aprovado em novembro de 2002 Apoiado pela Rational, IBM, Computer Associates e outras Orientado a objetos, utiliza UML como notação

36 Principais elementos de SPEM

37 Principais elementos de SPEM

38 Diagrama de atividades – Modelagem de XP (parcial)

39 Diagrama de atividades – Modelagem de XP

40 Diagrama de atividades – Modelagem de XP

41 Diagrama de classe – Ponto de vista estático de XP (parcial)

42 Fluxo de XP mostrado no site oficial

43 Fluxo de XP

44 Fluxo de XP

45 Fluxo de XP

46 Papeis Oficiais Outros papéis encontrados em sites sobre XP
Cliente, programador, testador Outros papéis encontrados em sites sobre XP Tracker, gerente, goldOwner, goalDonor, ...

47 eXtreme Programming Eduardo Aranha