Post on 07-Apr-2016
eXtreme Programming
Eduardo Aranha
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
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
Foco na satisfação do cliente
Desenvolver o que o cliente precisa no momento que é necessário
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
Princípios básicos
Comunicação– 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
Principais elementos de SPEM
Principais elementos de SPEM
Diagrama de atividades – Modelagem de XP (parcial)
Diagrama de atividades – Modelagem de XP
Diagrama de atividades – Modelagem de XP
Diagrama de classe – Ponto de vista estático de XP (parcial)
Fluxo de XP mostrado no site oficial
Fluxo de XP
Fluxo de XP
Fluxo de XP
Papeis
Oficiais– Cliente, programador, testador
Outros papéis encontrados em sites sobre XP– Tracker, gerente, goldOwner, goalDonor, ...
eXtreme Programming
Eduardo Aranha