Metodologias Ágeis e Scrum

Jun – 2019
QUEBRA GELO

1. O que você faria se ganhasse 10 milhões de reais na loteria?

2. Qual período em sua vida foi o mais interessante?
3. Qual é sua série de TV favorita?
4. Qual é o seu bolo favorito?
5. O que você aprendeu recentemente?
6. Que cor de meias você prefere?
7. Como você prefere o seu café?
8. Qual foi o seu melhor (mais divertido) dia de trabalho?
 Ronaldo Zanardo

20 anos de experiência na área de Tecnologia de grandes empresas.

Atuo como facilitador de inovação por meio de abordagem, metodologias e ferramentas

como o Design Thinking, Business Model Canvas, Lean Startup e Negócios e Tech
Exponenciais com o objetivo de ajudar pessoas e empresas na busca de soluções de valor
para sua vida e seus negócios.
Apresentação Pessoal

Nome
Sonho de infância
Agenda

Case Sentinel
Cascata
Priorização de Projetos
Manifesto Ágil
Metodologia Scrum
Sprint na Prática
Referências
“
O desperdício é mais
um crime contra a
sociedade do que
uma perda nos

”
negócios
Taiichi Ohno, Toyota
A Fonte!
Case
Projeto
Sentinel
Sistema Virtual Case File

✓ Iniciou em 2001 orçamento de US$ 170 milhões;

✓ Cancelado em 2004 sem nada ter sido codificado;

✓ Retomado em 2005 para ser entregue em 2009 com novo orçamento de

US$ 451 milhões;

✓ Em 2010 já tinha consumido U$ 405 milhões sendo realizado somente a

metade do trabalho. (mais U$ 350 milhões e mais 6 à 8 anos)

 Resolvendo a coisa!

✓ Havia 1100 requisitos;

✓ Priorizaram os itens mais importantes (maior valor para o projeto);

✓ Regra 80/20 (onde 80% do valor dos software vem de 20% das

funcionalidades);

✓ Para finalizar precisaram de U$ 20 milhões, 18 meses e 40

funcionários, sistema entregue em julho de 2012.

waterfall
 Modelo Cascata

Começo Planejar
do
Construir
Projeto

Testar

Revisar

Entregar
Faça uma coisa de cada vez

“ As pessoas não realizam multitarefas porque são boas

nisso. Elas o fazem porque são mais distraídas.

Número de projetos Porcentagem de tempo

David Sanbonmatsu

”
Perda causada pela mudança
Simultâneos disponível para cada projeto de contexto
1 100% 0%

2 40% 20%

3 20% 40%

4 10% 60%

5 5% 75%
Fonte: Software com Qualidade, de Gerald Weinberg
Exemplo Priorização entre Projetos
Projeto A A1 A2 A3 = A

Projeto B B1 B2 B3 = B

Projeto C C3
C1 C2 = C

Estratégia tradicional: “Tudo é importante, vamos fazer tudo ao mesmo tempo!” A B C

A1 B1 C1 A2 B2 C2 A3 B3 C3

Janeiro Fevereiro Março Abril Maio Junho Julho

Estratégia ágil: “Prioridade e foco!”

A1 A2 A3 B1 B2 B3 C1 C2 C3

Janeiro Fevereiro Março Abril Maio Junho Julho

A B C
Vamos testar?!
Manifesto para o desenvolvimento ágil de software
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o
nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho,
passamos a valorizar:

1.Indivíduos e interações mais que processos e ferramentas

2.Software em funcionamento mais que documentação abrangente
3.Colaboração com o cliente mais que negociação de contratos
4.Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à
esquerda.

http://www.manifestoagil.com.br/
 Princípios por trás do manifesto ágil
1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software
de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam
a mudanças, para que o cliente possa tirar vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência
aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente,
durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte
necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e
usuários, devem ser capazes de manter indefinidamente, passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam
seu comportamento de acordo.
 O que é Scrum?

Scrum é um framework estrutural que vem sendo utilizado

para gerenciar o desenvolvimento de produtos complexos
desde o inicio de 1990. Ele não é um processo ou uma
técnica para construir produtos; em vez disso, é um
framework dentro do qual você pode empregar vários
processos ou técnicas.

Definição de Scrum – Fonte Scrum Guide

Mas é só para TI?
 Puxada

Empurrada
 Como funciona?

SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5

Planejar Planejar Planejar Planejar Planejar

Construir Construir Construir Construir Construir

Testar Testar Testar Testar Testar

Revisar Revisar Revisar Revisar Revisar

Entregar Entregar Entregar Entregar Entregar

 Teoria do Scrum Aspectos significativos do processo devem
estar visíveis aos responsáveis pelos
resultados. Exemplo:

• Uma linguagem comum referindo-se ao

Transparência processo deve ser compartilhada por
todos os participantes; e,
• Uma definição comum de “Pronto” deve
ser compartilhada por aqueles que
realizam o trabalho e por aquele que
Se foi detectado que um ou mais aceitam o resultado do trabalho.
aspectos de um processo desviou
para fora dos limites aceitáveis, o
processo ou material que está sendo
produzido deve ser ajustado.

Adaptação Inspeção

Os usuários do Scrum devem,

frequentemente, inspecionar os
artefatos do Scrum e o progresso e
detectar variações, mas elas não
devem ser tão frequentes ao ponto
de atrapalhar a execução das
tarefas.
O Time Scrum

Product Owner Scrum Master

Time de Desenvolvimento
 É o responsável por maximizar o valor do
produto e do trabalho do Time de
Desenvolvimento.

Ele é uma pessoa e não um comitê e é

único responsável por gerir o Backlog do
Produto

Product Owner • Expressar claramente os itens do Backlog do

Produto;
• Ordenar os itens do Backlog do Produto;
• Garantir o valor do trabalho realizado;
• 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.

Fonte Scrum Guide

 Responsável por garantir que o
Scrum seja entendido e
aplicado ele faz com que o Time
Scrum adere à teoria, práticas e
Scrum Master
regras da metodologia.

Fonte Scrum Guide

SM trabalhando para:
Product Owner
➢ Encontrar técnicas para o
gerenciar o Backlog do Produto.
➢ Comunicar a visão, objetivos e
itens do Backlog do Produto.
➢ Ensinar o Time de
Desenvolvimento a criar itens do
Backlog do Produto.
➢ Facilitar os eventos Scrum
conforme necessário.
Scrum Master
Time de Desenvolvimento
➢ Treinar o autogerenciamento.
➢ Ensinar e liderar na criação de
produtos de alto valor.
➢ Remover impedimentos para o
progresso do time.
➢ Facilitar eventos Scrum
conforme necessário.
➢ Treinar o Time em ambientes
organizacionais onde o Scrum
ainda não é aplicado.
Organização
➢ Liderando e treinando a
organização no Scrum.
➢ Planejando implementações
Scrum na organização.
➢ Suportando funcionários e
partes interessadas.
➢ Gerar mudanças que
aumentem a produtividade.
➢ Trabalhando com outros SM
para aumentar a eficiência.
Fonte Scrum Guide
 O Time de Desenvolvimento é
formado por profissionais que
realizam o trabalho de entregar
uma versão que seja útil do
“Produto” ao final de cada Sprint.

Time de Tem como característica:

Desenvolvimento
• Auto organizados.
• Times de Desenvolvimento são multifuncionais.
• Desenvolvedores independente do que está
Tamanho do Time: sendo construído.
• Os participantes podem ter habilidades
específicas, mas a responsabilidade pertence
Ele deve conter no mínimo 3 e no
ao Time.
máximo 9 integrantes. PO e SM não
• Não contém sub-times.
fazem parte dessa contagem.
Fonte Scrum Guide
 Ciclo Scrum

Reunião
Diária

Revisão
da Sprint
Sprint
1-4 semanas

Backlog do Produto Backlog da Sprint Iteração Produto acabado ou

incremento
Retrospectiva
da Sprint

Fonte Scrum Guide

 Eventos Scrum (Cerimônias)

Reunião
Diária

Revisão
da Sprint
Sprint
1-4 semanas

Backlog do Produto Backlog da Sprint Iteração Produto acabado ou

incremento
Retrospectiva
da Sprint

Fonte Scrum Guide

Duração máxima de oito horas para uma
Sprint de um mês de duração.

Este plano é criado com o trabalho colaborativo de todo o Time

Scrum.

Ela responde as seguintes questões:

• O que pode ser entregue como resultado do incremento da próxima Sprint?
• Como o trabalho necessário para entregar o incremento será realizado?

Tópico Um: O que pode ser Pronto nesta Sprint?

Tópico Dois: Como o trabalho escolhido será Pronto?

Objetivo ou meta da Sprint

Fonte Scrum Guide
Duração mínima de uma semana e máxima
de quatro semanas.

Sprints permitem previsibilidade que garante inspeção e

adaptação do progresso em direção ao objetivo e são limitadas
a um mês corrido.

Durante a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo dela;
• As metas de qualidade não diminuem;
• O escopo pode ser clarificado e renegociando entre o PO e o Time de
Desenvolvimento.

Fonte Scrum Guide

Duração de 15 minutos. Ela deve ser
realizada no mesmo horário e local todo dia.

O SM assegura que o Time de Desenvolvimento tenha a reunião, mas o Time é

o responsável por conduzir a Reunião Diária.

O SM reforça a regra de que somente os membros do Time de Desenvolvimento

participem da reunião.

O que deve ser esclarecido:

• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da Sprint?
• O que eu farei hoje para o Time de Desenvolvimento atender a meta da Sprint?
• Eu vejo algum obstáculo que eu ou o Time de Desenvolvimento no atendimento da meta da Sprint?

O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da
Sprint.
Fonte Scrum Guide
É executada no final do Sprint para
inspecionar o incremento e adaptar o
Backlog do Produto se necessário, tem
duração de 4 horas de duração para Sprints
de um mês.

• Participantes (Time Scrum e os Stakeholders chaves convidados pelo PO);

• O PO esclarece quais itens do Backlog do Produto foram “Prontos” e quais
não;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais
problemas ocorreram e como eles foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e
responde dúvidas sobre o incremento;
• O PO discute o Backlog do Produto tal como está, projetando prováveis
datas de conclusões, tendo como base o progresso do até agora;

O resultado da Reunião é um Backlog do Produto revisado que

define o provável Backlog para a próxima Sprint.
Fonte Scrum Guide
Ocorre depois da Revisão da Sprint e antes
da reunião de Planejamento da próxima
Sprint e tem 3 horas de duração, para
Sprints de um mês

O Scrum Master encoraja o Time Scrum a melhorar, dentro do framework

Scrum.
Ao final da Retrospectiva, o Time Scrum deverá ter identificado melhorias que
serão implementadas na próxima 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.

Fonte Scrum Guide

 Artefatos Scrum

Reunião
Diária

Revisão
da Sprint
Sprint
1-4 semanas

Backlog do Produto Backlog da Sprint Iteração Produto acabado

ou incremento
Retrospectiva
da Sprint

Fonte Scrum Guide

O Backlog do Produto é uma lista ordenada
de tudo que deve ser necessário no produto
e ele nunca está completo.

Ele é a única origem dos requisitos para

qualquer mudança a ser feita no produto.
Ele é um artefato vivo.

Múltiplos Times Scrum frequentemente trabalham juntos no mesmo Produto e o

Time de Desenvolvimento é o responsável por todas as estimativas..

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.

Fonte Scrum Guide

O Backlog do Sprint é um conjunto de
itens do Backlog do Produto
selecionados para a Sprint, juntamente
com o plano, ele é a previsão do Time de
Desenvolvimento do que estará no
próximo incremento.

O Time de Desenvolvimento cria o plano com detalhes suficientes e que pode

ser modificado ao longo de toda a Sprint pelo time, sempre que um trabalho é
necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint.

Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos

itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento
acompanha estes resumos diários e projeta a probabilidade de alcançar o
objetivo da Sprint.
Fonte Scrum Guide
É a soma de todos os itens do
Backlog do Produto completado
durante a Sprint e o valor do
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.

Fonte Scrum Guide

 Backlog do Produto
e
Estórias dos Usuários
Backlog do Produto é uma lista
priorizada, contendo breves descrições de todas Item 1
as funcionalidades desejadas para o produto.
Item 2
Em projetos ágeis não é necessário iniciar um
projeto com um esforço inicial demorado, Item 3
coletando e documentando todos os requisitos de
uma vez. Item 4

Normalmente, a equipe e o Product Owner (dono Item 5

do produto) escrevem e priorizam os itens iniciais
do Product Backlog, sendo esses itens Item 6
suficientes para que a equipe inicie a primeira
iteração.
Item 7

O Product Backlog irá crescer e mudar

Item 8
à medida em que se aprende mais sobre o
produto e sobre o cliente.

Fonte: www.culturaagil.com.br
Uma estória de usuário pode ser
caracterizada como uma curta e simples Mesa de
descrição da necessidade do cliente. aula

Ela normalmente é contada a partir da

COMO facilitador QUERO
perspectiva de quem precisa da nova
uma mesa de 1 metro de
necessidade, sendo geralmente um usuário, altura, redonda e com
cliente ou representante de negócios do cliente. rodinhas PARA que os
participantes possam
trabalhar de maneira
Aplicar o conceito INVEST colaborativa.

I – Independente
N – Negociável
V – grande Valor
E – Estimável
S – Small (pequeno)
T – Testável

Fonte: www.culturaagil.com.br
Sprint e
Releases
 A sprint é um período de tempo onde um
Est 1
trabalho específico deve ser executado,
concluído e preparado para uma posterior
Est 2 Sprint 1 revisão.

Est 3 Release 1 As sprints são compostas por:

➢ Reunião de planejamento da sprint;
Est 4 ➢ O trabalho de desenvolvimento (execução);
Sprint 2 ➢ Reuniões diárias;
Est 5 ➢ Revisão da sprint;
➢ Retrospectiva da sprint.

Est 6
Release, são pacotes de incrementos que
Est 7 Sprint 3 Release 2
compõem um plano de entregas. Ela pode
ter uma ou mais Sprints inseridas e são
Est 8
organizadas de acordo com suas
características e funções.

Fonte: www.culturaagil.com.br
Quadro
Kanban
Kanban é uma palavra
japonesa (lógico) e seu
significado literal é “cartão” ou
“sinalização”.

É um método para a
implantação de mudanças que
não prescreve papéis ou
práticas específicas.

Em vez disso, oferece uma

série de princípios que buscam
melhorar o desempenho e
reduzir desperdício, eliminando
atividades que não agregam
valor para a equipe.

Fonte: www.culturaagil.com.br
Cinco fundamentos:

1. Visualizar o fluxo de
trabalho;
2. Limitar trabalho em
andamento;
3. Medir e gerenciar o
fluxo;
4. Tornar o processo e as
politicas explicitas;
5. Utilizar um modelo que
reconhece
oportunidades de
melhoria.
 Gráfico
Burndown
Gráfico Burndown, tem
como objetivo ajudar a
equipe a realizar o 30
acompanhamento do 7
trabalho tendo como
pontos de atenção o
6

Esforço
esforço vs tempo. 20
10
Ele da visibilidade de
como está o trabalho da 10
equipe e previsibilidade de
quando o trabalho será
finalizado. Tempo

SP1 SP2 SP3

Princípio MVP
Lean Startup
“ Uma Startup é uma instituição humana
projetada para criar novos produtos e serviços
sob condições de extrema incerteza.

”
Eric Ries – A Startup Enxuta
“ O objetivo de uma startup é descobrir a
coisa certa a criar – a coisa que os
clientes querem e pela qual pagarão – o

”
mais rápido possível.

Eric Ries – A Startup Enxuta

 MVP
CONSTRUIR MEDIR
Converter as
ideias em Ver como os
produtos clientes
respondem

APRENDER
Pivotar ou
Perseverar
 Ciclo de
Feedback
Canvas Lean Startup
Problemas Soluções Proposta de Vantagens Segmentos de
Valor única injustas mercado
Listar três possíveis
Listar os três soluções para os Apresentar os ponto Identificar e
principais problemas problemas Definir uma proposta que não podem ser apresentar qual é o
que você identificou apresentados de valor única, bem facilmente copiados público alvo.
clara e que expresse ou comprados.
o seu diferencial para (diferencial)
que o consumidor
escolha o seu produto
ou serviço.

Métricas Chaves Canais

Registrar as Apresentar os
atividades chaves que caminhos para chegar
você está medindo. nos clientes.

Estrutura de custos Fontes de renda

Identificar e apresentar: Identificar e apresentar:
• Custos de aquisição • Modelo de receita
• Custos de distribuição • Valor vitalício ou por tempo de vida
• Hospedagem • Receitas
• Pessoas e etc... • Margem de crescimento

www.innovathinking.com.br
 1. Escolha um Dono do Produto.
2. Selecione uma equipe.
3. Escolha um Scrum Master.
4. Crie e priorize um backlog do produto.
5. Refine e estime o backlog.
Legal! 6. Planeje o Sprint.
Mas por onde eu 7. Dê visibilidade ao trabalho.

começo? a. Quadro Scrum (Kanban)

b. Gráfico Burndown
8. Realize reunião diária.
9. Revise o Sprint.
10. Faça retrospectiva do Sprint.
11. Comece imediatamente o Sprint seguinte
Mão na Massa
PO
SM

“Construtores”
6 Grupos

1 Cliente –
Missão
Construir Backlog
Estória de usuário
 Warm up
Colaboração
Sprint
Planejamento da Sprint
Iteração
Revisão da Sprint
Retrospectiva do Sprint
E aí? O que aprendemos?
Referências
Referências
para Leitura
 Sites
http://innovathinking.com.br/ https://www.abuzitos.com.br/

https://culturaagil.com.br/
O B R I G AD O
www.innovathinking.com.br

https://www.facebook.com/innovathinking/

https://www.linkedin.com/in/ronaldo-zanardo/

Ronaldo Zanardo
ronaldo.zanardo@innovathinking.com.br

+55.11.94524 3819