www.agilcoop.org.br

Métodos Ágeis de Desenvolvimento de Software

Experimental Software Engineering Latin American Workshop

ESELAW’2007

Fabio Kon, João Eduardo Ferreira, Hugo CorbucciDepartamento de Ciência da Computação

IME/USP

2Copyleft AgilCoop

Nossa experiência

• Cursos de graduação em XP desde 2001

• Apresentações– SBES, SUCESU, SEPAI, SEBRAE, etc.– Arquivos disponíveis: AgilCoop

• Assessorias em métodos ágeis

• Artigos científicos e dissertações

3Copyleft AgilCoop

Novos ventos no mundo do Desenvolvimento de Software

• Sociedade demanda– grande quantidade de sistemas/aplicações– software complexo, sistemas distribuídos,

heterogêneos– requisitos mutantes (todo ano, todo mês, todo dia)

• Mas, infelizmente,– não há gente suficiente para desenvolver tanto

software com qualidade.

4Copyleft AgilCoop

Roteiro

• Motivação– Problemas e possíveis direções

• Métodos ágeis– Princípios– Problemas com os métodos tradicionais– Alguns métodos ágeis– Apresentação mais detalhada de XP

5Copyleft AgilCoop

Problemas

• Com métodos tradicionais de desenvolvimento– Supõem que é possível prever o futuro– Pouca interação com os clientes– Ênfase em burocracias

• (documentos, formulários, processos, controles rígidos, etc.)

– Avaliação do progresso baseado na evolução da burocracia e não do código

• Com software– Grande quantidade de erros– Falta de flexibilidade

6Copyleft AgilCoop

Como resolver esse impasse?

• Melhores Tecnologias– Padrões de Projeto (reutilização de idéias)– Componentes (reutilização de código)– Middleware (aumenta a abstração)

• Melhores Metodologias– Métodos Ágeis (o foco desta apresentação)– outras... (abordadas em ES)

7Copyleft AgilCoop

Metodologias de Desenvolvimento de Software OO

• “Tradicionais”– Comunidade de Engenharia de Software– IEEE/ACM ICSE– p.ex. Carnegie-Mellon SEI– RUP, CMMi, etc.

• Ágeis– Comunidade de POO– ACM OOPSLA– p.ex. Johnson @ Illinois, Beck, Cockburn, Jeffries,

Cunningham…– XP, Crystal, Scrum, Lean, etc.

8Copyleft AgilCoop

O que é desenvolvimento de sofware ?

• Por: Alistair Cockburn

• Se você sabe o que é, pode aplicar soluções conhecidas.

Modelagem (Jacobson)Engenharia (Meyer)Disciplina (Humphreys)Poesia (Cockburn)Artesanato (Knuth)Arte (Gabriel)

9Copyleft AgilCoop

Métodos Ágeis deDesenvolvimento de Software

• Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.

• Questionam e se opõem a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos.

• Manifesto Ágil:• Assinado por 17 desenvolvedores em Utah em

fevereiro/2001. • http://agilemanifesto.org

10Copyleft AgilCoop

O Manifesto do Desenvolvimento Ágil de Software

• 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.

11Copyleft AgilCoop

Princípios do Manifesto Ágil

• Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor.– Entregar versões funcionais em prazos curtos.– Estar preparado para requisitos mutantes.– Pessoal de negócios e desenvolvedores juntos.– Troca de informações através de conversas

diretas.

12Copyleft AgilCoop

Mais princípios do Manifesto Ágil

• Medir o progresso através de software funcionando.

• Desenvolvimento sustentável.• Construir projetos com indivíduos motivados.• Simplicidade é essencial.• De tempos em tempos, o time pensa em como se

tornar mais eficiente e ajusta o seu comportamento de acordo.

13Copyleft AgilCoop

Em um projeto ágil ideal…. (1/2)

• O gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos.

• Os desenvolvedores concordam em prosseguir sem ter todos os requisitos documentados.

• Os membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas.

14Copyleft AgilCoop

Em um projeto ágil ideal….(2/2)

• Os gerentes percebem que não precisam dizer à equipe o que fazer, ou garantir o que vai ser feito.

• A equipe percebe que ninguém vai dizer o que fazer, isto faz parte do trabalho da equipe.

• Não existem mais a impressão de divisão (testers and programmers), todos são desenvolvedores.

15Copyleft AgilCoop

Enquanto isso, no mundo tradicional...

Requisitos

Análise

Implementação

Arquitetura eDesign

Testes

Manutenção

16Copyleft AgilCoop

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 implementar o sistema por inteiro antes de enviá-lo ao cliente.

17Copyleft AgilCoop

O que está por trás deste modelo?

Cus

to d

e m

udan

ças

requisitos desenho testes análise implementação produção

18Copyleft AgilCoop

E se a realidade hoje em dia fosse outra?

Cus

to d

e m

udan

ças

tempo

19Copyleft AgilCoop

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).

20Copyleft AgilCoop

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

• Orientação a Objetos/Aspectos: facilita e cria oportunidades para mudanças.

• Técnicas de Refatoração.• 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.

21Copyleft AgilCoop

Principais Métodos Ágeis

• Hoje concentrar-nos-emos em:– Programação eXtrema (XP)

• Outros métodos ágeis interessantes:– Crystal (uma família de métodos)– Scrum– Adaptive Software Development– Feature Driven Development– etc.

22Copyleft AgilCoop

A família Crystal de Métodos

• Criada por Alistair Cockburn• http://alistair.cockburn.us/crystal• Editor da série Agile Software Development

da Addison-Wesley.

23Copyleft AgilCoop

Pequeno histórico

• Foi contratado em 1990 pela IBM– documentar a metodologia de desenvolvimento– optou por entrevistar as diversas equipes

• Resultados:– Pedidos de desculpa por não utilizar ferramentas

• e entregar software funcionando– Explicações sobre como metodologias foram

seguidas à risca• e o projeto falhou

24Copyleft AgilCoop

Conclusões de Cockburn

• Pode-se trocar (com vantagens) documentação escrita por conversas face a face.

• Quanto mais se entrega software testado e funcionando, menos se depende da documentação escrita (promissórias).

25Copyleft AgilCoop

Classificação de Projetos de Desenvolvimento de Software

Número de pessoas envolvidas

C

ritic

alid

ade

(def

eito

s cau

sam

per

das d

e...)

Comfort(C)

Essentialmoney

(E)

Life(L)

+20%

. . . Prioridade para responsabilidade legal

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioridade para Produtividade & Tolerância

Discretionarymoney

(D)

26Copyleft AgilCoop

Escopo da Família Crystal

Red

C6 C20 C40 C80

D6 D20 D40 D80

E6 E20 E40 E80

Clear Yellow Orange

L6 L20 L40 L80

27Copyleft AgilCoop

Principais Características da Família Crystal

• Filosofia básica:– ênfase em comunicação– leve nos produtos gerados (evitar “peso morto”)

• Princípios:– Precisamos de menos produtos intermediários se possuímos:

• canais de comunicação informal ricos e rápidos• entrega freqüente de código funcionando• uso dos pontos fortes das pessoas (conversas, olhar a sua volta,

interagir com outros)• estar ciente dos pontos fracos das pessoas (baixa disciplina,

falta de cuidado)

28Copyleft AgilCoop

Adaptação da Metodologia

• Em cada caso, escolha a metodologia mais leve possível que seja capaz de entregar o que você precisa.

• Quanto maior o projeto (número de pessoas), maior burocracia será necessária e pior será a produtividade.

• Oficinas de Reflexão (Reflection Workshops) ao final de cada fase.

29Copyleft AgilCoop

Oficinas de Reflexão(Reflection Workshops)

• Perguntas:– O que aprendemos na última fase (p.ex. mês)?– O que podemos fazer de uma forma melhor?

• Resultado:– pôster Tentar

testes automatizadosmultas para interrupçõesescrita pareada de testes

Manterreuniões com cliente

programação pareada

Problemasmuitas interrupções

erros no código entregue

30Copyleft AgilCoop

Mais perguntas na reflexão

• O que fizemos de bom e de ruim? • Quais são as nossas prioridades? • O que mantivemos de mais importante? • O que podemos mudar para a próxima vez?• O que podemos adicionar/tirar?

• Após 2 ou 3 versões incrementais, a metodologia começa a convergir para uma metodologia específica adaptada ao projeto em questão.

31Copyleft AgilCoop

Scrum

• Jeff Suttherland– http://jeffsutherland.com

• Ken Schwaber– http://www.controlchaos.com

• Conferências– OOPSLA 96, PLoP 98

• Inspiração– Desenvolvimento Iterativo e Incremental em

empresas (DuPont) nos anos 80

32Copyleft AgilCoop

Programação eXtremaXP

• Metodologia de desenvolvimento de software aperfeiçoada nos últimos 8 anos.

• Ganhou notoriedade a partir da OOPSLA’2000.

• Nome principal: Kent Beck.

33Copyleft AgilCoop

Reações iniciais a XP

• Alguns odiaram, outros amaram.

• Quem gosta de programar ama!• Deixa o bom programador livre para fazer

o que ele faria se não houvesse regras.• Força o [mau] programador a se

comportar de uma forma similar ao bom programador.

34Copyleft AgilCoop

A Quem se Destina XP?

• Grupos de 2 a 10 [20] programadores• Projetos de 1 a 36 meses (calendário)• De 1000 a 250 000 linhas de código• Papéis:

– Programadores (foco central) (sem hierarquia)– “Treinador” ou “Técnico” (coach)– “Acompanhador” (tracker)– Cliente

35Copyleft AgilCoop

E Se Eu Não Me Encaixo Nesses Casos?

• Você ainda pode aprender muito sobre desenvolvimento de software.

• Terá elementos para repensar as suas práticas.

• No início se dizia:– “Ou você é 100% eXtremo ou não é eXtremo.

Não dá prá ser 80% XP.”• Hoje não é mais necessariamente assim.

36Copyleft AgilCoop

Os Valores de XP

• Comunicação• Feedback• Coragem• Simplicidade

37Copyleft AgilCoop

As 12 Práticas de XP(versão 2000)

1. Planejamento2. Fases Pequenas3. Metáfora4. Design Simples5. Testes6. Refatoração7. Programação

Pareada

8. Propriedade Coletiva

9. Integração Contínua

10.Semana de 40 horas

11.Cliente junto aos desenvolvedores

12.Padronização do código

38Copyleft AgilCoop

Princípios Básicos de XP

• Feedback rápido

• Simplicidade é o melhor negócio

• Mudanças incrementais

• Carregue a bandeira das mudanças / não valorize o medo (Embrace change)

• Alta qualidade do código

39Copyleft AgilCoop

As 4 Variáveis do Desenvolvimento de Software

• Tempo

• Custo

• Qualidade

• Escopo (foco principal de XP)

40Copyleft AgilCoop

Um Projeto XP

• Fase de Exploração– duração: 1 a 6 meses. – termina quando a primeira versão do

software é enviada ao cliente.– clientes escrevem “historias” (story cards).– programadores interagem com clientes e

discutem tecnologias.– Não só discutem, experimentam diferentes

tecnologias e arquiteturas para o sistema.– Planejamento: 1 a 2 dias.

41Copyleft AgilCoop

Um Dia na Vida de um Programador XP

• Escolhe uma história do cliente.• Procura um par livre.• Escolhe um computador para programação

pareada.• Seleciona um “cartão de história” contendo

uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

42Copyleft AgilCoop

Um Dia na Vida de um Programador XP

• Discute modificações recentes no sistema

• Discute história do cliente

• Testes

• Implementação

• Projeto (design)

• Integração

43Copyleft AgilCoop

Um Dia na Vida de um Programador XP

• Atos constantes no desenvolvimento:– Executa testes antigos.– Busca oportunidades para simplificação.– Modifica desenho e implementação

incrementalmente baseado na funcionalidade exigida no momento.

– Escreve novos testes.– Enquanto todos os testes não rodam a 100%,

o trabalho não está terminado.– Integra novo código ao repositório.

44Copyleft AgilCoop

Testes

• Fundamento mais importante de XP.• É o que dá segurança e coragem ao grupo.• Testes de unidades (Unit tests)

– escritos pelos programadores para testar cada elemento do sistema (p.ex., cada método em cada caso).

• Testes de funcionalidades (Functional tests)– escritos pelos clientes para testar a

funcionalidade do sistema (Testes de aceitação).

45Copyleft AgilCoop

Testes

• Testes das unidades do sistema– Tem que estar sempre funcionando a 100%.– São executados várias vezes por dia.– Executados à noite automaticamente.

• Testes das funcionalidades (aceitação)– Vão crescendo de 0% a 100%.– Quando chegam a 100% acabou o projeto.

46Copyleft AgilCoop

O Código

• Padrões de estilo adotados pelo grupo inteiro.

• O mais claro possível.– nomes claros (intention-revealing names)– XP não se baseia em documentações

detalhadas e extensas (perde-se sincronia).• Comentários sempre que necessários.• Comentários padronizados.• Programação Pareada ajuda muito!

47Copyleft AgilCoop

Programação Pareada

• Erro de um detectado imediatamente pelo outro (grande economia de tempo).

• Maior diversidade de idéias, técnicas, algoritmos.• Enquanto um escreve, o outro pensa em contra-exemplos,

problemas de eficiência, etc. • Vergonha de escrever código feio (gambiarras) na frente do

seu par.• Pareamento de acordo com especialidades.

• Ex.: Sistema Multimídia Orientado a Objetos• Experimentos controlados mostraram que a qualidade do

código produzido aumenta sem perda de velocidade [Laurie Williams]

48Copyleft AgilCoop

Propriedade Coletivado Código

• Modelo tradicional: só autor de uma função pode modificá-la.

• XP: o código pertence a todos.• Se alguém identifica uma oportunidade

para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça.

• Mas rode os testes!

49Copyleft AgilCoop

Refatoração(Refactoring)

• Uma [pequena] modificação no sistema que não altera o seu comportamento funcional.

• mas que melhora alguma qualidade não-funcional:– simplicidade– flexibilidade– clareza– [desempenho]

50Copyleft AgilCoop

Exemplos de Refatoração

• 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)

51Copyleft AgilCoop

Cliente

• Responsável por escrever “histórias”.• Muitas vezes é um programador ou é

representado por um programador do grupo.• Trabalha no mesmo espaço físico do grupo.• Novas versões são enviadas para produção

todo mês (ou toda semana).• Feedback do cliente é essencial.• Requisitos mudam (e isso não é mau).

52Copyleft AgilCoop

Coach(treinador)

• Em geral, o mais experiente do grupo.– (eXPeriente em metodologia, não na tecnologia)

• Identifica quem é bom no que.• Lembra a todos as regras do jogo (XP).• Eventualmente faz programação pareada.• Não desenha arquitetura, apenas chama a

atenção para oportunidades de melhorias.• Seu papel diminui à medida em que o time fica

mais maduro.

53Copyleft AgilCoop

Tracker(Acompanhador)

• A “consciência” do time.• Coleta estatísticas sobre o andamento do projeto.

Alguns exemplos:• Número de histórias definidas e implementadas.• Número de testes de unidade.• Número de testes funcionais definidos e funcionando.• Número de classes, métodos, linhas de código.

• Mantém histórico do progresso.• Faz estimativas para o futuro.

54Copyleft AgilCoop

Conclusão: Ser Ágil = Vencer Medos

• Escrever código.• Mudar de idéia.• Ir em frente sem saber tudo sobre o futuro.• Confiar em outras pessoas.• Mudar a arquitetura de um sistema em

funcionamento.• Escrever testes.

55Copyleft AgilCoop

As 12 Práticas de XP(versão 2000)

1. Planejamento2. Fases Pequenas3. Metáfora4. Design Simples5. Testes6. Refatoramento7. Programação

Pareada

8. Propriedade Coletiva

9. Integração Contínua

10.Semana de 40 horas

11.Cliente junto aos desenvolvedores

12.Padronização do código

56Copyleft AgilCoop

2a edição em 2004Por que mudou?

• 5 anos de experiência e retorno da comunidade• Críticas ao 1º livro:

– Você quer nos forçar a programar da sua maneira!– XP é muito radical!– XP despreza o design!– XP despreza a documentação!– XP despreza conhecimentos especializados!– XP não escala e não funciona para equipes dispersas

geograficamente!• O livro foi então completamente re-escrito

57Copyleft AgilCoop

Definindo XP

• 1ª edição - 1999– “XP é uma metodologia leve para times

médios ou pequenos desenvolvendo software em face a requisitos vagos e que mudam rapidamente”

• 2ª edição - 2004– “XP trata de mudança social”

58Copyleft AgilCoop

Valores, princípios e práticas

• Valores são abstratos, práticas são concretas

• Valores trazem propósito às práticas• Práticas evidenciam e facilitam a

“prestação de contas” dos valores• Princípios são técnicas intelectuais para

traduzir valores em práticas

59Copyleft AgilCoop

Valores – o que mudou?

• Comunicação, simplicidade, feedback, coragem

• + Respeito– valor complementar aos 4 anteriores– respeito entre os membros da equipe– respeito ao projeto– ao cliente– aos demais funcionários da empresa

60Copyleft AgilCoop

Princípios

• Humanidade– Balancear as necessidades pessoais com as

necessidades do time.• Economia

– Evite o risco do “Sucesso Técnico”. Tenha certeza que o sistema cria valor para o negócio.

• Benefício Mútuo– Todas as atividades devem trazer benefício

a todos os envolvidos.

61Copyleft AgilCoop

Princípios

• Auto-Semelhança– Tente aplicar a estrutura de uma solução em

outros contextos e escalas.• Melhoria

– Valorize atividades que começam agora e se refinam ao longo do tempo.

• Diversidade– Ao formar os times pense em garantir uma

boa diversidade de habilidades, atitudes e perspectivas.

62Copyleft AgilCoop

Práticas – o que mudou?

• Abordagem mais leve para adoção das práticas– as práticas não devem ser impostas, devem ser

escolhidas– não precisam ser adotadas todas de uma vez

• Práticas primárias– independentes e sempre seguras de se adotar– proporcionam melhorias imediatas

• Práticas corolárias– difíceis de adotar sem domínio das primárias

63Copyleft AgilCoop

Práticas Primárias

• Sentar Junto– Desenvolva num ambiente grande o suficiente para

o time todo ficar junto

• Time Completo– Monte um time multi-disciplinar, com todas as

habilidades necessárias para o sucesso do projeto

• Área de Trabalho Informativa– Um observador interessado deve ser capaz de ter

uma idéia do andamento do projeto andando pela área de trabalho

64Copyleft AgilCoop

Práticas Primárias

• Trabalho Energizado– Trabalhe apenas enquanto puder ser produtivo

e o número de horas que puder agüentar.

• Programação Pareada

• Histórias– Unidades de funcionalidade visíveis ao cliente.– Estimativa é feita o mais cedo possível para

facilitar a interação entre o cliente e a equipe.

65Copyleft AgilCoop

Práticas Primárias

• Ciclo Semanal– Representa uma iteração– Planeje o trabalho uma semana de cada vez– Reunião no início da semana para discutir o

progresso, escolher histórias e dividi-las em tarefas

• Ciclo Trimestral (Season Cycle)– Identificar gargalos e iniciar reparos– Planejamento do tema da estação– Foco no todo: onde o projeto se encaixa na

organização

66Copyleft AgilCoop

Práticas Primárias• Folga

– Inclua no plano algumas tarefas menores que podem ser removidas caso ocorra um atraso

– Não se comprometa além do que é possível ser realizado

• Build de 10 minutos– Faça o build AUTOMÁTICO do sistema INTEIRO e

rode TODOS os testes em até 10 minutos.

• Desenvolvimento Dirigido por Testes

67Copyleft AgilCoop

Práticas Primárias

• Integração Contínua– Integração pode ser síncrona ou assíncrona (no

build)

• Design Incremental– Invista no design do sistema todos os dias– O conselho não é minimizar o investimento em

design no curto prazo, mas manter o investimento proporcional às necessidades do sistema

– Design feito mais próximo de quando é usado é mais eficiente

68Copyleft AgilCoop

Como começar?

• Práticas dependem da situação e do contexto, são um guia para onde você pode chegar.

• Adote XP em passos pequenos (mude uma coisa de cada vez).

• Crie consciência da necessidade de uma prática usando métricas.

• Avalie a experiência de adoção.

69Copyleft AgilCoop

Práticas Corolárias

• Envolvimento Real com o Cliente– Faça com que as pessoas cujas vidas e

negócios serão afetados pelo sistema façam parte do time.

• Implantação Incremental– Ao substituir um sistema legado, troque

partes da funcionalidade gradualmente. • Continuidade do Time

– Mantenha times eficientes trabalhando juntos.

70Copyleft AgilCoop

Práticas Corolárias• Redução do Time

– Mantenha a carga de trabalho constante e distribua as tarefas de modo a deixar alguém ocioso

– Com o tempo, essa pessoa pode ser liberada para formar novos times

• Análise de Causa Inicial– Sempre que encontrar um defeito, elimine o defeito

e sua causa– “Os 5 Porquês”

• Código Compartilhado

71Copyleft AgilCoop

Práticas Corolárias

• Código e Testes– Os únicos artefatos permanentes

• Repositório Único de Código– Desenvolva num repositório único. Branches

podem existir, mas devem ser incorporados logo

• Implantação Diária– Coloque software novo em produção toda

noite

72Copyleft AgilCoop

Práticas Corolárias

• Contrato de Escopo Variável– Contratos devem fixar tempo, custo e

qualidade, mas a negociação de escopo deve ser aberta

• Pague-Pelo-Uso– Cobre por cada vez que o sistema é usado– O dinheiro é o feedback máximo

73Copyleft AgilCoop

Resumo – evolução das práticas

74Copyleft AgilCoop

Maiores Informações

AgilCoop:

www.agilcoop.org.br/portal/agilcast

Outros:www.agilealliance.org

www.xispe.com.brwww.extremeprogramming.orgwww.agilealliance.com.br

75Copyleft AgilCoop

FIM

76Copyleft AgilCoop

Quando XP Não Deve Ser Experimentada?

• Quando o cliente não aceita as regras do jogo.• Quando o cliente quer uma especificação

detalhada do sistema antes de começar.• Quando os programadores não estão

dispostos a seguir (todas) as regras.• Se (quase) todos os programadores do time

são medíocres.

77Copyleft AgilCoop

Quando XP Não Deve Ser Experimentada?

• Grupos grandes (>10 [>20] programadores).• Quando feedback rápido não é possível:

– sistema demora 6h para compilar.– testes demoram 12h para rodar.– exigência de certificação que demora meses.

• Quando não é possível realizar testes (muito raro).

• Quando o custo de mudanças é essencialmente exponencial.

78Copyleft AgilCoop

Características Comuns dos Métodos Ágeis

• Coloca o foco:– Na entrega freqüente de sub-versões do

software [funcionando] para o cliente.– Nos seres humanos que desenvolvem o

software.• Retira o foco de:

– Processos rígidos e burocratizados.– Documentações e contratos detalhados.– Ferramentas que são usadas pelos seres

humanos.

79Copyleft AgilCoop

Práticas de XP

• As práticas foram refatoradas(veja www.extremeprogramming.org/rules.html)

• Mas a idéia é exatamente a mesma.

• Novas práticas interessantes:• Conserte XP quando a metodologia quebrar.• Mova as pessoas.• Client Proxy (by Klaus).

80Copyleft AgilCoop

Conclusão

• XP não é para todo mundo– mas é para quase todo mundo

• Mas todos podemos aprender com ela– melhorando a qualidade do software– melhorando a produtividade