O documento fornece uma introdução à história, princípios e práticas do framework Scrum para desenvolvimento de produtos complexos. Ele descreve os pilares do Scrum (transparência, inspeção e adaptação), os papéis (ScrumMaster, Product Owner e Time de Scrum) e o ciclo básico de uma Sprint no Scrum.

1. “um framework para desenvolver produtos
complexos em ambientes complexos”
Rafael Sabbagh, CSM, CSP
Marcos Garrido, CSPO

2. Agenda
PARTE 1
• Um pouco de história
• Agilidade
• Scrum
– Pilares
– Papéis
– Ciclo do Scrum
PARTE 2
• Scrum vs. Métodos Tradicionais
• Caso real: Aplicação de Scrum em
projeto na Petrobras

3. Um pouco de história...
• Década de 50: a gestão de projetos é reconhecida como disciplina,
nascida a partir da administração
• Henri Fayol:
– Seu trabalho é a base para a gestão de projetos tradicional
– O gestor possui 5 funções básicas:
• O gráfico de Gantt é adotado como ferramenta para listar,
acompanhar e controlar a execução das tarefas contidas em um
projeto.
• Até então a gestão de projetos é voltada para grandes projetos de
engenharia e construção civil.
Planejar Organizar Comandar Controlar Coordenar

4. Um pouco de história...
• Década de 60: o desenvolvimento de software
começa a ganhar complexidade.
• Para gerenciar projetos de software, as empresas
utilizam a medotologia tradicional antes aplicada a
projetos de engenharia e construção civil.
• Problemas começam a surgir: desenvolvimento de
software exige mudanças frequentes
• Winston Royce (1970): artigo criticando a abordagem
tradicional para a gestão de projetos de software,
que fica conhecida como waterfall.

5. Um pouco de história...
• Waterfall, por Winston Royce (1970)

6. Um pouco de história...

7. Um pouco de história...
• Waterfall segue o conceito Big Design Up
Front (BDUF).
• Os defensores do BDUF acreditam que o
tempo gasto revisando exaustivamente a
especificação garante a ausência de
mudanças críticas na fase de execução.
• McConnell (1996): “corrigir erros ainda na
fase de especificação gasta entre 50 e 200
vezes menos tempo do que se o erro fosse
encontrado durante a execução do projeto”.

8. Um pouco de história...
• Meredith & Mantel: “problemas de
comunicação e entendimento do que deve
ser feito são responsáveis por falhas nos
projetos”.
• Metodologias tradicionais sugerem que:
– Mudanças devem ser evitadas a todo custo.
– Se não for possível evitá-las, o gerente de projetos
deve gerenciá-las.
• Para as metodologias tradicionais, a
mudança pode ter um efeito devastador

9. Um pouco de história...
• DeGrace & Stahl (1990): Fatores que tornam
questionável o uso de BDUF para projetos de
software:
– Requisitos não são completamente compreendidos no
início do projeto;
– Usuários só sabem exatamente o que querem após ver
uma versão inicial do software;
– Requisitos mudam durante o processo de
desenvolvimento;
– Novas ferramentas e tecnologias tornam a estratégia
de desenvolvimento imprevisível.
• Isso se aplica a diversos outros tipos de projeto
• BDUF é considerado adequado apenas para projetos
estáveis, com pouca ou nenhuma mudança.

10. Um pouco de história...
• Se você ainda não conhece o
problema, como especificá-lo
corretamente?
• Solução é usar o método:
– Cálculo Hipotético Utilizando Técnicas
Estatísticas

11. Um pouco de história...
• Se você ainda não conhece o
problema, como especificá-lo
corretamente?
• Solução é usar o método:
– Cálculo Hipotético Utilizando Técnicas
Estatísticas

12. Um pouco de história...
• Se você ainda não conhece o
problema, como especificá-lo
corretamente?
• Solução é usar o método:
CHUTE

13. Um pouco de história...
• Questões importantes:
– Ainda existem projetos com pouca ou
nenhuma mudança?
– O que acontece quando um projeto com
muitas mudanças é gerenciado da forma
tradicional?
• “A pior coisa que pode acontecer
é o cliente receber exatamente
aquilo que comprou”

14. Um pouco de história...

15. Um pouco de história...
Fonte: Standish Group
Chaos Report – Sucesso em Projetos de Software
Recente pesquisa no Brasil com gerentes
de projeto aponta a mudança de escopo
(71%) como o fator principal para
insucesso em projetos de software

16. Agilidade

17. Manifesto Ágil
"Estamos descobrindo maneiras melhores de desenvolver software fazendo-
o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho,
passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os
itens à esquerda."
2001 - representantes de processos leves de
desenvolvimento de software se reuniram para discutirem o
que seus processos possuíam em comum.
O resultado foi o Manifesto Ágil:

18. Princípios Ágeis
• Satisfação do cliente através da entrega rápida e
frequente de produto funcional
• Produto funcional é a principal medida de progresso do
projeto
• Mudanças são vistas como parte natural do processo e
são bem-vindas
• Cooperação diária entre a equipe de projeto e o pessoal
de negócios
• Comunicação aberta dentro da equipe

19. Princípios Ágeis
• Equipe de pessoas motivadas, com o suporte necessário
e confiança
• Atenção contínua para o bom design e excelência técnica
• Simplicidade. Nada de desperdícios!
• Equipes autogerenciadas: Empowerment!
• Foco maior nas pessoas do que nos processos
• Melhoria contínua

21. Aplicação
Métodos Ágeis não servem apenas
para desenvolvimento de software!

22. Aplicação
Métodos ágeis podem ser utilizados em
projetos em que há:
- Ambiente de mudanças frequentes
- Requisitos
- Tecnologia
- Leis e regras
- Ambiente de incertezas
- Necessidade de entrar rapidamente
no mercado
- Oportunidades
- Responder a uma ameaça

23. Aplicação
Exemplos:
• Alexandre Magno (CST): Scrum
Executivo – mudança organizacional
• Projetos de Publicidade/Marketing
– Ex: Accenda (http://grupoaccenda.com.br)
• Projetos de Hardware
• Infra-estrutura
• Jogos olímpicos, Copa do mundo…

24. O que é Scrum?

25. Scrum...
• ...é um framework para desenvolvimento de produtos
complexos em ambientes complexos;
• ...não é um processo ou técnica: dentro de Scrum
podem-se empregar diversos processos e técnicas;
• ...utiliza abordagem iterativa e incremental para
melhorar a predizibilidade e o controle de riscos;
• ...gera entrega frequente de valor para o cliente;
• ...torna transparentes problemas das práticas de
desenvolvimento, para que se possa melhorá-las;
• ...utiliza inspeção e adaptação para melhoria
contínua, em ciclos de feedback.

26. Scrum: Origens
• Ken Schwaber: www.controlchaos.com
• Jeff Suttherland: jeffsutherland.com
• Mike Beedle: www.mikebeedle.com
• “The New New Product Development
Game”, de Takeuchi e Nonaka
• Sistema de Produção da Toyota: modelo
enxuto e just-in-time

27. Processos Definidos X Empíricos
• Processo definido
– Ambientes controlados – ex: linhas de produção
• Processo empírico:
– Complexos e imprevisíveis
• Scrum é embasado na teoria de controle de
processos empíricos
• Três pilares sustentam a teoria de controle
de processos empíricos: Transparência,
Inspeção e Adaptação

28. Pilares

29. Os Pilares do Scrum
• #1: Transparência
– Aspectos que afetam o resultado do
projeto devem ser visíveis para os
que gerenciam estes resultados
– O que é visto deve ser compreendido:
se quem inspeciona o processo
acredita que está pronto, isso deve
corresponder à definição de pronto
utilizada

30. Os Pilares do Scrum
• #2: Inspeção
– Deve haver inspeção no processo
com frequência suficiente para se
detectar variações inaceitáveis

31. Os Pilares do Scrum
• #3: Adaptação
– Ao se detectar variações
inaceitáveis, o processo deverá ser
ajustado o tão rápido quanto
possível para se minimizar desvios
ainda maiores

32. Introdução ao
Ciclo do Scrum

33. O Ciclo do Scrum
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
o BACKLOG DA SPRINT
em
u
d
m
E
e
A
a
m
s
o
e
l
i
c
s
n
f
A
a
i
t
v
n
a
d
o
e
a
a
p
l
q
l
v
r
u
d
i
m
o
i
o
i
p
a
r
e
e
i
,
c
z
n
i
a
c
e
t
o
d
l
n
e
o
,
a
t
q
ã
c
d
,
u
o
h
e
c
i
p
a
h
s
d
e
m
a
e
e
m
f
a
s
r
a
e
d
e
a
z
ú
o
n
d
u
n
v
a
d
m
e
o
e
l
a
v
c
S
o
i
m
r
P
m
e
e
R
u
n
o
n
I
N
t
i
o
ã
T
,
o
a
d
e
maiBsr
A
p
e
e
C
r
1
p
q
i
o
5
r
K
u
e
r
L
i
m
i
s
p
t
O
á
e
e
i
n
r
n
G
i
t
u
o
t
e
a
s
t
D
r
o
n
á
n
s
O
t
e
o
p
p
P
r
d
m
a
o
R
o
r
d
o
a
O
u
c
m
p
l
z
D
i
e
r
i
d
o
U
n
o
m
T
t
o
e
u
O
o
n
m
v
a
e
i
r
n
R
v
c
E
i
r
s
e
U
i
b
m
N
i
l
e
i
I
d
Ã
n
a
O
t
o
d
e
D
n
o
e
E
p
r
R
o
d
E
u
V
t
o
I
S
,Ã
q
O
u
e
e
s
c
a
i
g
o
p
n
m
r
i
e
f
u
i
s
c
n
e
a
i
n
c
v
t
a
a
ç
l
o
ã
r
o
q
p
u
a
e
r
a
f
o
o
ifceliteonte
O repreEsle
n
e
t
n
a
t
A
n
A
ã
t
o
e
e
q
i
q
d
n
E
u
u
o
s
,
i
p
e
p
c
e
e
r
e
l
m
e
i
e
e
f
e
n
a
n
s
s
t
z
e
t
e
ã
t
g
e
o
,
o
u
s
o
t
i
s
r
d
r
P
a
e
e
a
b
R
q
,
r
a
e
u
O
s
l
ú
i
h
e
s
D
n
o
i
r
t
U
e
o
n
C
ú
s
c
o
n
o
T
c
e
m
i
c
p
l
o
a
r
d
a
e
a
O
W
N
E
R
r
,
e
l
p
e
r
v
e
a
s
R
n
e
E
t
n
a
T
t
a
c
R
n
o
O
t
m
e
S
d
o
P
o
E
c
l
c
C
i
e
l
i
T
e
n
I
n
t
V
e
t
e
A
r
e
,
e
q
o
d
u
n
e
i
d
s
c
e
i
t
i
d
o
v
e
s
e
,
r
a
i
f
i
c
p
a
a
r
o
t
i
r
q
u
e dessfaunlicsitoandoeur
b
e
e
q
m
u
ise
it
osq
,
u
o
e
q
p
u
o
e
d
e
s
e
m
r
á
e
l
f
h
e
o
i
t
r
o
a
rno
no próxpirmóxoimcioclocicdleod
d
e
e
s
d
e
e
n
s
v
e
o
n
l
v
v
i
m
o
l
v
e
i
n
m
t
o
e
:
n
t
o

34. Papéis

35. Papéis no Scrum
• ScrumMaster:
– responsável por garantir que o processo
é entendido e seguido
• Product Owner:
– responsável por maximizar o valor, para
o cliente, do trabalho que o Time de
Scrum faz
• Time de Scrum:
– é a equipe, que faz o trabalho
propriamente dito

36. Papéis no Scrum: O ScrumMaster
• Garante a adesão do time aos valores do Scrum,
práticas e regras
• Ajuda o Time de Scrum e a organização a adotarem
o Scrum
• Remove os impedimentos que atrapalham o trabalho
do Time de Scrum
• Ajuda o Time de Scrum a usar o auto-gerenciamento
e a multidisciplinaridade, a ser mais produtivo e a ter
mais qualidade
• O ScrumMaster não gerencia o Time de Scrum: o
Time de Scrum é auto-organizável

37. Papéis no Scrum: O Product Owner
• Gerencia a lista de requisitos (Backlog do Produto)
através do contato frequente com o(s) cliente(s), e
garantir sua visibilidade a todos
• Assegura o valor do trabalho realizado pelo Time de
Scrum: garante o ROI do cliente
• Gerencia a visão do produto: estabelece, mantém e
comunica
• Gerencia as entregas do produto para o cliente
• É sempre uma pessoa, e não um comitê. Mas pode
ser aconselhado/influenciado por outras pessoas
• Suas decisões devem ser respeitadas: ninguém mais
pode mudar as prioridades

38. Papéis no Scrum: O Time de Scrum
• É a equipe de desenvolvimento do projeto, com 5 a 9
membros, que:
• Transformam a lista de requisitos (Backlog do
Produto) em incrementos de funcionalidades
potencialmente entregáveis em cada iteração
• São multidisciplinares: todo conhecimento necessário
para gerar o incremento
• Não há títulos no Time de Scrum
• Gerenciam a iteração de desenvolvimento
• São auto-organizáveis: ninguém diz ao Time de
Scrum como transformar o Backlog do Produto em
incrementos entregáveis.

39. O Ciclo do
Scrum

40. Backlog do Produto
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Pro
O
dP
uc
ro
t d
O
u
w
cn
t e
O
rw
le
nv
ea
rn
in
ta
se
cr
o
e
m
es
ot(e
ss
)
cliente(sre) q
o
u
s
i
s
r
e
i
t
q
o
u
s
i
s
n
i
o
t
o
B
sA
m
C
a
K
i
s
L
p
O
r
G
i
o
r
D
i
t
á
O
r
i
o
s
n
a
q
u
e
P
l
e
R
m
O
o
D
m
U
e
T
n
O
t
o

41. O que é o Backlog do Produto?
• É uma lista incompleta e dinâmica dos requisitos do
produto, ordenados por prioridade de desenvolvimento
• A prioridade é determinada por: valor que gerará ao cliente
naquele momento, risco e necessidade
• Contém funcionalidades, correções de bugs, tecnologias e
melhorias que constituem a mudança que será
implementada no produto
• O Product Owner é o responsável por atualizar, priorizar e
dar visibilidade ao Backlog do Produto
• Nunca está completo – evolui à medida que o produto e o
ambiente evoluem
• Seus itens possuem descrição e estimativa em pontos de
esforço. Itens do alto da lista são de menor granularidade e
mais detalhados

42. Reunião de Planejamento da Sprint
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum então se reúne com o
Product Owner e decide, a partir do
Backlog do Produto, o que será feito no
próximo ciclo de desenvolvimento:
o BACKLOG DA SPRINT

43. O que é a Reunião de Planejamento da Sprint?
• Planejamento da iteração:
– Time de Scrum e Product Owner defininem que
itens do Backlog do Produto serão
implementados na Sprint e os quebram em
tarefas - Backlog da Sprint
• 1a. Parte: O quê?
– Escolha de itens mais prioritários do Backlog do
Produto a serem implementados
– Definição da Meta da Sprint
• 1a. Parte: Como?
– Time de Scrum quebra itens em tarefas e estima
o tempo que levará para realizar cada tarefa

44. O que é o Backlog da Sprint?
• Composto por uma lista dos itens que serão desenvolvidos
durante a Sprint, as tarefas correspondentes, o andamento
e as estimativas
• Os itens são selecionados do Backlog do Produto na
Reunião de Planejamento da Sprint
• Cada item é quebrado em tarefas. Parte das tarefas é
definida no Planejamento da Sprint, parte ao longo do
Sprint
• O Backlog da Sprint é modificado ao longo da Sprint –
estimativas são atualizadas, tarefas podem surgir para os
itens já existentes
• Deve ter alta visibilidade
• Pertence ao Time de Scrum

46. A Sprint
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum faz o trabalho no ciclo
de desenvolvimento, a SPRINT

47. O que é a Sprint? (1/2)
• Sprint é a iteração (ciclo) de desenvolvimento
– Reunião de Planejamento da Sprint
– Trabalho de Desenvolvimento
– Revisão e Retrospectiva da Sprint
• Cada Sprint deve ter uma Meta
• Tem duração fixa (de 2 semanas a 1 mês) e
ocorrem uma atrás da outra
– Duração deve contemplar horizonte curto suficiente
para que mudanças não alterem a Meta
• ScrumMaster deve assegurar que não seja
feita nenhuma mudança que afete a Meta da
Sprint

48. O que é a Sprint? (2/2)
• Cada Sprint deve ter como saída um
incremento do produto
potencialmente entregável
• A Sprint pode ser cancelada se a
Meta da Sprint perder o sentido –
somente Product Owner pode decidir
• É muito raro a Sprint ser cancelada

49. A Reunião Diária
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24
HORAS
Em cada dia, o Time de Scrum faz uma
reunião de 15 minutos para promover
visibilidade e comunicação

50. O que é a Reunião Diária?
• Reunião de 15 minutos realizada todo dia no mesmo
local, à mesma hora.
– Visibilidade
– Comunicação
– Decisão rápida
• Cada membro do Time de Scrum detalha:
– O que ele completou desde a última reunião diária;
– O que ele vai fazer antes da próxima reunião diária;
– Quais obstáculos estão em seu caminho.
• O ScrumMaster deve remover os obstáculos
encontrados
• O gráfico de BURNDOWN deve ser atualizado!

51. O que é o Burndown da Sprint?
• É um gráfico que mostra a soma dos
tempos estimados restantes das tarefas da
Sprint pelo tempo
– Y: tempos estimados restantes
– X: dias da Sprint
• Serve para acompanhar o progresso em
direção ao final de um sprint
• É feito inicialmente no Planejamento da
Sprint e deve ser atualizado a cada dia da
Sprint

52. Incremento no Produto
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24
HORAS
Ao final da Sprint, o Time de Scrum terá
produzido um incremento PRONTO no
produto, que significa valor para o cliente

53. O que significa Pronto?
• Ao final da Sprint, o trabalho desenvolvido
deve estar pronto
• Mas o que significa “pronto”?
• O Time de Scrum e o Product Owner devem
definir o que significa “pronto”
• Quando alguém diz que algo está “pronto”,
todos devem entender o que isso significa
• Ex. de software: codificado, testado e
documentado

54. A Reunião de Revisão da Sprint
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
O Time de Scrum então se reúne com o
Product Owner e apresenta o que foi feito
na REUNIÃO DE REVISÃO DA SPRINT

55. O que é a Revisão da Sprint?
• Reunião onde o Time mostra aos
stakeholders o que foi feito durante a Sprint:
– Product Owner presente
• Time de Scrum demonstra o que fez e
responde a perguntas
• Product Owner verifica o que foi e o que não
foi feito na Sprint
• Deve prover entradas para a Reunião de
Planejamento de Sprint seguinte

56. A Reunião de Retrospectiva
BACKLOG
DO
PRODUTO
BACKLOG
DA SPRINT
REUNIÃO
DIÁRIA
INCREMENTO DO
PRODUTO
POTENCIALMENT
ENTREGÁVEL
2-4 SEMANAS
24 HORAS
E, em seguida, o Time de Scrum se reúne
para a RETROSPECTIVA, onde verifica o
que funcionou bem e o que pode melhorar
na próxima Sprint

57. O que é a Retrospectiva da Sprint?
• Reunião para inspecionar como correu a
Sprint com relação às pessoas,
relacionamentos, processos e ferramentas:
– Product Owner não deve estar presente
• Identificar e priorizar:
– O que foi bem?
– O que pode melhorar?
• Identificar ações para melhorias - adaptação

58. E o ciclo recomeça...
BACKLOG
DO
PRODUTO
2-4 SEMANAS

59. Exercício
de
Priorização

60. Planejando um Hotel
• Formem grupos de até 5 pessoas
• Escolham um membro do grupo para
ser o Product Owner
• O Product Owner representa os
clientes (demais membros do grupo)
que estão construindo um hotel
• O Product Owner deve priorizar (do
maior para o menor) os itens que
devem fazer parte do seu hotel com
base no desejo dos seus clientes

61. Planejando um Hotel
• Itens disponíveis para priorização:
Internet no Quarto
Camareira /
Arrumadeira
Piscina
Escada
Estacionamento
Elevador
Quartos
Quartos
Recepção
Restaurante
Cozinha do Hotel

62. Planejando um Hotel
• Agora imagine que durante a
construção o dinheiro acabou assim
que o 5º Item ficou pronto.
• Pergunta:
– Os primeiros 5 itens são suficientes para
tornar o hotel viável?

63. Scrum
vs.
Métodos Tradicionais

64. Desperdício
Metodologias não-ágeis afirmam que devem ser gerados
inúmeros documentos para o sucesso do projeto
Declaração
Preliminar
de Escopo
Termo de Plano de
Abertura Gerenciamento
do Projeto
Pedidos de Relatório de
Mudança Progresso
Relatório de
Desempenho
Relatório de
Aceite
Relatório de
Encerramento
Cronograma
Detalhado
Análise de
Earned Value
Docu
m
ento de
Lições
Apr
e
Diagramas de
Sequência
Diagrama de
Componentes
Diagrama de
Colaboração
Diagrama
de Estados
D
i
agrama de
Casos de Uso
Diagrama
de Pacotes
iagrama de
Atividades
...algo D
mais?
O custo de produção e manutenção
destes documentos compensa?
Quantos destes documentos se
manterão atualizados?
Quantos serão realmente úteis para o ndidas
desenvolvimento do projeto?

65. Desperdício
Fonte: Standish Group CHAOS Report
raramente serão utilizadas
Em projetos típicos, 50% do tempo é gasto
com requisitos, arquitetura e especificação
Análise de Requisitos
Especificação /
Arquitetura
Implementação Testes Manutenção
e isso tudo é feito antes de se
3
c5
o%
nst
d
ro
usir
re
q
qu
ua
is
li
q
to
us
em
r fud
na
cm
ionalidade!
65% das funcionalidades nunca ou
e para
piorar...

66. Desperdício
Afinal, o objetivo do projeto é o
produto, e não a documentação!
Com Scrum, o projeto deve ter somente a
documentação suficiente e necessária.
Ou seja, adote somente o que será usado.

67. Desperdício
A documentação do projeto não pode
roubar tempo e recursos do
desenvolvimento do produto.
A documentação do produto é importante e
não pode ser deixada de lado.
Atenção!!!

68. Maior Valor Primeiro
Em metodologias não-
ágeis, o cliente só percebe
retorno ao investimento no
final do projeto.
Entrega

69. Mudanças Frequentes
Em metodologias tradicionais, a
mudança é fonte de estresse!
Mudança é
indesejada!
Mudança é
arriscada!
Mudança é
cara!
Mudança
deve ser
negociada!
Como quase todo o planejamento é feito
no começo do projeto, há pouquíssimo
espaço para mudanças!

70. Mudanças Frequentes
O contrato com escopo amarrado deve nos
defender! O cliente vai querer mudar tudo!
Cada mudança deve ser negociada com o
cliente! Seu impacto deve ser quantificado!
Cada mudança deve ser revista, aprovada,
planejada, documentada e gerenciada!

71. Mudanças Frequentes
Como o Scrum lida com a mudança?
Scrum encara a mudança como parte natural
do processo de desenvolvimento
Mudanças solicitadas pelo cliente podem ser
introduzidas no produto na sprint seguinte!
A resposta rápida à mudança pode se
transformar em vantagem competitiva!

72. Comunicação
Em um projeto tradicional, quando o
cliente é encorajado a participar?
Análise de Requisitos
Especificação /
Arquitetura
Implementação Testes Manutenção

73. Comunicação
Em um projeto tradicional, quando o
cliente é encorajado a participar?
Análise de Requisitos
Testes de Aceitação

74. Comunicação
Em um projeto tradicional, quando o
cliente é encorajado a participar?
Análise de Requisitos
Testes de Aceitação
O cliente percebe o projeto como
uma grande caixa preta, cujo
conteúdo será revelado apenas no
final do processo

75. Comunicação
Assim, ao final do
projeto, o resultado
dificilmente atenderá às
necessidades do cliente
naquele momento!

76. Comunicação
Como o Scrum lida com a comunicação?
O Product Owner está em frequente
contato com o cliente para
levantar suas necessidades
O cliente recebe frequentemente
novas versões...
...e assim pode mais rapidamente dar
feedback para a equipe

77. Comunicação
A relação com o cliente deixa de ser
meramente comercial, e passa a contemplar:
Parceria Cumplicidade Satisfação Fidelidade
E assim, cria-se uma relação de longo
prazo com o cliente.
O cliente se sente envolvido no processo,
compartilhando a responsabilidade

78. Comunicação
Em metodologias não-ágeis, como se
promove a visibilidade no projeto
para seus stakeholders?
Principalmente através de documentação...
...que dá
muito
trabalho
...que não é
eficiente
...que não
se mantém
atualizada
...que acaba
deixada de
lado

79. Comunicação
No Scrum, a visibilidade no projeto é
constantemente promovida!
Reuniões
diárias
Kanban
Equipe em
um mesmo
ambiente
Envolvimento
do cliente
Gráficos de
Burndown
Entregas
frequentes
Reunião de
Revisão
Retros-
pectiva
...são alguns exemplos.

80. Scrum na Petrobras
Case de Sucesso

81. Obrigado!
Rafael Sabbagh
sabbagh@gmail.com
Marcos Garrido
mgarridobr@gmail.com