Extreme Programming

1. Extreme Programming Régis Simão e Ciro Coelho

2. Agenda • Introdução • Valores • Ciclo de Vida • Práticas • Documentação • Equipe • Quando não usar XP • Como implantar • Bibliografia

3. Introdução • Livros

4. Introdução • Livros – The XP Series

5. Introdução • Outras Referências • Site: • www.improveit.com.br/xp • Grupos: • http://tech.groups.yahoo.com/group/xprio • http://br.groups.yahoo.com/group/xprecife • http://tech.groups.yahoo.com/group/xp-rs • http://br.groups.yahoo.com/group/xpnorte • http://tech.groups.yahoo.com/group/xpsc • http://tech.groups.yahoo.com/group/xpbh • http://tech.groups.yahoo.com/group/xpsp

6. Introdução • Extreme Programming (XP) é um processo de desenvolvimento de software voltado para: • Projetos cujos requisitos são vagos e mudam com freqüência; • Desenvolvimento de sistemas orientados a objetos; • Equipes pequenas, preferencialmente até 12 desenvolvedores; • Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. Fonte: Livro Extreme Programming. Autor Vinícius Manhães Teles

7. Valores • Feedback • Comunicação • Simplicidade • Coragem

8. Valores • Feedback • Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, gerando feedback para a equipe de desenvolvimento. • É o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente. • Garante que a equipe direcione as suas atenções para aquilo que irá gerar mais valor.

9. Valores • Comunicação • O XP busca aproximar todos os envolvidos do projeto • Permite que o cliente compartilhe o seu aprendizado com a equipe • Promover a comunicação face-a-face ou da forma mais rica que for viável. • A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem.

10. Valores • Feedback e Comunicação

11. Valores • Simplicidade • Temos que implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. • Ao codificar, deve-se preocupar apenas com os problemas de hoje. • Deve-se deixar os problemas do futuro para o futuro. • As generalizações devem ser feitas quando elas vierem na forma de uma necessidade específica e não como uma especulação.

12. Valores • Coragem • “A equipe precisa ser corajosa e acreditar que, utilizando as práticas e valores do XP, será capaz de fazer o software evoluir com segurança e agilidade.” • “Em muitos casos, a equipe alterará algo que vinha funcionando corretamente, o que leva ao risco de gerar falhas no sistema.” TELES, Vinícius M. Extreme Programming. Novatec Editora, 2006

13. Ciclo de Vida • Desenvolvimento Tradicional • Desenvolvimento Ágil • Ciclo Semanal

14. Definição de Requisitos Projeto de Software Implementação e teste de unidade Integração e teste de sistema Operação e Manutenção Ciclo de Vida • Desenvolvimento Tradicional • Ciclo de Vida em Cascata • Forte influência da Revolução Industrial • Software construído linearmente, seguindo uma seqüência de fases

15. Ciclo de Vida • Desenvolvimento Tradicional • Ciclo de Vida em Cascata • Base de vários processos de software • Interpretação errada do ciclo de vida do Rational Unified Process (RUP)

16. Ciclo de Vida • Desenvolvimento Tradicional • Características do Ciclo de Vida em Cascata • Linearidade • Determinístico • Especialização • Foco na execução

17. Ciclo de Vida • Desenvolvimento Ágil • Categorias de Trabalhadores (Drucker, 1999. In: Teles, 2006) • Trabalhador Manual • Habilidades Manuais • Fácil de Automatizar • Determinístico • Repetitivo • Trabalhador do Conhecimento • Uso intensivo de conhecimento e criatividade • O XP vê o desenvolvimento de software como um processo de uso intensivo de conhecimento e criatividade

18. Atribuir requisitos aos incrementos Projetar arquitetura do sistema Definir esboço dos requisitos Desenvolver incremento do sistema Validar incremento Integrar incremento Validar sistema Sistema final Sistema incompleto Ciclo de Vida • Desenvolvimento Ágil • Ciclo de Vida Incremental

19. Ciclo de Vida • Desenvolvimento Ágil • Ciclo de Vida em Espiral

20. Ciclo de Vida • Desenvolvimento Ágil Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

21. Ciclo de Vida • Ciclo Semanal Validação parcial com o cliente Definição com o cliente Teste Avaliação pelo cliente Desenvolvimento Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

22. Ciclo de Vida • Ciclo Semanal • Feedback e Aprendizagem Fonte: Palestra Extreme Programming, abraçando a mudança. Autor Helder da Rocha

23. Práticas

24. Práticas • Jogo do Planejamento • É uma reunião onde o cliente avalia as funcionalidades que devem ser implementadas e prioriza aquelas que farão parte do próximo release ou da próxima iteração. • Visa assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente a cada dia de trabalho. • O projeto é dividido em Releases e Iterações. • Cliente e a equipe podem revisar o planejamento constatemente. • As funcionalidades são descritas em pequenos cartões e são chamadas de Estórias.

25. Práticas • Jogo do Planejamento • Exemplos de Estórias (Teles, 2006): Apresente ao cliente as dez tarifas mais baratas para uma determinada rota (Beck, 2001). Para cada conta, computar o saldo fazendo a adição de todos os depósitos e a subtração de todas as deduções (Jeffries, 2001). Produzir um extrato para cada conta, mostrando a data, o número, o beneficiário e a quantia da transação. Segue um extrato de exemplo em anexo – faça o relatório parecer com o exemplo (Jeffries, 2001). A tela de login deve permitir que o usuário pule o login. Neste caso, o usuário entrará no sistema como guest (Newkirk, 2001). O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, último nome e filiação). Dois campos de senha para confirmação (Newkirk, 2001).

26. Práticas • Jogo do Planejamento • Estórias • São sempre escritas pelo próprio cliente. • Criam um vínculo com o cliente. • Formalizam o pensamento do cliente. • Não têm formato de escrita. • Devem ser limitadas pelo tamanho do cartão, simplicidade. • Podem ser dividas em tarefas, quando muito complexas. • Dão a noção de custo. • Cada desenvolvedor seleciona uma estória ou tarefa a ser feita em um determinado prazo.

27. Práticas • Jogo do Planejamento • Estimativas • Estimativa baseada no conceito de Dia Ideal de Desenvolvimento (só para implementação). • Estima-se cada estória com a unidade Ponto (dia ideal de desenvolvimento). • No canto superior esquerdo do cartão, colocam-se os pontos estimados. • No canto superior direito do cartão, ficam os pontos realmente consumidos. • A estimativa deve ser por comparação. • A estimativa deve ser feita em equipe. • O cliente deve sempre participar. • Velocidade é a quantidade de pontos que uma equipe implementou na iteração anterior.

28. Práticas • Jogo do Planejamento • Exemplo de Planejamento de uma Iteração de 2 semanas: • 2 semanas = 10 dias úteis • 1 dia útil para a reunião de planejamento da iteração • 1 dia útil para a reunião de encerramento da iteração • Dias úteis disponíveis para o desenvolvimento = 10 – 2 = 8 • Números de desenvolvedores = 6 = 3 x 2 = 3 pares • 1 par / dia = 1 ponto • 1 par em 8 dias = 1 x 8 = 8 pontos • 3 pares em 8 dias = 3 x 8 = 24 pontos

29. Práticas • Jogo do Planejamento • Acompanhamento Visual Não iniciado Em andamento Finalizado Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

30. Práticas • Cliente Presente • O cliente deve estar presente durante o desenvolvimento. • Presente em: • Reuniões de Planejamento das Releases e das Iterações • Reuniões de Encerramento das Releases e das Iterações • Alguns momentos do desenvolvimento para tirar dúvidas e validar algumas informações. • O cliente deve conduzir o desenvolvimento a partir do feedback que recebe do sistema. • A presença do cliente simplifica a comunicação.

31. Práticas • Stand Up Meeting • Reunião rápida que a equipe de desenvolvimento faz a cada manhã para avaliar o trabalho do dia anterior e priorizar aquilo que será implementado no dia. • Três perguntas devem ser respondidas por cada desenvolvedor: • O que foi feito no dia anterior? • O que vai ser feito hoje? • Tem algo atrapalhando ou necessário para o trabalho a ser realizado? • Os problemas relatados devem ser tratados fora da reunião!

32. Práticas • Desenvolvimento Guiado pelos Testes • Os desenvolvedores escrevem testes para cada funcionalidade antes de implementá-las. • Benefícios: • melhoram o entendimento sobre as necessidades do cliente, • projetam melhor as interfaces externas dos métodos e classes e • limitam até onde codificar cada funcionalidades. • Tipos de Testes: • Testes de Unidade sobre cada classe, criado e executado pelo Desenvolvedor • Testes de Aceitação sobre funcionalidade ou estórias, escrito pelo cliente e pelo Analista de Testes, executado principalmente pelo cliente

33. Práticas • Desenvolvimento Guiado pelos Testes • Exemplo de um Teste de Unidade Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).

34. Práticas • Desenvolvimento Guiado pelos Testes • Exemplo de um Teste de Unidade Fonte: Desenvolvimento Orientado a Testes (www.improveit.com.br).

35. Práticas • Desenvolvimento Guiado pelos Testes • Exemplo de um Teste de Aceitação Fonte: Livro Extreme Programming, Autor: Vinícius Manhães Teles

36. Práticas • Programação em Pares • A implementação é sempre feita por duas pessoas. • Enquanto uma pessoa implementa, a outra avalia o código que está sendo feito, realizando uma revisão constante. • A cada 15 minutos, a pessoa que está implementado passa a fazer a avaliação e a outra implementa. • A cada turno as duplas trocam.

37. Práticas • Programação em Pares • Benefícios: • Aumenta a produtividade • Melhora a solução • Dissemina conhecimento de negócio • Nivela habilidades • Desafios: • Organização do escritório • Visão gerencial • Relacionamento humano • Competição

38. Práticas • Refactoring • O refactoring é a técnica de alterar o código sem alterar a funcionalidade. • O objetivo é fazer o código ficar mais simples de ser manipulado. • Anda de mãos dadas com o código coletivo e testes de unidades. • Existem livros específicos sobre técnicas de refactoring.

39. Práticas • Código Coletivo • Procura evitar “ilhas de conhecimento”. • Quando só uma pessoa conhece uma solução, pode ser um gargalho no desenvolvimento. • Com a programação em pares, os desenvolvedores passam a ser conhecedores de todas as funcionalidades. • Eles têm acesso a todas as funcionalidades, podendo alterá-las sem necessitar de autorização, inclusive fazendo refactoring.

40. Práticas • Código Padronizado • A equipe deve estabelecer padrões de implementação que devem ser seguidos por todos. • Isto agiliza as manutenções e torna o código mais homogêneo. • Exemplo: • Code Conventions for the Java Programming Language da SUN • Writting Robust Java Code de Scott Ambler • Características de um padrão: • Indentação • Letras maiúsculas e minúsculas • Comentários • Nome

41. Práticas • Código Padronizado • Quando alguém encontra algo fora do padrão deve-se: • Alertar a equipe o que está fora do padrão e forma correta de fazer. • Fazer refactoring do código, colocando-o no padrão. • Dificuldades • Ter um padrão. Se não tiver, utilize um pronto! • Mudança de hábito.

42. Práticas • Design Simples • Para ser ágil, a equipe deve optar por um código que seja suficiente para atender as necessidades atuais do cliente. • Necessidades futuras serão atendidas quando elas forem requisitadas, fazendo-se uso do refactoring e testes, por exemplo. • A única coisa constante em um projeto de software é a mudança (Beck, 2000. In: Teles, 2006): • Os requisitos mudam • O design muda • A tecnologia muda • A equipe muda • Os membros da equipe mudam

43. Práticas • Design Simples • Estratégia do XP para um código simples (Teles, 2006): • Comece escrevendo um teste para funcionalidade a ser desenvolvida. • Faça o design e implemente apenas o suficiente para passar nos testes. • Repita os passos 1 e 2 quantas vezes forem necessárias. • Se você identificar a oportunidade de tornar o design mais simples, faça-o.

44. Práticas • Design Simples • Ferramentas: • Utilize as ferramentas mais simples. • Se desejar gerar documentações e diagramas, lembre que tem que mantê-las atualizadas. • A documentação sempre tem que refletir o código, senão não serve pra nada! • Documente as decisões importantes.

45. Práticas • Ritmo Sustentável • Os desenvolvedores devem trabalhar apenas 8 horas por dia. • As horas-extras devem ser evitadas. • Isto para permitir que os desenvolvedores se mantenham atentos, criativos e dispostos a solucionar os problemas. • Sugestão: • 08:00 às 08:30  Ler e-mails • 08:30 às 09:00  Stand Up Meeting • 09:00 às 12:00  Programação em Pares • 14:00 às 17:00  Programação em Pares • 17:00 às 17:30  Ler e-mails • 17:30 às 18:00  Estudo para refactoring

46. Práticas • Integração Contínua • Consiste da equipe integrarem seus códigos com o restante do sistema várias vezes ao dia. • Para garantir que o sistema esteja funcionando corretamente após uma integração, é necessário realizar todos os testes (testes de regressão). • Código avança através de três fases: • local, • candidato à liberação e • disponibilizado no repositório • Utilize uma máquina em separado para a integração: backup e “ritual”.

47. Práticas • Integração Contínua • Ferramentas: • Ferramenta de build • Sistema de controle de versão • O processo de integração é feito corretamente quando: • Deve ser fácil e rápido obter o código fonte do qual você necessita; • Deve ser fácil e rápido armazenar as suas mudanças; • O repositório deve detectar conflitos e é importante que seja simples resolvê-los; • Não deve haver espera, isto é, se um par precisa editar alguma coisa, ele deve seguir adiante sem que nada o impeça.

48. Práticas • Releases Curtos • A equipe deve produzir um conjunto pequeno de funcionalidades (release) • Colocar a release em produção rapidamente para que o cliente possa fazer uso das funcionalidades o mais cedo possível. • Durante o projeto, a equipe colocará diversas versões do sistema em produção, gerando um fluxo contínuo de valor para o cliente. • Aumenta Feedback • Aumenta o Retorno do Investimento

49. Práticas • Releases Curtos Fonte: Workshop Desenvolvimento Ágil. Autor Vinícius Manhães Teles

50. Práticas • Metáfora • A equipe de desenvolvimento transmite idéias complexas de forma simples através de metáforas. • A metáfora do time de futebol para entender a utilização das práticas de futebol