Embed Size (px)
Citation preview
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
“
”
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/
Manifesto Ágil:
Valores, princípios e práticas
Definição de requisitos
Entrega do produto
Waterfall: Abismo entre
O cliente não é apenas um gerador
de demandas, participa do processo
e é parte da equipe.
O SCRUM é iterativo e incremental
Um processo de desenvolvimento
iterativo e incremental
para gerenciamento de projetos
e desenvolvimento ágil de software.
O Scrum é
Responsável
pelo produto
Responsável para
que o ambiente de
trabalho funcione
Responsável pelo
desenvolvimento
no dia-a-dia
PO é a voz do cliente
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
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.
Elevator statement or
Elevator speech
Visão de produto
O que estamos fazendo, por quê, para quem, qual é o principal benefício, qual é
o principal diferencial
30”de conversa
Visão de produto
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.
Visão de produto
Imagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
Product Vision BoxFrente
• 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/
Product Vision BoxVerso
• Principais features
• Principais requisitos operacionais
Visão de produto
Visão de produto
Trade off matrix
Custo
Prazo
Escopo
Fixo Variável
x
x
x
Visão de produto
Fator de exploração
Visão de produto
Custo de atraso
Visão de produto
Atributos de performance e qualidade
Visão de produto
Arquitetura do produto
Visão de produto
Dificuldades e riscos
Visão de produto
Principais marcos do projeto
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
Visão de produto
Visão de produto
• É responsável pela visão de produto
• Compartilha essa visão com o time
• Refina essa visão com o time
Visão de produto
Product Owner
Uma boa visão de produto
permanece relativamente
constante, o caminho para
implementação da visão é
frequentemente adaptado
Visão de produto
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
Quem? / O que? / Por que?
Product backlogUtilizando user stories
User Story Descrição de uma necessidade para um público
específico com um valor de negócio
Identificar/conhecer público e definir “personas”
Product backlogUser stories
Algumas técnicas:
• Entrevistas
• Questionários
• Observação
Product backlogUser 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
Product backlogUser story - Story-writing Workshop
Fonte: http://www.agileway.com.br/2010/07/20/story-writing-workshop/
Product backlogUser stories
Independente
Negociável
Estimável
Pequena
Testável
• 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
Product backlogUser stories
(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.
Product backlog
User Story
Descrição de uma necessidade
para um público específico com
um valor de negócio
Story
StoryStoryStory
StoryStoryStory
Tema
Épico
Épicos
Grande feature sem
especificação ou definição clara,
é uma story grande, bruta
Temas
Um grupo de stories
Fatores de priorização
Valor Custo
Exploração Risco
Fatores de priorizaçãoValor
• KANOFeature: Empolgante, lienar, mandatória
• Theme ScreeningA partir de uma funcionalidade eleita como base, as outras são
comparadas com ela
• Buy a featureAs funcionalidades são precificadas para que os clientes
negociem a compra das mais importantes
Fatores de priorizaçãoValor
Fatores de priorizaçãoCusto
Planning poker
Fatores de priorizaçãoExploração
O scrum foi feito para projetos com fator de exploração alto
Exploração de Requisitos
Exploração de Tecnologia
Quanto mais você acredita 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
Fatores de priorizaçãoRisco x Valor
Alto riscoBaixo valor
Alto riscoAlto valor
Baixo riscoBaixo valor
Baixo riscoAlto valor
Valor
Risco
Fatores de priorizaçãoRisco x Valor
Risco
Valor
Alto riscoBaixo valor
Alto riscoAlto valor
Baixo riscoBaixo valor
1
Baixo riscoAlto valor 2
3
Product backlog
Alta prioridade
Baixa 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
Do manifesto Ágil:
"Responder a mudanças
mais que seguir um plano”
“Colaboração com o cliente
mais que negociação de contratos”
Sprint atual(users stories)
Release atual(users stories
agrupadas por temas)
Próxima release(users stories ou epicos)
Product backlog
Ready
Condição para o requisito entrar no sprint
• User story?
• Teste de aceitação?
• Qual é o grau de detalhamento necessário?
Done
Condição para saída de um item do sprint
• Codificado?
• Testado?
• Documentado?
Condições de satisfação
Planejamento de release
Determinar as
condições de
satisfação
Estimar os
itens do
Backlog
Estimar a
velocidade
do Sprint
Priorizar
User Stories
Selecionar
um tamanho
de Sprint
Selecionar
itens e datas
do Release
Continua planejando releases até que a visão de produto seja alcançada
PO + Time
comunicação
Product Owner deve
Manter um canal de comunicação forte e aberto com Scrum master/ Time
Ter alta disponibilidade
Responder à questões diariamente
Product Owner dentro do
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
Do manifesto Ágil:
“Indivíduos e interação entre eles
mais que processos e ferramentas
Time dentro do mesmo elevador que o PO
PO dentro do mesmo taxi que o TIME
