Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TDC2018SP | Trilha Requisito Ageis - Historias de usuarios - Basico e alem

175 views

Published on

TDC2018SP | Trilha Requisito Ageis - Historias de usuarios - Basico e alem

Published in: Education
  • Be the first to comment

TDC2018SP | Trilha Requisito Ageis - Historias de usuarios - Basico e alem

  1. 1. Histórias de Usuário Augusto Rückert Product Manager @ Grupo Zap The Best The Rare The Rest
  2. 2. grupozap.com
  3. 3. Era uma vez… The Best: Histórias de usuário 101 The Rare: Escrevendo histórias melhores The Rest: Quando não é uma história
  4. 4. The Best História de Usuário 101
  5. 5. ?.
  6. 6. O que é uma história de usuário? ?. Histórias de usuário 101.
  7. 7. Não é uma especificação funcional Não é para relatar um bug Não é um documento de definições técnicas Não é uma enunciação detalhada Não é um requisito Não é um contrato Não é algo para funcionar sem o P.O. O que não é uma história de usuário... ×
  8. 8. Uma história de usuário é... É uma requisição de funcionalidade sobre o ponto de vista do usuário É uma expressão negociável de uma necessidade É uma expressão de um incremento usável de software
  9. 9. Por que escrevemos histórias, não especificações ou requisitos? ?. Histórias de usuário 101.
  10. 10. Facilitam o diálogo Qualquer um pode escrever Qualquer um pode entender a demanda Focam na entrega de valor Facilitam a mudança de comportamento Descrevem uma possibilidade/demanda, não uma solução Escrevemos histórias pois elas
  11. 11. Cascata: o objetivo aqui é gerenciar e garantir o escopo e reduzir o risco
  12. 12. Cascata: esse documento contém TUDO?!
  13. 13. 3Cs !. Histórias de usuário 101. Componentes da histórias de Ron Jeffries
  14. 14. Cartão Conversação Confirmação !. 3Cs.
  15. 15. Sucinta Compreensível por todos Descartável Não é um requisito a ser rastreado 3Cs - Cartão
  16. 16. Discutida e negociada Não é uma ordem É uma ferramenta para o diálogo e tomada de decisão 3Cs - Conversação
  17. 17. Todos confirmam seu entendimento Há consenso O valor está claro Conseguimos progredir 3Cs - Confirmação
  18. 18. Declaração de Valor Critérios de aceitação Anatomia básica de um Cartão
  19. 19. Declaração de Valor Critérios de aceitação Anatomia básica de um Cartão
  20. 20. Modelos de Declaração de Valor !. Histórias de usuário 101.
  21. 21. Como/Sendo um <papel/persona/perfil> quero/preciso/necessito de <meta/desejo> pois/de modo que <benefício> Modelo Connextra (padrão mais conhecido)
  22. 22. Exemplo Como um Vendedor quero adicionar novos itens em um pedido recorrente de modo que não precise reagendar tudo novamente Modelo Connextra (padrão mais conhecido)
  23. 23. Mike Cohn Como um <papel/persona/perfil> quero/preciso/necessito de <meta/desejo> Variações do Modelo Connextra
  24. 24. Mike Cohn Como um Vendedor quero listar todos os pedidos de um cliente Variações do Modelo Connextra
  25. 25. Chris Matts A fim de <benefício a ser recebido> como um <papel/persona/perfil>, eu quero <meta/desejo> Variações do Modelo Connextra
  26. 26. Chris Matts A fim de visualizar toda minha infraestrutura como um Administrador de rede, eu quero uma visão centralizada dos meus elementos monitorados Variações do Modelo Connextra
  27. 27. Variações do Modelo Connextra 5Ws (Who, When, Where, What, Why) Como <quem>, <quando> <onde>, eu <o que>, porque <por que>
  28. 28. Variações do Modelo Connextra 5Ws (Who, When, Where, What, Why) Como Vendedor, ao acessar as últimas vendas efetuadas, eu preciso ordená-las por data de entrega, porque preciso avisar os clientes do prazo dado pela fábrica
  29. 29. Variações do Modelo Connextra Para demonstrar diferenciação Diferente do(a) <situação atual ou indesejada>, Como <papel>, Eu quero/preciso que <situação desejada>
  30. 30. Variações do Modelo Connextra Para demonstrar diferenciação Diferente do relatório de compras atual, Como administrador, Eu quero/preciso que seja informado quem efetuou a compra
  31. 31. The Rare Escrevendo histórias melhores
  32. 32. INVEST !. Escrevendo histórias melhores.
  33. 33. Independente (Independent) Negociável (Negotiable) Possui valor para os usuários/clientes (Valuable to users) Estimável (Estimatable) Pequena (Small) Testável (Testable) Seis atributos para uma boa história, de Bill Wake
  34. 34. Não seja genérico !. Escrevendo histórias melhores.
  35. 35. Não use declarações vagas: "Como usuário..." Uma das grandes vantagens das histórias dos usuários é fazer com que os desenvolvedores entendam mais das motivações dos usuários e tenham maior empatia por eles. Identifique quem é o usuário
  36. 36. A identificação do usuário deve servir como ponto para discussão: O que ele faria? Como ele faria? Qual abordagem se adapta melhor a esse usuário? Identifique quem é o usuário
  37. 37. Defina quando e onde: "[...] a listagem de contatos [...]" "[...] quando adiciono um novo pedido de frete [...]" "[...] ao finalizar a inclusão de um novo host na monitoração [...]" Identifique o contexto
  38. 38. Defina um contexto maior: um objetivo de negócio que sustente mais de uma história Um contexto genérico não irá prover nada de interessante para discussão e melhoria do produto. Somente será uma desculpa para o aumento descontrolado do escopo, baseado em vontades individuais ou opiniões de Hippos Identifique o contexto
  39. 39. Avalie a zona de controle e a esfera de influência !. Escrevendo histórias melhores.
  40. 40. Todo sistema tem 3 áreas: A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos Um pouco de teoria de sistemas...
  41. 41. Todo sistema tem 3 áreas: A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos A esfera de influência que inclui atividades que nós podemos impactar, mas não exercemos controle sobre Um pouco de teoria de sistemas...
  42. 42. Todo sistema tem 3 áreas: A zona de controle que inclui aquelas coisas no sistema que nós podemos mudar nós mesmos A esfera de influência que inclui atividades que nós podemos impactar, mas não exercemos controle sobre E o ambiente externo que inclui os elementos que não temos nenhuma influência Um pouco de teoria de sistemas...
  43. 43. O motivo da necessidade do usuário deve estar na esfera de influência do time O entregável (o que o usuário quer) deve estar na zona de controle do time Em uma boa história...
  44. 44. Como gerente de vendas, eu preciso saber o número total de vendas por vendedor, pois assim posso calcular e submeter as comissões mensais para o RH da empresa
  45. 45. Como gerente de vendas, eu preciso saber o número total de vendas por vendedor, pois assim posso calcular e submeter as comissões mensais para o RH da empresa Zona de controle do time Esfera de influência do time
  46. 46. Uma boa história implica em ter algum risco !. Escrevendo histórias melhores.
  47. 47. Micro-histórias Histórias enganadoras Histórias falsas Situações nas quais não há riscos...
  48. 48. Micro-histórias Difícil identificar os riscos Não são problemáticas por si só Devem ser eliminadas em planejamentos de médio e longo prazo Situações nas quais não há riscos...
  49. 49. Jeff Patton nos diz para pensar em Asteroids…
  50. 50. Histórias enganadoras Descrevem uma solução, e não uma necessidade do usuário Situações nas quais não há riscos...
  51. 51. Histórias enganadoras Como administrador do sistema, quero poder acessar mais rapidamente a interface principal, por isso preciso que a carga de requisições da interface seja reduzida/saneada Situações nas quais não há riscos...
  52. 52. The Rest Quando não é uma história
  53. 53. Não escreva histórias falsas !. Quando não é uma história.
  54. 54. Como desenvolvedor, eu preciso eliminar as tabelas duplicadas da base de dados ?. Quando não é uma história.
  55. 55. Como P.O., eu quero que na listagem de endereços a coluna de nomes fique mais destacada que a coluna de valores ?. Quando não é uma história.
  56. 56. Como testador, eu preciso preparar o plano de testes da versão 3.5 ?. Quando não é uma história.
  57. 57. Por que esses enunciados não são histórias de usuário? ?. Quando não é uma história.
  58. 58. Histórias falsas são aquelas que enunciam necessidades do time: Como desenvolvedor, eu preciso… Como P.O., eu quero… Como testador, eu preciso... Não são usuários... tanto a necessidade quanto a entrega estão na zona de controle do time Por que não é uma história?
  59. 59. Não se trata de um usuário Não é uma requisição de uso para uma persona Não traz valor para o negócio Por que não é uma história?
  60. 60. Se não traz valor para o usuário, por que fazemos? ?. Quando não é uma história.
  61. 61. Bem mais fácil gerar funcionalidades desnecessárias quando fazemos o que queremos
  62. 62. Quando é algo que precisamos fazer !. Quando não é uma história.
  63. 63. Preparação/Manutenção de ambiente Correções de defeitos Ajustes pontuais e melhoria de performance Não entrega valor, mas precisa ser feito
  64. 64. Saber expressar o que precisamos discutir e fazer
  65. 65. Faça para não precisar fazer mais Descreva a ação a ser tomada Discuta e escreva Foque no que pode ser automatizado Para preparar/ajustar o ambiente
  66. 66. Decreva o que está errado Descreva o comportamento aberrante Descreva o comportamento esperado Demonstre ação ou condição Ao executar [...] Quando [...] Para correções de defeitos
  67. 67. Descreva a necessidade O que precisa ser feito, não como faremos Tenha ciência de que você (geralmente) já está em dívida Escreva de forma a manter a conversação Demonstre o valor de fazer aquilo Para ajustes pontuais e melhoria de performance
  68. 68. Descreva a necessidade Precisamos <necessidade>, pois <motivo> Para ajustes pontuais e melhoria de performance
  69. 69. Descreva a necessidade Precisamos ajustar o tamanho das colunas, pois algumas estão com o texto do cabeçalho cortado Para ajustes pontuais e melhoria de performance
  70. 70. Quando é uma pergunta !. Quando não é uma história.
  71. 71. Quando é uma pergunta Há algo a ser feito, mas não sabemos como !. Quando não é uma história.
  72. 72. Se quem fez a requisição não sabe o que quer, vamos descobrir juntos
  73. 73. Há algo a ser feito, mas não sabemos como: Testar uma tecnologia Há alto grau de incerteza na aplicação Não é possível estimar Falta conhecimento no time Temos dúvidas sobre isso...
  74. 74. Determine qual a pergunta a ser respondida Determine qual a entrega esperada Determine um tempo razoável a ser consumido para ter a resposta Negocie quais aspectos serão levados em conta e quais não A sua requisição é uma pergunta
  75. 75. Antes de ir embora...
  76. 76. Antes de ir embora...
  77. 77. Escreva cedo a declaração de valor e deixe para detalhar depois Evite escrever soluções Pense em mais de um stakeholder que pode tirar proveito da solução para a situação elencada. Isso abre oportunidade para quebrar a história depois Dicas finais
  78. 78. Use figuras para explicar a história Escreva as dúvidas Foque na declaração do problema/necessidade do usuário ao invés do problema técnico Discuta a história Dicas finais
  79. 79. Fifty Quick Ideas to Improve Your User Stories Gojko Adzic, David Evans User Stories Applied Mike Cohn User Story Mapping Jeff Patton Algumas referências
  80. 80. Alguma pergunta? Obrigado :) Augusto Rückert Product Manager @ Grupo Zap @ruckert augusto.ruckert@grupozap.com

×