SETIC Scrum & XP

4,285 views
4,145 views

Published on

Agilidade com Scrum e XP apresentado no SETIC 2010 do IFSC

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,285
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

SETIC Scrum & XP

  1. 1. Agilidade com Scrum e eXtreme Programming Luiz Fernando Ramos Costa Coordenadoria de Serviços e Sistemas de Rede DTIC – IF-SC – (48) 3877-9051 luiz.costa@ifsc.edu.br www.fernandocosta.com.br www.twitter.com/fernandocosta
  2. 2. Facilitador  Scrum  eXtreme Programming Agenda Fernando Costa Formado em Redes de Computadores Pós-graduando em Eng. de Software Certificado LPIC-1, NCLA, DCTS Orientador do SENAC TI Analista de TI na Reitoria do IFSC
  3. 3. Paradoxo de Cobb We know why projects fail, we know how to prevent their failure – so why do they still fail? Martin Cobb Treasury Board of Canada Secretariat Nós sabemos porque os projetos falham, sabemos como previnir – Porque eles continuam falhando?
  4. 4. Reflexão do Caranguejo  Todos os caranguejos ficam amarrados a um barbante que fica solto.  Não é preciso amarrar pois todos querem fugir mas cada um que ir para um lado diferente.  Ficam no mesmo lugar
  5. 5. Valores do Manifesto Ágil Processos e ferramentas Indivíduos e interações ao invés de Seguir um plano Resposta à mudanças www.agilemanifesto.org Documentação abrangente Software que funciona Negociação de contrato Colaboração do cliente
  6. 6. Princípios do Manifesto Ágil 1 - O principal compromisso é com a satisfação do cliente, por meio da entrega mais rápida e contínua de produto com valor 2 - Receba bem as mudanças de requisitos(mesmo em estágios tardios do projeto). Processos ágeis devem admitir mudanças que trazem vantagens competitivas ao cliente 3 - Libere produto frequentemente (de 2 a 4 semanas), dando preferência para uma escala de tempo curta
  7. 7. Princípios do Manifesto Ágil 4 - Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhandos juntos a maior parte do tempo do projeto 5 - Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado 6 - O método mais eficiente e efetivo para repassar a informação entre a equipe é pela comunicação face a face
  8. 8. Princípios do Manifesto Ágil 7 - Produto funcionando é a principal medida de progresso de um projeto 8 - Processos ágeis promovem o desenvolvimento sustentado. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente 9 - Atenção contínua para excelência técnica e bom projeto (planejamento) aprimoram a agilidade
  9. 9. Princípios do Manifesto Ágil 10 - Simplicidade é essencial e deve ser assumida em todos os aspectos do projeto 11 - As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas 12 - Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento
  10. 10. SCRUM Ken Schwaber @kschwaber
  11. 11. Em resumo... Imagem disponível em: www.mountangoatsoftware.com/scrum
  12. 12. Cliente (ou Product Owner)  Quem é o nosso cliente?  Funcionalidades do produto  Decide as datas e conteúdo  Rentabilidade (ROI)  Ajusta e prioriza funcionalidades e prioridades  Aceita o rejeita resultados
  13. 13. Scrum Master  Remove obstáculos  Não tem autoridade  Produtividade da equipe  Conduz eventos  Escudo da equipe
  14. 14. Equipe (ou team)  5 a 9 pessoas  Multi-funcional  Auto-organizável  Sugere funcionalidades do produto
  15. 15. Product Backlog  Lista de funcionalidades desejadas no projeto  Os itens que compõe a lista são chamados de histórias ou itens de backlog  Todos podem incluir histórias  Somente o Product Owner pode priorizá-las  Product Owner pode priorizar novamente no início de cada Sprint
  16. 16. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de produtos 2 Carrinho de compras 3 Cadastro do cliente 4 Boleto bancário 5 Cartão de crédito
  17. 17. Planning Poker  Vamos estimar os itens de Backlog? Quem?  Product Owner  Scrum Master  Equipe
  18. 18. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de produtos 3 2 Carrinho de compras 5 3 Cadastro do cliente 2 4 Boleto bancário 4 BB e CEF (sem usar pagseguro) 5 Cartão de crédito 3 Visa e MasterCard
  19. 19. Importância Qual a importância dos itens de backlog para o Product Owner?
  20. 20. Must (tem que ter) Should (deveria ter) Could (poderia ter) Want (interessante) Catálogo de produtos Boleto bancário Vídeo dos produtos Cadastro de clientes Controle de estoque Cartão de crédito Fotos dos produtos Registro do pedido e entrega Carrinho de compras Regras de promoções
  21. 21. Must (tem que ter) Should (deveria ter) Could (poderia ter) Want (interessante) Catálogo de produtos Boleto bancário Vídeo dos produtos Cadastro de clientes Controle de estoque Cartão de crédito Fotos dos produtos Registro do pedido e entrega Carrinho de compras Regras de promoções
  22. 22. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de produtos 1 3 2 Carrinho de compras 1 5 3 Cadastro do cliente 1 2 4 Boleto bancário 2 4 BB e CEF (sem usar pagseguro) 5 Cartão de crédito 3 3 Visa e MasterCard
  23. 23. Sprint  Deve ter um objetivo  Período de 2 a 4 semanas  Nenhuma mudança no sprint  Processo baseado em uma série de iterações  Produto é desenvolvido no sprint
  24. 24. Product Burnup Chart
  25. 25. Planejamento da Sprint  Cliente, ScrumMaster e Equipe  Cliente seleciona itens do Product backlog  O Sprint backlog  Tarefas identificadas e estimadas (1 a 16 horas)  De forma colaborativa (por todos)  Equipe compromete-se a concluir as tarefas
  26. 26. Planejamento da Sprint ID – 1 Catálogo de produtos ID – 1.1 Administrador de produtos 1 hr ID – 1.3 Front-end da loja 3 hr ID – 1.2 Busca fonética 1 hr
  27. 27. Scrum diário  Tempo de 15 minutos  Todos em pé  Não é para a solução de problemas − Todos são convidados − Apenas a Equipe, ScrumMaster e Product Owner podem falar  Sincronização do conhecimento  Atualização do burnup chart 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?
  28. 28. Gerenciando o Sprint Backlog  Cada membro da equipe escolhe a tarefa que fará  Trabalhos nunca são atribuídos  Atualização diária da estimativa do trabalho restante  Equipe pode adicionar, apagar ou mudar tarefas (não itens de backlog)
  29. 29. Scrum board
  30. 30. Revisão da Sprint  Informal  Todos participam  Hora do feedback  Resultados do Sprint Comunicação eficaz: (bala / bombom)
  31. 31. Retrospectiva da Sprint  Feita após cada Sprint  Periodicamente observe pontos positivos e negativos  Tipicamente de 15 a 30 minutos  Todos participam
  32. 32. Inicia, Pára, Continua  A equipe discute o que gostaria de: Iniciar a fazerIniciar a fazer Parar de fazerParar de fazer Continuar fazendoContinuar fazendo Esta é uma das várias maneiras de se conduzir uma retrospectiva do Sprint
  33. 33. Agora vocês explicam! :)
  34. 34. eXtreme Programming Kent Beck @kentbeck
  35. 35. Você está fazendo assim? Comunicação
  36. 36. Fazer software é dureza
  37. 37. Boa notícia Cases de sucesso:  Google  Microsoft  Philips  FAB (BR)  Oi Paggo
  38. 38. Má notícia • Seus colegas não vão acreditar • O seu chefe não vai aceitar • O chefe do seu chefe não pode nem pensar
  39. 39. Não é assim que se faz software Falhas: a) Não entregam o acordado b) Estouram o orçamento c) Estouram o prazo d) Todas alternativas
  40. 40. Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group
  41. 41. 64% de desperdício  Podem gerar algumas horas extras para a equipe  Cliente paga por lixo
  42. 42. Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group
  43. 43. 20% muito útil  Geram pelo menos 80% do valor do produto  20%? desconhecido no início do projeto “XP é a arte de maximizar a quantidade de software que você não vai fazer “
  44. 44. Análise Pai(cliente): 1 dia de projeto Mãe(desenv.): 9 meses de projeto
  45. 45. Análise Cliente: “Não era nada disso que eu queria...”
  46. 46. Mentalidade
  47. 47. Cascata
  48. 48. Custo da mudança por Barry Bohem
  49. 49. Problemas e mudanças Patente do VELCRO: em 1941 por Georges de Mestral
  50. 50. Meio digital  Fluidez  Maleabilidade  Invisibilidade  Complexibilidade (elementos distintos)  Baixo custo de manufatura  Rapidez evolução
  51. 51. Nova mentalidade • Chef • Escritor
  52. 52. eXtreme Programming
  53. 53. Valores do XP RespeitoRespeito C om u nicação C om u nicação Feed b ack Feed b ack C orag em C orag em S im plicid ad e S im plicid ad e
  54. 54. Valores do XP  Simplicidade Faça sempre da maneira mais simples e que vá funcionar  Comunicação Dentro do time, entre o cliente e a equipe...  Feedback Testes de aceitação, presença do cliente  Coragem Para fazer refactoring, para jogar fora o código e refazer tudo no dia seguinte  Respeito Trabalho em equipe
  55. 55. Uma pergunta “Como você programaria se tivesse tempo suficiente?” Kent Beck
  56. 56. Possíveis respostas  Mais testes?  Mais projeto e arquitetura?  Menos pessoas?  Mais qualidade?
  57. 57. Programando ao extremo Testar toda hora!! Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! Integrar a maior quantidade de vezes possível! Iterações realmente curtas!
  58. 58. Práticas do XP Testes de Aceitação Releases Curtas Planning Game Cliente Presente Integração Contínua Passo Sustentável Metáfora Posse Coletiva Coding Standard Design Simples Refactoring Programação em pares Test-Driven Development Adaptado de xprogramming.com
  59. 59. Cliente presente e envolvido • Responsabilidade do projeto: – Equipe – Cliente • Comprometimento
  60. 60. Jogo do planejamento • Reunião semanal onde todos participam • Escopo reavaliado • Cliente prioriza e seleciona as histórias que serão desenvolvidas • Ao fim da semana o cliente recebe produto funcionando
  61. 61. Reunião em pé • 10/15 minutos • Todos em pé • Não é para a solução de problemas − Todo mundo é convidado − Apenas a Equipe pode falar • Sincronização do conhecimento 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?
  62. 62. Ritmo sustentável • Semana de 40 horas (8hr/dia) Sem hora extra: • Baixa produtividade • Código de má qualidade • Aumento de BUGs
  63. 63. Programação em par • Forneça suporte e ferramentas • Experimente, você vai se surpreender • Alterne os pares para não ficar cansativo e nivelar o time • Respeite a individualidade das pessoas
  64. 64. Código padronizado
  65. 65. Código Coletivo • Inibe ilhas de conhecimento • Padrão de codificação • Membro da equipe pode ter férias • Direito de ficar doente
  66. 66. Integração contínua • Divergências aparecem antes de virar um problema • “Isso funcionava na minha máquina”
  67. 67. Projeto simples • Faça o essencial • Tudo pode mudar
  68. 68. Refatoração • “Time que está ganhando não se mexe” – FALSO • Ex.: Empresas estáveis quebram se não mudarem • Melhoria contínua
  69. 69. Desenv. Orientado por testes TDD • Início é um pouco demorado • Primeiro o teste, depois a funcionalidade para passar no teste • Testes automatizados: Unitários, Interface e Aceitação • RETORNO: Salvação no FIM do projeto
  70. 70. Releases curtos
  71. 71. Equipe nivelada
  72. 72. Papéis Tracker Programador Goal Donnor Gold Owner Coach Manager Analista de Testes
  73. 73. Dúvidas? Luiz Fernando Ramos Costa Coordenadoria de Serviços e Sistemas de Rede DTIC – IF-SC – (48) 3877-9051 luiz.costa@ifsc.edu.br www.fernandocosta.com.br www.twitter.com/fernandocosta Agradecimento: Vinícius Manhães Teles Improve It www.innovit.com.br

×