1/30

Visão Geral sobre o XP – eXtreme Programming

Alexandre Monteiro

2/30

Manifesto Ágil [1/5] Assinado por 17 desenvolvedores

com reconhecimento mundial em Utah em fevereiro/2001.

Declaração de 4 valores http://www.agilemanifesto.org/

3/30

Manifesto Ágil [2/2]

“Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que:

Indivíduos e interações são mais importantes que processos e ferramentas.

Software funcionando é mais importante do que documentação completa e detalhada.

Colaboração com o cliente é mais importante do que negociação de contratos.

Adaptação a mudanças é mais importante do que seguir o plano inicial.

Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “

4/30

Metodologias Ágeis eXtreme ProgrammingeXtreme Programming FDD Lean Software Development Cristal Family Scrum (...)

5/30

Em meados de 1990, Kent BeckKent 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 XP - eXtreme Programming

O surgimento do XPO surgimento do XP

6/30

“Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança”

O que é eXtreme Programming?O que é eXtreme Programming?

Kent BeckKent Beck

7/30

Programando ao Extremo Levar todas as boas práticas ao

Extremo Se testar é bom, vamos testar toda hora!! Se projetar é bom, vamos fazer disso parte

do trabalho diário de cada pessoa! Se integrar é bom, vamos integrar a maior

quantidade de vezes possível! Se iterações curtas é bom, vamos deixar as

iterações realmente curtas!

8/30

Mudanças sempre ocorrem Clientes não sabem o que querem

no início Desenvolvedores não sabem qual

a melhor maneira de fazer o software no início

Medo da mudança trava o desenvolvimento

9/30

Avanços Nos últimos 30 anos...

Melhoria nos processos Iterativo Incremental

Melhorias nas ferramentas IDEs, automação...

Maior abstração no desenvolvimento Orientação a Objetos Orientação a Aspectos Orientação a ...

10/30

Mudar não é tão caro

Requisitos Análise Projeto Implementação

Testes Produção t

custo

11/30

XP inclui... Comunicação Coragem Feedback Simplicidade Respeito

12/30

Comunicação Soluções de problemas

normalmente já são conhecidas... O problema é a solução chegar a

quem precisa Comunicação face a face é a

maneira mais rápida de “espalhar” conhecimento

13/30

Coragem Extreme Programming é novo e

diferente Atitude é mais importante que

processo Coragem pra dizer a verdade, para

recomeçar do zero, para inovar

14/30

Feedback Feedback <-> Comunicação Feedback aumenta aprendizado e

produtividade

15/30

Simplicidade Regra geral Pensar sempre : “ O que pode ser

feito que seja o mais simples que funciona?”

Simplicidade normalmente gera mais valoroverhead

Geração de valor

Simplicidade

16/30

Respeito Coragem, Feedback, Simplicidade,

Comunicação... Respeito é necessário para tirar o

máximo desses valores Respeito pelo próximo

Feedback, Comunicação Respeito por si mesmo

Coragem, Simplicidade

17/30

Boas Práticas Test First Design

Refactoring

Stand-up Meeting

Continuous Integration

A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema.

Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

Reuniões rápidas e diárias com a equipe

A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos.

18/30

Boas Práticas Pair Programming

Move People Around

Collective Code Ownership

Coding Standards

Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor.

Todo código é desenvolvido seguindo um padrão.

E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo.

As duplas de programação são revezadas em média a cada 2h.

19/30

Boas Práticas The Customer is

Always Available

Small Release

Simple Design

O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades.

O código está, a qualquer momento, na forma mais simples que passe todos os testes.

O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos.

20/30

Boas Práticas

40-Hour Week

On-Site Customer

Acceptance Tests

Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve-se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa .

Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas

São definidos pelo usuário e são os critérios de aceitação do software.

21/30

Boas Práticas System Metaphor

Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes.

A idéia é que exista um objeto "produto" que sofre várias modificações ao longo da "linha de montagem", onde outros objetos trabalham sobre o produto. A vantagem é que é simples adicionar "máquinas novas" a linha de montagem.

A Fábrica

Quando o "produto" precisa passar pela mão de várias pessoas, às vezes para conhecimento, aprovação ou modificação do conteúdo. Podem existir modificações feitas pelo sistema, nesse caso, existem "destinatários virtuais" que recebem a mensagem, analisam e despacham para quem deve. A diferença básica do Correio para a Fábrica é que ele não segue uma linha.

O Correio

O objeto é um "turista", o Servlet e o Banco são hospedagens, os dados são a bagagem, o objeto que tira os dados do "turista" e coloca ou no Servlet (em XML) ou no Banco são "carregadores de bagagem". Quando a "bagagem" está guardada no hotel "Banco de Dados" o "turista" recebe um ticket da bagagem para poder pegar ela depois (o Identificador único da tabela).

Turista

22/30

Papéis no XPBig Boss / XpManagerBig Boss / XpManager

Deve fazer:

• Agendar reuniões;

• Escrever atas;

• Manter o XP Tracker informado dos acontecimentos das reuniões

Não deve fazer:

•Deixar que problemas externos interfiram no desenvolvimento

•Dizer quando as coisas devem acontecer

•Dizer às pessoas o que fazer

•Cobrar das pessoas

23/30

Papéis no XPXp Gold Owner (Cliente - Xp Gold Owner (Cliente - O proprietário do O proprietário do ouroouro)

É quem paga pelo sistema, geralmente o dono da empresa.

Deve fazer:

• Escrever User Stories

• Definir prioridades

• Definir testes de aceitação

• Validar testes de aceitação

• Esclarecer dúvidas

Xp Goal DonorXp Goal Donor

Não deve fazer:

• Implementar código

• Definir quanto tempo uma tarefa leva para ser feita

24/30

Papéis no XPXp Coach Xp TrackerXp Coach Xp Tracker

Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game.

CoordenadoresCoordenadores

Deve fazer:

• Coletar métricas

• Manter todos informados do que está acontecendo

• Definir testes de aceitação

• Tomar atitudes diante de problemas

• Sugerir sessões de CRC (Class, Responsabilities , Collaboration)

25/30

Papéis no XP

Deve fazer:

• Estimar prazos de User Stories

• Implementar código de produção

• Trabalhar em par

• Fazer refactoring

• Corrigir bugs

Não deve fazer:

• Criar/Alterar novas funcionalidades

• Escrever testes de aceitação

Programador Programador (Driver/Partner)(Driver/Partner)

26/30

Um Projeto XP

27/30

28/30

Planejamento das iterações Divida o projeto em etapas de 1 ou 2 semanas; Considere prazos fixos e escolha um dia da

semana para integrações e entregas; (segunda ou sexta-feira);

Planeje reuniões diárias para acompanhar a evolução do projeto (“stand-up”, meeting matinal);

As iterações serão as unidades de referência para fazer estimativas;

Entre no jogo para entregar um produto a cada iteração.

29/30

Conclusão Extreme Programming

Atitude Disciplina

Mudança é algo normal Aceitar, não fugir

Conjunto de boas práticas

30/30

Referências XPRecife – Grupo de Estudos de

Métodos Ágeis de Recife www.cin.ufpe.br/~xprecife

Xispê – Portal Brasileiro de XP www.xispe.com.br