SCRUM PARA

PROJETOS DE
ENGENHARIA
FUNDAMENTOS
SCRUM
A ORIGEM DO SCRUM

PRIMEIRO
PROJETO MANIFESTO
ÁGIL SCRUM.ORG
NA EASEL

1993 1995 2001 2002 2009 2017 2020

NOVO
APRESENTAÇÃO ALLIANCE
NO CONGRESSO GUIDE
ADRIANE COLOSSETTI
EMPRESÁRIA, ENTERPRISE AGILE TRANSFORMATION, PMP, MASTER
EM PNL
• CEO da Sunsetti Treinamentos e Serviços.
• Mestre em Inteligência Artificial (FEI).
• Bacharel em Engenharia da Computação e Ciência
da Computação.
• Professora em cursos de graduação da área de TI e
Projetos na FIAP e FEI.
• Certificada PMP, PSM I e II, PSPO I, SPS,
Management 3.0, KMP I, KMP II, MASTER COACH
(SBCoaching), ITIL Fundation V3, COBIT V4.1.
Líder Coach, Agile Transformation, Practitioner PNL
(Sociedade Brasileira de PNL), Master em PNL
(Sociedade Internacional de PNL).
CLEBER WILLIAN GOMES
EMPRESÁRIO, SIX SIGMA BLACK BELT, PSM E PSPO CERTIFICADO.

 Consultor Sênior da Sunsetti Treinamentos e Serviços;

 Mestre em Inteligência Artificial (FEI);
 Engenheiro Mecânico;
 MBA de Gestão Empresarial e MBA de Gestão de Projetos.
 Professor FEI, MBA, pós-graduação e cursos de graduação da área de
Engenharia e projetos.
 Certificado PSM I, PSPO I, Six Sigma Black Belt.
 Gerente de Projetos Globais na Ford, VW, MWM e Multinacionais.
 BJETIVO
DO TREINAMENTO

❖ Conhecer os princípios básicos do SCRUM.

❖ Entender ao planejamento de um projeto utilizando SCRUM.

❖ Compreender as técnicas para a execução de um Sprint.

❖ Aplicar o conhecimento através de jogos de projeto.

"SCRUM não é uma metodologia, é um caminho" Ken Schwaber

70% A TRANSFORMAÇÃO ÁGIL
60%
60%
53% 52%
50%
39%
40%
31% 29%
30%
20% 16%
11% 9%
10%
0%
1994 2015 Waterfall 2015 Agil
Failed Challenged Successful
 Scrum
Lean Software Development
Kanban (process + method)
Extreme Programming (XP)
Continuous Integration (CI)
AGILE
Continuous Delivery (CD)
Feature Driven Development (FDD) Escalado
Test Driven Development (TDD) Scrum-of-Scrums
Crystal Clear Nexus
Scrum at Scale (Scrum@Scale)
Framework Large-scale Scrum (LeSS)
Scaled Agile Framework (SAFe)
Disciplined Systems Development
Method (DSDM)
Agile Project Management (AgilePM)
Agile Unified Process (AUP)
Open Unified Process (OpenUP)
ÁGIL

RÁPIDO
 V
P P
A
R R
L
MANIFESTO
I N R
ÁGIL
T
N C E I
D Í S C É um modelo mental,
S P A descrito por 4 valores,
E I S definidos por 12
princípios, manifestados
T O em muitas práticas.
S
 4 VALORES
Indivíduos e interações Processos e ferramentas

Software funcionando Documentação abrangente

MAIS QUE
Colaboração do Cliente Negociação de contratos

Resposta às modificações Seguir um plano

 1 Satisfação do cliente por meio de entrega contínua

2 Modificação de requisitos são bem-vindas

12 3 Entrega de software funcionando frequentemente

PRINCÍPIOS 4 Pessoal de negócio e desenvolvedores Juntos

5 Indivíduos motivados

6 Equipes auto-organizadas
 7 Conversa face a face para levantar informações

8 Software funcionando como medida de progresso

12 9 Ritmo constante de desenvolvimento sustentável

PRINCÍPIOS
10 Excelência técnica

11 Simplicidade

Equipe reflete sobre como se tornar mais efetiva, então

12 sintoniza e ajusta adequadamente seu comportamento
O QUE PRECISA PARA SER ÁGIL?
MINDSET ÁGIL VALORES

PRINCÍPIOS PRÁTICAS

PROCESSOS FERRAMENTAS
O QUE SIGNIFICA O SCRUM?
FORMAÇÃO ORDENADA DO RUGBY.
Nesta jogada, oito jogadores
disputam a reposição de bola
atuando em conjunto com o
mesmo objetivo, sendo que se
um deles falhar, todos falham.
 o É um framework.

o Os requisitos são listados em um “Product

Backlog”.

CARACTERÍSTICAS o O produto evolui em uma série de “sprints”.

DO SCRUM o Não há processo de desenvolvimento definido.

o Equipes que se auto-gerenciam.

o Foco no trabalho em equipe e na melhoria

contínua.
MODELO TRADICIONAL

APROVA-
PESQUISA ESCRITA DESIGN EDIÇÃO ENTREGA
ÇÃO

MODELO ÁGIL
SPRINT SPRINT SPRINT SPRINT

TEMPO
VISÃO GERAL SCRUM
TIME PLANNING
2 SEMANAS = 4 HORAS

BOXED 3 SEMANAS = 6 HORAS

4 SEMANAS = 8 HORAS

RETROSPECTIVA SPRINT REVIEW

2 SEMANAS = 1 HORA 2 SEMANAS = 2 HORAS
3 SEMANAS = 2 HORAS 3 SEMANAS = 3 HORAS
4 SEMANAS = 3 HORAS 4 SEMANAS = 4 HORAS

1S 2S 3S 4S
Planning
REUNIÃO DIÁRIA SPRINT Review
Até 15 minutos 1 A 30 DIAS
Retrô
 PILARES DO SCRUM

TRANSPARÊNCIA Foco na definição de pronto.

INSPEÇÃO Inspeção de tudo que é produzido.
ADAPTAÇÃO Sprint Plan, Reunião diária, Reunião revisão, Retrospectiva.
VALORES DO SCRUM
Ajudar as equipes a adotarem o SCRUM, entregar software com qualidade e
ainda garantir um ambiente agradável para se trabalhar.

CORAGEM COMPROMISSO RESPEITO ABERTURA FOCO

VALORES DO SCRUM
VALORES VISÃO TRADICIONAL VISÃO SCRUM

Culpar a tudo e a todos Ter coragem de fazer a coisa certa e trabalhar

Coragem em problemas difíceis.
pelos problemas
Fazer o melhor progresso possível em direção
Foco Manter o cliente satisfeito
a metas.

Respeito Você como herói para resolver Se respeitam quanto a serem pessoas
os problemas capazes e independentes e vice versa

Comprometimento Se comprometer só porque Comprometimento com o time e com a meta

o chefe mandou da Sprint.

Abertura O Scrum Team e seus stakeholders são

Falar bem do que você faz
abertos quanto ao trabalho e os desafios.
 PAPÉIS SCRUM

PRODUCT OWNER SCRUM MASTER DEVELOPERS

 PRODUCT OWNER
o Define as funcionalidades do produto, mantendo o Product Backlog;

o Atua como facilitador quando há mais clientes envolvidos;

o Define e prioriza o backlog de acordo com o valor de negócio;

o Define o conteúdo das releases – ajusta quando necessário;

o Define os critérios de aceite;

o Monta estratégia para chegada do produto ao mercado.

 PRODUCT OWNER
o Visão clara do orçamento e do produto;

o Refina o backlog;

o Colabora diretamente com o time;

o Apresenta ao time os requisitos necessários para a entrega do produto;

o Aceita ou rejeita o resultado dos trabalhos;

o Garante que especialistas estejam disponíveis para o time.

 SCRUM MASTER
o Responsável por promover e suportar o Scrum como definido no Guia
Scrum;

o Líder coach / líder servidor do time – treina os developers em

autogerenciamento e interdisciplinaridade;

o Responsável pela aplicação dos valores e práticas do Scrum;

o Remove os impedimentos;

o Garante a plena função e produtividade da equipe;

 SCRUM MASTER
o Garante a colaboração entre os envolvidos;

o Protege a equipe das interferências / intervenções externas que quebram o

foco do desenvolvimento;

o Sempre atento aos débitos técnicos;

o Responsável por garantir que o produto atenda às necessidades do cliente;

o Auxilia o Product Owner com o Product Backlog;

o Facilita os eventos Scrum;

o Torna os artefatos do Scrum visíveis.

DEVELOPERS
o São auto-gerenciados. Ninguém (nem mesmo o Scrum Master) diz aos
developers como transformar o product backlog em incrementos de
funcionalidades potencialmente liberável;

o São multifuncionais, multidisciplinares e comprometidos;

o Responsáveis por entregar o que foi acordado como meta da Sprint;

o Definir como as tarefas devem ser divididas para gerar o resultado esperado;

o Definir quem irá executar as tarefas e em que ordem elas são realizadas;

o O Scrum não reconhece sub-times no Developers.

 COMPROMETIMENTO

A mudança é individual e
não da organização.
QUEM É QUEM NO TIME SCRUM?
PRODUCT BACKLOG
CARTÃO DE HISTÓRIAS
ÉPICO
EPIC

HISTÓRIA - A HISTÓRIA - B

ISSUE ISSUE

T – A1 T – A2 T – A3 T – B1 T – B2 T – B3

TASK TASK
 ÉPICO / HISTÓRIAS DE USUÁRIOS
Produto Casa

Épicos Sala Cozinha Banheiro

H1 H2 H3 H1 H2 H3 H1 H2 H3

Histórias
CARTÃO DE HISTÓRIAS
EXEMPLO PRODUCT BACKLOG
MVP E PLANEJAMENTO DE RELEASES
CONSTRUA UM MVP

MÍNIMO VIÁVEL
O menor tamanho Uma proposição de valor
possível que possa ser
entregue no menor
MVP importante que agrega
valor aos seus clientes.
tempo possível

Objetivo: incorporar a menor quantidade possível de

recursos.
MVP

MÁXIMO

MÍNIMO MVP
MVP

Caroli, Paulo
MVP
Como definir?
• Entenda as necessidades imediatas para o negócio;
• Identifique as histórias relacionadas;
• Priorize as histórias;
• Agrupe as histórias em releases para entregar valor ao negócio.
3 perguntas:
• Tem valor suficiente para as pessoas utilizá-lo?
• Demonstra benefícios?
• Permite avaliar e orientar o trabalho futuro?
 NÍVEIS DE PLANEJAMENTOS
RELEASE 1

SPRINT 1 SPRINT 2 SPRINT 3

Tarefa 1 8h

Tarefa 2 4h

Tarefa 3 2h

Tarefa 4 4h
 PLANEJAMENTO DOS RELEASES

Determinar a META do release:

o Todo release deve ter uma meta a ser atingida.

o Deve estar alinhada com as necessidades do negócio.

o Deve ser definida pelo PO.

REFINAMENTO
 REFINAMENTO
o O objetivo do refinamento é aprimorar o product backlog para que esteja
pronto antes da próxima sprint planning.

o Normalmente é realizada em 2 a 3 dias antes do final da sprint.

o Esclarecer todos os pontos e dúvidas do time.

o Reduzir os riscos dos itens do Product Backlog e ver se tem algum

impedimento ou falta de detalhes que a impeçam de entrar na sprint ou
fazer com que a reunião de planejamento do sprint demore muito.
 REFINAMENTO
Uso das 7 dimensões do produto.

ATORES AÇÕES
INTERFACES AMBIENTE

REGRAS
DE DADOS
NEGÓCIO QUALIDADE
 CRITÉRIOS DE ACEITAÇÃO
A elaboração dos critérios de aceitação auxiliam o Time na validação
das funcionalidades construídas.
ESTIMATIVA
ESTIMATIVA DO PRODUCT BACKLOG

o A técnica de estimativa mais utilizada em projetos Scrum é o Planning

Poker.

o O esforço estimado para os itens do Product Backlog deve ser

negociado entre o time e o PO.
PLANEJAMENTO DA SPRINT

SPRINT BACKLOG
PLANNING POKER
PLANNING POKER

1 2 3 5 8 13 21

o Foco: Comprometimento com o prazo.

Cálculo de
Velocidade
 CÁLCULO DA VELOCIDADE

o O cálculo da velocidade é necessário para determinar quantos itens do

Product Backlog podem ser construídas durante uma sprint.

o Considera-se o tamanho estimado para cada item como fator de medida

de produção do time.
 CÁLCULO DA VELOCIDADE

• Para calcular a velocidade usamos a fórmula:

Velocidade =
Capacidade de produção do time x Fator de foco

• Quando NÃO se tem histórico ou algum sprint executado pelo time,

o fator de foco inicial pode variar entre 50% e 70% para um novo
time SCRUM.
 CÁLCULO DA VELOCIDADE
Um time novo com 3 pessoas alocadas 100% do tempo, para a realização de
um sprint de 2 semanas (10 dias), com fator de foco igual a 60%.
Equipe Recursos Alocação Produção
3 pessoas Huguinho 100% 100% de10 dias = 10 homem/dia (h/d)
Zezinho 100% 100% de 10 dias = 10 homem/dia (h/d)
Luizinho 100% 100% de 10 dias = 10 homem/dia (h/d)

A capacidade produtiva do time é calculada da seguinte forma:

Capacidade produtiva = Número de dias do sprint x número recursos
Capacidade produtiva = 10 dias x 3 recursos = 30 h/d
Velocidade = 30 h/d x 60%
Velocidade = 18 pontos por sprint.
CÁLCULO DA VELOCIDADE

Fator de Foco =

Número de pontos produzidos

Capacidade de produção do time
 CÁLCULO DA VELOCIDADE
Equipe Recursos Alocação Produção
3 pessoas Huguinho 100% 100% / 10 dias = 10 homem/dia (h/d)
Exemplo:
Zezinho 100% 100% / 10 dias = 10 homem/dia (h/d)
Luizinho 100% 100% / 10 dias = 10 homem/dia (h/d)

Em um sprint de 2 semanas produziu-se 22 pontos.

Soma-se a produção dos recursos do projeto = 30 h/d

Aplicando a fórmula:
Fator de Foco = número de pontos produzidos
capacidade produção time

Fator de foco = 22 / 30 = 0,73 = 73%

 CÁLCULO DA VELOCIDADE
o Dessa forma vamos calcular a velocidade considerando a alocação abaixo e o
fator de foco calculado anteriormente (73%):

Velocidade = capacidade de produção do time x fator de foco

Equipe Recursos Alocação Produção
3 pessoas Huguinho 100% 100% / 10 dias = 10 homem/dia (h/d)
Zezinho 100% 100% / 10 dias = 10 homem/dia (h/d)
Luizinho 100% 100% / 10 dias = 10 homem/dia (h/d)

Velocidade = 30 h/d x 73% = 22 pontos por sprint.

Assim, nenhum sprint planejado pode ter mais do que 22 pontos.

 CÁLCULO DA VELOCIDADE
Resumo das fórmulas:

Velocidade = capacidade de produção do time x fator de foco

Capacidade produção = Número dias sprint x número recursos

Fator de Foco = Número de pontos produzidos

Capacidade de produção do time
DoR e DoD
CONCEITO DE READY - DOR

o Verificar se a história é clara e se todos os membros têm uma

compreensão do que precisa ser feito, ou seja, se a história tem
informações suficientes para começar a ser desenvolvido.

o Cada empresa define quais as exigências, por exemplo: se deve

conter um protótipo, diagrama, validado pelo usuário, entre outras.

o Na Review meeting a DoR deve ser revisada para melhorar a

qualidade ou aumentar a velocidade de construção.
EXEMPLO DE UM CHECKLIST DE UMA HISTÓRIA:
✓ É pequena suficiente para caber em um sprint?
✓ As dependências estão identificadas?
✓ Tem um esboço da tela?
✓ Os critérios de aceitação estão descritos de forma clara e testável?
✓ Os requisitos não funcionais estão identificados?
✓ Está sem impedimentos?

READY DONE
 CONCEITO DE PRONTO - DoD
o Definido pelo Time Scrum para dar transparência ao processo de formalização de
que um sprint está concluído.

o Todos do Time devem estar cientes e de acordo.

o Deve ter suas características publicada a todos os envolvidos.

READY DONE

SPRINT

PRODUCT BACKLOG PRODUCT INCREMENT

 CONCEITO DE PRONTO
EXEMPLO
✓ História definida, telas desenhadas e validada pelo PO
✓ História construída.
✓ Realizado os testes unitários sem erros.
✓ Funcionalidade inspecionada.
✓ Testes de aceitação 100% OK.
Kanban
 QUADRO DE KANBAN META DA SPRINT

IMPEDIMENTOS
TO DO DOING DONE

COMO 3
USUÁRIO
...

COMO 2
USUÁRIO DoD
...
✓ .
COMO 4 ✓ .
✓ .
USUÁRIO
✓ .
...
Entregas Descobertas Estratégias
BURNDOWN CHART
O Scrum Burndown Chart é uma ferramenta de medição visual que mostra o
trabalho realizado por dia contra a taxa projetada de conclusão para a versão
atual do projeto. Sua finalidade é permitir visualizar se o projeto está no
caminho para entregar a solução esperada dentro da programação desejada.
REUNIÃO DIÁRIA
REUNIÃO DIÁRIA
Eram sugestões do Guide 2017:

o O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a

meta da Sprint?
o O que eu farei hoje para ajudar o Time de Desenvolvimento atender a
meta da Sprint?
o Eu vejo algum obstáculo que impeça a mim ou o Time de
Desenvolvimento no atendimento da meta da Sprint?

Todos os membros dos Developers devem participar e não deve durar mais
de 15 minutos.
REVISÃO DA SPRINT
REVISÃO DA SPRINT
Tem como principal objetivo inspecionar e obter opiniões e impressões de
como foi a sprint para o Product Owner e convidados.

o O time Scrum é quem realiza a apresentação, que deve ser feita no formato
de demonstração.
o O Product Owner avalia se a meta da sprint foi atingida, faz anotações que
poderão se transformar em novos itens para o Product Backlog.
o Product Backlog atualizado.
RETROSPECTIVA DA SPRINT
RETROSPECTIVA DA SPRINT
o O que correu bem durante o sprint?
o O que não correu bem durante o sprint?
o Quais melhorias poderiam ser feitas no próximo sprint?

Sem esta reunião a equipe nunca será capaz de melhorar a sua

produtividade;

É parte integrante do processo de "inspecionar e adaptar".

DÚVIDAS?
OBRIGADA
Adriane Colossetti
[email protected]