Pico

Crescimento Declínio

Ciclo de vida corporativo

Do século XX

~ 60 anos

Tempo

Steven Blank –Innovation at 50x

 Pico Pico

Crescimento Declínio

Ciclo de vida corporativo

Do século XXI

~ 20 anos

Tempo

Steven Blank –Innovation at 50x

STEVE BLANK, STANFORD
PASSADO CONHECIDOS

PRESENTE CONHECÍVEIS

FUTURO INCOGNOSCÍVEIS

6
Os três estágios

PRODUCT->MARKET FIT

PROBLEM->SOLUTION FIT SCALE

 "Não é sobre finanças. Não é
estratégia. Não é tecnologia. É o
trabalho em equipe que continua
sendo a maior vantagem
competitiva, tanto porque é tão
poderoso quanto raro."

Patrick Lencioni
Um grupo de desenvolvedores de software percebeu que a forma de resolver problemas e
desenvlver produtos precisava se diferente e, juntos, criaram o Manifesto Ágil
 Colaboração com o
Indivíduos e Interações Software Funcionando Responder a Mudanças
Cliente

Processos e Negociação de
Documentação Extensa Seguir um Plano
Ferramentas Contratos
 Colaboração com o
Indivíduos e Interações Software Funcionando Responder a Mudanças
Cliente

Processos e Negociação de
Documentação Extensa Seguir um Plano
Ferramentas Contratos
 Colaboração com o
Indivíduos e Interações Software Funcionando Responder a Mudanças
Cliente

Processos e Negociação de
Documentação Extensa Seguir um Plano
Ferramentas Contratos
 Colaboração com o
Indivíduos e Interações Software Funcionando Responder a Mudanças
Cliente

Processos e Negociação de
Documentação Extensa Seguir um Plano
Ferramentas Contratos
 Colaboração com o
Indivíduos e Interações Software Funcionando Responder a Mudanças
Cliente

Processos e Negociação de
Documentação Extensa Seguir um Plano
Ferramentas Contratos
 O MANIFESTO ÁGIL
O Manifesto Ágil é uma declaração de valores e princípios
essenciais para o desenvolvimento de software. Ele foi criado em
fevereiro de 2001, onde se reuniram 17 profissionais que já
praticavam métodos ágeis como XP, DSDM, SCRUM, FDD e etc.
Durante a reunião, foram observados os pontos comum de
projetos que tiveram sucesso em suas metodologias e com base
nesse pontos foi criado o Manifesto para Desenvolvimento Ágil de
Software, no qual chamamos de Manifesto Ágil.
O Manifesto Ágil aborda valores que todos os profissionais ali
reunidos acordaram em seguir e disseminar.
 OS 12 PRINCÍPIOS 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.
 Conhecimento

A posteriori A priori
ou empírico

Algo é conhecido a posteriori quando é Algo é conhecido a priori quando é conhecido

conhecido através da experiência (sensorial ou independentemente da experiência e através do
introspectiva), da experimentação. pensamento apenas, da razão, dedução e
reminiscência.
CYNEFIN
Framework Cynefin
CONFUSO
CONFUSO
CONFUSO
 PRODUCT->MARKET FIT

PROBLEM->SOLUTION FIT SCALE

CONFUSO
CONFUSO
 Conhecimento

A posteriori A priori
ou empírico

Algo é conhecido a posteriori quando é Algo é conhecido a priori quando é conhecido

conhecido através da experiência (sensorial ou independentemente da experiência e através do
introspectiva), da experimentação. pensamento apenas, da razão, dedução e
reminiscência.
EMPÍRICO

DETERMINÍSTICO
CONFUSO

SOBREVIVÊNCIA
MODELO DE DIFUSÃO DA INOVAÇÃO
RETARDATÁRIOS
 Lean Proveniente do Lean manufacturing, Toyota

Agile
Um conjunto de valores e princípios

SCRUM Um Framework, assim como outros

O SCRUM
O modelo em cascata
A n á l i se d e
1 N e ces si d ad es
Ciclo de Vida do
Desenvolvimento de
2 D e s i gn Software

3 D e s envo lvi m en t o

4 Testes

5 Manutenção
 Cone dA Incerteza
Em cenários complexos, em decorrência
da incerteza, a precisão das estimativas
aumenta. À medida que o trabalho
progride
Variabilidade das estimativas

Tempo TRANSIÇÃO
CONSTRUÇÃO

ELABORAÇÃO

INICIAÇÃO
 PREDITIVO X ADAPTATIVO

PREDITIVO
Escopo fixo. Os requisitos são
detalhados no começo do projeto.

ESCOPO

QUALIDADE

Incertezas serão acomodadas aqui:

no prazo, nos custos ou em ambos
PRAZO CUSTO
 PREDITIVO X ADAPTATIVO

ADAPTATIVO OU EMPÍRICO
Tolerância zero é criada
CUSTO PRAZO
parar prazo e custos.

QUALIDADE

ESCOPO As incertezas serão acomodadas no

escopo. O escopo precisará ser flexível.
 PILARES DO SCRUM

TRANSPAR ÊNCI A

INSPEÇÃO

ADAPTAÇÃO
GERENCIAMENTO DE PROJETOS
Pilares do SCRUM
transparência
O que esperam de mim e o que eu espero dos outros

A informação tem que ser a mesma,

Independente de quem perguntou ou
Quem respondeu TODOS OS EVENTOS E
ARTEFATOS DO SCRUM
Todos devem entender claramente a
Informação

Inclusive o que não está bem!

Pilares do SCRUM
Inspeção
Os processos, práticas e tarefas devem ser
constantemente observados:

O que posso fazer melhor?

O que não fiz bem? EVENTOS

• DAILY MEETING
• REVIEW
O que posso deixar de fazer?
Pilares do SCRUM
Adaptação
Identificados os pontos críticos, o que preciso fazer para
melhorar?

Como garantir que o que deu errado

Não ocorra novamente?
EVENTOS
• PLANNING
Como garantir que o deu certo volte a • DAILY MEETING
ocorrer? • REVIEW
• RETROSPECTIVE
SCR PAPEIS, EVENTOS E ARTEFATOS
UM
 SCRUM Papéis
Representa o interesse dos clientes, assegura que as entregas adicionem
valor e que o backlog esteja sempre priorizado, atualizado e que reflita
Product Owner aquilo que é mais importante para os usuários, clientes e para a empresa.

Foco prioridades para o negócio, adição de

valor • Líder de uma equipe autogerenciável.
• Tem um papel de mentor, que remove impedimentos e desenvolve
SCRUM Master constantemente as pessoas.
• Tem perguntas, não respostas. Caminha com a equipe num constante
processo que busca identificar o que não está funcionando e o que deve ser
Foco nos processos e no desenvolvimento das mudado.
pessoas

• Time auto-organizado, autogerenciável, empoderado e independente.

Desenvolvedores Possuem autoridade para tomar decisões, assumir riscos e
responsabilidades.
• Equipe multidisciplinar e com profundos conhecimentos sobre sua área de
Foco nas entregas, valor adicionado e em atuação.
uso
 PRODUCT OWNER – DONO DO PRODUTO

• Sempre uma pessoa, não deve ser um grupo ou comitê

• Cada backlog representa apenas um produto e deve ter apenas um Dono de
Produto
• Responsável por garantir que “o produto certo” seja feito
• Responsável pelo que foi produzido também nos sprints, no sentido de “o
que foi produzido”
• Decide quando uma release (liberação) deve ou não ser feita para o cliente
• Responsável por passar informações para stakeholders sobre o andamento
do projeto
 PRODUCT OWNER – DONO DO PRODUTO

• Conhece os interesses do cliente, usuários e stakeholders do projeto ou

produto que está sendo desenvolvido.
• Esse papel precisa conhecer bem sobre o negócio e sobre as “personas” que
utilizarão o produto.
• Tem autoridade na organização para tomar as decisões necessárias, no
momento apropriado. A palavra final sobre o produto é dele.
• Em última instância, é o responsável pelo sucesso do produto sob o ponto de
vista do negócio.
• É a interface entre a equipe scrum e o “mundo externo”.
 PRODUCT OWNER – DONO DO PRODUTO

• É responsável por criar a lista com os requisitos do que será construído e

essa lista recebe o nome de backlog do produto
• É o responsável pelo que está dentro (e pelo que está fora) do backlog do
produto, e pela priorização dos itens.
• É o responsável por detalhar os requisitos para a equipe de desenvolvimento
até que todos tenham um claro entendimento do que deve ser
desenvolvido.
• O nível de detalhes necessário para que a equipe de desenvolvimento
compreenda os requisitos é obtido por meio de conversas e não por
documentos.
• É o único que possui autoridade para mudar a prioridade dos itens do
backlog
 PRODUCT OWNER – DONO DO PRODUTO

• Pode adicionar e remover itens do backlog, desde que isso não interfira no
andamento do sprint.
• Determina os critérios de aceitação, qualidade e restrições de prazo e custos.
• É responsável por fornecer feedback constante sobre o desempenho da
equipe e sobre a qualidade do que foi desenvolvido
• Deve estar 100% disponível para conversar com o time de desenvolvimento,
quando este precisar.
• Aceita ou rejeita um trabalho realizado pela equipe de desenvolvimento.
 PRODUCT OWNER – DONO DO PRODUTO

O que ele/ela tem?

• Autoridade na organização para tomar
decisões sobre o backlog
O que ele/ela não
• Entendimento claro sobre o que tem?
adiciona valor para o cliente
• Pouco envolvimento com a equipe e
• Bom relacionamento, habilidades de pouca disponibilidade para tirar
negociação e de comunicação dúvidas

• Ação do tipo “comando e controle”,

gerenciando percentual de
conclusão de atividades, prazos, etc.
PRODUCT OWNER – DONO DO PRODUTO

Precisam ter um bom

conhecimento de SCRUM.
 SCRUM MASTER
• Tem gestão sobre os processos e não sobre as pessoas
• Comemora as vitórias com o time, incentivando-os e recompensando-os
• Ajuda o time a remover impedimentos (e também remove quando o time
não sabe ou não consegue fazer isso sozinho)
• Faz a mediação de conflitos e ajuda o time a se desenvolver
• Estudioso sobre agilidade, desenvolve-se, desenvolve o time e toda a
organização por meio de treinamentos
• Interage com outros Scrum Masters para melhorar o uso do Scrum na
empresa.
 SCRUM MASTER
• É o técnico do time, um líder servidor.
• Facilita e organiza todos os eventos do scrum (planning, daily, review e
retro)
• Ajuda a equipe a se aprimorar com relação ao framework e ao
desenvolvimento pessoal de cada integrante
• Engaja a todos e facilita a comunicação
• Foca nos pilares do Scrum (transparência, inspeção e adaptação)
• Protege o time de interferências externas, por exemplo, cuidando para que
a Sprint esteja protegida de mudanças.
 SCRUM MASTER
NÃO É O GERENTE DE PROJETOS.

ESSE PAPEL NÃO EXISTE NO SCRUM.

 SCRUM MASTER
• Tem o papel de “mentor” do PO para o refinamento constante do backlog
• Tem a preocupação de ajudar o time na melhoria constante quanto à
produtividade e qualidade, zelando sempre por um ambiente sustentável.
• Tem a responsabilidade de ajudar a equipe a utilizar sua criatividade e o
“espírito de equipe”. Combate o estilo “comando e controle” no ambiente
da equipe.
• Pode ajudar a equipe, orientando com consultoria técnica sobre o
desenvolvimento do produto. Pode ser um “consultor”, mas, não fará o
trabalho da equipe.
• É o ponto de referência sobre o Scrum na equipe e trabalha na
disseminação da cultura na organização.
 SCRUM MASTER
O que ele/ela tem?
• Profundo conhecimento sobre
SCRUM
• Mentoria junto à equipe e ao PO
• Facilitador, bom comunicador e
O que ele/ela não
integrador da equipe tem?
• Algum conhecimento técnico para
aconselhar a equipe • Relação hierárquica com a equipe
• Disposição para auxiliar a • “Mão na massa”, fazendo as tarefas
organização na utilização do SCRUM do sprint
• Estilo de gestão “comando e
controle”
 DEVELOPERS
• São os responsáveis pelas tarefas necessárias para construir as
funcionalidades especificadas pelo PO para cada sprint.
• São os responsáveis por determinar o que é necessário fazer para alcançar a
meta do sprint.
• São auto-organizados e independentes de quaisquer entidades externas para
desenvolver os produtos de um sprint.
• Não há líderes em uma equipe de desenvolvimento. Todos são igualmente
responsáveis pelo sucesso do sprint.
 DEVELOPERS
• O tamanho recomendado para um time de desenvolvimento é de até 8
pessoas (10 com o Scrum Master e Product Owner).
• Integrantes podem ser substituídos quando necessário e todos devem estar
cientes de que isso impactará a produtividade do time por um tempo.
Recomenda-se mudar a equipe sempre ao terminar um sprint.
• Não há outro papel dentro de um time de desenvolvimento (analista,
programador, testador, etc...). Todos são “DEVELOPERS”.
 DEVELOPERS
O que ele/ela tem?
• Transparência em suas ações.
• Busca por melhoria constante.
• Apoio ao PO e ao valor a ser O que ele/ela não
adicionado ao cliente.
• É autogerenciável.
tem?
• Ação individualista e egoísta
• Conhecimento pleno do Scrum, dos
papeis, cerimônias e artefatos do • Dificuldade em assumir
framework. responsabilidades
• Aceitar trabalho que sabe não ser capaz
de fazer no tempo de uma Sprint.
• “Meu trabalho está pronto, a culpa é
dele/a que não fez”.
Time SCRUM
• A figura de gestão, embora exista na organização, não existe na composição do time SCRUM.
• Aqui, o próprio time é o responsável por TODO o trabalho. O time scrum independe de outras pessoas para
desenvolver o produto. A equipe multifuncional possui todo o conhecimento e as habilidades necessárias
para completar o trabalho.
• O time busca continuamente melhorar sua interação e comunicação, reduzindo a carga de gestão e
maximizando a quantidade de trabalho que não é necessário ser feito.
• Times especialistas dão lugar a equipes multifuncionais. Todos os papeis estão presentes.
Valores do SCRUM
 Conceitos do SCRUM
Timebox É A DURAÇÃO MÁXIMA
Timebox é um conceito que diz que a DE UM EVENTO.
quantidade de tempo (horas ou dias, o
que depende das unidades sendo
utilizadas para um determinado
evento) é imutável, ou seja, a
quantidade de tempo não poderá
aumentar caso algum problema ou
novo requisito seja identificado.

GERENCIAMENTO DE PROJETOS
 Conceitos do SCRUM
sprint
Um evento que contém todos os outros eventos do
SCRUM. Uma SPRINT representa um período de 30 dias (ou
menos).

O Sprint pode ser considerado o principal evento do

SCRUM, porque é nele que serão aplicados os demais
Sprint
eventos.

É aqui que ocorre a produção de um produto ou parte

dele.
Daily
Todos os Sprints devem possuir uma estrutura
exatamente igual. As funcionalidades construídas no
Sprint são provenientes dos IBLs (itens de backlog)
selecionados.

GERENCIAMENTO DE PROJETOS
 CONCEITOS DO SCRUM
SPRINT
A duração de um Sprint deve considerar:

• O tempo entre uma release e outra;

• O nível de incerteza envolvido no produto;
• A disponibilidade do PO e dos clientes para o
feedback;
• A sobrecarga de trabalho em cada Sprint
(manter equilibrado);
• A velocidade do time comparada com a
quantidade de trabalho necessária para
produzir um incremento de produto;
 CONCEITOS DO SCRUM
Algumas equipes utilizam o conceito de
SPRINT sprint0, que é um sprint que tem o
objetivo de preparar o ambiente e o
A duração de um Sprint deve considerar: backlog do produto.
ESSE CONCEITO NÃO EXISTE NO SCRUM.
• O tempo entre uma release e outra;
• O nível de incerteza envolvido no produto;
• A disponibilidade do PO e dos clientes para o
feedback;
• A sobrecarga de trabalho em cada Sprint
(manter equilibrado);
• A velocidade do time comparada com a
quantidade de trabalho necessária para
produzir um incremento de produto;
 SCR
UM Sprint - x
Até 30 dias
1º 2º 3º 4º 5º 6º 7º 8º 9º 10º

Sprint X
Revisão
Planejamento – Sprint X

Retrospectiva
Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária Reunião diária

GERENCIAMENTO DE PROJETOS
 CONCEITOS DO SCRUM
Backlog do Produto Alta Histórias
• Criado a partir da Visão do Produto
A
• Geralmente composto por Histórias de Usuário
B
(User Stories)
C
• É uma lista ordenada de tudo aquilo que é

Prioridade
necessário para criar o produto. D

• Constituído e priorizado pelo Product Owner E

• O que estiver fora desta lista não será feito. F

• O Backlog do Produto contém requisitos de G

negócio, não funcionais, melhorias, correções,
H
testes de arquitetura, etc.
I

Baixa
 CONCEITOS DO SCRUM
O Dono do Produto e o Backlog do Produto
• O Dono do Produto é o Dono do Backlog do Produto!
• Ele prioriza os itens de maior valor para o negócio!
• É ele quem adiciona ou remove os itens do backlog
• É o responsável por refinar constantemente o backlog,
mantendo os itens do topo (prioritários) no nível de
detalhamento necessário para que o time construa a
funcionalidade.
• Pode (e deve) contar com a ajuda do DEVELOPERS.
• Mantém o backlog transparente para TODA a organização.
 CONCEITOS DO SCRUM
Backlog do Produto Alta Histórias

• Nunca está totalmente pronto, está em constante A

evolução (ambiente complexo) B

• Antes de cada Sprint o dono do produto faz a re- C

priorização do Backlog

Prioridade
D
• O backlog é constantemente refinado (antigo
E
Grooming, atual Refinement)
F
• Por que? – Para prover mais detalhes sobre
determinado requisito, à medida que esses detalhes G
estejam disponíveis H
• Quem? – Todo o Time SCRUM I

Baixa
 CONCEITOS DO SCRUM
Backlog do Produto Alta Histórias
• Criado a partir da Visão do Produto
A
• Geralmente composto por Histórias de Usuário
B
(User Stories)
C
• É uma lista ordenada de tudo aquilo que é

Prioridade
necessário para criar o produto. D

• Constituído e priorizado pelo Product Owner E

• O que estiver fora desta lista não será feito. F

• O Backlog do Produto contém requisitos de G

negócio, não funcionais, melhorias, correções,
H
testes de arquitetura, etc.
I

Baixa
BACKLOG DO PRODUTO
 BACKLOG DEEP E REQUISITOS INVEST
Alta Histórias

B
OS REQUISITOS DEVEM SER

INVEST
C
Prioridade

Independente
Negociável
Valiosa
Estimável
S Pequena
Testável
Baixa
META DO PRODUTO
• Estado futuro do produto;

• A Meta do produto está no Product Backlog

• O Backlog do Produto emerge para definir "o que" a meta do produto irá
cumprir.

A Meta do Produto é o objetivo de longo prazo para o Scrum Team.

Eles devem cumprir (ou
abandonar) um objetivo antes de assumir o próximo
DEFINIÇÃO DE FEITO (DONE) - DoD
• Todos precisam ter clareza de quando um produto está pronto para ser
lançado

• A organização deve determinar os seus critérios

• Os times, a partir dos critérios organizacionais, criam e refinam suas

definições de pronto
DEFINIÇÃO DE FEITO (DONE) - DoD
META DA SPRINT
• É o único objetivo da Sprint;

• Cria coerência e foco, encorajando o Scrum Team a trabalhar junto ao invés

de iniciativas separadas.

• Se o trabalho acabar sendo diferente do que eles esperavam, eles

colaboram com o Product Owner para negociar o escopo do Sprint Backlog
dentro da Sprint sem afetar a Meta da Sprint.
Sprint Planning
A meta do sprint, definida durante a
Incrememento de produto reunião de sprint planning, corresponde a
um passo em direção à meta da release ou
de roadmap.
Meta do sprint
Deve ser uma frase curta e mensurável ao
final do sprint, garantindo assim que
Meta do Produto todos saibam dizer se ela foi ou não
alcançada. Se a meta se tornar obsoleta,
o Developers informa o po e o sprint pode
Visão do produto ser cancelado por ele.
FRAMEWORK SCRUM
Framework SCRUM

Backlog do Produto
MODELO DE TUCKMAN
Dissolução

Formação Desempenho

Acordo

Conflito
MODELO DE TUCKMAN
Framework SCRUM

Backlog do Produto
SPRINT PLANNING

• Por que esta Sprint é

valiosa?

• O que pode ser feito

nesta Sprint?

• Como o trabalho
escolhido será
realizado? (COMO)
Sprint Planning
1 2 3
Backlog do Produto

Performance e
Capacidade do Time

Definição de Pronto
PRIMeIRO TÓPICO: SEGUNDO Tópico : O que terceiro Tópico: Como o
Compromissos da Por que esta Sprint é pode ser feito nesta trabalho escolhido
Retrospectiva
valiosa Sprint? será realizado?
Incremento de produto .

Saída: Backog da Sprint

Framework SCRUM

Backlog do Produto
Framework SCRUM

Backlog do Produto
Framework SCRUM

Backlog do Produto
 Conceitos do SCRUM
DAILY SCRUM
O objetivo do Daily Scrum é inspecionar o progresso em
direção à Meta da Sprint e adaptar o Sprint Backlog
conforme necessário, ajustando o próximo trabalho
planejado.

O Daily Scrum é um evento de 15 minutos para os

Desenvolvedores do Time Scrum. Para reduzir a
complexidade, ela é realizada no mesmo horário e local
todos os dias úteis da Sprint

As Daily Scrums melhoram a comunicação, identificam

impedimentos, promovem a agilidade na tomada de decisões
e, consequentemente, eliminam a necessidade de outras Daily
reuniões.

GERENCIAMENTO DE PROJETOS
 DAILY SCRUM
OBJETIVO
Cada membro deve responder as seguintes perguntas:
 O que fiz ontem que ajudou a equipe de desenvolvimento a
atingir o objetivo da Sprint?
 O que vou fazer hoje para ajudar a equipe de desenvolvimento a
alcançar o objetivo da Sprint?
 Vejo qualquer impedimento que me impede ou a equipe de
desenvolvimento de cumprir o objetivo da Sprint?

DURAÇÃO
 15 minutos (não mais que isso)
 Realizadas no mesmo horário e local para reduzir a
complexidade
Framework SCRUM

Backlog do Produto
Framework SCRUM

Backlog do Produto
 MUDANÇAS NO SPRINT
• O que foi acordado para o Sprint não deve
mudar.

• Entre os Sprint, o PO pode (e deve) reclassificar

a lista

• A composição do time, a qualidade acordada,

a meta do sprint e os itens de backlog não
mudam durante o sprint
 SPRINT REVIEW
Objetivo principal
• Mostrar o que foi produzido no sprint.

Quem participa
• Product Owner, SCRUM Master, membros do time,
clientes, usuários, stakeholders e qualquer pessoa que
esteja interessada no resultado da sprint;
• Qualquer participante pode falar, fazer perguntas ou
observações;
Duração
• 4 horas para um sprint de 1 mês. É proporcional.
 SPRINT – ABORTAR MISSÃO
Um Sprint pode ser cancelado caso o objetivo se
torne obsoleto.

Lembre-se que apenas o Dono do Produto tem

autoridade para cancelar um Sprint.

Após um cancelamento, os produtos concluídos

são disponibilizados para a revisão, a retrospectiva
é realizada, os itens não concluídos retornam ao
backlog e nova reunião de planejamento de sprint
é realizada logo em seguida.
 SPRINT REVIEW
Objetivo principal
• Mostrar o que foi produzido no sprint.

Quem participa
• Product Owner, SCRUM Master, membros do time,
clientes, usuários, stakeholders e qualquer pessoa que
esteja interessada no resultado da sprint;
• Qualquer participante pode falar, fazer perguntas ou
observações;
Duração
• 4 horas para um sprint de 1 mês. É proporcional.
 LEMBRE-SE DA DEFINIÇÃO DE PRONTO

A definition of done, ou simplesmente DOD, é um acordo formal do scrum team que define
claramente quais são os passos mínimos para a conclusão de um item potencialmente
entregável.

Serve como um contrato entre o SCRUM Team e o Product Owner, garantindo que todo o
produto gerado pelo projeto estará dentro dos padrões de qualidade estabelecidos entre eles.
É uma forma de se buscar a excelência, especialmente em um cenário multi-iterativo

Os requisitos/histórias são divididos em tarefas durante o planejamento de sprint . o DOD é

usado para validar se todas as principais tarefas são contabilizadas. É como uma lista de
verificação para checar se todas as atividades necessárias foram concluídas
LEMBRE-SE DA DEFINIÇÃO DE PRONTO
 SPRINT REVIEW
O dono do produto explica quais itens do backlog do produto foram "concluídos" e o que
não foi "feito";

A equipe de desenvolvimento demonstra o trabalho que tem "feito" e responde

perguntas sobre o incremento;

A equipe de desenvolvimento discute o que aconteceu bem durante o sprint, quais os

problemas encontrados e como esses problemas foram resolvidos (na perspectiva do
produto);

O dono do produto discute e adapta o backlog do produto.

Todo o grupo colabora sobre o que fazer em seguida, de modo que o sprint review
forneça uma contribuição valiosa para o planejamento sprint subsequente;

Mudanças no mercado, na expectativa dos clientes e de prioridades são discutidas aqui.

Há uma revisão de orçamento, tempo, mercado e restrições em geral para o próximo

lançamento (release) do produto
 SPRINT RETROSPECTIVE
O b jetivo p r i n cip al
• A retrospectiva sprint é uma oportunidade
para a equipe scrum se inspecionar e criar um
plano para melhorias a serem promulgadas
durante o próximo sprint.

O b jetivos s e cundár ios

• Inspecionar como o último sprint foi
relacionado às pessoas, relacionamentos,
processos e ferramentas;
• Crie um plano para implementar melhorias na
forma como o scrum team faz o seu trabalho
 SPRINT RETROSPECTIVE
O b jetivo p r i n cip al
• A retrospectiva sprint é uma oportunidade
para a equipe scrum se inspecionar e criar um
plano para melhorias a serem promulgadas
durante o próximo sprint.

O b jetivos s e cundár ios

• Inspecionar como o último sprint foi
relacionado às pessoas, relacionamentos,
processos e ferramentas;
• Crie um plano para implementar melhorias na
forma como o scrum team faz o seu trabalho
 SPRINT RETROSPECTIVE
O b jetivo p r i n cip al
• A retrospectiva sprint é uma oportunidade
para a equipe scrum se inspecionar e criar um
plano para melhorias a serem promulgadas
durante o próximo sprint.

O b jetivos s e cundár ios

• Inspecionar como o último sprint foi
relacionado às pessoas, relacionamentos,
processos e ferramentas;
• Crie um plano para implementar melhorias na
forma como o scrum team faz o seu trabalho
 SPRINT RETROSPECTIVE
O que Funcionou O que não funcionou
Faltou
Testes melhor
planejamento
do Sprint

Usuário
Distante

Comunicaçã
o entre os
Reuniões membros
Diárias Alguns
membros
chegam
tarde
 PRODUCT->MARKET FIT

PROBLEM->SOLUTION FIT SCALE

MODELO DE DIFUSÃO DA INOVAÇÃO
RETARDATÁRIOS
LEAN STARTUP

Medir

Aprender

Construir
Empírico x Adaptativo
PREDITIVO
Escopo fixo. Os requisitos são
detalhados no começo do
projeto.

ESCOPO

QUALIDADE

Incertezas serão
acomodadas aqui: no prazo,
PRAZO CUSTO nos custos ou em ambos
Empírico x Adaptativo
ADAPTATIVO OU EMPÍRICO
Tolerância zero é criada
parar prazo e custos.
CUSTO PRAZO

QUALIDADE

ESCOPO As incertezas serão

acomodadas no escopo. O
escopo precisará ser flexível.
CONCEITOS DO SCRUM
Mudanças e Incertezas
Mudanças e Incertezas
Conceitos do SCRUM
Visão

Roadmap

Release

Sprint

Daily
Sobre o Roadmap
Conceitos do SCRUM
Releases

Release

Sprint

Daily
 Conceitos do SCRUM
Release Planning
O plano de releases determina o objetivo dos
“lançamentos para o mercado”, definindo as
entregas de maior prioridade e considerando mitigar
os principais riscos
Release
Um plano de release pode ser compreendido como a
visão do produto distribuída numa linha do tempo, Sprint
estabelecendo possíveis datas de liberação.
Trata-se, também, de uma ferramenta para que o
Daily
P.O. controle os custos incorridos no
desenvolvimento do produto.
 MAIS HISTÓRIAS DE USUÁRIOS

Temas épicos e histórias de usuários

Épico história história história

história história história

história história história

Tema história história história história história história

história história história história história história

história história história história história história

 HISTÓRIAS DE USUÁRIOS
Cartão, conversa e confirmação
FRENTE

VERSO
 Priorizando o Backlog
M O S COW

M Us SeTmH AiVsEs: o o p r o d u t o é O dono do produto é livre para

inviável. determinar os critérios de valor
O para o negócio que utilizará para
S é de extrema importância
HOULD HAVE:
definir as prioridades. Ex: roi,
riscos, dependências, time to
C OéU LdDeHsAeVjEá: v e l . market, etc...
O
W Os Ne’rTi aH A lVeE :g a l t e r , m a s , n ã o
faremos agora.
CICLO DE VIDA DO PRODUTO
Conceitos do SCRUM
Story Mapping
 Conceitos do SCRUM
Product Vision Box
Crie uma caixa figurativa
que represente seu
produto.
Conceitos do SCRUM
Modelo KANO Satisfação

"Não sabia que

queria, mas eu
gosto disso". De desempenho

Encantamento

Qualidade Qualidade
insuficiente suficiente

Básicas "Não vai aumentar

minha satisfação,
mas pode diminuir".

Insatisfação
 HISTÓRIAS DE USUÁRIOS - SPIKE

SPIKE
• Uma SPIKE é uma user story com
pouca ou nenhuma definição.

• Uma história ou tarefa destinada a

responder uma pergunta ou a coletar
informações, em vez de produzir
entregas
 HISTÓRIAS DE USUÁRIOS - SPIKE

Escrevendo uma boa SPIKE

• Seja claro sobre o conhecimento que você está
tentando obter e sobre os problemas que você
está tentando abordar.

• Seja timeboxed. Spikes deve ser timeboxed para

que você faça apenas o trabalho suficiente para
obter o valor necessário.
 ESTIMATIVAS ÁGEIS
Um ponto de história É uma unidade
de MEDIDA, que faz sentido para o
time SCRUM e indica se a história é
grande ou pequena. Dessa forma, o
time de desenvolvimento realiza as
estimativas baseando-se no tamanho
relativo das histórias, e não no tempo
para sua implementação. O valor em
si não é importante, o que importa é o
valor relativo!
ESTIMATIVAS ÁGEIS – STORY POINTS

PLANNING POKER
 PLANNING POKER
É uma técnica baseada em consenso e
gamificada para estimar, usada
principalmente para estimar o esforço
ou o tamanho relativo das histórias de
usuário ou requisitos. O planning
poker tem o objetivo de eliminar a
ancoragem das estimativas, quando o
primeiro número falado em voz alta
estabelece um precedente para as
estimativas subsequentes.
Conceitos do SCRUM
E aí galera,
quanto tempo
isso vai levar?

1 3
Conceitos do SCRUM
E aí galera,
quanto tempo
isso vai levar?

1 3
 ESTIMATIVAS ÁGEIS – IDEAL DAYS

Dias ideais não são como “dias de calendário”

Dias Ideais correspondem à quantidade de

trabalho que um profissional de nível sênior,
com fluência nas tecnologias e ferramentas
envolvidas consegue realizar em 08 (oito) horas
de trabalho dedicadas (sem interrupções).
ESTIMATIVAS ÁGEIS – IDEAL DAYS
O Total Cost of Ownership (TCO), em é uma
métrica de análise que tem como
objetivo calcular os custos de vida e de
aquisição de um produto.

O conceito de TCO existe há mais de cem

anos, suas raízes datam do primeiro
quarto do século XX. O Grupo Gartner
popularizou-o nos anos oitenta..

Débito técnico é uma das grandes causas de um

TCO desfavorável!
 O TCO de um produto pode ser dividido em três
grande grupos de custos:

• Custos para o
desenvolvimento/aquisição do produto
Custo de Custo de
compra operação • Custos de operação/uso do produto

• Custos de suporte/manutenção do
produto
Custo de
manutenção O dono do produto deve considerar todos
os grupos de custos para maximizar o ROI e
reduzir TCO.
COMO MELHORAR O ROI DO PRODUTO (E REDUZIR O TCO)
• Priorizar funcionalidades com maior percepção de valor.

• Entregar rápido, pegar feedback rápido, aprender rápido e

errar cedo!

• Corrigir os erros e refatorar o código e o design

• Automatizar testes

• Preocupar-se sempre com a qualidade do produto.

• Planejar estrategicamente as releases

Mudanças ao longo do tempo “custam caro”

O tempo de desenvolvimento é cada vez mais

alto

A capacidade nas sprints é reduzida

A equipe se desmotiva e abandona o produto

O cliente fica satisfeito no começo e, depois,

descontente para sempre

“Por fora bela viola, por dentro pão

bolorento”
REFINEMENT DO BACKLOG E DEFINIÇÃO DE READY

Os itens podem ter uma

definição de “ready” Product Backlog
significa que as histórias
podem ser “puxadas” pela
equipe.

A equipe deve ser capaz

de determinar o que
Priorizar
precisa ser feito e a
Estimar
quantidade de trabalho Criar e Refinar
necessária para completar
a história do usuário.
 Sprint Planning
SPRINT BACKLOG
Sprint Planning
 Sprint Backlog
IBLs A FAZER FAZENDO FEITO

[IBL001]

[IBL003]

[IBL002]
• À medida que o integrante da equipe
conclua sua atividade, ele PUXA uma
outra atividade do Backlog

• O time refina suas tarefas ao longo do

Sprint
BURNDOWN CHART
ESTIMATIVA VELOCITY
ESTIMATIVA VELOCITY
BURNUP CHART
BURNDOWN CHART
 BURNDOWN CHART

O burndown da release é um instrumento poderoso para

que o dono de produto acompanhe o trabalho restante
até o alcance de um objetivo de lançamento. Ele é
consultado ao final do sprint!
BURNDOWN CHART
 BURNDOWN CHART

ESTIMATIVA MÁXIMA E MÍNIMA DE

ENTREGA, COM BASE NO MELHOR E PIOR
CENÁRIO. CONHECENDO A ORDENAÇÃO
DO BACKLOG, É POSSÍVEL SABER SE MUST,
SHOULD OU COULD FICARÃO DE FORA
 BURNDOWN CHART

ESTIMATIVA DE QUANDO CONSEGUIMOS

ENTREGAR TODO O ESCOPO (MÁXIMO E
MÍNIMO) COM BASE NOS CENÁRIOS.
Gerir a mudança é estar sempre atento aos fatores que nos
prendem ao estado atual”