Please enable JavaScript.
Coggle requires JavaScript to display documents.
O Guia do Scrum
Nov / 2020
Ken Schwaber e Jeff Sutherland
Scrum 03
…
O Guia do Scrum
Nov / 2020
Ken Schwaber e Jeff Sutherland
Mapa Mental por Plínio de Albuquerque
Mudar o modelo central ou ideias do Scrum, remover elementos ou não seguir as regras do Scrum, encobre os problemas e limita os benefícios do Scrum, potencialmente até tornando-o inútil.
Definição
do Scrum
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos
-
Propositalmente incompleto, apenas definindo as partes necessárias para implementar a teoria Scrum
Construído sobre a inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às pessoas instruções detalhadas, as regras do Guia do Scrum orientam seus relacionamentos e interações.
-
Torna visível a eficácia relativa da gestão atual, meio ambiente e técnicas de trabalho, para que melhorias possam ser feitas
Teoria
do Scrum
Baseado em
-
Lean thinking:
Reduz o desperdício e se concentra no essencial
Emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar o risco
Envolve grupos de pessoas que, coletivamente, possuem todas as habilidades e conhecimentos necessários para fazer o trabalho e compartilhar ou adquirir essas habilidades conforme necessário
Combina quatro (4) eventos formais para inspeção e adaptação, contidos dentro de um evento, a Sprint
( 3 ) Pilares
1º Transparência
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o trabalho
-
-
2º Inspeção
Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência e diligência para detectar variações ou problemas potencialmente indesejáveis
-
3º Adaptação
Se algum aspecto de um processo se desviar fora dos limites aceitáveis ou se o produto resultante for inaceitável, o processo que está sendo aplicado ou os materiais que estão sendo produzidos devem ser ajustados
-
A adaptação se torna mais difícil quando as pessoas envolvidas não são empoderadas ou auto-gerenciadas
-
( 5 ) Os Valores
do Scrum
-
2º Foco
Seu foco principal é o trabalho da Sprint para fazer o melhor progresso possível em direção a essas metas
-
4º Respeito
Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham
5ª Coragem
Os membros do Scrum Team têm a coragem de, fazer a coisa certa e trabalhar em problemas difíceis
Scrum Team
Consiste em um Scrum Master,
um Product Owner e Developers
-
Uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto
-
Autogerenciáveis: decidem internamente
quem faz o quê, quando e como
Pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo dentro de uma Sprint (10 ou menos pessoas)
- Times menores se comunicam
melhor e são mais produtivos.
- Se os Scrum Teams se tornarem muito grandes, eles devem considerar a reorganização em vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar o mesma meta do produto, Product Backlog e Product Owner
-
-
-
Developers
-
Responsável por:
- Criar um plano para a Sprint, o Sprint Backlog;
- Introduzir gradualmente qualidade aderindo a uma Definition of Done;
- Adaptar seu plano a cada dia em direção à meta da Sprint;
- Responsabilizar-se mutuamente como profissionais
Product Owner
Responsável pelo gerenciamento
eficaz do Product Backlog, que inclui:
- Desenvolver e comunicar explicitamente a meta do produto;
- Criar e comunicar claramente os itens do Product Backlog;
- Ordenar os itens do Product Backlog;
Pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o Product Owner ainda é o responsável
Toda a organização deve respeitar suas decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio do incremento inspecionável na revisão da sprint.
É uma pessoa, não um comitê
Pode representar as necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê-lo tentando convencer o Product Owner
Scrum Master
Responsável por estabelecer o Scrum conforme definido no Guia do Scrum, ajudando todos a entender a teoria e a prática do Scrum, tanto no Scrum Team quanto na organização
Responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas, dentro do framework Scrum
-
Serve ao Scrum Team
de várias maneiras, incluindo:
- Treinar os membros do time em autogerenciamento e cross-funcionalidade;
- Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definition of Done;
- Provocando a remoção de impedimentos ao progresso do Scrum Team;
- Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox
Serve o Product Owner de
várias maneiras, incluindo:
- Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
- Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;
- Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;
- Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário
Serve a organização de
várias maneiras, incluindo:
- Liderar, treinar e orientar a organização na adoção do Scrum;
- Planejar e aconselhar implementações de Scrum dentro da organização;
- Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;
- Remover barreiras entre stakeholders e Scrum Teams
( 4 ) Eventos Scrum
- A falha em operar quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e adaptação;
- São usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum;
- Ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade
A Sprint
-
-
Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints
Durante a Sprint:
- Nenhuma mudança é feita que coloque em risco a meta da Sprint;
- A qualidade não diminui;
- O Product Backlog é refinado conforme necessário;
- O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido
Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor
-
Existem várias práticas para prever o progresso: burn-downs, burn-ups ou cumulative flows
Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint
1º Sprint Planning
-
-
O Product Owner garante que os participantes estejam preparados para discutir os itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto
O Scrum Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos
Aborda os seguintes tópicos:
- Tópico 1: Por que esta Sprint é valiosa? Todo o Scrum Team colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders
- Tópico 2: O que pode ser feito nesta Sprint? Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança.
- Tópico 3: Como o trabalho escolhido será realizado? Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definition of Done. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos
Timebox definido com duração máxima de de oito horas para uma Sprint de um mês. Para Sprints mais curtas, o evento geralmente é mais curto.
2º Daily Scrum
Propósito de inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado
Evento de 15 minutos para os Developers do Scrum Team, realizado no mesmo horário e local, todos os dias úteis da Sprint
Os Developers podem selecionar qualquer estrutura e técnicas que quiserem, desde que seu Daily Scrum se concentre no progresso em direção a Meta da Sprint e produza um plano de ação para o próximo dia de trabalho. Isso cria foco e melhora o autogerenciamento.
Melhoram as comunicações, identificam os impedimentos, promovem a rápida tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões
Não é o único momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint
3º Sprint Review
-
O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido
Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir
-
-
Timebox com prazo máximo de quatro horas para uma Sprint de um mês. Para Sprints mais curtas, o evento geralmente é mais curto.
4º Sprint Retrospective
-
O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definition of Done
O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvidos
O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint
-
( 3 ) Scrum Artifacts
1º Product Backlog
-
É uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de trabalho realizado pelo Scrum Team
Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de transparência após as atividades de refinamento.
O Product Backlog refinement é o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho.
Os Developers que farão o trabalho são responsáveis pelo dimensionamento. O Product Owner pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs (trocas de itens)
2º Sprint Backlog
-
- Meta da Sprint (por que);
- Conjunto de itens do Product Backlog selecionados para a Sprint (o que);
- Plano de ação para entregar o Incremento (como).
-
-
3º Incremento
-
Cada incremento é adicionado a todos os incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos.
-
A fim de fornecer valor, o incremento deve ser utilizável
-
-
um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor
-