O Papel do Product Owner
Upcoming SlideShare
Loading in...5
×
 

O Papel do Product Owner

on

  • 1,626 views

 

Statistics

Views

Total Views
1,626
Views on SlideShare
1,599
Embed Views
27

Actions

Likes
5
Downloads
32
Comments
2

1 Embed 27

http://paper.li 27

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

O Papel do Product Owner O Papel do Product Owner Presentation Transcript

  • Marcia Maia. Product Owner no Terra. Arquiteta de informação.Designer pela UFPE, pós graduada em Ergonomia eUsabilidade pela PUC-RJ. Trabalhou com Scrum também naGlobo.com e na Locaweb.Dezembro/2010
  • 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/
  • Waterfall: Abismo entreDefinição de requisitosEntrega do produto
  • O SCRUM é iterativo e incrementalO cliente não é apenas um geradorde demandas, participa do processoe é parte da equipe.
  • O Scrum éUm processo de desenvolvimentoiterativo e incrementalpara gerenciamento de projetose desenvolvimento ágil de software.
  • Responsável Responsável para Responsável pelopelo produto que o ambiente de desenvolvimento trabalho funcione 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 produtoDefinir claramente o que é o produtocom objetivo de que todos trabalhemcom o própósito de atingir o mesmofim.Deve ser feita antes de se começar odesenvolvimento do projeto.
  • Visão de produtoElevator statement orElevator 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 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 produtoProduct Vision BoxFrente• Nome do produto• Tres ou quatros pontos chaveque ajudem a vender o produtoImagem: http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
  • 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/
  • Visão de produtoTrade off matrix Fixo Variável Custo x Prazo x Escopo x
  • Visão de produtoFator de exploração
  • Visão de produtoCusto de atraso
  • Visão de produtoAtributos de performance e qualidade
  • Visão de produtoArquitetura do produto
  • Visão de produtoDificuldades e riscos
  • Visão de produtoPrincipais marcos do projeto
  • 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
  • Visão de produto
  • 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
  • Visão de produtoUma boa visão de produtopermanece relativamenteconstante, o caminho paraimplementação da visão éfrequentemente adaptado
  • Product backlogLista de tudo que gostaríamos deter no produtoDerivado de um plano de negóciosou de uma visão de produtoPode ser escrito em formato de userstories, use cases, features, etcResponsabilidade do PO, mastodos podem contribuir
  • Product backlogUtilizando user storiesUser StoryDescrição de uma necessidade para um públicoespecífico com um valor de negócioQuem? / O que? / Por que?
  • Product backlogUser storiesIdentificar/conhecer público e definir “personas”Algumas técnicas: • Entrevistas • Questionários • Observação
  • Product backlogUser storiesPara escrever as users stories:• Necessidades dos usuários• Necessidades do cliente/empresa• Histórico do produto (se houver)• PO pode escrever sozinho oupromover 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
  • Product backlogUser 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 feitoscomo casos de aceitação, wireframes ouespecificações e através da comunicação
  • (Sobre documentação...)Do Manifesto Ágil:“Software em funcionamentomais que documentação abrangente”A quantidade e o formatoda documentação deve serfeita de acordo com asnecessidades da equipe edo ambiente.
  • Product backlogUser StoryDescrição de uma necessidade Storypara um público específico comum valor de negócioTemas TemaUm grupo de stories Story Story Story Story Story StoryÉpicosGrande feature sem Épicoespecificação ou definição clara,é uma story grande, bruta
  • 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ãocomparadas com ela• Buy a featureAs funcionalidades são precificadas para que os clientesnegociem a compra das mais importantes
  • Fatores de priorizaçãoValor
  • Fatores de priorizaçãoCustoPlanning poker
  • Fatores de priorizaçãoExploraçãoExploração Quanto mais você acreditade 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 TecnologiaO scrum foi feito para projetos com fator de exploração alto
  • Fatores de priorizaçãoRisco x ValorRisco Alto risco Alto risco Baixo valor Alto valor Baixo risco Baixo risco Baixo valor Alto valor Valor
  • Fatores de priorizaçãoRisco x ValorRisco Alto risco Alto risco Baixo valor Alto valor 1 Baixo risco Baixo risco Baixo valor Alto valor 2 3 Valor
  • Product backlogAlta 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 momentoBaixa prioridade
  • Do manifesto Ágil:"Responder a mudançasmais que seguir um plano”“Colaboração com o clientemais que negociação de contratos”
  • Product backlog Sprint atual (users stories) Release atual (users stories agrupadas por temas) Próxima release (users stories ou epicos)
  • 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?
  • Planejamento de release Continua planejando releases até que a visão de produto seja alcançada Selecionar um tamanho de SprintDeterminar as Estimar os Estimar a Selecionarcondições de itens do velocidade itens e datassatisfação Backlog do Sprint do Release Priorizar User Stories
  • PO + Time
  • comunicação
  • Product Owner deveManter um canal de comunicação forte e abertocom Scrum master/ TimeTer alta disponibilidadeResponder à questões diariamente
  • Product Owner dentro do
  • Product Owner nas cerimonias do ScrumNo Sprint Planning 1, PO leva o backlog idealmenteestimado e priorizado, onde a meta do Sprint deveser definida e o time junto com o PO decide o queentra no SprintDeve participar, APENAS se convidado:• Sprint planning 2• Reuniões diárias• Retrospectiva
  • Do manifesto Ágil:“Indivíduos e interação entre elesmais que processos e ferramentas
  • Time dentro do mesmo elevador que o PO
  • PO dentro do mesmo taxi que o TIME