29/03/2010

SCRUM

Revisão de Scrum

O papel do Product Owner

Visão do produto

Product Backlog

Product Owner e as cerimônias do Scrum

Planejamento e tracking de Releases

4 sprints de 1:45 horas e intervalos de 15 min

§ Sprint1 (9:00 – 10:45)
§ Sprint2 (11:00 – 12:45) Na sprint:
§ Almoço (12:45 – 14:00) -Planning
-Execução
§ Sprint3 (14:00 – 15:45)
-Retrospective
§ Sprint4 (16:00 – 17:45)

1
 29/03/2010

Manifesto Ágil
“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o
nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a
valorizar:

Indivíduos e interações entre eles mais que processos e ferramentas

Produto 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.”

http://agilemanifesto.org

A Motivação do manifesto ágil vem da

constatação de que:
§ Os clientes ou usuários não tem certeza do que eles
querem
§ Eles tem dificuldade de expressar tudo o que querem
e pensam
§ Muitos detalhes do que eles querem só serão
revelados durante o desenvolvimento
§ Os detalhes são complexos para as pessoas
§ Na medida em que elas veem o produto sendo
construído, mudam de idéia
§ Forças externas trazem mudanças ou melhorias nos
requisitos

Exercício 1
§ Entregar a bolinha
▪ Criar um percurso onde:
▪ Passo curto = $50,00
▪ Passo longo = $80,00
▪ Pulo = $100,00
▪ Giro = 20,00

2
 29/03/2010

Exercício 2
§ Atividade 1
§ Atividade 2

Exercício 3
§ Entregar um layout de uma sala de treinamento
Scrum ideal

Scrum é...

um processo ágil que nos permite focar na
entrega de maior valor de negócio no menor
tempo.
§ Permite rápida e repetidamente inspecionar o
software funcionando.
§ O negócio define as prioridades.
§ A equipe se auto-organiza para determinar qual a
melhor forma de entregar as funcionalidades de
maior prioridade.

3
 29/03/2010

Principais características do Scrum

§ Times pequenos e multi-disciplinares
§ Times self-empowered
§ Scrum Master facilitador
§ Product Backlog

Visão Dailly Scrum

Burndown chart

Iteration Wall

Pigs

Scrum e mudança organizacional

4
 29/03/2010

Quais são as atribuições de um gerente de

produto na sua empresa (ou nos seus
projetos)?

Na sua opinião, quais deveriam ser as

atribuições dele?

Ser a voz do cliente

Definir as funcionalidades chave do produto

5
 29/03/2010

Descrever, priorizar e refinar requisitos

continuamente

Ser responsável pelo sucesso

do projeto e pelo ROI

Definir datas de Releases

Criar e atualizar plano de Release e reports

6
 29/03/2010

Gerenciar de forma pró-

pró-ativa stakeholders e
chickens

Definir Metas

Dar direcionamento ao trabalho

7
 29/03/2010

Responder às questões diariamente

Participar das reuniões do Scrum

Aceitar ou rejeitar entregas (resultados)

8
 29/03/2010

Definir a visão do produto

O Product Owner dentro do taxi

Características Ter habilidade para criar e

desejadas em um comunicar a visão do
Product Owner produto
Entender o valor do
Entender processo criativo
necessidades do
cliente
Lider Facilitador
Tomar decisões e
saber quando dizer Possuir bom
não relacionamento com
stakeholders

9
 29/03/2010

Problemas comuns
§ Product Owner sem poder de decisão
§ Product Owner com baixa disponibilidade
§ Product Owner não foi preparado/treinado para
exercer o papel

Há uma forte relação entre o

sucesso de um projeto Scrum e o
PO com poder e bem treinado

A agenda de um Product Owner

Horário Atividade
09:00 – 10:00 Trabalhar nos novos requisitos e incluí-los no Product Backlog
10:00 – 10:15 Visitar Dailly Meeting para ver se posso ajudar em algo
10:15 – 11:00 Permanecer no ambiente do time para responder à perguntas
11:00 – 12:00 Reunião com stakeholders para discutir sobre o Product Backlog e
dia

sua priorização
12:00 – 13:00 Almoço com Fernanda, gerente de portifólio, para discutir sobre o
Product Roadmap e próximos releases
13:00 – 15:00 Iniciar preparativos para próxima Sprint Planning Meeting. Inserir
condições de aceitação para novas user stories
15:00 – 17:00 Participar da reunião de estimativas do time e facilitar durante o
Planning Poker
17:00 – 18:00 Responder e-mails e cuidar de assuntos funcionais

10
 29/03/2010

Dia Atividade
15/03 Sprint Planning Meeting #1 (participar)
Sprint Planning Meeting #2 (estar disponível)
16/03 Reunião com high management (e stakeholders) para apresentar
meta da sprint

sprint
17/03
18/03 Reunião para capturar necessidades de mudança no product
Backlog
19/03
22/03
23/03 Reunião com Scrum Master (e time) para refinar Product Backlog
24/03 Facilitar Reunião de estimativas
25/03 Revisar Product Backlog e sua priorização
26/03 Sprint Review (e retrospective)
Atualizar plano de release

Fase Atividade
Pré-game -Identificar necessidades estratégicas do projeto (patrocinador,
time, infra-estrutura, etc)
-Realizar kick-off com todos os que até aqui já tenham sido
Projeto

identificados como Pig ou Chicken

-Vision Meeting
-Elaborar Project Datasheet
-Elaborar e priorizar Product Backlog
-Elaborar plano de release
Game - Participar de todas as Sprint Planning Meetings e Reviews. Quando
necessário, visitar Dailly Meeting e participar da Retrospective
-Estar disponível para o time (ou garaintir que alguém por mim
designado esteja)
-Manter Product Backlog
-Atualizar Plano de Release
Pós-game -Project Retrospective
-Tornar resultados visíveis para outros (e futuros) projetos Scrum na
empresa; e/ou para o Enterprise Scrum

Pergunta!!!
§ O Product Owner é uma pessoa da empresa
cliente ou da empresa fornecedora?

11
 29/03/2010

Uma visão é uma clara imagem que gera uma

atração emocional entre pessoas e produtos
§ Product Owner é o responsável pela criação da
visão
§ Ele compartilha essa visão com o time
§ Ele refina essa visão com o time

Uma boa visão de produto permanece

relativamente constante, ao passo que o
caminho para implementação da visão é
freqüentemente adaptado.

Product Box (Vision Box e Elevator Statement)

Project Scope (Project Datasheet)

Project Plan (Releases e Sprint Plan)

12
 29/03/2010

Elevator Statement

Elevator Statement
Para cliente / público alvo
que necessidade do cliente / público ou oportunidade
o nome do produto
é um categoria do produto
que principal benefício ou razão para comprar o produto
diferentemente do principal competidor ou alternativa
nosso produto principal diferenciação

Para estudantes e profissionais que tem dificuldade

em encontrar cursos (e capacitação) de acordo com
o seu interesse, o Dondee é uma ferramenta de
busca web especializada na área educacional que,
de forma simples, permite que o usuário procure
por cursos e turmas e obtenha resultados
relevantes. Diferentemente de uma pesquisa por
treinamentos realizada em ferramentas genéricas
de busca, como o Google, os resultados trazidos
pelo Dondee são gerados através de pesquisa
exclusiva em sites da área educacional.

13
 29/03/2010

Os membros do seu time estão no mesmo

elevador?

Exercício 4
§ Praticando Elevator Statement

Product Vision Box

§ Nome do produto
§ Gráficos
§ Três ou quatro pontos chaves para vender o
produto
§ Seis a oito principais features no verso
§ Principais requisitos operacionais

14
 29/03/2010

Exercício 5
§ Praticando Product Vision Box

Remember the future

§ Para descobrir o entendimento de sucesso do
cliente e iniciar a visualização do Roadmap do
projeto

Product Roadmap

15
 29/03/2010

Exercício 6
§ Praticando Remember the future

Project Datasheet

Project Datasheet

CLIENTES

16
 29/03/2010

Project Datasheet

Gerente de Projeto
Gerente de Produto

Project Datasheet

Project Datasheet

17
 29/03/2010

Project Datasheet

Fator de Exploração

Project Datasheet

Custo do atraso

Project Datasheet

18
 29/03/2010

Project Datasheet

Project Datasheet

Benefícios para o cliente

Project Datasheet

19
 29/03/2010

Project Datasheet

Arquitetura do produto

Project Datasheet

Dificuldades e Riscos

Exercício 7
§ Praticando Project Datasheet

20
 29/03/2010

Lista de Funcionalidades, necessidades, desejos...

Emergentes, priorizados e estimados
Mais detalhes nos itens do topo Todos podem contribuir
Uma única lista para múltiplos times
Product Owner é o responsável pela sua priorização
Mantido e postado visivelmente
Derivado de um Plano de negócios ou de uma visão de produto
Pode ser escrito no formato de sua preferência (use cases, user stories, features)

Engenharia do Product Backlog

Alta prioridade Cada Sprint implementa os requisitos de prioridade
mais alta

Cada novo requisito é priorizado e

inserido no Product Backlog pelo Product
Owner a qualquer momento

Requisitos podem ser repriorizados pelo Product Owner

a qualquer momento

Requisitos podem ser removidos do Product

Backlog pelo Product Owner a qualquer
momento
Baixa prioridade

21
 29/03/2010

Requisitos Ready

... Se transformam em...

Funcionalidades Done

User Stories

User Story

Os 3 C’s da User Story

Card
(Cartão)
Conversation
(Conversa)
Confirmation
(Confirmação)

22
 29/03/2010

User Story

User Story

Perfil

User Story

Persona
§ São essencialmente um conjunto de pessoas que
ajudam a transformar o genérico “usuário” em
seres humanos com comportamentos e objetivos
semelhantes. As diferenças entre uma persona e
outra seria em torno do que as pessoas fazem e
por que fazem, nos termos de seus objetivos e
motivações

23
 29/03/2010

User Story

Como um <PERFIL> eu posso/gostaria/devo

Quem?
<FUNCIONALIDADE> para <VALOR AO
NEGÓCIO>

O que?
Como um INSTRUTOR eu devo APONTAR A
LISTA DE PRESENÇA DOS ALUNOS para
MANTER AS INFORMAÇÕES DO
TREINAMENTO ATUALIZADAS
Por que?

User Story

Com o propósito de <VALOR AO NEGÓCIO>,

Por que?
como um <PERFIL>, eu posso/gostaria/devo
<FUNCIONALIDADE>

Quem?
Com o propósito de MANTER AS
INFORMAÇÕES DO TREINAMENTO
ATUALIZADAS, como um INSTRUTOR eu
devo APONTAR A LISTA DE PRESENÇA
O que?

User Story

Observações
§ Em um projeto ideal nós devemos ter uma única
pessoa responsável pelo trabalho de priorização
das stories;
§ Uma característica marcante de projetos stories-
driven é que clientes e usuários estão envolvidos
no projeto em toda a duração;
§ User stories devem ser compreensíveis por todos
usuários, clientes e time de desenvolvimento;
§ User stories evitam “interpretações” de
documentação

24
 29/03/2010

User Story

Técnicas de elaboração
§ Pelo fato de stories fazerem parte de todo o ciclo
de vida de um projeto ágil é importante que
utilizemos técnicas para captá-las e elaborá-las da
melhor maneira possível
§ As técnicas mais interessantes são:
▪ Entrevistas
▪ Questionários
▪ Observação
▪ Story-writing workshops

User Story

Técnicas de elaboração: Entrevista

§ Prepare-se: defina o assunto e objetivo da entrevista,
estude o que está disponível
§ Prepare o entrevistado: comunique o entrevistado
com antecedência estabelecendo o objetivo e o
tempo da reunião
§ Conduza a entrevista: seja objetivo, evite dispersão,
ouça mais e fale o essencial, anote sem criticar
§ Termine a entrevista: recapitule a informação obtida,
agradeça a atenção e estabeleça um canal para
futuros contatos

User Story

Técnicas de elaboração: Entrevista

§ Cuidado com perguntas fechadas

Você quer a nossa nova versão do

Você quer a nossa produto rodando em um browser,
O queversão
nova você acha
do de nossa próxima versão
mesmo dosabendo
produto que
rodar emvai
isto um
produto rodando em Quais as vantagens
browser? queavocê
reduzir visualiza? terá uma
performance,
um browser? interface mais pobre e diminuirá a
sua interatividade com o sistema?

25
 29/03/2010

User Story

Técnicas de elaboração: Questionário

§ É uma técnica mais interessante para ser utilizada
na busca de novas informações de uma user story
já existente, e não para encontrar ou elaborar uma
nova
§ Excelente para equipes distribuídas
§ Pode contribuir na definição de prioridades do
Product Backlog

User Story

Técnicas de elaboração: Questionário

§ Deve ter questões claras e não ambíguas
§ Deve ter fluxo bem definido
§ Deve ter administração planejada em detalhes
§ Deve-se levantar antecipadamente as dúvidas das
pessoas que irão respondê-lo
§ Use vocabulário das pessoas que irão responder
§ Evite perguntas tendenciosas

User Story

Técnicas de elaboração: Observação

§ Deve-se inserir na rotina de trabalho das
organizações
§ Identifica-se quais atividades podem ser
automatizadas
§ Identifica-se os potenciais usuários
§ Identifica-se as tarefas que eles querem realizar
com a ajuda do novo sistema
§ Deve-se complementar a observação com
entrevistas específicas

26
 29/03/2010

User Story

Técnicas de elaboração: Story-writing

workshop
§ Reuniões que incluem PO, cliente, usuários,
desenvolvedores e qualquer pessoa que possa
contribuir no processo de descoberta de stories
§ Os participantes escrevem a quantidade de stories
que conseguirem sem se preocupar com
prioridades
§ Usa brainstorming e prototipação de desenho

User Story

Técnicas de elaboração: Story-writing

workshop ACME
treinamentos
Dar credibilidade
às campanhas
Bom ranking Agilidade na Tomar decisões
atualização de sobre as Inserir Apostila
informações campanhas

Editar descrição Visualizar Inserir Video

Importar dados de
dos cursos ranking dos cursos Aula
cursos
e turmas
Gerar relatório de Receber
Contratar links
Copiar turma interesses e notificação de
patrocinados
clientes denúncia

User Story

Teste de aceitação
§ Uma das melhores formas de se expressar alguns
detalhes discutidos com o cliente (Product Owner,
especialista de domínio...) é a escrita de testes de
aceitação
§ O Product Owner, com a colaboração de quem
achar necessário, é quem deve escrever os testes
de aceitação, e o deve fazê-lo antes da
codificação
§ Testes DEVEM fazer parte do processo e devem
ser automatizados sempre que possível

27
 29/03/2010

User Story

Teste de aceitação Teste de Aceitação

1. O sistema mostra uma lista dos
cursos existentes e permite que a
secretária escolha um.
2. O sistema mostra os dados do curso
escolhido e solicita um nome para o
novo curso.

User Story

Stories, Temas e Épicos

STORY

EPIC STORY
STORY STORY

STORY

Theme
STORY STORY STORY STORY

STORY STORY STORY STORY

STORY STORY STORY

Exercício 8
§ Praticando User Stories

28
 29/03/2010

Priorização por temas

§ A priorização por temas deve ser considerada
visto que muitas vezes uma história não pode ser
priorizada sem a outra
§ Por mais que boas histórias devem ser
independentes (I do INVEST), quando falamos em
valor do negócio elas normalmente se
complementam
§ O que é mais importante: a emissão da nota fiscal
eletrônica ou a baixa do pagamento de um
cliente?

Fatores de Priorização

Fatores de Priorização

29
 29/03/2010

Fatores de Priorização

Fatores de Priorização

Fatores de Priorização

30
 29/03/2010

Fatores de Priorização

COMBINANDO OS QUATRO FATORES

Técnicas de Priorização
§ Kano: composta por entrevistas com os usuários e
opiniões de experts
§ Theme Screening: composta apenas por opiniões
de experts baseadas em comparações realizadas
com um tema importante
§ Buy a feature: composta por negociação entre
clientes e patrocinadores com o propósito de
“comprar” funcionalidades para o próximo release

Técnica de priorização: Kano Model

§ Classifica as funcionalidades em:
▪ EMPOLGANTES: funcionalidades que o usuário acredita
desejar, mas não tem certeza se seu custo-benefício
compensa
▪ LINEAR: quando mais dessas funcionalidades tiver,
melhor
▪ MANDATÓRIA: devem estar presente para que o cliente
esteja satisfeito

31
 29/03/2010

Técnica de priorização: Kano Model

§ Para saber se uma funcionalidade é desejada, linear
ou mandatória você deve:
▪ Realizar as perguntas direcionadas para um grupo de no
máximo 20 pessoas de perfís variados;
▪ Realizar uma pergunta funcional:
Como você se sentirá se a funcionalidade estiver presente?
▪ Realizar uma pergunta disfuncional:
Como você se sentirá se a funcionalidade estiver ausente?

Técnica de priorização: Kano Model

Pergunta funcional
Se o próximo release incluir a emissão de nota
fiscal eletrônica, como você se sentirá?
( ) Eu imaginava que seria dessa forma
( ) Eu gostaria que fosse dessa forma
( ) Eu ficarei neutro
( ) Eu posso viver sem isso
( ) Eu não gostaria que isso acontecesse

Técnica de priorização: Kano Model

Pergunta disfuncional
Se o próximo release NÃO incluir a emissão de nota
fiscal eletrônica, como você se sentirá?
( ) Eu imaginava que seria dessa forma
( ) Eu gostaria que fosse dessa forma
( ) Eu ficarei neutro
( ) Eu posso viver dessa forma
( ) Eu não gostaria que isso acontecesse

32
 29/03/2010

Técnica de priorização: Kano Model

§ Tabela de priorização
Pergunta Disfuncional
Gostaria Imaginava Neutro Vivo sem Não gostaria
Gostaria Q E E E L
Imaginava
Funcional

C I I I M
Pergunta

Neutro C I I I M
Vivo sem C I I I M
Não gostaria C C C C Q
M mandatório Q questionável
L linear C contrário
E empolgante I indiferente

Técnica de priorização: Kano Model

Coleta dos resultados
Questionável
Mandatório
Indiferente

Contrário
Desejado

Linear

Emissão de NF 3 11 31 1 3 2
Exportação de dados legados 4 22 20 4 1 0
Automatização de remarcação de bilhetes 21 9 14 5 1 1

Técnica de priorização: Theme Screening

§ Selecionar entre 5 a 9 critérios para avaliar o que é
mais importante para o próximo sprint
§ Selecionar um tema que servirá como base para
os fatores de comparação. Deve ser um tema que
seja visualizado como algo que deveria entrar no
próximo sprint e de amplo conhecimento do time
§ Compare cada tema candidato com o tema base

33
 29/03/2010

Técnica de priorização: Theme Screening

§ Tabela de priorização
+ = mais que 0 = mesmo que - = menos que Temas

BASE
A B C D E F
Critérios
Importa para os clientes atuais + + - 0 - + 0
Colabora para o atingimento das metas do quarter + - 0 0 0 0 0
Elimina problemas antigos dos usuários + 0 0 0 + - +
Ajuda na tomada de decisão do board 0 0 0 0 + 0 +
Score 3 0 -1 0 1 0 2
Rank 1 4 5 4 3 4 2

Técnica de priorização: Buy a feature

§ Atividade indicada para grupos de quatro a sete clientes
e/ou patrocinadores
§ Crie uma lista de potenciais funcionalidades / temas /
histórias e defina o preço de cada uma delas. Assim como
um produto real, o preço pode ser baseado em custo de
desenvolvimento, valor para o cliente ou qualquer padrão
que você queira utilizar
§ Clientes/patrocinadores compram funcionalidades para a
próxima release
§ Garanta que haja funcionalidades caras o suficiente para
que nenhum cliente possa comprá-
comprá-la, pois isto irá
motivar negociação entre eles.

Exercício 9
§ Praticando Priorização

34
 29/03/2010

Estimativas

1 2 3 5 8 13 20

Planning Poker

Por que Planning Poker funciona?

§ Apresenta múltiplas opiniões de especialistas quanto
à estimativa de um item, e como Scrum trabalha com
times multi-funcionais, é sempre importante ter um
consenso quanto a este valor
§ Estimula o diálogo entre os rounds, e cada membro
do time tem que explicar para todos os outros o
motivo de ter atribuído tal tamanho. Todo esse
processo gera compartilhamento de conhecimento
§ Estudos mostram que estimativas feitas em grupo
vem sendo mais bem sucedidas que estimativas
individuais

Sprint Planning Meeting

Dailly Scrum

Review Meeting

Retrospective Meeting

Sprint

35
 29/03/2010

Sprint Planning Meeting #1 (Preparação)

§ Certifique-se que o Product Backlog esteja priorizado
§ Certifique-se que os Backlog Items estejam estimados
§ Tenha em mãos um calendário com possíveis
impedimentos em datas do Sprint (feriados, ausências
previstas de membros, etc)
§ Tenha em mãos anotações com os resultados da Sprint
Review anterior
§ Certifique-se que a agenda da próxima Sprint esteja
pronta, composta de: data inicial e final, anotações,
impedimentos previstos, etc

Sprint Planning Meeting #1 (a reunião)

§ O Product Owner deve falar ao time sobre a visão do
produto
§ O Product Owner e o time devem definir a meta da
Sprint
§ O time deve realizar a estimativa dos itens do
Backlog que não estejam estimados
§ O Product Owner e o time, em consenso, escolhem
os itens que irão fazer parte do próximo Sprint,
Sprint, estes
itens selecionados são chamados de Selected
Product Backlog

Sprint Planning Meeting #2

§ Caso necessário, pode ser solicitada a presença do
Product Owner para esclarecer dúvidas sobre
itens do Selected Product Backlog

36
 29/03/2010

Product Owner na Dailly Scrum Meeting

Product Owner na Review Meeting

§ O time apresenta os resultados da Sprint
§ Product Owner avalia se a meta da Sprint foi
alcançada
§ Product Owner faz anotações que podem se
transformar em itens do Product Backlog
§ Product Owner reprioriza o Product Backlog
§ Product Owner pode fechar uma release com as
funcionalidades apresentadas
§ Product Owner pode escolher não continuar com o
projeto

Product Owner na Retrospective Meeting

37
 29/03/2010

Product Owner na Sprint

Terminando a Sprint antes da sua finalização

§ Uma Sprint pode ser terminada antes da sua
finalização nas seguintes situações:
▪ O time sente que não conseguirá atingir a meta
▪ O Product Owner percebe que mudanças em fatores
externos influenciarão diretamente no valor da meta da
Sprint
§ Caso uma Sprint seja cancelada deve-
deve-se inicar
imediatamente o planejamento da próxima

Sprint x Release

Velocidade x Tamanho x Duração

Gordura??

Tracking

38
 29/03/2010

A cebola do planejamento
Strategy

Portifolio

Product

Release
Iteration

Day

Planejamento de Releases
Continua planejando até que a Visão seja alcançada

Selecionar um
tamanho de
Sprint

Determinar as Estimar os Estimar Selecionar

condições de Itens do Velocidade Itens e data
satisfação Backlog do Release

Priorizar User
Stories

Velocidade do time

39
 29/03/2010

Tamanho Cálculo Duração

70 pontos por
210 pontos 3 Sprints
Sprint

Resultado de um planejamento de Release

Sprint 1 Sprint 2 Sprint 3 Sprint 4 - 7

Planejamento com gordura

Tarefa 1 1 5

Tarefa 2 45 30

Tarefa 3 10 5

Tarefa 4 7 7

Tempo total estimado: 63 t

Tempo de “gordura” : 47 t Total gasto: 110 t

40
 29/03/2010

Planejamento com pulmão

Tarefa 1 1

Tarefa 2 45

Tarefa 3 10

Tarefa 4 7

25

Tempo total estimado: 63 t

Tempo de pulmão : 25 t Total gasto: 88 t

Tracking (Burndown Chart)

Chart)

Tracking (Burndown Chart)

Chart)

41
 29/03/2010

Marcos Tor Arao, CSM, CSPO

mtarao@uol.com.br

Material extraído do curso oficial Certified Scrum Product Owner da Adaptworks

(Alexandre Magno)

42