1

Extreme Programming

2 2

Manifesto do Desenvolvimento Ágil

www.agilealliance.org

Aplicar os ideais do desenvolvimento ágil ao nosso processo particular poderia nos ajudar a ser mais ágeis, mesmo que não pudéssemos adotar XP.

Indivíduos e interações mais que processos e ferramentas.

Trabalhar no software mais que documentação abrangente.

Colaboração do cliente mais que negociação contratual.

Responder às mudanças mais que seguir um plano.

3 3

O que é XP?

Processo de desenvolvimento de software Projetos com requisitos muito voláteis Equipes pequenas (até ~10 pessoas)

Desenvolvimento incremental

4 4

O que é um projeto de sucesso?

Cumpre o orçamento Cumpre o prazo Cliente fica feliz Equipe fica feliz

5 5

Premissas do desenvolvimento

Cliente é capaz de especificar um software antes de iniciar o desenvolvimento

Equipe de desenvolvimento é capaz de quantificar o esforço

Equipe é capaz de criar o software imaginado pelo cliente

Cliente ficará feliz

6 6

Resumo

Divisão nítida entre “produção” e “consumo”

Cliente produz uma especificação que é consumida pela equipe de desenvolvimento

Equipe de desenvolvimento produz o software que é consumido pelo cliente

7 7

Motivação: custo de uma alteração

Tempo de Projeto

Cu

sto

$ 1Requisitos

$ 10Análise

$ 100Design

$ 1.000Implem.

$ 10.000Testes

8 8

Premissas Básicas do Modelo Tradicional

É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema.

É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la.

É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

9 9

Por que software falha?

10 10

Problemas desta premissa

Premissa é irreal em vários casos O cliente não é capaz de especificar o

software previamente Grande problema:

DETALHE

11 11

Premissa do desenvolvimento ágil APRENDIZADO FEEDBACK DESENVOLVIMENTO

ITERATIVO

12 12

Aprendizado O cliente aprende durante

o desenvolvimento Descobre novas

possibilidades Muda as prioridades

13 13

Trabalho intelectual

Retrabalho é uma característica do trabalho intelectual

ExperimentaçãoCriaçãoRevisãoExperimentação ...

14 14

Premissa: custo de uma alteração

Tempo de Projeto

Cu

sto

15 15

E se essa fosse a realidade?

A atitude dos desenvolvedores de software seria completamente diferente:Tomaríamos as grandes decisões o mais

tarde possível. Implementaríamos agora somente o que

precisamos agora.Não implementaríamos flexibilidade

desnecessária (não anteciparíamos necessidades).

16 16

E essa é a nova realidade !(pelo menos em muitos casos)

Orientação a Objetos facilita e cria oportunidades para mudanças

Técnicas de Refatoramento possibilita melhorar continuamente a implementação

aumentando constantemente a qualidade do código produzido

Testes automatizados nos dão segurança quando fazemos mudanças

Prática / cultura de mudanças aprendemos técnicas e adquirimos experiência em

lidar com código mutante

17 17

As 4 Variáveis do Desenvolvimento de Software

• Tempo

• Custo

• Qualidade

• Escopo (foco principal de XP)

18 18

Valores

FeedbackComunicaçãoSimplicidadeCoragem

19 19

User Stories

Funcionalidades são informadas através de user stories

Estórias devem ser simples

Desenvolvedores estimam tempo

20 20

Planejamento

De posse das estimativas, é possível priorizar

Cliente entrega as estórias priorizadas para serem implementadas

Desenvolvedores respeitam as prioridades dos clientes

Projeto é dividido em partes: releases e iterações

21 21

Priorização

Cliente deve priorizar as estórias

Para obter o máximo de valor rapidamente

Se baseia nas suas necessidades e nas estimativas dos desenvolvedores

22 22

Release e Iteração

R1 R2 R3 R4

I1

S1

8 Sem.

I2 I3 I4

2 Sem.

1 Sem.

S2

Projeto: 8 meses = 32 semanas

23 23

Release Planning

Cliente recebe um “orçamento” dos desenvolvedores

Seleciona as estórias prioritárias que possam ser implementadas dentro do orçamento

Pode trocar estórias durante o release

R1 R2 R3 R4

8 Sem.

24 24

Iteration Planning

Cliente recebe um “orçamento” Não pode haver troca de funcionalidades

durante uma iteração Velocidade: quantidade de estórias que a

equipe consegue implementar em uma iteração

I1 I2 I3 I4

2 Sem.

25 25

Stand-up meeting

Reunião rápida

Diária Usada para

atualização da equipe

26 26

Desenvolvimento: orientação a objetos Sistema é composto

por pequenas peças Peças têm objetivos

específicos Facilita construção Facilita evolução

27 27

Buscando bugs

Sistemas podem ter defeitos

É difícil descobrir qual é a peça defeituosa

É mais fácil se o problema for detectado logo após a adoção da peça

28 28

Test Driven Design

No XP, primeiro se especifica o teste

Depois se constrói a peça

29 29

Unit Test

Nome dado à verificação feita sobre cada peça

Cada peça possui um unit test associado a ela

Testes são automatizados Quando uma nova peça entra

no sistema, todos os testes são executados

30 30

31 31

32 32

Acceptance Test

Cliente deve especificar testes de aceitação para cada funcionalidade de uma iteração

Sistema deve passar nestes testes ao término da iteração

33 33

Pair Programming

Todo código é escrito em par

Duas pessoas trabalham em um único computador

Uma digita, enquanto a outra revisa, corrige e sugere

34 34

Collective code ownership

Todos são responsáveis por todas as partes do sistema

Código tem que estar sempre “limpo”

Todos são capazes de modificá-lo

35 35

Refactoring Uma [pequena] modificação no sistema

que não altera o seu comportamento funcional

mas que melhora alguma qualidade não-funcional:simplicidade flexibilidadeclarezadesempenho

36 36

Exemplos de Refactoring

Mudança do nome de variáveis

Mudanças nas interfaces dos objetos

Pequenas mudanças arquiteturais

Encapsular código repetido em um novo método

Generalização de métodos• raizQuadrada(float x) raiz(float x, int n)

37 37

Desenvolvimento em equipe

Como conciliar diversos desenvolvedores? Estrutura de diretórios Atualização do código por várias pessoas

diferentes

38 38

CVS – Repositório de fontes Check out Add Commit Update Conflict Remove

39 39

CVS

40 40

40 hour week

Desenvolvimento de software é um trabalho intelectual intenso

Não é produtivo trabalhar além do limite

41 41

Customer onsite Fator mais

importante no XP:ComunicaçãoFeedback

Viabiliza a simplicidade da metodologia

War room c / quadro branco

42 42

Feedback constante

Permite que pequenas mudanças sejam feitas

Evita a necessidade de mudanças bruscas

Mantém o projeto em curso

43 43

Integração contínua Máquina destacada para a integração Integração ocorre diversas vezes ao dia Os testes são executados em cada

integração Correções são feitas imediatamente

44 44

Ambientes para deployment

Como lidar com diferentes ambientes?

Exemplo:DesenvolvimentoAceitaçãoProdução

45 45

Ambientes para deployment

Desenvolvimento

Aceitação

Produção

46 46

Problemas de ter vários ambientes

Possíveis erros devido a tarefas manuais repetitivas

Gasto de tempo

47 47

Automatização do deployment

Agiliza as integrações Evita erros

48 48

Ant

49 49

Exemplo simples

<project name="projeto" default="desenvolvimento">

<target name="desenvolvimento"> <mkdir dir="build"/> <javac srcdir="src" destdir="build"/> <junit> <test name="test.SystemTester"/> </junit> </target>

</project>

targ

et

tasks

50 50

Ambiente de Desenvolvimento

Desejável que tenha:Code completionValidação on-lineSuporte à depuraçãoSuporte a Refactoring Integração com jUnit Integração com CVS Integração com Ant

51 51

Exemplos

52 52

Importância da IDE para o XP

Ganho de tempo Automação Facilidade de uso Verificação permanente do código

53 53

Importância da IDE para o XP

54 54

Steering Pequenas mudanças Ajustes simples ao

longo do tempo

X

55 55

Segredo do sucesso

O conjunto é o que faz a diferença

A ausência de uma prática mostra a deficiência de outras

Metáfora do time de futebol

56 56

XP e RUP

XP RUP

Foco nas práticas da equipe Foco nos artefatos

Comportamental Prescritivo

Projetos de determinados tamanhos

Qualquer projeto

57 57

Negociação

Venda técnica Venda focada em negócio Duas propostas:

Escopo fechadoEscopo variável

58 58

Resistências

Dificuldades com a área de TI Grande resistência dos desenvolvedores Pouca resistência na área usuária do

cliente Estratégia: pedido de tempo

59 59

Ambiente de desenvolvimento

Sala dedicada unicamente ao projeto Mural Quadros brancos Mesas que suportam programação em par Equipamentos com bom desempenho

60 60

XP no Brasil

2000: algumas práticas começam a ser usadas em projetos no Sul

Dez/2002: primeiro XP Brasil Jan/2003: fundação do XP Rio Fev/2003: primeiro projeto full-XP em uma

grande empresa brasileira (em andamento) Nov/2003: lançamento previsto do primeiro

livro brasileiro sobre XP

61 61

Referências Site Xispê

http://www.xispe.com.br XP Rio

http://www.yahoogroups.com/groups/xprio Lista Xpers

http://www.yahoogroups.com/groups/xpers