O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Scrum.pdf

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 81 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

Scrum.pdf

  1. 1. PDS SCRUM Prof. Pedrina Brasil pedrina.brasil@ifrn.edu.br
  2. 2. ● ● O nome SCRUM é derivado do Rugby – É um método de reinício de jogada; – Os jogadores se empurram para pegar a bola; Envolve o trabalho de equipe Introdução 2
  3. 3. ● ● ● Na Engenharia de Software, SCRUM é um framework de processo – Técnicas e métodos variados são aplicados; Não é uma metodologia que fará você desenvolver produtos melhores; Não é uma bala de prata: não te dá respostas rápidas ao desenvolvimento de software; Introdução 3
  4. 4. ● 4 ● Ajudar a construir com qualidade e com melhor retorno de investimento – É um processo gerencial; – Define papéis, artefatos e “cerimônias” (eventos); – Esses elementos podem ser adicionados de acordo com sua necessidade; Pode ser aplicado em qualquer contexto no qual pessoas trabalhem para atingir um objetivo. Introdução
  5. 5. ● 5 ● ● As equipes se auto-organizam para maximizar a comunicação e diminuir a supervisão; O produto evolui em uma série de “sprints”; Os requisitos (funcionalidades) são listados em um “product backlog”; Principais Características
  6. 6. ● 6 ● ● ● Criadores –Jeff Suttherland - jeffsutherland.com –Ken Schwaber - controlchaos.com Um dos primeiros a adotar –Mike Beedle - mikebeedle.com Conferências: OOPSLA 96, PLoP 98 Inspiração – Desenvolvimento Iterativo e Incremental em empresas (DuPont) nos anos 80. Origem do Scrum
  7. 7. Visão Geral 7
  8. 8. Visão Geral 8
  9. 9. ● 9 ● ● É um ciclo: lembre-se do modelo iterativo; Uma Sprint pode durar de duas a quatro semanas – O tempo da Sprint deve ser definido previamente; Durante uma sprint, são realizadas as tarefas priorizadas – Tarefas podem ser quebradas em duas ou mais; – Cada tarefa é atribuída a um membro da equipe ● O colaborador é quem escolhe a tarefa. – Não há mudanças nas tarefas durante o Sprint. Sprint
  10. 10. ● 10 ● ● ● Estórias; Product Backlog; Sprint Backlog; Gráfico Burndown; Artefatos
  11. 11. ● 11 ● ● ● Estórias; Product Backlog; Sprint Backlog; Gráfico Burndown; Artefatos
  12. 12. ● ● ● São pequenas descrições que detalham itens a serem considerados; Ajuda na compreensão do problema; Ajuda a levantar e organizar os requisitos. Estórias (User Stories) 12
  13. 13. ● ● ● É composta por uma ou mais sentenças; As sentenças são construídas na linguagem de negócio ou cotidiana do usuário final; Captura “o que”, “quem” e “por quê” um requisito precisa ser implementado de forma concisa; Estórias (User Stories) 13
  14. 14. ● 14 ● É um artefato que está presente em outras metodologias ágeis; Toda estória é composta: – Ator: é o proprietário (usuário) da estória ● É recomendado descrever de forma específica quem é o ator – Isso ajuda a identificar o contexto da história dentro do sistema – Ação: é o que o ator quer fazer; ● Utilizando a ação, o autor espera alcançar seu objetivo no sistema; – Funcionalidade: é o que o ator espera que aconteça ao realizar a ação ● ● É o resultado de executar a ação segundo a ótica do ator; Também pode ser visto como justificativa. Estórias (User Stories)
  15. 15. ● 15 ● ● ● Uma lista ordenada de tudo o que é necessário no produto (lista de funcionalidades); Cada item deve ter seu peso (prioridade) de acordo com a vontade do cliente; É replanejado no início de cada Sprint; É gerada incrementalmente – Começa-se pelo básico; – O extra aparece com o tempo. Product Backlog
  16. 16. ● Backlog inicial – Deve conter características que agreguem algum valor de negócio ao produto; – Novos requisitos aparecem quando o cliente vê o produto; Product Backlog Este é o Product Backlog 16
  17. 17. ● Exemplo de um Product Backlog: Product Backlog IMPORTÂNCIA 17 Funcionalidades Funcionalidade 8 Funcionalidade 3 Funcionalidade 4 Funcionalidade 1 Funcionalidade 2 Funcionalidade 10 Funcionalidade 7 Funcionalidade 9 Funcionalidade 6 Funcionalidade 5 IMPRESCINDÍVEL IMPORTANTE SERIA BOM TER
  18. 18. ● 18 Exemplo de um Product Backlog: Product Backlog Item Estimativa Permitir que o usuário edite seu perfil no sistema. 3 Permitir que o usuário envie documento para o cliente por meio do sistema. 5 Permitir que o usuário cancele uma transação corrente. 3 Permitir que o gerente gere um relatório financeiro. 8 Permitir que um usuário aloque tarefas para outro usuário. 8 Como estimar o esforço para determinada atividade?
  19. 19. ● ● É uma prática que ajuda na estimativa de uma história ou de uma tarefa; Uma boa métrica deve levar em consideração a opinião de todo o time; Planning poker 19
  20. 20. ● 20 ● ● Planning poker, do português “Poker do planejamento”; Ajuda a chegar em um consenso na estimativa do esforço demandado para uma tarefa; Assim como User Stories, não é uma técnica exclusiva do Scrum – Outras metodologias ágeis utilizam o planning poker; Planning poker
  21. 21. ● 21 ● ● ● ● Cada membro recebe um conjunto de cartas com sequenciais; Para cada estória de usuário analisada, cada membro joga uma carta com a face para baixo sobre a mesa; Em cada carta estará contido o valor numérico de pontos que o mesmo considera justo para que a estória seja concluída; Para as grandes diferenças entre valores, os membros que jogaram esses valores devem expor suas razões; Com base nas explicações, as cartas são jogadas novamente até que um consenso seja encontrado. Planning poker
  22. 22. ● ● ● As cartas possuem uma sequência de valores; Essa sequencia pode ser simples: – 0, 1, 2, 3, 4, 5, 6, 7, 8… Considerando a inerente possibilidade de valores distantes serem escolhidos, pode-se utilizar outras sequencias – Sequencia de Fibonacci; Planning poker 22
  23. 23. ● Exemplo de conjunto de cartas: Planning poker 23
  24. 24. ● Exemplo de conjunto de cartas: Planning poker ● 24 Significa que o membro não se sente confiante para atribuir um valor a tarefa;
  25. 25. ● Exemplo de conjunto de cartas: Planning poker ● 25 Significa que a tarefa é absolutamente desnecessária e deveria ser descartada;
  26. 26. ● Exemplo de conjunto de cartas: Planning poker ● 26 Significa que a tarefa necessita de uma pequeno esforço para ser concluída;
  27. 27. ● Exemplo de conjunto de cartas: Planning poker 27 significaca que a tarefa é extremamente importante;
  28. 28. ● Exemplo de conjunto de cartas: Planning poker ● Significa uma pausa para refletir antes de tomar a decisão; ● Esta pausa é importante e deve ser respeitada quando solicitada; ● É muito provável que os membros não abusem dela. 28
  29. 29. ● Exemplo de conjunto de cartas: Planning poker – Os outros números representam o sentimento dos membros quanto ao esforço necessário para a realização da tarefa. 29
  30. 30. ● Cenário: – Reunião de planejamento da sprint com toda a equipe (4 pessoas); – É hora da estimativa dos esforços das tarefas ● Todos (menos o ScrumMaster e o P.O.) recebem suas cartas: Planning poker em ação 30
  31. 31. ● 31 ● ● O Scrum Master pede então que o PO leia a primeira estória de usuário “Como usuário, quero acessar o site através do celular e usar todos os recursos, assim como no navegador do desktop”; O Scrum Master pede que todos os membros pensem sobre o esforço para aquela estória; Em seguida, pede que todos mostrem suas cartas. Planning poker em ação
  32. 32. ● 32 1a Rodada – Alan e Carlos fazem jogadas extremas; – Nesta situação o Scrum Master pergunta a ambos o motivo de suas escolhas; – Após suas justificativas, é realizada a 2a Rodada. Planning poker em ação Membro Carta Lucas 8 Ana 5 Alan 21 Carlos 3 Maria 5
  33. 33. ● 33 2a Rodada – Os valores estão mais uniformes; – Com esse cenário, pode-se assumir algumas opções: 1) Incentivar a discussão até um consenso geral; 2) Fazer uma média dos valores; 3) Como os valores estão próximos, assumir o maior valor.. Planning poker em ação Membro Carta Lucas 8 Ana 5 Alan 8 Carlos 5 Maria 5
  34. 34. ● 34 ● ● Uma lista de tarefas a ser completadas dentro de uma Sprint; Os itens são derivados a partir do Product Backlog; São considerados – A prioridade que o cliente deu aos itens; – O tempo e esforço estimados pela equipe para completar os vários itens; Sprint Backlog
  35. 35. ● 35 ● ● ● ● ● Cada indivíduo escolhe o trabalho que fará – Trabalhos nunca são atribuídos; Atualização diária da estimativa do trabalho restante Qualquer membro da equipe pode adicionar, apagar ou mudar tarefas; O trabalho aparece a partir do Sprint; Se uma tarefa não é clara, defina-a como um item com uma quantidade maior de tempo e subdivida-a depois; Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas; Sprint Backlog
  36. 36. ● ● Mostra a linha de esforço frente aos trabalhos que precisam ser realizados; O eixo y analisa a quantidade de trabalho a ser completado e o eixo x o tempo de execução; Gráfico Burndown 36
  37. 37. ● 37 ● ● Também é divido em duas partes: um gráfico para o Produto e outro para o Sprint. – Mede o progresso do desenvolvimento do produto e da Sprint; Representa diariamente o processo do trabalho desenvolvido; Em resumo: um gráfico que mostra “quanto falta”; Gráfico Burndown
  38. 38. ● O gráfico burndown ajuda a medir o projeto: Gráfico Burndown 38
  39. 39. ● O gráfico burndown ajuda a medir o projeto: Gráfico Burndown 39
  40. 40. ● 4 ● ● Product Owner; Scrum Master; Team; Papéis
  41. 41. ● 4 ● ● Product Owner; Scrum Master; Team; Papéis
  42. 42. ● 42 ● ● ● Maximiza o produto – Define as funcionalidades e restrições; – Prioriza as funcionalidades de acordo com o valor; – Define visão, objetivos e datas de lançamento; Maximiza o time – Aceita ou rejeita os resultados dos trabalhos; Representa usuários e clientes – Deve ser apenas uma pessoa, e não um comitê Responsável por gerenciar o backlog do produto. Product Owner
  43. 43. ● 43 ● ● ● ● Não define tarefas; Não distribui tarefas; Tira dúvidas (sobre “o que”); Não invade “o como”; Valida o produto. Product Owner
  44. 44. ● 44 Gerenciamento do Product Backlog – Expressa os itens do backlog de forma clara; – Ordena os itens do backlog para alcançar metas; – Garante visibilidade, transparência e clareza – Garante o entendimento dos itens para que a equipe de desenvolvimento entenda o que deverá ser feito. Product Owner
  45. 45. ● É o Product Owner quem faz a ponte entre a área de negócios e a equipe Scrum Product Owner 45
  46. 46. ● É o Product Owner quem faz a ponte entre a área de negócios e a equipe Scrum Product Owner – O PO deve entender as necessidades e prioridades de cada indivíduo da equipe Scrum; – Deve ser seu porta-voz; 46
  47. 47. ● É o Product Owner quem faz a ponte entre a área de negócios e a equipe Scrum Product Owner – Mas ele também deve se comunicar com o time Scrum para ajudar na ordem em que o produto será construído; 47
  48. 48. ● 48 ● ● É uma pessoa em tempo integral com responsabilidades significativas; Uma única pessoa pode não ser capaz de lidar com a quantidade de coisas que o PO tem que fazer e se preocupar; Sob certas circunstâncias, pode se fazer necessário um time de Product Owners. Product Owner
  49. 49. Product Owner 49
  50. 50. ● 50 Caracterísrticas do PO – Conhecimento de Negócio; – Habilidade com Pessoas; – Autoridade; – Responsabilidade. Product Owner
  51. 51. ● Caracterísrticas do PO Product Owner 51
  52. 52. ● O dia-a-dia do PO Product Owner 52
  53. 53. ● 53 ● ● Product Owner; Scrum Master; Team; Papéis
  54. 54. ● 54 ● ● Aplicar valores e práticas Scrum – Garante que o Scrum seja bem compreendido e aplicado; – Mantenedor, guardião do processo e das boas práticas; Remover barreiras entre o desenvolvimento e o cliente; Garantir a produtividade do time – Garantir que o time não assuma mais coisas do que consegue em uma sprint; Scrum Master
  55. 55. ● 55 ● ● Blindar o time contra interferências externas – Servidor, removedor de riscos; – Ajuda o time a entender as interações úteis e inúteis; – Protege a equipe de excesso de otimismo; Melhorar o dia a dia dos membros do time; Pode ser considerado um professor, mentor, coach; Scrum Master
  56. 56. ● 56 ● ● ● Compreender e praticar a agilidade; Facilitar os eventos do Scrum. Trabalhando para o PO: – Auxiliar em técnicas para gerenciamento do backlog; – Comunicar a visão e o objetivo dos itens do backlog; Trabalhando para o time: – Treinar auto-gerenciamento e interdisciplinaridade; – Facilitar os eventos de scrum sempre que necessário; – Garantir que o scrum está sendo seguido. Scrum Master
  57. 57. ● 57 Exemplos de obstáculos a serem removidos: – “O meu quebrou e eu preciso de um novo”; – “Eu preciso de tempo para debugar um problema no ”; – “Eu preciso de ajuda para entender ”; – “O cliente não teve tempo de se reunir conosco no planejamento e por isto estou parado”; – “O presidente da empresa pediu para eu resolver um problema para ele em outro projeto, por um dia ou dois...” Scrum Master
  58. 58. ● 58 ● ● Product Owner; Scrum Master; Team; Papéis
  59. 59. ● ● ● Team = Equipe – Responsáveis por entregar o produto; Estão todos no mesmo barco; Os papéis dos stakeholders caem em duas categorias: porcos e galinhas Team 59
  60. 60. ● ● Os porcos: – Scrum Master; – Team; As galinhas: – Representantes do Cliente ● Pessoas que criam o ambiente para implantação do produto; – Outros stakeholders ● ● Representam as várias pessoas envolvidas com o projeto; Clientes ou fornecedores; Team 60
  61. 61. Team ● Os porcos: – Scrum Master; – Team; ● As galinhas: – Representantes do Cliente ● Pessoas que criam o ambiente para implantação do produto; – Outros stakeholders ● Representam as várias pessoas envolvidas com o projeto; ● Clientes ou fornecedores; 29
  62. 62. ● Tamanho: sacia a fome com duas pizzas; – Originalmente: 7± 2; – Hoje, são aceitos times 6 ± 3 ● Resultados demonstraram que times com 3 ou 4 membros foram bem sucedidos! Team 62
  63. 63. ● Em 7± 2 ou 6 ± 3, o valor máximo é 9: – A ideia original vem do artigo “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information” – Em ambientes complexos, o número 9 pode ser útil para comunicação, relacionamentos e produtividade Team 63
  64. 64. 32
  65. 65. ● 65 ● ● Multi-funcional e multi-disciplinar; Dedicação integral; Auto-organizável – Não devem possuir títulos distintos de desenvolvedor ● ● Desenvolvedor Junior, Pleno e Sênior; Não existe nível hierárquico; – Individualmente, cada membro pode ter habilidades específicas, mas a responsabilidade é do time; Team
  66. 66. ● 66 ● ● ● Planejamento da Sprint; Reuniões Diárias; Revisão da Sprint; Retrospectiva da Sprint; Eventos
  67. 67. ● 67 ● ● ● Planejamento da Sprint; Reuniões Diárias; Revisão da Sprint; Retrospectiva da Sprint; Eventos
  68. 68. ● 68 Selecionam-se itens do Product Backlog e as tarefas são identificadas e estimadas – Ou seja, prepara-se o Sprint Backlog ● Detalha cronograma e responsabilidades na Sprint; – Esse procedimento é feito de forma colaborativa e não apenas pelo Scrum Master; – Duas etapas: ● ● O que será feito? Como será feito? ● ● É realizada no início de cada Sprint; É limitada a um período de 8 horas – 4 horas para priorização: Product Owner; – 4 horas para planejamento. Planejamento da Sprint
  69. 69. ● ● Reuniões Diárias = Daily Scrums; Comunicação é essencial; Reuniões Diárias 69
  70. 70. ● ● ● Apenas os membros da equipe; No início de cada dia de um Sprint; Diariamente, em pé, durante exatos 15 minutos; Reuniões Diárias 70
  71. 71. ● 71 ● ● Sempre começa na hora; Sempre no mesmo local e horário – Geralmente pela manhã; Todos são bem vindos, mas somente os porcos falam; Reuniões Diárias
  72. 72. ● 72 ● ● Cada membro da equipe deve responder as seguintes perguntas: – O que eu fiz desde ontem? – O que eu planejo fazer hoje? – Algo me impediu de atingir meu objetivo? O Scrum Master é o responsável por resolver os possíveis impedimentos levantados; Ajuda a manter os objetivos e não perder o foco – Evita atrasos de projeto; – Qualquer deslize pode ser corrigido de imediato. Reuniões Diárias
  73. 73. ● 73 Kanban Board – É uma tabela que serve para determinar tarefas exemplo: para executar, em andamento ou finalizada; – Permite um controle detalhado de produção com informações sobre quando, quanto e o que produzir. Reuniões Diárias
  74. 74. ● Kanban Board – É uma tabela que serve para determinar tarefas – exemplo: para executar, em andamento ou – finalizada. – Kanban permite um controle detalhado de – produção com informações sobre quando, quanto – e o que produzir Reuniões Diárias 74
  75. 75. ● ● Revisão da Sprint = Sprint Review; Apresentação dos resultados obtidos – Revisar o trabalho que foi completado (ou não) durante o Sprint; – Incremento do produto potencialmente utilizável e funcional; Revisão da Sprint 75
  76. 76. ● 76 ● ● ● Uma demonstração – Ocorre navegação do sistema; – Apresenta-se o resultado da Sprint aos stakeholders; Todo o time participa – Time, scrum master e PO; Evento informal; É limitado a um período de 4 horas. Revisão da Sprint
  77. 77. ● 77 ● ● ● Guiado pelo Scrum Master; Ocorre após a revisão da sprint e antes da próxima reunião de planejamento; Inspeciona como foi a última sprint em termos de – Pessoas e relações; – Processos e ferramentas; Enquanto a revisão da sprint analisa o produto, a retrospectiva analisa o processo Retrospectiva da Sprint
  78. 78. ● 78 ● ● Inspeciona o andamento do último Sprint; Identifica os pontos positivos e negativos – Os pontos negativos exigem melhoria; Traça plano de ação para as melhorias já no próximo Sprint. Retrospectiva da Sprint
  79. 79. ● 79 ● ● É considerado como resultado do Sprint. Para saber quando uma finalidade do produto está concluída é utilizado Definition of Done (DoD). Este documento consiste em uma lista de todas as atividades que são necessárias para a entrega do produto. Produto Finalizado
  80. 80. Quem usa Scrum? 80
  81. 81. PDS SCRUM Prof. Pedrina Brasil pedrina.brasil@ifrn.edu.br

×