EXtreme Programming Eduardo Aranha. O surgimento de XP Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software

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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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

Documents

EXtreme Programming Eduardo Aranha. O surgimento de XP Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software