tds-as

Aula - FrameWork Scrum - Parte Teórica

Objetivos da Aula

História do Scrum
Scrum Guide
Pilares, Definições e Características do Scrum
Fluxo do processo Scrum
Organização e Papeis do Scrum
Princípios do Scrum
Ciclo de Vida do Scrum
Eventos do Scrum
Artefatos do Scrum
Modelos de quadros

História - Scrum

Fruto de adaptações do método Lean de produção da Toyota e do ciclo OODA da aviação de combate dos USA, conforme palavras do próprio Jeff.

Guia Oficial do Scrum

Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles.

Certificações

Scrum.org
Scrumalliance.org

Algumas Empresas que utilizam Scrum

Google
Microsoft
IBM
Borland
Amazon

Definição do Scrum

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.

Pilares Fundamentais do Scrum

Transparência
Inspeção
Adaptação

Características do Scrum

Scrum é:

Leve;
Simples de entender;
Difícil de dominar

Características do Scrum

O SCRUM emprega uma abordagem iterativa e incremental.

Princípios do Scrum

Principio 1 – Controles Empíricos de Processos
Principio 2: Auto-Organização
Principio 3: Colaboração
Principio 4: Priorização Baseada em Valor
Principio 5: Time-Boxing
- Sprint de 4 semanas – Sprint Planning 8 horas de reunião – Sprint Review 4 horas – Sprint Retrospectiva 3 horas
- Sprint de 3 semanas – Sprint Planning 6 horas de reunião – Sprint Review 3 horas – Sprint Retrospectiva 2.25 horas
- Sprint de 2 semanas – Sprint Planning 4 horas de reunião – Sprint Review 2 horas – Sprint Retrospectiva 1.5 horas
- Sprint de 1 semanas – Sprint Planning 2 horas de reunião – Sprint Review 1 horas – Sprint Retrospectiva 1.25 horas
- Daily 15 minutos independentemente do tamanho da sprint
Principio 6: Iterativa e Incremental

Papéis do Scrum

Características do Time Scrum:

São times auto organizáveis;
Entregam produtos de forma iterativa e incremental;
Um Scrum Team típico tem de 3 a 9 pessoas, embora haja relatos de projetos Scrum com equipes maiores

Product Owner

O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho do Time de Desenvolvimento;
Faz o papel de cliente diante do time Scrum;
Define os requisitos do produto;
Determina a data de entrega e conteúdo a ser desenvolvido;
Prioriza as necessidades (histórias) de acordo com o valor de negócio;
Aceita ou rejeita as entregas.
O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto:
- – Expressar claramente os itens do Backlog do Produto;
- – Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
- – Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
- – Garantir que o Backlog do Produto seja visível, transparente, claro para todos;
- – Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

Scrum Master

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Também atua como facilitador nas reuniões.
O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.
O Time Scrum: Time de Desenvolvimento:
O Time de Desenvolvimento 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.
A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Mudanças apenas em outro Sprint.

A Sprint

O coração do Scrum é a Sprint, um time-boxed de um mês ou mais, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint.
Durante a Sprint:
- Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
- As metas de qualidade não diminuem; e,
- O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.
Uma Sprint pode ser cancelada -> somente pelo Product Owner.

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;
O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint;
O Product Owner debate o objetivo da Sprint;
A entrada da reunião de planejamento da Sprint é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento.
Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.

Reunião diária

A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Time de Desenvolvimento 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.
O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.
O Scrum Master reforça a regra de que somente os integrantes do Time de Desenvolvimento participem da Reunião Diária.
Todos os dias, o Time de Desenvolvimento deve entender como o mesmo pretende trabalhar em conjunto, como um time auto organizado, para completar o objetivo da Sprint e criar o incremento previsto até o final da Sprint. Alguns Times de Desenvolvimento utilizam perguntas, outros se basearão em discussões. Aqui segue um exemplo do que pode ser utilizado:
- O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
- O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
- Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?

Revisão da Sprint

A Revisão da Sprint é executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se necessário. Durante a reunião de Revisão da Sprint o Time Scrum e as partes interessadas colaboram;
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.
Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;
O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;
O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;

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.
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 é usualmente menor.
O propósito da Retrospectiva da Sprint é:
- Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
- Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
- Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;

Backlog do Produto

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.
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.
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.
Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro da Sprint são considerados como “Preparados” para seleção no Planejamento da Sprint.
O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalham fazem a estimativa
O Product Owner acompanha o total do trabalho restante pelo menos a cada Reunião de Revisão da Sprint.

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.

Incremento

Um incremento é uma parte principal inspecionável de trabalho pronto que suporta empirismo no final da sprint.
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 de ser utilizado e atender a definição de “Pronto” do Time Scrum.

Ferramentas do GP com Scrum

JIRA
Monday
Trello
Project
Asana
Clickup
Redmine