O Papel do Product Owner

1.978 visualizações

Publicada em

Publicada em: Tecnologia
2 comentários
8 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
1.978
No SlideShare
0
A partir de incorporações
0
Número de incorporações
31
Ações
Compartilhamentos
0
Downloads
46
Comentários
2
Gostaram
8
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

O Papel do Product Owner

  1. 1. 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
  2. 2. 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/
  3. 3. Waterfall: Abismo entreDefinição de requisitosEntrega do produto
  4. 4. O SCRUM é iterativo e incrementalO cliente não é apenas um geradorde demandas, participa do processoe é parte da equipe.
  5. 5. O Scrum éUm processo de desenvolvimentoiterativo e incrementalpara gerenciamento de projetose desenvolvimento ágil de software.
  6. 6. Responsável Responsável para Responsável pelopelo produto que o ambiente de desenvolvimento trabalho funcione no dia-a-dia
  7. 7. PO é a voz do cliente
  8. 8. 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
  9. 9. 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.
  10. 10. Visão de produtoElevator statement orElevator speech
  11. 11. Visão de produto O que estamos fazendo, por quê, para quem, qual é o principal benefício, qual é o principal diferencial 30”de conversa
  12. 12. 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.
  13. 13. 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/
  14. 14. 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/
  15. 15. Visão de produtoTrade off matrix Fixo Variável Custo x Prazo x Escopo x
  16. 16. Visão de produtoFator de exploração
  17. 17. Visão de produtoCusto de atraso
  18. 18. Visão de produtoAtributos de performance e qualidade
  19. 19. Visão de produtoArquitetura do produto
  20. 20. Visão de produtoDificuldades e riscos
  21. 21. Visão de produtoPrincipais marcos do projeto
  22. 22. 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
  23. 23. Visão de produto
  24. 24. 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
  25. 25. Visão de produtoUma boa visão de produtopermanece relativamenteconstante, o caminho paraimplementação da visão éfrequentemente adaptado
  26. 26. 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
  27. 27. Product backlogUtilizando user storiesUser StoryDescrição de uma necessidade para um públicoespecífico com um valor de negócioQuem? / O que? / Por que?
  28. 28. Product backlogUser storiesIdentificar/conhecer público e definir “personas”Algumas técnicas: • Entrevistas • Questionários • Observação
  29. 29. 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
  30. 30. Product backlogUser story - Story-writing Workshop Fonte: http://www.agileway.com.br/2010/07/20/story-writing-workshop/
  31. 31. Product backlogUser stories Independente Negociável Estimável Pequena Testável
  32. 32. 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
  33. 33. (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.
  34. 34. 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
  35. 35. Fatores de priorização Valor Custo Exploração Risco
  36. 36. 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
  37. 37. Fatores de priorizaçãoValor
  38. 38. Fatores de priorizaçãoCustoPlanning poker
  39. 39. 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
  40. 40. Fatores de priorizaçãoRisco x ValorRisco Alto risco Alto risco Baixo valor Alto valor Baixo risco Baixo risco Baixo valor Alto valor Valor
  41. 41. 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
  42. 42. 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
  43. 43. Do manifesto Ágil:"Responder a mudançasmais que seguir um plano”“Colaboração com o clientemais que negociação de contratos”
  44. 44. Product backlog Sprint atual (users stories) Release atual (users stories agrupadas por temas) Próxima release (users stories ou epicos)
  45. 45. 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?
  46. 46. 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
  47. 47. PO + Time
  48. 48. comunicação
  49. 49. Product Owner deveManter um canal de comunicação forte e abertocom Scrum master/ TimeTer alta disponibilidadeResponder à questões diariamente
  50. 50. Product Owner dentro do
  51. 51. 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
  52. 52. Do manifesto Ágil:“Indivíduos e interação entre elesmais que processos e ferramentas
  53. 53. Time dentro do mesmo elevador que o PO
  54. 54. PO dentro do mesmo taxi que o TIME

×