Extreme programming

906 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
906
No SlideShare
0
A partir de incorporações
0
Número de incorporações
12
Ações
Compartilhamentos
0
Downloads
19
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Extreme programming

  1. 1. Conhecendo  XP   e  Lean Entenda o que a Toyota, os processos e as pessoas tem haver com o desenvolvimento de software
  2. 2. De onde vem isso?•  DeMarco, Tom; Lister, Tim. Peopleware: Productive Projects and Teams. Dorset House Publishing.•  Poppendieck, Tom & Mary. Lean Software Development: An Agile Toolkit. Addison-Wesley.•  DeMarco, Tom. Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency. Broadway.
  3. 3. De onde vem isso?•  Poppendieck, Tom & Mary. Implementing Lean Software Development: From concept to cash. Addison-Wesley.•  Cockburn, Alistair. Agile Software Development: The Cooperative Game. Addison-Wesley Professional.
  4. 4. De  onde  vem  isso? •  Material de aula do Certified Scrum Trainer Michel Goldenberg;•  Schwaber, Ken; Beedle, Mike. Agile Software Development with Scrum. Prentice Hall.•  Schwaber, Ken. Agile Project Management with Scrum. Microsoft Press.
  5. 5. Os dois tipos de processo•  Processos definidos•  Processos empíricos
  6. 6. Processos definidos•  Dado um conjunto de entradas bem definidas, a mesma saída é gerada sempre;•  Tudo é repetível;•  Trabalhos são associados um ao outro na forma de uma corrente;
  7. 7. Processos empíricos•  Entradas e saídas não são previsíveis;•  Inspeção e controle de direcionamento contínuos e em prazos cursos para avaliar os resultados;•  Ajustes imediatos para todo e qualquer problema que surgisse;
  8. 8. Usar processos definidos em casos empíricos causa:•  Surpresas desagradáveis;•  Perda de controle do processo;•  Produtos incompletos ou completamente errados;
  9. 9. Eu  não  posso  ter  pessoas   E  processos? •  Se você valoriza as pessoas, os processos tornam-se menos importantes, eles tornam-se mais maleáveis, eles não pertencem aos chefes, mas as pessoas;
  10. 10. Eu  não  posso  ter  pessoas   E  processos? •  Se você valoriza os processos, eles tornam-se mais importantes do que as pessoas que os executam (afinal, o processo já diz como as coisas devem ser), o trabalho das pessoas é apenas executar;
  11. 11. O  que  nós  vemos  no  dia-­‐‑a-­‐‑ dia? Processos normalmente são mais importantes do que as pessoas
  12. 12. Mas  em  alguns  lugares,  as  pessoas  são  mais  importantes   do  que  os  processos
  13. 13. Onde?
  14. 14. Como  tudo  começou? •  Japão, 1940;•  Povo pobre, mercado pequeno;•  Produção em massa era impossível, o mercado não seria capaz de absorver os produtos;
  15. 15. Como  produzir  carros  em   pequenas  quantidades   com  o  custo  de  carros   produzidos  em  massa?
  16. 16. Elimine  o   desperdício! Essa foi a solução encontradapor Taiichi Ohno, pai do Toyota Production System, simples, não?
  17. 17. Simples,  até  ele  dizer  pra  você  o  que  é  desperdício Qualquer coisa que não gere valor para o cliente, é desperdício
  18. 18. Exemplos  de  desperdício   segundo  Ohno •  Estoque;•  Transporte;•  Movimento;•  Espera;•  Produzir algo antes da hora que ele é necessário;•  Serviços extras;•  Defeitos;
  19. 19. Como  funciona  uma   indústria  de  carros  da   velha  guarda? •  Vários departamentos diferentes produzem pilhas de produtos intermediários;•  Estes produtos ficam estocados nas fábricas até que a linha de produção precise deles;
  20. 20. Como  funciona  uma   indústria  de  carros  da   velha  guarda? •  Quando a linha de produção precisa de alguma coisa, vai ao estoque e pega os produtos que são necessários;•  Após reunir as partes, eles começam a produção, se houver alguma falha em alguma das partes e ela só for descoberta agora, tudo o que está no estoque vai pro lixo;
  21. 21. E  como  a  Toyota  faz? •  Só é produzido o que é necessário;•  Não existem diversas equipes para se produzir um carro, apenas uma “célula” cuida de fazer todo o trabalho;•  Se um defeito é encontrado, toda a linha de produção pára até que o defeito seja corrigido;
  22. 22. Onde  entram  as  pessoas? •  Agora não é mais responsabilidade do processo garantir que as coisas funcionem, é das pessoas, pois agora todos controlam a linha de produção e tem o dever de mandar parar tudo se houver algum problema;
  23. 23. Mas  o  que  é  que  isso  tem   haver  com  sofware? •  Você já teve que escrever “componentes” para uso futuro?•  Já escreveu documentos que ninguém leu?•  Já encontrou defeitos que impediam o uso de aplicações em produção?
  24. 24. Mas  o  que  é  que  isso  tem   haver  com  software? •  Já adicionou uma funcionalidade que ninguém havia pedido?•  Já deixou o cliente esperando por uma ferramenta que nunca chega?
  25. 25. Toyota  Product   Developmemt  System  –   Lean  Development A prática do Lean Software development (e dasmetodologias ágeis no geral) tem como base osavanços da gestão industrial capitaneada pelaToyota e outras montadoras do Oriente;
  26. 26. Os  7  tipos  de  desperdício Indústria Software Estoque Trabalho  feito  “pela  metade” Processamento  extra Processos  extras Superprodução Funcionalidades  “extras” Transporte Troca  de  tarefas Movimento Movimento Espera Espera Defeitos Defeitos
  27. 27. Post-­‐‑it’s  de  desperdício •  Pegue 3 post-its (ou mais) e escreva exemplos de desperdício da sua empresa ou que você já tenha visto acontecer;•  Cole eles no quadro na posição que você achar mais correta;
  28. 28. Indústria Software Estoque Trabalho  feito  “pela  metade” Processamento  extra Processos  extras Superprodução Funcionalidades  “extras” Transporte Troca  de  tarefas Movimento Movimento Espera Espera Defeitos Defeitos
  29. 29. Trabalho  feito  “pela   metade” •  Sabe aquele seu framework “caseiro”, ele mesmo;•  Qualquer coisa que você faça que não vai ser utilizado imediatamente;•  No dia que você realmente precisar, será que ele atende as necessidades?
  30. 30. Processos  extras •  Sabe aquele diagrama UML que ninguém olhou? Pois é, ficou obsoleto;•  Já pensou em quem está lendo esses documentos que você anda fazendo? Traças letradas essas viu.•  Cada folha de papel que você usa, é uma árvore a menos no mundo J
  31. 31. Funcionalidades  extras •  “Olha, agora o menu aparece e desaparece!”•  Cada linha de código a mais é uma linha de código que precisa ser testada, compilada e documentada;•  Usuário + Opções = Problema
  32. 32. Troca  de  tarefas •  “Olha, você tem 8 horas hoje, então são 16 bugs para corrigir, um a cada 30 minutos, agora começa que os primeiros 30 minutos já tão contando”;•  Desenvolvimento de software é uma tarefa que se faz com o cérebro, quem trabalha com os dedos é digitador;
  33. 33. Uma  pequena  pausa  para   um  clássico •  Peopleware, DeMarco e Lister;•  Desenvolvedores só produzem de verdade quando eles entram no estado de “flow”;•  Você só entra em “flow” após algum tempo de trabalho concentrado e initerrupto;
  34. 34. Espera •  “Seguinte, já tá quase pronto, mas eu só posso colocar em produção depois que o financeiro liberar a nota e o gerente terminar a planilha de horas”;•  Quanto o seu cliente perde de dinheiro a cada segundo sem utilizar a aplicação?
  35. 35. Movimento •  “Ei, você sabe se os testes passaram?”•  “Náo, vai ali e pergunta pra equipe de testes”•  “O analista já tá com o documento de requisitos?”•  “Não, o arquiteto ainda tá validando ele”
  36. 36. Movimento •  “Como assim eu vou ter que ir pro Amazonas pra poder fazer uma visita ao cliente?”•  “Será que essa p&%%# só atende pelo call center?”
  37. 37. Defeitos •  “Errrrrr... Cê sabe aquela piada do gato que subiu no telhado?”•  “Sei.”•  “Sabe o banco de dados?”•  “Fala.”•  “Ele subiu no telhado.”
  38. 38. Extreme  Programming O que é isso?
  39. 39. O  que  não  é  XP? •  A solução pros seus problemas de software atrasado;•  A solução pro seu problema de equipes com baixa produtividade;•  A solução proseu problema de produtos que não atendem as necessidades do cliente;
  40. 40. O  que  é  XP? •  Um framework de práticas e métodos que fazem com que os problemas sejam detectados cedo o suficiente para que a solução deles seja rápida e indolor (ou nem tanto indolor assim…);
  41. 41. Histórico •  Desenvolvido originalmente por Kent Bech, para um projeto da folha de pagamento da Chrysler em 1996;•  Desenvolvido da necessidade de se colocar ordem no caos no qual o projeto se encontrava;•  Foi a primeira “metodologia ágil” do mercado, mas é influenciada fortemente por outras idéias;
  42. 42. Características  básicas  do   XP •  Ciclos curtos de entrega, normalmente de 2 a 4 semanas;•  Equipes pequenas e multidisciplinares, onde todas as necessidades estão cobertas;•  O cliente faz parte da equipe e é responsável por definir e ajudar a priorizar o trabalho que deve ser feito;
  43. 43. XP é bom pra ajudar...•  Projeto a 4 meses andando sem produzir nada de útil;•  Moral baixa e equipe sem apoio da gerência;•  Produto complexo e de necessidade básica para a empresa;•  O que é que nós podemos fazer?
  44. 44. ... A arte do possível•  Fazer o máximo possível com aquilo que temos na mão hoje;•  Produzir valor para o cliente o mais rápido possível;•  Ser transparente, estar sempre disponível para inspeções e adaptar-se sempre as mudanças do mercado;
  45. 45. Waterfall Análise Design Desenvolvimento Teste Implantação
  46. 46. ÀGILIteração  1 Iteração  2 Iteração  3
  47. 47. Cada  iteração Testes Análise Implantação Design Desenvolvimento
  48. 48. Planos  VS  Valor Waterfall ÁgilO que é fixo Funcionalidades Tempo, CustoO que é estimado Tempo, Custo Funcionalidades
  49. 49. Contratos  de  escopo   aberto •  Contrata-se baseado no tempo e não na funcionalidade;•  Funciona mais próximo de uma consultoria do que de desenvolvimento de software;•  Baseia-se na confiança mútua entre cliente e fornecedor;
  50. 50. XP  é  bom  porque: •  Entrega valor mais rápido e baseado exatamente na necessidade do cliente;•  Ciclos curtos aumentam a flexibilidade e as respostas a mudanças no ambiente externo e interno ao projeto;•  Inspeções frequentes garantem que as funcionalidades implementadas realmente representam funcionalidades necessárias;
  51. 51. Os  princípios  do  XP •  Feeback;•  Sempre assuma a simplicidade;•  Abraçe a mudança;
  52. 52. As  atividades  do  XP •  Codificação;•  Testes;•  Ouvir;•  Design;
  53. 53. Codificação •  É a atividade mais importante e a que deve ser mais protegida;•  Sem código não há produto;•  Também envolve a escolha da melhor implementação pra se resolver um problema;•  Pode ser utilizado pra comunicar e expressar idéias sobre os problemas encontrados;
  54. 54. Testes •  Testes formam um dos pilares do XP junto com o código, não há código escrito sem que hajam testes em XP;•  Os testes servem tanto pra demonstrar o que precisa ser feito como também são os primeiros clientes do código que está sendo produzido;•  O sistema deve conter testes unitários e testes de aceitação;
  55. 55. Ouvir •  Os desenvolvedores devem ouvir e prestar atenção nas necessidades dos clientes;•  A participação direta de todos os envolvidos na hora de discutir uma necessidade faz com que seja mais fácil de acertar na sua implementação no final;•  A proximidade entre cliente e equipe faz com que os resultados gerem mais valor;
  56. 56. Parada  importante  –   Linguagem  ubíqua •  Cliente e equipe de desenvolvimento devem criar um vocabulário próprio pra discutir os objetos do sistema;•  Não devem haver traduções dos conceitos reais do problema para os conceitos que estão sendo aplicados no sistema;•  Os envolvidos devem construir esse vocabulário junto, para que todos possam discutir pensando a mesma coisa;
  57. 57. Design  (ou  arquitetura) •  É o processo de diminuir as dependências entre as partes diferentes do projeto;•  Não é necessário planejar tudo antes de acontecer, mas um pouco de planejamento deve ser feito pra evitar que o sistema tenha dependências demais;•  O apoio dos testes deve ser utilizado ao melhorar o design da aplicação;
  58. 58. Valores  do  XP •  Comunicação•  Simplicidade•  Feedback•  Coragem•  Respeito
  59. 59. Comunicação •  Construir software é transformar as idéias do cliente em uma solução de computador, transmitir essas idéias para a equipe é um ponto chave na produção de software;•  Utilize ténicas especializadas para disseminação do conhecimento entre a equipe, como testes automatizados, programação em par e movendo pessoas para partes dos sistemas que elas não conhecem;
  60. 60. Simplicidade •  YAGNI – You Aint Gonna Need it – Você não vai precisar disso;•  Procure soluções simples, fáceis de serem entendidas e documentadas a soluções complexas para os seus problemas;•  Procure implementar as funcionalidades pensando no HOJE e não em um futuro que ainda não existe;
  61. 61. Feedback  –  é  tudo •  Todo o ciclo de XP é alimentado pelo feedback do cliente e dos testes, tudo é feedback;•  Do sistema: feedback dos testes unitários e testes de aceitação;•  Do cliente: feedback sobre o que e como o programa faz suas coisas e como ele pode melhorar;•  Da equipe: feedback sobre onde melhorar, quais requisitos não técnicos precisam ser melhorados, onde o código precisa de re-trabalho;
  62. 62. Coragem •  Refactorings devem ser constantes e fazer parte do dia a dia da equipe toda;•  Não deve haver medo de se implementar uma solução menos complexa quando ela atinge a necessidade atual;•  Não deve haver medo de remover o que é inútil, não foi utilizado ou não o gerou valor que era esperado;
  63. 63. Respeito •  Para si e para os outros membros da equipe;•  As pessoas devem respeitar o trabalho dos outros ao não escrever código que quebre os testes, que seja fora dos padrões pré-definidos;•  As pessoas devem procurar oferecer o melhor de si para que o seu trabalho também possa ser respeitado e admirado pelos outros membros da equipe;
  64. 64. Quais  os  papéis  no  XP? •  Gerente;•  Cliente;•  Equipe;
  65. 65. Gerente •  Protege a equipe do caos que existe fora da iteração;•  Avalia o progresso da equipe dia a dia, para que seja possível perceber cedo quando problemas estão a caminho;•  Mantém a equipe trabalhando com o máximo de produtividade;•  Remove os impedimentos que possam surgir no caminho da equipe;
  66. 66. Bons gerentes são...•  Líderes;•  Facilitadores;•  Comunicadores;
  67. 67. Cliente •  Define o que o produto deve ter e sua visão geral;•  É responsável por criar as user stories;•  Define a importância de cada estória e se elas entram no sprint ou não;•  Aceita (ou não) o produto desenvolvido pela equipe;•  Não é quem paga, é quem USA o sistema;
  68. 68. Equipe •  De 5 a 9 pessoas, idealmente 6 ou 7;•  Multifuncional;•  Auto-gerenciável;•  Capaz de tomar decisões sozinhos sobre como atingir o objetivo final (entregar valor ao final da iteração);
  69. 69. Equipe •  Responsável por escolher o trabalho que vai ser executado durante a iteração (baseado nas prioridades do cliente);•  Responsável por quebrar as funcionalidades em trabalhos e estimar a sua complexidade;•  Deve continuar seguindo as políticas da empresa, quando elas existirem;
  70. 70. COMUNICAÇÃO
  71. 71. O  que  o  cliente  queria?
  72. 72. O  que  foi  entregue?
  73. 73. Equipes  muito  grandes? •  Equipes com mais do que 8 pessoas devem ser quebradas em equipes menores;•  O sistema deve ser modularizado de forma a diminuir a dependência do trabalho entre as duas equipes;•  A integração entre os trabalhos de ambos deve ser constante (Big Bang Integration NÃO FUNCIONA);
  74. 74. Quem  pode  meter  o   bedelho  na  coisa?
  75. 75. Se você é galinha...•  Você não faz parte do time;•  Você não pode mandar no time;•  Você não pode alterar o caminho do time;•  Quer mandar? Seja porco!
  76. 76. Mãos a obra! Release   Visão Preparação Planning Iteration  Produto Iteração Planning
  77. 77. Começando•  Equipe e cliente se reúnem para:•  Definir a visão do projeto;•  Começar a discutir e preparar as user stories (não é necessário colocar tudo, apenas trabalho suficiente para 1 iteração);•  Criar e estimar user stories;
  78. 78. Exemplo  de  user  stories User Story Priori Estimat ty eComo usuário eu gostaria de criar uma conta H 4Como usuário eu gostaria de enviar um H 8documentoComo usuário eu gostaria de visualizar um H 5documentoComo usuário eu gostaria de buscar H 10documentos pelo texto delesComo usuário eu gostaria de criar pastas para M 3os documentosComo usuário eu gostaria de poder mover um M 3documento para uma pastaComo usuário eu gostaria de taggear um L 4documento
  79. 79. User  stories •  Devem ser escritas seguindo o padrão: o  Como <ator>, eu gostaria de <ação>, para <motivo>;•  Com os seguintes atributos: o  Tamanho relativo (definido em pontos ou dias/horas ideais); o  Prioridade; o  Condições de satisfação;
  80. 80. Exemplo
  81. 81. Tech  Stories •  Quando necessário, a equipe também pode definir estórias para o produto;•  Essas estórias devem entrar na priorização pelo cliente, através de negociação com a equipe;•  Deve ficar claro qual o objetivo da estória e se outras funcionalidades (ou user stories) dependem da implementação dela;
  82. 82. Frente  e  verso
  83. 83. Detalhes  que  surgem •  Quando uma User Story cresce demais, ela deve ser quebrada em casos menores;•  Se conforme as conversas novos casos ou caminhos são descobertos, os dados novos são adicionados a estória;•  Estórias grandes demais sempre podem esconder uma falha na hora de se comunicar com o cliente ou requisitos incertos;
  84. 84. Return  of  Investment
  85. 85. Criando  user  stories ¢ Formem equipes;¢ Escolham um cliente;¢ Escolham um produto a ser definido;¢ Definam de 10 a 12 user stories;¢ Priorizem com o cliente¢ 30 minutos;
  86. 86. Release  planning •  Fase de exploração – cliente define um conjunto de necessidades que ele gostaria de ver implementadas•  Fase de compromisso – equipe avalia e estima uma data de quando esse release pode ser lançado pra produção•  Fase de correção – momento onde equipe e cliente podem ajustar as necessidades
  87. 87. Release  Planning  -­‐‑  2 •  Definição geral do que queremos como produto;•  Definição do tempo/dinheiro disponível para atingir esse objetivo;•  Montagem das primeiras iterações através das user stories que já foram definidas;•  Definição do tamanho (em tempo) das iterações;
  88. 88. Spike  solutions •  Funcionalidades que são incertas demais ou que a equipe ainda não sabe exatamente como implementá-las podem ser prototipadas uma solução “pra jogar fora”;•  Uma spike é uma avaliação feita pra ajudar a estimativa de uma funcionalidade onde ainda não há segurança do seu resultado final;•  Spikes devem sempre ser utilizados quando o problema é desconhecido ou é difícil avaliar o quão difícil é implementar alguma coisa;
  89. 89. Definindo  valores
  90. 90. Colocando  cerâmica  na   casa •  Considerando que colocar cerâmica no banheiro demora 4 horas, quanto tempo demora pra se colocar cerâmica em todos os outros cômodos da casa?
  91. 91. Estimativas •  O tamanho de uma User Story;•  Influenciado por o  O quanto difícil é a Story; o  Qual o tamanho do trabalho.•  Valor relativo;
  92. 92. Estimativas  –   Classificando  risco •  Dados (o quanto sabemos sobre a necessidade) o  Sabemos tudo (0) o  Sabemos alguma coisa (1) o  Não sabemos nada (2)•  Volatilidade (o quanto essa necessidade pode mudar) o  Nada (0) o  Pouco (1) o  Muito (2)•  Complexidade (o quanto difícil é implementar) o  Fácil (0) o  Médio (1) o  Difícil (2)
  93. 93. Reformem  a  cozinha  do   Mike  Cohn •  Reformem a cozinha do Mike Cohn o  Instale um piso novo de madeira o  Pinte os armários o  Instale uma bancada de granito o  Pinte a cozinha inteira o  Substituir o fogão elétrico por um fogão a gás o  Instale uma geladeira nova
  94. 94. Velocidade •  Para poder executar um Release Planning, é necessário ter uma velocidade;•  A velocidade média da equipe pode ser descoberta através de: o  Média das velocidades anteriores; o  Avaliação da velocidade média por 1 ou 2 sprints; o  Chute;
  95. 95. Iteration  planning •  As user stories do release planning são agora transformadas em tarefas e distribuidos entre a equipe;•  Devem ter ser estimados unitariamente, tarefas longas demais devem ser quebradas em tarefas menores;•  Membros da equipe selecionam as tarefas que desejam trabalhar, a quantidade de trabalho deve acompanhar a média entre toda a equipe;
  96. 96. Iteration  Planning •  Definição do que vai ser implementado durante a iteração;•  Definir o objetivo de alto nível da iteração;•  Caminho geral de como o objetivo vai ser atingido (design técnico);•  Selecionar o trabalho que vai ser feito nessa iteração través das user stories;
  97. 97. Na  hora  de   implementar… •  Pegue uma tarefa;•  Selecione um parceiro;•  Escreva o teste;•  Escreva o código que faz o teste passar;•  Execute o teste;•  Refatore o código;•  Execute os testes de aceitação;
  98. 98. PRODUTOENTREGÁVEL Production
  99. 99. E  se  as  coisas  não   estiverem  caminhando? •  Se a equipe sente que não tem condições de entregar o produto;•  Se o mercado mudou abruptamente e isso não havia sido previsto;•  Se algum desastre aconteceu;•  A iteração pode ser cancelado e um novo iteration planning deve ser chamado;
  100. 100. Stand up meeting•  O que você fez ontem?•  O que você vai fazer hoje?•  Há alguma coisa atrapalhando o seu trabalho?
  101. 101. Regras •  Não há discussão, apenas apresentação, discussões são movidas para DEPOIS;•  Apenas os porcos falam, mas galinhas podem assistir;•  Deve ser curto, direto e feito com todos os membros em pé;
  102. 102. Iteration  Review •  Apresentação geral de o que foi produzido pela equipe;•  Idealmente, todos devem ser convidados pra isso;•  Esquema de workshop/feira de ciências normalmente é o melhor para apresentações;
  103. 103. Retrospectiva •  O que funcionou durante o sprint?•  O que não funcionou?•  Podemos melhorar? Onde? Como? A que custo?
  104. 104. Outras  práticas  comuns   do  XP •  Pair Programming;•  Ritmo sustentável;•  Mover as pessoas dentro do projeto;•  O código pertence a todos;•  Existe um padrão definido sobre como o código deve ser escrito;

×