1. Extreme Programming

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çõesmais que processos e ferramentas. Trabalhar no softwaremais que documentação abrangente. Colaboração do clientemais que negociação contratual. Responder às mudançasmais que seguir um plano.

3. O que é XP? • Processo de desenvolvimento de software • Projetos com requisitos muito voláteis • Equipes pequenas (até ~10 pessoas) • Desenvolvimento incremental

4. O que é um projeto de sucesso? • Cumpre o orçamento • Cumpre o prazo • Cliente fica feliz • Equipe fica feliz

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. 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. Custo Tempo de Projeto $ 1 Requisitos $ 10 Análise $ 100 Design $ 1.000 Implem. $ 10.000 Testes Motivação: custo de uma alteração

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. Por que software falha?

10. Problemas desta premissa • Premissa é irreal em vários casos • O cliente não é capaz de especificar o software previamente • Grande problema: DETALHE

11. Premissa do desenvolvimento ágil • APRENDIZADO • FEEDBACK • DESENVOLVIMENTO ITERATIVO

12. Aprendizado • O cliente aprende durante o desenvolvimento • Descobre novas possibilidades • Muda as prioridades

13. Trabalho intelectual • Retrabalho é uma característica do trabalho intelectual • ExperimentaçãoCriaçãoRevisãoExperimentação ...

14. Custo Tempo de Projeto Premissa: custo de uma alteração

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. 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. As 4 Variáveis do Desenvolvimento de Software • Tempo • Custo • Qualidade • Escopo (foco principal de XP)

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

19. User Stories • Funcionalidades são informadas através de user stories • Estórias devem ser simples • Desenvolvedores estimam tempo

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. 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. Release e Iteração Projeto: 8 meses = 32 semanas 8 Sem. R1 R2 R3 R4 2 Sem. I2 I3 I4 I1 1 Sem. S1 S2

23. 8 Sem. R1 R2 R3 R4 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

24. 2 Sem. I2 I3 I4 I1 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

25. Stand-up meeting • Reunião rápida • Diária • Usada para atualização da equipe

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. 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. Test Driven Design • No XP, primeiro se especifica o teste • Depois se constrói a peça

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

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

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. Desenvolvimento em equipe • Como conciliar diversos desenvolvedores? • Estrutura de diretórios • Atualização do código por várias pessoas diferentes

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

39. CVS

40. 40 hour week • Desenvolvimento de software é um trabalho intelectual intenso • Não é produtivo trabalhar além do limite

41. Customer onsite • Fator mais importante no XP: • Comunicação • Feedback • Viabiliza a simplicidade da metodologia • War room c / quadro branco

42. Feedback constante • Permite que pequenas mudanças sejam feitas • Evita a necessidade de mudanças bruscas • Mantém o projeto em curso

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. Ambientes para deployment • Como lidar com diferentes ambientes? • Exemplo: • Desenvolvimento • Aceitação • Produção

45. Produção Aceitação Desenvolvimento Ambientes para deployment

46. Problemas de ter vários ambientes • Possíveis erros devido a tarefas manuais repetitivas • Gasto de tempo

47. Automatização do deployment • Agiliza as integrações • Evita erros

48. Ant

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> tasks target

50. Ambiente de Desenvolvimento • Desejável que tenha: • Code completion • Validação on-line • Suporte à depuração • Suporte a Refactoring • Integração com jUnit • Integração com CVS • Integração com Ant