2. Marcia Maia. Product Owner no Terra. Arquiteta de informação.
Designer pela UFPE, pós graduada em Ergonomia e
Usabilidade pela PUC-RJ. Trabalhou com Scrum também na
Globo.com e na Locaweb.
Dezembro/2010
3.
4. Manifesto Ágil:
Valores, princípios e práticas
“ 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.
Fonte: http://manifestoagil.com.br/
11. Responsabilidades do PO
Visão de produto
Requisitos / User stories
Product backlog / Priorização
Dar direcionamento ao trabalho
Aprovar ou rejeitar entregas
Metas e releases
ROI
12. Visão de produto
Definir claramente o que é o produto
com objetivo de que todos trabalhem
com o própósito de atingir o mesmo
fim.
Deve ser feita antes de se começar o
desenvolvimento do projeto.
14. Visão de produto
O que estamos fazendo,
por quê, para quem, qual é
o principal benefício, qual é
o principal diferencial
30”de conversa
15. Visão de produto
Estamos redesenhando o webmail do
TerraMail para que o produto permita a
inclusão de novas funcionalidades,
possibilite futuras alterações e seja
possível integrá-lo a outros produtos Terra.
Além de oferecer uma nova interface web
mais simples de usar e mais consistente
para todos os usuários, e usuários em
potencial, Brasil e Latam.
16. Visão de produto
Product Vision Box
Frente
• Nome do produto
• Tres ou quatros pontos chave
que ajudem a vender o produto
Imagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
17. Visão de produto
Product Vision Box
Verso
• Principais features
• Principais requisitos operacionais
Imagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
25. Visão de produto
Project data sheet
• Definição e objetivos do produto
• Funcionalidades chave do produto
• Benefícios para o cliente
• Trade off matrix
• Fator de exploração
• Custo de atraso
• Atributos de performance e qualidade
• Arquitetura do produto
• Dificuldades e riscos
• Principais marcos do projeto
27. Visão de produto
Product Owner
• É responsável pela visão de produto
• Compartilha essa visão com o time
• Refina essa visão com o time
28. Visão de produto
Uma boa visão de produto
permanece relativamente
constante, o caminho para
implementação da visão é
frequentemente adaptado
29. Product backlog
Lista de tudo que gostaríamos de
ter no produto
Derivado de um plano de negócios
ou de uma visão de produto
Pode ser escrito em formato de user
stories, use cases, features, etc
Responsabilidade do PO, mas
todos podem contribuir
30. Product backlog
Utilizando user stories
User Story
Descrição de uma necessidade para um público
específico com um valor de negócio
Quem? / O que? / Por que?
32. Product backlog
User stories
Para escrever as users stories:
• Necessidades dos usuários
• Necessidades do cliente/empresa
• Histórico do produto (se houver)
• PO pode escrever sozinho ou
promover story-writing workshop
33. Product backlog
User story - Story-writing Workshop
Fonte: http://www.agileway.com.br/2010/07/20/story-writing-workshop/
35. Product backlog
User stories
• Devem ser compreensíveis por todos:
usuários, cliente e time de desenvolvimento
• Evitam “interpretações” de documentação
• Detalhes das users stories podem ser feitos
como casos de aceitação, wireframes ou
especificações e através da comunicação
36. (Sobre documentação...)
Do Manifesto Ágil:
“Software em funcionamento
mais que documentação abrangente”
A quantidade e o formato
da documentação deve ser
feita de acordo com as
necessidades da equipe e
do ambiente.
37. Product backlog
User Story
Descrição de uma necessidade Story
para um público específico com
um valor de negócio
Temas Tema
Um grupo de stories Story Story Story
Story Story Story
Épicos
Grande feature sem Épico
especificação ou definição clara,
é uma story grande, bruta
39. Fatores de priorização
Valor
• KANO
Feature: Empolgante, lienar, mandatória
• Theme Screening
A partir de uma funcionalidade eleita como base, as outras são
comparadas com ela
• Buy a feature
As funcionalidades são precificadas para que os clientes
negociem a compra das mais importantes
42. Fatores de priorização
Exploração
Exploração Quanto mais você acredita
de Requisitos que os requisitos vão
mudar ao longo do tempo
ou que a equipe não
conhece a tecnologia a ser
utilizada mais alto será o
nível de exploração, mais
adequado será utilizar o
scrum
Exploração
de Tecnologia
O scrum foi feito para projetos com fator de exploração alto
43. Fatores de priorização
Risco x Valor
Risco
Alto risco Alto risco
Baixo valor Alto valor
Baixo risco Baixo risco
Baixo valor Alto valor
Valor
44. Fatores de priorização
Risco x Valor
Risco
Alto risco Alto risco
Baixo valor Alto valor 1
Baixo risco Baixo risco
Baixo valor Alto valor 2
3
Valor
45. Product backlog
Alta prioridade Cada sprint implementa as
estórias 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 retirados
do Product Backlog pelo Product
Owner a qualquer momento
Baixa prioridade
46. Do manifesto Ágil:
"Responder a mudanças
mais que seguir um plano”
“Colaboração com o cliente
mais que negociação de contratos”
47. Product backlog Sprint atual
(users stories)
Release atual
(users stories
agrupadas por temas)
Próxima release
(users stories ou epicos)
48. Condições de satisfação
Condição para o requisito entrar no sprint
• User story?
Ready • Teste de aceitação?
• Qual é o grau de detalhamento necessário?
Condição para saída de um item do sprint
• Codificado?
Done • Testado?
• Documentado?
49. Planejamento de release
Continua planejando releases até que a visão de produto seja alcançada
Selecionar
um tamanho
de Sprint
Determinar as Estimar os Estimar a Selecionar
condições de itens do velocidade itens e datas
satisfação Backlog do Sprint do Release
Priorizar
User Stories
54. Product Owner nas cerimonias do Scrum
No Sprint Planning 1, PO leva o backlog idealmente
estimado e priorizado, onde a meta do Sprint deve
ser definida e o time junto com o PO decide o que
entra no Sprint
Deve participar, APENAS se convidado:
• Sprint planning 2
• Reuniões diárias
• Retrospectiva