O documento apresenta os principais conceitos e práticas do eXtreme Programming (XP), uma metodologia ágil de desenvolvimento de software. Em 3 frases ou menos: XP enfatiza a comunicação, simplicidade e feedback rápido através de práticas como programação em pares, desenvolvimento guiado por testes, integração contínua e pequenos lançamentos frequentes. A metodologia valoriza a interação humana sobre processos e ferramentas e entrega de software funcionando sobre documentação extensa. O foco está na qualidade do código e no at

1. Conhecendo o
eXtreme Programming

2. Quem sou eu?
Guilherme Lacerda
guilhermeslacerda@gmail.com
Mestre em Ciência da Computação, área de Engenharia de Software (UFRGS)
Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter)
Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anos
de experiência em modelagem e desenvolvimento OO
Instrutor/Consultor de Metodologias Ágeis da TargetTrust
Pioneiro em Metodologias Ágeis no Brasil (Lean, SCRUM e XP)
Fundador do XP-RS (Grupo de Usuários de Metodologias Ágeis do RS) e Vice-Coordenador
do GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado a SUCESU-RS
Editor do Portal InfoQ Brasil
Membro do IASA e da Scrum Alliance

3. Quem faz programa?
Por que 80% a 90% dos projetos de SW
fracassam?
Fonte: Standish Group

4. Principais Problemas
Sistemas entregues com atrasos e/ou orçamento estourado
Não atendem os requisitos de negócio
Clientes descontentes (sem confiança nos desenvolvedores)
Clientes não têm compreensão clara do que é desenvolvido
Clientes não dão suporte correto para o desenvolvimento
Clientes não estão interessados em participar de processos
complexos

5. Principais Problemas
Desenvolvedores trabalham muitas horas!
Desenvolvedores relaxam na disciplina
Desenvolvedores perdem o foco
Processos prescritivos são atrativos para a gerência mas não para
os desenvolvedores
Baseados no paradigma do comando e controle
Tenta minimizar o papel do cliente
Foco em tecnologia e não no negócio

6. Como resolvê-los?

7. Como resolvê-los?

8. O que é ser Ágil?
Ágil é ser rápido, ligeiro (dicionário)
Eficaz: produz o resultado esperado
Eficiente: produz o resultado esperado, mas com qualidade
Características importantes:
Foco nas necessidades do cliente (resultado!)
Liderança
Envolvimento das pessoas
Melhoria Contínua
Tomada de decisões baseada em análise de dados e informações
(controle!)

9. Direitos do Cliente (Ron Jeffries)
Planejamento Geral, definindo o que pode ser realizado, quando e a
que custo
Ver e acompanhar o andamento do projeto e, principalmente, o
progresso do SW, passando por testes definidos em conjunto com a
equipe
Mudar de idéia, substituir funcionalidades, sem pagar custos
exorbitantes
Ser informado de mudanças no cronograma, em tempo de escolher e
reduzir o escopo
Poder cancelar o projeto a qualquer momento e ainda assim ter um
sistema funcionando, refletindo o investimento realizado até o
momento

10. Direitos do Desenvolvedor (Ron Jeffries)
Saber o que é necessário, com declarações claras de
prioridade
Produzir trabalho de qualidade o tempo todo
Pedir e receber ajuda da equipe, superiores e clientes
Fazer e atualizar suas próprias estimativas
Aceitar as suas responsabilidades, ao invés de tê-las impostas

11. Processos de Software
Processos Tradicionais
Analisar, projetar e só depois iniciar codificação
Prever o futuro
Ter certeza do que se sabe hoje será exatamente o que se quer amanhã
Temores
Mudança de requisitos depois de concluída a fase de análise e projeto

12. Manifesto Ágil
“Estamos evidenciando maneiras melhores de desenvolver
software fazendo-o nós mesmos e ajudando outros a fazê-lo.
Através desse trabalho, passamos a valorizar:
Interação entre pessoas MAIS QUE processos e ferramentas;
Software em funcionamento MAIS QUE documentação abrangente;
Responder a mudanças MAIS QUE seguir um plano.
Colaboração com o cliente MAIS QUE negociação de contratos;
Ou seja, mesmo tendo valor os itens à direita, valorizamos
mais os itens à esquerda.”
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward
Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick,
Ken Schwaber, Jeff Shuterland, Dave Thomas
Utah – Fevereiro de 2001

13. Waterfall X Ágil

14. Cone da Incerteza

15. Riscos
Riscos de Planejamento
Será que conseguiremos
terminar até outubro?
Riscos de Custo
Será que conseguiremos comprar o servidor pelo preço definido
anteriormente?
Riscos de Requisitos
Será que temos todas as informações para começar o trabalho?

16. Risco X Valor
Alto Risco Alto Risco
Baixo Valor Alto Valor
Risco
Baixo Risco Baixo Risco
Baixo Valor Alto Valor
Valor
Evitar Fazer Primeiro
Risco
Fazer por último Fazer depois
Valor

17. Waterfall, Iterativo

18. eXtreme Programming

19. eXtreme Programming

20. XP
Criado por Kent Beck, Ron Jeffries e Ward Cunningham
Disciplina de desenvolvimento de SW, voltada para equipes
pequenas e médias, com requisitos vagos ou que mudam
freqüentemente
Principal tarefa é a codificação

21. XP

22. Valores
Comunicação
Práticas valorizam a comunicação, não limitada a procedimentos formais
Simplicidade
Incentiva ao extremo práticas que reduzam a complexidade
Feedback
Práticas garantem um rápido feedback sobre várias partes do projeto
Coragem
Práticas aumentam a confiança dos desenvolvedores e do próprio cliente

23. Comunicação

24. Comunicação

25. Comunicação

26. Variáveis de um Projeto
Processos Tradicionais
Tempo
Escopo Manipula-se a
Custo Qualidade
eXtreme Programming
Tempo Manipula-se a
Qualidade Escopo
Custo

27. XP
Práticas organizacionais
Práticas de equipe
Práticas de pares

28. Equipe (Whole Team)
Equipe XP = Cliente + Time de Desenvolvimento
As funções do cliente englobam:
Definição dos requisitos do projeto
Definição de prioridades
Controle do rumo do projeto
Definir os testes de aceitação do SW
Os papéis do time de desenvolvimento englobam:
desenvolvedores
testadores (ajudam o cliente com os testes de aceitação)
analistas/projetistas (ajudam o cliente a definir requisitos)
gerente (garante os recursos necessários)
coach (orienta a equipe, controlando a aplicação do XP)
tracker (coleta as métricas do projeto)

29. Equipe (Whole Team)

30. Jogo de Planejamento (Planning Game)
Principais definições
Definição das User Stories (atividade + tarefas)
Estimativas de User Stories
Prioridades (tarefas + importantes)
Próximos passos
Planejamento de release (cliente propõe as funcionalidades e
desenvolvedores avaliam)
Planejamento da iteração (define as funcionalidades da iteração e os
desenvolvedores estimam)
Ótimo feedback para o cliente, que dirige o projeto
Idéia clara do avanço do projeto
Clareza: Redução de Riscos, aumentando a chance de sucesso

31. Produto, Release, Planejamento
Release 1 Release 2 Release 3
Planejamento
Iteração 1 Iteração 2 Iteração 3-5
Tarefa A
Tarefa B
Tarefa C

32. Releases, Iterações, Velocidade
Um release é formado de múltiplas iterações
Cada iteração pode ser planejada com o mesma caixa de tempo
Stories são colocadas dentro de cada caixa, até estar completa
O tamanho da caixa é a velocidade planejada
3 4 2
3 7
4
5 4
5
2 6 4
2 5
6

33. Testes de Aceitação (Acceptance Tests)
São elaborados pelo cliente em conjunto com analistas e testadores
São automatizados
Quando rodarem com sucesso, funcionalidade foi implementada
Devem ser rodados a cada iteração
Roteiro com um conjunto de respostas esperadas
Ótimo feedback para o cliente
Pode se saber, a qualquer momento, o % de implementação do SW e
quanto falta

34. Pequenos Lançamentos (Small Releases)
Disponibiliza a cada iteração SW 100% funcional
Versão disponibilizada imediatamente
Redução de riscos (se o projeto terminar, parte existe e funciona)
Detecção prévia de problemas
Comunicação entre cliente e desenvolvedor
Cada lançamento possui funcionalidades prioritárias para a iteração
Lançamento pode ser destinado a
usuário/cliente (testa, avalia e oferece feedback)
usuário/final (sempre que possível)
Design simples e integração contínua são práticas essenciais

35. Projeto Simples (Simple Design)
Projeto está presente em todas as etapas XP
Projeto começa simples e se mantém assim através de testes e
refinamento de código (refactoring)
Em XP, é levado ao extremo
Não é permitido implementar qualquer funcionalidade adicional que
não será usada na iteração atual
Implementação ideal é aquela que
Passa por todos os testes
Expressa todas as idéias definidas no planejamento
Não contém código duplicado ou que “cheire”
Prever o futuro é impossível e é “anti-XP”

36. Programação em Pares (Pair Programming)
SW é desenvolvido em pares
“2 cabeças juntas são melhores que duas cabeças separadas”
1 piloto e 1 co-piloto
Papéis são alternados freqüentemente
Benefícios
Melhor qualidade de código (refactoring, testes)
Revisão constante do código
Nivelamento da equipe
Maior comunicação
“Um” pelo preço de “Dois”??
Pesquisas demonstram que duplas produzem código de melhor
qualidade em aproximadamente o mesmo tempo que programadores
que trabalham sozinhos

37. Programação em Pares (Pair Programming)
Efeitos sobre a produtividade da equipe
“Um trabalha enquanto o outro não faz nada...”
Pressupõe comunicação contínua
pesquisas mostram atividades desempenhadas na metade do tempo de
desenvolvimento
Produtividade a curto prazo X longo prazo
Pressão do Par
Concentração, incentivo, responsabilidade
Revezamentos
Disseminação do conhecimento
Desafios
Organização do escritório, visão gerencial, relacionamento humano,
competição

38. Desenvolvimento Dirigido por Testes (Test-Driven
Development)
XP valoriza o desenvolvimento dirigido por testes
São automatizados, executados o tempo todo
Testes “puxam” o desenvolvimento
Cada unidade de código só tem valor se o teste funcionar 100%
Testes dão coragem para mudar
De que adianta a OO isolar a interface da implementação se o
desenvolvedor tem medo de mudar a implementação?

39. Desenvolvimento Dirigido por Testes (Test-Driven
Development)
TDD
Obter
tarefa Criar Código de Codificar Fazer
Teste para a tarefa Refactoring
Passou nos testes?
Sim: Nova tarefa Não: Revisar código

40. Refatoração (Refactoring)
Design é melhorado continuamente através de refinamento
Mudança proposital no código que está funcionando
Melhorar sua estrutura interna sem alterar a funcionalidade
Visa simplificar o código, remover o código duplicado
Principal referência é o catálogo de refactorings de Martin Fowler
Existência prévia de testes é fundamental para utilização desta
prática (elimina o medo dos desenvolvedores de adotar a mudança)
“Software é como a nossa casa”
Organizados X desorganizados
XP enfatiza código de alta qualidade

41. Integração Contínua (Continuous Integration)
XP mantém o SW integrado o tempo todo
Realizada pelo menos uma vez por dia
Para integrar, deve-se realizar os testes primeiro
“Reduz o tempo passado no inferno da integração” - Martin Fowler
Benefícios
Expõe o estado atual de desenvolvimento
Oferece feedback
Estimula agilidade e versões freqüentes do SW

42. Posse Coletiva (Collective Ownership)
O código tem um único dono: a equipe
Qualquer par de programadores pode melhorar o código
Revisão constante do código
Aumenta a comunicação
Aumenta a qualidade (menos duplicação, maior coesão) e diminui os
riscos de dependência de indivíduos
Todos compartilham a responsabilidade pelas alterações
Ideal que se troque os pares periodicamente
“Todos conhecem tudo”
Testes e integração contínua são essenciais e dão segurança

43. Padrões de Codificação (Coding Standards)
Os padrões de codificação são definidos pela equipe
Organização de código
Nomenclaturas
Código com aspecto de escrito por um único desenvolvedor
Competência
Organização
Práticas e valores favorecidos
Posse coletiva
Comunicação
Programação em Pares
Refactoring
Projeto Simples

44. Metáfora (Metaphor)
Equipes XP mantém uma visão compartilhada do sistema
Analogia com outros sistemas (natural, computacional, abstrato)
Exercício de criatividade e abstração
Ótima fonte de comunicação entre a equipe, facilitando inclusive as
estimativas
Pattern de alto nível

45. Ritmo Saudável (Sustainable Pace)
XP está na arena para ganhar
Projetos vampiros não são projetos XP
Semanas de 80 horas
Código ruim, relaxamento da disciplina, stress da equipe
Tempo ganho será perdido depois
São aceitáveis eventuais horas extras quando a produtividade é
maximizada

46. Reuniões em Pé (StandUp Mettings)
A maioria dos desenvolvedores odeiam reuniões
Assuntos demorados e desgastantes
Impedem os desenvolvedores de codificar
As reuniões são valiosas quando
Não perdem o foco
São breves
São abordadas tarefas realizadas e a realizar

47. Spikes de Planejamento (Spike Solution)
São investigações de tecnologias que podem ser utilizadas no
projeto
Auxiliam nas estimativas e na especificação do projeto
Podem durar horas ou dias, porém devem ser curtos
Englobam
Avaliações de arquiteturas
Algoritmos
componentes e frameworks
BDs
Servidores de aplicação, Web
Utilização de artefatos e ferramentas

48. Ambiente de Trabalho
O ambiente deve apoiar a aplicação das práticas
Tem importância vital para um projeto de software
Trabalhar próximo dos colegas
Facilitar a comunicação
Equipamentos
Mesas e cadeiras
Equipamentos tecnológicos
Telefones
Mural
Quadro Branco
Calendário
Comida ☺
Isolamento (equipes e projetos)

49. Documentação Ágil
Complexidade do Software
Tempo de desenvolvimento
Equipes
Futuras manutenções
Até que ponto documentar?
Uso incorreto da documentação
Quando documentar?
Documentos que compõem a documentação
User stories, testes de aceitação, testes de unidade, documentação de
código fonte, Modelo de Classes, Modelo de Dados, Processos de
Negócio, Manual de usuário, Acompanhamento diário,
Acompanhamento do Projeto

50. Ferramentas de Apoio
Mais em http://xprogramming.com/software.htm

51. IDEs

52. IDEs

53. Teste de Unidade

54. Teste de Unidade

55. Teste de Unidade

56. Testes Funcionais

57. Patterns, Boas Práticas, Refactoring

58. Patterns, Boas Práticas, Refactoring

59. Code Coverage

60. Code Coverage

61. Code Coverage

62. Code Coverage

63. Code Coverage

64. Code Coverage

65. Documentação

66. Integração Contínua

67. Integração Contínua

68. Padrões de Codificação

69. Padrões de Codificação

70. Mercado
HP Objective Solutions
Ford ImproveIt
Symantec Brasil Telecom
Motorola Embrapa
Chrysler Qualiti
BMW Trevisan Tecnologia
Borland Argonavis
IBM CETIP
First National Bank Secretaria da Fazenda SP
Thought Works Smart Tech Consulting
CC Pace Systems iQualy
Industrial Logic IME-USP
Moore EverSystems
Workshare PowerLogic Consultoria
Xerox UFRJ
Siemens PUC-Rio
Object Mentor Surya Tecnologia

71. Principais Eventos

72. Adotando e Escalando XP
Adote as práticas em doses homeopáticas
Não seja afobado, saboreie a mudança
Enfatize o problema mais importante
Dificuldades culturais
Deixar alguém mexer no seu código
Pedir ajuda
Ânsia de tentar prever o futuro
Escrever testes antes de codificar
Refatorar com freqüência (superar o medo)
Situações difíceis de aplicar XP
Equipes grandes e distribuídas geograficamente
Perda do controle sobre código
Feedback demorado

73. Adotando e Escalando XP
XP e os processos ágeis valorizam as pessoas
Bons desenvolvedores criam bons SWs
Processos ágeis são suplementos aos outros métodos
São atitudes
São efetivos
Não é um ataque à documentação e sim a criação de documentos que
tem valor
Não são para todos
O segredo está na sinergia de suas práticas
Menos formalidade, mais diversão

74. Considerações Finais
XP é uma disciplina de desenvolvimento ágil de SW baseada em
comunicação, feedback, simplicidade e coragem
Para usar XP é preciso fazer com que a equipe se una em torno de
práticas simples, obtendo feedback e reajustando estas práticas para
cada situação particular
XP pode ser implementada aos poucos, porém, a maior parte das
práticas são essenciais
Nem todos os projetos são bons candidatos para XP.
XP não é para todo mundo, mas todo mundo pode aprender com XP
Adotar Processos Ágeis não é simplesmente aplicá-lo
É preciso entender sua filosofia

75. Combinando Lean + SCRUM + XP

76. Combinando Lean + SCRUM + XP

77. Formação em Metodologias Ágeis
Introdução ao Lean – Promovendo a Mudança Cultural (8h)
Projetos Ágeis com SCRUM – Gestão e Acompanhamento (20h)
Técnicas para gerar Código de Qualidade com eXtreme Programming
(12h)
Cursos In Company e Consultorias

78. Apoio