Guia SCRUM - material para certificação CSM

678 visualizações

Publicada em

Este Guia SCRUM é material usado para certificação Certified SCRUM Master da https://www.scrumalliance.org

Publicada em: Negócios
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
678
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
17
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Guia SCRUM - material para certificação CSM

  1. 1. CSM - João Antonio Ferreira joao.parana@gmail.com Guia do Scrum As regras do jogo 1
  2. 2. CSM - João Antonio Ferreira joao.parana@gmail.com Baseado no guia da https://www.scrumalliance.org Inicio de tudo : Ken Schwaber e Jeff Sutherland em 1995. O Guia do Scrum documenta o Scrum conforme desenvolvido e sustentado por mais de 20 anos via Scrum Alliance 2
  3. 3. CSM - João Antonio Ferreira joao.parana@gmail.com O propósito do Guia do Scrum: contém a definição do Scrum papéis, eventos, artefatos e as regras do Scrum 3
  4. 4. CSM - João Antonio Ferreira joao.parana@gmail.com Definição do Scrum: Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. 4
  5. 5. CSM - João Antonio Ferreira joao.parana@gmail.com Scrum é: 1. Leve 2. Simples de entender 3. Difícil de dominar 5
  6. 6. CSM - João Antonio Ferreira joao.parana@gmail.com Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos complexos 6
  7. 7. CSM - João Antonio Ferreira joao.parana@gmail.com Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. 7
  8. 8. CSM - João Antonio Ferreira joao.parana@gmail.com As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre eles. 8
  9. 9. CSM - João Antonio Ferreira joao.parana@gmail.com Teoria do Scrum 9
  10. 10. CSM - João Antonio Ferreira joao.parana@gmail.com Dicionário: Usaremos os acrônimos abaixo PO - Product Owner SM - Scrum Master DEV - Developer Team 10
  11. 11. CSM - João Antonio Ferreira joao.parana@gmail.com Scrum é fundamentado nas teorias empíricas de controle de processo. O empirismo afirma que o conhecimento vem da experiê ncia e de tomada de decisões baseadas no que é conhecido. 11
  12. 12. CSM - João Antonio Ferreira joao.parana@gmail.com O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos. 12
  13. 13. CSM - João Antonio Ferreira joao.parana@gmail.com Trê s pilares apoiam a implementação de controle de processo empírico: transparê ncia, inspeção e adaptação. 13
  14. 14. CSM - João Antonio Ferreira joao.parana@gmail.com Transparê ncia - Aspectos significativos do processo devem estar visíveis a todos os responsáveis pelos resultados. Uma linguagem comum (ubíqua) referindo-se ao processo deve ser compartilhada por todos os participantes 14
  15. 15. CSM - João Antonio Ferreira joao.parana@gmail.com Uma definição comum do significado de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho. 15
  16. 16. CSM - João Antonio Ferreira joao.parana@gmail.com Inspeção - Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção a detectar variações. Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a própria execução das tarefas. 16
  17. 17. CSM - João Antonio Ferreira joao.parana@gmail.com Adaptação - Se um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios. 17
  18. 18. CSM - João Antonio Ferreira joao.parana@gmail.com O Scrum prescreve quatro Eventos formais, nos limites da Sprint: 1. Reunião de planejamento 2. Reunião diária 3. Reunião de revisão 4. Reunião de Retrospectiva 18
  19. 19. CSM - João Antonio Ferreira joao.parana@gmail.com O Time Scrum é composto : Scrum Master Produt Owner Developer Team 19
  20. 20. CSM - João Antonio Ferreira joao.parana@gmail.com Times Scrum são: auto-organizáveis multifuncionais. 20
  21. 21. CSM - João Antonio Ferreira joao.parana@gmail.com Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por outros de fora do Time. 21
  22. 22. CSM - João Antonio Ferreira joao.parana@gmail.com Times multifuncionais possuem todas as competê ncias necessárias para completar o trabalho sem depender de outros que não fazem parte da equipe. 22
  23. 23. CSM - João Antonio Ferreira joao.parana@gmail.com O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. 23
  24. 24. CSM - João Antonio Ferreira joao.parana@gmail.com Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades de realimentação. 24
  25. 25. CSM - João Antonio Ferreira joao.parana@gmail.com Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do produto do trabalho esteja sempre disponível ao final de cada Sprint. 25
  26. 26. CSM - João Antonio Ferreira joao.parana@gmail.com O PO - ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do DEV. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. 26
  27. 27. CSM - João Antonio Ferreira joao.parana@gmail.com O PO é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui: 1. Expressar claramente os itens do Backlog do Produto 2. Ordenar os itens do Backlog do Produto para alcançar as metas 3. Garantir o valor do trabalho realizado pelo DEV 4. Garantir que o Backlog do Produto seja visível, transparente, claro para todos 5. Mostrar no que o Time Scrum vai trabalhar a seguir 5. Garantir que o DEV entenda os itens do Backlog do Produto no nível de detalhe necessário. 27
  28. 28. CSM - João Antonio Ferreira joao.parana@gmail.com O PO pode fazer o trabalho dele, com a ajuda do DEV. No entanto, o PO continua sendo o responsável pelos resultados do trabalho. 28
  29. 29. CSM - João Antonio Ferreira joao.parana@gmail.com O PO é uma pessoa e não um comitê . 29
  30. 30. CSM - João Antonio Ferreira joao.parana@gmail.com O PO pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o PO. 30
  31. 31. CSM - João Antonio Ferreira joao.parana@gmail.com Para que o PO tenha sucesso, toda a organização deve respeitar as suas decisões. 31
  32. 32. CSM - João Antonio Ferreira joao.parana@gmail.com As decisões do PO são visíveis no conteúdo e na priorização do Backlog do Produto. Ninguém além do PO tem permissão para falar com o DEV sobre diferentes configurações de prioridade, e o DEV não tem permissão para agir sobre o que outras pessoas disserem. 32
  33. 33. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. 33
  34. 34. CSM - João Antonio Ferreira joao.parana@gmail.com Somente integrantes do DEV criam incrementos. 34
  35. 35. CSM - João Antonio Ferreira joao.parana@gmail.com Os DEV - Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e gerenciar seu próprio trabalho. 35
  36. 36. CSM - João Antonio Ferreira joao.parana@gmail.com A sinergia resultante aperfeiçoa a eficiê ncia e a eficácia do DEV - DEV como um todo. 36
  37. 37. CSM - João Antonio Ferreira joao.parana@gmail.com Os DEV tem as seguintes características: 1. Eles são auto-organizados. Ninguém diz ao DEV como transformar o Backlog do Produto em Incremento de Produto 2. DEV são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o Incremento do Produto 3. O Scrum não reconhece títulos para os integrantes do DEV que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa. Não há exceções para esta regra. 4. Individualmente os integrantes do DEV podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao DEV como um todo 5. DEV não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios. 37
  38. 38. CSM - João Antonio Ferreira joao.parana@gmail.com Tamanho do DEV Deve ser pequeno o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho dentro dos limites da Sprint. 38
  39. 39. CSM - João Antonio Ferreira joao.parana@gmail.com Menos de trê s integrantes no DEV diminuem a interação e resultam em um menor ganho de produtividade. 39
  40. 40. CSM - João Antonio Ferreira joao.parana@gmail.com Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando um DEV incapaz de entregar um incremento potencialmente utilizável (Incremento de Produto). 40
  41. 41. CSM - João Antonio Ferreira joao.parana@gmail.com Havendo mais de nove integrantes é exigida muita coordenação. Pode causar problemas de Comunicação e Gestão. 41
  42. 42. CSM - João Antonio Ferreira joao.parana@gmail.com Times de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar. 42
  43. 43. CSM - João Antonio Ferreira joao.parana@gmail.com Os papéis de PO e de SM Não SÃO incluídos nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint. 43
  44. 44. CSM - João Antonio Ferreira joao.parana@gmail.com O SM - responsável por garantir que o Scrum seja entendido e aplicado. 44
  45. 45. CSM - João Antonio Ferreira joao.parana@gmail.com O SM faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O SM é um facilitador para o Time Scrum (servo e lider). 45
  46. 46. CSM - João Antonio Ferreira joao.parana@gmail.com O SM ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são. 46
  47. 47. CSM - João Antonio Ferreira joao.parana@gmail.com O SM ajuda todos a mudarem estas interações para maximizar o valor criado pelo Time Scrum. 47
  48. 48. CSM - João Antonio Ferreira joao.parana@gmail.com O SM trabalhando para o PO O SM serve o PO de várias maneiras: 1. Aplicando técnicas para o gerenciamento do Backlog 2.Comunicando claramente a visão do Produto, objetivos e itens do Backlog para o DEV 3. Ensinando ao Time Scrum a criar itens de Backlog do Produto de forma clara e concisa 4. Compreendendo a longo-prazo o planejamento do Produto no ambiente empírico 5. Compreendendo e praticando a agilidade 6. Facilitar os eventos Scrum conforme exigidos 48
  49. 49. CSM - João Antonio Ferreira joao.parana@gmail.com O SM trabalhando para o DEV O SM serve ao DEV de várias maneiras: 1. Treinar o DEV em autogerenciamento e interdisciplinaridade 2. Ensinar e liderar o DEV na criação de produtos de alto valor 3. Remover impedimentos para o progresso do DEV 4. Facilitar os eventos Scrum conforme exigidos 5. Treinar o DEV em ambientes organizacionais nos quais o Scrum não é totalmente adotado ou compreendido. 49
  50. 50. CSM - João Antonio Ferreira joao.parana@gmail.com O SM trabalhando para a Organização O SM serve a Organização de várias maneiras: 1. Liderando e treinando a organização na adoção do Scrum 2. Planejando implementações Scrum dentro da organização 3. Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico 4. Causando mudanças que aumentam a produtividade do Time Scrum 5. Trabalhando com outros SMs para aumentar a eficácia da aplicação do Scrum nas organizações. 50
  51. 51. CSM - João Antonio Ferreira joao.parana@gmail.com Eventos Scrum Eventos prescritos são usados no Scrum para criar uma rotina e um ritmo Servem também para minimizar a necessidade de reuniões extras. 51
  52. 52. CSM - João Antonio Ferreira joao.parana@gmail.com Todos os eventos são eventos time-boxed, de tal modo que todo evento tem uma duração máxima. 52
  53. 53. CSM - João Antonio Ferreira joao.parana@gmail.com Uma vez que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar sempre que o propósito do evento é alcançado. 53
  54. 54. CSM - João Antonio Ferreira joao.parana@gmail.com Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa. 54
  55. 55. CSM - João Antonio Ferreira joao.parana@gmail.com Estes eventos são especificamente projetados para permitir uma transparê ncia e inspeção criteriosa. A não inclusão de qualquer um dos eventos resultará na redução da transparê ncia e da perda de oportunidade para inspecionar e adaptar. 55
  56. 56. CSM - João Antonio Ferreira joao.parana@gmail.com Sprint é o coração do Scrum um time-boxed de um mê s ou menos, durante o qual um “Pronto” é criado. Pronto » versão incremental potencialmente utilizável do produto, também chamado: Incremento de Produto 56
  57. 57. CSM - João Antonio Ferreira joao.parana@gmail.com Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. 57
  58. 58. CSM - João Antonio Ferreira joao.parana@gmail.com As Sprints são compostas por: 1. uma reunião de planejamento 2. reuniões diárias 3. o trabalho de desenvolvimento 4. uma reunião de revisão 5.uma reunião retrospectiva 58
  59. 59. CSM - João Antonio Ferreira joao.parana@gmail.com Durante a Sprint: 1. Não são feitas mudanças que possam por em perigo o objetivo da Sprint 2. As metas de qualidade não diminuem 3. O escopo pode ser esclarecido e renegociado entre o PO e o DEV 59
  60. 60. CSM - João Antonio Ferreira joao.parana@gmail.com Cada Sprint pode ser considerada um projeto com horizonte de até um mê s. Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído, um plano flexível que irá guiar a construção, o trabalho e o por fim o resultado que é o Incermento de Produto. 60
  61. 61. CSM - João Antonio Ferreira joao.parana@gmail.com Sprints são limitadas a um mê s corrido. Quando o horizonte da Sprint é muito longo, o risco pode crescer consideravelmente. Sprints permitem previsibilidade que garante a inspeção e adaptação em direção à meta. Sprints de um mês, também limitam o risco ao custo de apenas um mê s corrido. 61
  62. 62. CSM - João Antonio Ferreira joao.parana@gmail.com Cancelamento da Sprint: Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o PO tem a autoridade para cancelar a Sprint, embora ele possa fazer isso sob influê ncia das partes interessadas, do DEV ou do SM. 62
  63. 63. CSM - João Antonio Ferreira joao.parana@gmail.com A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâ ncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. 63
  64. 64. CSM - João Antonio Ferreira joao.parana@gmail.com Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente utilizável, o PO pode aceitar. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto pois o trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado. 64
  65. 65. CSM - João Antonio Ferreira joao.parana@gmail.com O cancelamento de Sprints consome recursos Todos tem que se reagrupar em outra reunião de planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns. 65
  66. 66. CSM - João Antonio Ferreira joao.parana@gmail.com Reunião de Planejamento da Sprint: O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da Sprint. Este plano é criado com o trabalho colaborativo de todo o Time Scrum. 66
  67. 67. CSM - João Antonio Ferreira joao.parana@gmail.com Reunião de planejamento da Sprint possui um time-box com no máximo oito horas (±5%) para uma Sprint de um mê s de duração. Para Sprints menores, este evento é menor e proporcional. Exemplo: 2 horas para um Sprint de uma semana. O SM garante que o evento ocorra e que os participantes entendam seu propósito. O SM ensina o Time Scrum a manter-se dentro dos limites do time-box. 67
  68. 68. CSM - João Antonio Ferreira joao.parana@gmail.com A reunião de planejamento da Sprint responde as seguintes questões: 1. O que pode ser entregue como resultado do incremento da próxima Sprint? 2. Como será realizado o trabalho necessário para entregar o incremento? 68
  69. 69. CSM - João Antonio Ferreira joao.parana@gmail.com Tópico 1: O que pode ser entregue na Sprint? O DEV trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O PO debate o objetivo que a Sprint deve realizar e os itens de Backlog que atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. 69
  70. 70. CSM - João Antonio Ferreira joao.parana@gmail.com As entradas da reunião de planejamento da Sprint são: 1. Backlog do Produto 2. O mais recente incremento do produto 3. A capacidade projetada do DEV na Sprint 4. Desempenho passado do DEV (empirico). A saída é: O número de itens selecionados do Backlog do Produto para a Sprint como selecionado pelo DEV 70
  71. 71. CSM - João Antonio Ferreira joao.parana@gmail.com Somente o DEV pode avaliar o que pode ser completado ao longo da próxima Sprint. 71
  72. 72. CSM - João Antonio Ferreira joao.parana@gmail.com Após o DEV escolher os itens de Backlog do Produto que irá entregar na Sprint, o Time Scrum determina a meta da Sprint. A meta da Sprint é o objetivo que será conhecido dentro da Sprint através da implementação do Backlog do Produto, e esta fornece orientação para o DEV sobre o porque dele estar construindo o incremento. 72
  73. 73. CSM - João Antonio Ferreira joao.parana@gmail.com Tópico 2: Como o trabalho escolhido será feito, ou seja, como ficará Pronto? Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o DEV decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog da Sprint. 73
  74. 74. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV frequentemente inicia o desenho do sistema e do trabalho necessário para converter o Backlog do Produto em um incremento utilizável do produto. O trabalho pode ser de vários tamanhos ou esforços. O trabalho suficiente é planejado durante o planejamento da Sprint pelo DEV para prever o que este acredita que poderá realizar durante o Sprint. 74
  75. 75. CSM - João Antonio Ferreira joao.parana@gmail.com Com o trabalho planejado pelo DEV para os primeiros dias da Sprint concluído este é decomposto em tarefas até o final da reunião, em unidades de um dia de duração ou menos. 75
  76. 76. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV se auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante a reunião de planejamento quanto durante a Sprint 76
  77. 77. CSM - João Antonio Ferreira joao.parana@gmail.com O PO pode ajudar a esclarecer os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca. Se o DEV determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint pode ser renegociados com o PO. 77
  78. 78. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV também pode convidar outras pessoas para participar desta reunião de forma a fornecer opinião técnica ou de domínios específicos. 78
  79. 79. CSM - João Antonio Ferreira joao.parana@gmail.com No final da reunião de planejamento da Sprint, o DEV deve ser capaz de explicar ao PO e ao SM como pretende trabalhar como equipe auto-organizada para completar o objetivo da Sprint e criar o incremento de produto acordado. 79
  80. 80. CSM - João Antonio Ferreira joao.parana@gmail.com Objetivo ou meta da Sprint: A meta da Sprint é um objetivo definido que pode ser satisfeito através da implementação de parte do Backlog do Produto chamado Backlog do Sprint. 80
  81. 81. CSM - João Antonio Ferreira joao.parana@gmail.com O objetivo do Sprint fornece uma direção para o DEV sobre o porquê de estar construindo o incremento. O objetivo da Sprint dá ao DEV alguma flexibilidade a respeito da funcionalidade que será completada dentro dos limites da Sprint. Os itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro que seja coerente e que faça o DEV trabalhar em conjunto em vez de em iniciativas separadas. 81
  82. 82. CSM - João Antonio Ferreira joao.parana@gmail.com Conforme o DEV trabalha, ele mantém o objetivo da Sprint em mente. A fim de satisfazer o objetivo da Sprint, implementam a funcionalidade e a tecnologia. Caso o trabalho acabe por se mostrar diferente do esperado pelo DEV, eles colaboram com o PO para negociar o escopo do Backlog da Sprint dentro da propria Sprint. 82
  83. 83. CSM - João Antonio Ferreira joao.parana@gmail.com Reunião Diária: A Reunião Diária do Scrum é um evento time- boxed de 15 minutos, para que o DEV possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta reunião é feita para inspecionar o trabalho desde a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima Reunião Diária. 83
  84. 84. CSM - João Antonio Ferreira joao.parana@gmail.com A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade. Durante a reunião os membros do DEV esclarecem: 1. O que eu fiz ontem que ajudou o DEV a atender a meta da Sprint? 2. O que eu farei hoje para ajudar o DEV a atender a meta da Sprint? 3. Eu vejo algum obstáculo que impeça a mim ou o DEV atender a meta da Sprint? 84
  85. 85. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV usa a Reunião Diária para: inspecionar o progresso em direção ao objetivo da Sprint e para inspecionar se o progresso tende no sentido de completar o trabalho do Backlog da Sprint 85
  86. 86. CSM - João Antonio Ferreira joao.parana@gmail.com A Reunião Diária aumenta a probabilidade do DEV atingir o objetivo da Sprint. 86
  87. 87. CSM - João Antonio Ferreira joao.parana@gmail.com Todos os dias, o DEV deve avaliar como pretende trabalhar em conjunto, num time auto- organizado, para completar o objetivo da Sprint e criar um incremento esperado de produto antes do final da Sprint. 87
  88. 88. CSM - João Antonio Ferreira joao.parana@gmail.com O membros do DEV frequentemente se encontram imediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou re-planejar, o restante do trabalho da Sprint. 88
  89. 89. CSM - João Antonio Ferreira joao.parana@gmail.com O SM assegura que o DEV faça a reunião, mas o DEV é responsável por conduzir a Reunião Diária. 89
  90. 90. CSM - João Antonio Ferreira joao.parana@gmail.com O SM ensina ao DEV a manter a Reunião Diária dentro do time-box de 15 minutos. 90
  91. 91. CSM - João Antonio Ferreira joao.parana@gmail.com O SM reforça a regra de que somente os integrantes do DEV participem da Reunião Diária. 91
  92. 92. CSM - João Antonio Ferreira joao.parana@gmail.com Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento do DEV. Esta é uma reunião chave para inspeção e adaptação. 92
  93. 93. CSM - João Antonio Ferreira joao.parana@gmail.com Revisão da Sprint: Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. 93
  94. 94. CSM - João Antonio Ferreira joao.parana@gmail.com Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas coisas que podem ser feitas para otimizar a entrega de valor. Esta é uma reunião informal e a apresentação do incremento destina-se a motivar e obter comentários e promover a colaboração e o feedback do Cliente. 94
  95. 95. CSM - João Antonio Ferreira joao.parana@gmail.com Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint de um mê s. Para Sprints menores, este evento é usualmente menor. O SM garante que o evento ocorra e que os participantes entendam o seu objetivo. O SM ensina a todos a manter a reunião dentro dos limites do Time-box. 95
  96. 96. CSM - João Antonio Ferreira joao.parana@gmail.com A Reunião de Revisão inclui os seguintes elementos: 1. Participantes: Time Scrum e os Stakeholders chaves convidados pelo PO 2. O PO esclarece quais itens do Backlog ficaram “Prontos” e quais não 3. O DEV fala sobre o que foi bem durante a Sprint, quais problemas surgiram e como foram resolvidos 4. O DEV demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento 5. O PO discute o Backlog do Produto tal como está. Ele projeta as prováveis datas de conclusão baseado no progresso observado 6. O grupo todo colabora sobre o que fazer a seguir 7. O grupo fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint 8. Análise de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer a seguir 9. Análise da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada do produto 96
  97. 97. CSM - João Antonio Ferreira joao.parana@gmail.com O resultado da Reunião de Revisão da Sprint é um Backlog do Produto revisado que define o provável Backlog da próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades do negócio 97
  98. 98. CSM - João Antonio Ferreira joao.parana@gmail.com Retrospectiva da Sprint: A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint 98
  99. 99. CSM - João Antonio Ferreira joao.parana@gmail.com A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião de planejamento da próxima Sprint. Esta é uma reunião time-boxed de trê s horas para uma Sprint de um mê s. Para Sprint menores, este evento é menor. O SM garante que o evento ocorra e que os participantes entendam seu propósito. O SM ensina todos a mantê -lo dentro do time-box. O SM participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo processo Scrum. 99
  100. 100. CSM - João Antonio Ferreira joao.parana@gmail.com O propósito da Retrospectiva da Sprint é: 1. Inspecionar como a última Sprint foi em relação às pessoas, os relacionamentos, os processos e às ferramentas 2. Identificar e ordenar os principais itens que foram bem e as potenciais melhorias 3. Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho 100
  101. 101. CSM - João Antonio Ferreira joao.parana@gmail.com O SM encoraja o Time Scrum a melhorar o processo de desenvolvimento e as práticas para fazê -lo mais efetivo e agradável para a próxima Sprint. Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto, adaptando a definição de “Pronto” quando apropriado. 101
  102. 102. CSM - João Antonio Ferreira joao.parana@gmail.com Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a si próprio. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento durante a Sprint. 102
  103. 103. CSM - João Antonio Ferreira joao.parana@gmail.com Artefatos do Scrum: Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparê ncia e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a transparê ncia das informações chave de modo que todos tenham o mesmo entendimento dos artefatos. 103
  104. 104. CSM - João Antonio Ferreira joao.parana@gmail.com Backlog do Produto: O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O PO é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. 104
  105. 105. CSM - João Antonio Ferreira joao.parana@gmail.com Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos e melhor entendidos. 105
  106. 106. CSM - João Antonio Ferreira joao.parana@gmail.com O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais apropriado, competitivo e útil. O Backlog do Produto existirá enquanto o produto também existir. 106
  107. 107. CSM - João Antonio Ferreira joao.parana@gmail.com O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. 107
  108. 108. CSM - João Antonio Ferreira joao.parana@gmail.com A medida que um produto é usado, ganha valor, e o mercado oferece retorno, o Backlog do Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de mercado ou tecnologia promovem mudanças no Backlog do Produto. 108
  109. 109. CSM - João Antonio Ferreira joao.parana@gmail.com Múltiplos Times Scrum podem trabalhar juntos no mesmo produto final. Um Backlog do Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado. 109
  110. 110. CSM - João Antonio Ferreira joao.parana@gmail.com O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto. Este é um processo contínuo em que o PO e o DEV colaboram nos detalhes dos itens do Backlog do Produto. 110
  111. 111. CSM - João Antonio Ferreira joao.parana@gmail.com Durante o refinamento do Backlog do Produto, os itens são analisados e revisados. O DEV decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de 10% da capacidade do DEV. Entretanto os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo PO ou a critério do PO. 111
  112. 112. CSM - João Antonio Ferreira joao.parana@gmail.com Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior detalhamento. Quanto menor a ordem na lista, menos detalhes. 112
  113. 113. CSM - João Antonio Ferreira joao.parana@gmail.com Os itens do Backlog do Produto que irão ocupar o desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do time- boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo DEV dentro da Sprint são considerados como “Preparados” - READY - para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de transparê ncia através das atividades de Refinamento. 113
  114. 114. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV é responsável por todas as estimativas. O PO deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca Apenas as pessoas que irão realmente realizar o trabalham (o time DEV) fazem a estimativa final. 114
  115. 115. CSM - João Antonio Ferreira joao.parana@gmail.com Monitorando o Progresso a Caminho do Objetivo: Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O PO acompanha o total do trabalho restante pelo menos a cada Reunião de Revisão da Sprint. O PO compara este valor com o trabalho restante na Reunião de Revisão da Sprint anterior, para avaliar o progresso na direção de completar o trabalho previsto, pelo tempo estimado para alcançar o objetivo. Esta informação deve ser transparente para todas as partes interessadas. 115
  116. 116. CSM - João Antonio Ferreira joao.parana@gmail.com Várias práticas como burndown, burnup e outras práticas de estimativa tem sido usadas para prever o progresso. Estas tem se provado úteis. Entretanto, não substituem a importâ ncia do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que tem acontecido pode ser usado para uma tomada de decisão a respeito do que virá. 116
  117. 117. CSM - João Antonio Ferreira joao.parana@gmail.com Backlog da Sprint: O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do DEV sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em um incremento “Pronto”. 117
  118. 118. CSM - João Antonio Ferreira joao.parana@gmail.com O Backlog da Sprint torna visível todo o trabalho que o DEV identifica como necessário para atingir o objetivo da Sprint. 118
  119. 119. CSM - João Antonio Ferreira joao.parana@gmail.com O Backlog da Sprint é um plano com detalhes suficientes para que as mudanças no progresso sejam entendidas durante a Reunião Diária. O DEV modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Esta modificação ocorre quando o DEV trabalha segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da Sprint durante a sua realização. 119
  120. 120. CSM - João Antonio Ferreira joao.parana@gmail.com Sempre que um novo trabalho é necessário, o DEV adiciona este ao Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente o DEV pode alterar o Backlog da Sprint durante a Sprint. 120
  121. 121. CSM - João Antonio Ferreira joao.parana@gmail.com O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o DEV planeja completar durante a Sprint, e pertence exclusivamente ao DEV. 121
  122. 122. CSM - João Antonio Ferreira joao.parana@gmail.com Monitorando o Progresso da Sprint: Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado. O DEV monitora o total do trabalho restante pelo menos a cada Reunião Diária. O DEV acompanha estes resumos diários e projeta a probabilidade de alcançar o objetivo da Sprint. Com o rastreamento do trabalho restante em toda a Sprint, o DEV pode gerenciar o seu progresso. 122
  123. 123. CSM - João Antonio Ferreira joao.parana@gmail.com Incremento: O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum. Este deve estar na condição utilizável independente do PO decidir por liberá-lo realmente ou não. 123
  124. 124. CSM - João Antonio Ferreira joao.parana@gmail.com Transparê ncia do Artefato: Scrum invoca transparê ncia. Decisões para otimizar o valor e o controle de riscos são feitos com base na percepção existente do estado dos artefatos. Na medida em que a transparê ncia é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e riscos podem aumentar. 124
  125. 125. CSM - João Antonio Ferreira joao.parana@gmail.com O SM deve trabalhar com o PO, DEV, e outras partes envolvidas para entender se os artefatos estão plenamente transparentes. Há práticas para lidar com transparê ncia incompleta, o SM deve ajudar todos a aplicar a mais apropriada prática na falta de uma transparê ncia plena. 125
  126. 126. CSM - João Antonio Ferreira joao.parana@gmail.com O SM pode detectar transparê ncia incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo atentamente o que está sendo dito, e detectando diferenças entre o esperado e o resultado real. 126
  127. 127. CSM - João Antonio Ferreira joao.parana@gmail.com O trabalho do SM é trabalhar com o Time Scrum e organizar o aumento da transparê ncia dos artefatos. Este trabalho geralmente envolve aprendizagem, convencimento e mudança. Transparê ncia não ocorre de um dia para o outro, mas é o caminho. 127
  128. 128. CSM - João Antonio Ferreira joao.parana@gmail.com Definição de “Pronto” Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso varie significativamente de um extremo ao outro para cada Time Scrum, os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo, assegurando a transparê ncia. 128
  129. 129. CSM - João Antonio Ferreira joao.parana@gmail.com Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho estará realmente completo no incremento do produto. 129
  130. 130. CSM - João Antonio Ferreira joao.parana@gmail.com A “Definição de Pronto” orienta o DEV no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante a Reunião de Planejamento da Sprint. 130
  131. 131. CSM - João Antonio Ferreira joao.parana@gmail.com O propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente utilizáveis que aderem à definição atual de “Pronto” do Time Scrum. 131
  132. 132. CSM - João Antonio Ferreira joao.parana@gmail.com O DEV entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, assim o PO pode escolher por liberá-lo imediatamente. Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem segui-la 132
  133. 133. CSM - João Antonio Ferreira joao.parana@gmail.com Se “pronto” para um incremento não é uma convenção de desenvolvimento da organização, o DEV do Time Scrum deve definir uma definição de “pronto” apropriada para o produto. Se há múltiplos Times Scrum trabalhando no lançamento do sistema ou produto, os times de desenvolvimento de todos os Times Scrum devem mutuamente definir a definição de “Pronto” em comum acordo. 133
  134. 134. CSM - João Antonio Ferreira joao.parana@gmail.com Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos. Com um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida para incluir critérios mais rigorosos de alta qualidade. 134
  135. 135. CSM - João Antonio Ferreira joao.parana@gmail.com Conclusão Papéis, artefatos, eventos e regras do Scrum são imutáveis Embora seja possível implementar somente partes do Scrum, o resultado final não é Scrum. Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas. 135
  136. 136. CSM - João Antonio Ferreira joao.parana@gmail.com Livros Scrum: Gestão ágil para projetos de sucesso de Rafael Sabbagh - Editora casa do Código The Art of Doing Twice the Work in Half the Time de Jeff Sutherland 136

×