User Stories

1.390 visualizações

Publicada em

1 comentário
13 gostaram
Estatísticas
Notas
  • Jogando.net/MU *28*

    Boa tarde amigos,

    Venham conhecer nossos Servidores de Mu
    Online Season 6 http://www.jogando.net/mu/
    >>muitos kits novos;
    >> Nossos GMs online em todos os servers
    Fazem eventos todos os dias:
    Fazemos sua Diversão com qualidade,há mais de 5 anos
    Servers ON 24 horas por dia
    Vários Server esperando por você.Venha se divertir de verdade.
    >>>CURTA nossa Fan page no Facebook e concorra a prêmios.
    SORTEIO de 2 pacotes de 100 JCASHs mais 15 dias VIP Premium
    >>>Conheçam também Animes Cloud -> http://www.animescloud.com, mais de 20.000 videos online,feito exclusivo para sua diversão.
    Site http://www.jogando.net/mu/ Benvindos ao nosso servidor.
    Wartemix Divulgadora Oficial !
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
1.390
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
13
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

User Stories

  1. 1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.brRepresentando requisitos com User Stories
  2. 2. @rodrigobranas rodrigo.branas@gmail.com http://www.agilecode.com.brFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCertificaçõesSCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM
  3. 3. Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 palestras em eventosLíder da área de desenvolvimento na GenneraAutor da revista Java MagazinePalestranteInstrutor da Academia Java e Agile da GlobalcodeCriador dos treinamentos de Clean Code, Selenium eMaven da Agile CodeTrabalhou com as empresas: EDS, HP, GM, Citibank,OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed,Suntech, Vale do Rio Doce, Senai, NET.
  4. 4. Definição de requisito: Condição que se deve satisfazer para alcançar determinado objetivo. (Fonte: dicio.com.br)
  5. 5. Como representar requisitos?
  6. 6. Problemas com abordagens mais pesadas
  7. 7. Desperdício com excesso de documentação
  8. 8. O que nos impedede entregarmais cedo?
  9. 9. O problema não está somente na quantidade de papel...
  10. 10. Aumento da distância entre clientes e equipe
  11. 11. Exposição a falhas noentendimento de documentos
  12. 12. Desperdício com entregas que não atendem as expectativas!
  13. 13. Por que esse tipo de problema ainda acontece?
  14. 14. Materialização dacomunicação sem feedback
  15. 15. User Stories tentam resolverproblemas de comunicação
  16. 16. Redução da quantidade de informação preliminar
  17. 17. Fortalecer a relação entre clientes e a equipe de desenvolvimento
  18. 18. Uma User Story é uma descrição em alto nível sob a perspectiva do cliente
  19. 19. Promessa decomunicação!
  20. 20. Debate: User Stories x Use Cases
  21. 21. Sacando dinheiro
  22. 22. “Como cliente do banco, eu desejopoder sacar dinheiro em terminais eletrônicos para evitar filas.”
  23. 23. The Three Cs of User Stories (by Ron Jeffries) Somente o cartão não basta!
  24. 24. Card
  25. 25. Por que utilizar um template? Como <Tipo de usuário>Desejo <Alcançar um objetivo> Por <Algum motivo>Original: As a <type of user>, I want<some goal> so that <some reason> (Mike Cohn)
  26. 26. Razão 1: Falando em primeirapessoa você pode se colocar no lugar do tipo de usuário em questão
  27. 27. Razão 2: Padronização do Product Backlog, pode facilitar a vida do Product Owner
  28. 28. Story Smell: Falta de justificativa (Exceto em casos óbvios)
  29. 29. Conversation
  30. 30. Cuidado para não conversar com as pessoas erradas
  31. 31. Já parou para pensar: “Por que o nome User Stories”?
  32. 32. Story Smell: Todas as User Stories são focadas no mesmo usuário.
  33. 33. Confirmation atravésde Testes de Aceitação!
  34. 34. Descrição de cenários reais, sepossível utilizando dados válidos
  35. 35. Cenário 1: Realização de saque emuma conta com créditoDado que a conta tem créditoE o cartão está na validadeE o terminal tem dinheiroQuando o cliente solicitar o saqueEntão o débito deve ser realizadoE o dinheiro deve ser entregueE o cartão deve ser devolvido
  36. 36. Cenário 2: Realização de saque emuma conta sem créditoDado que a conta está sem créditoE o cartão é validoQuando o cliente solicitar o saqueEntão a mensagem de aviso decrédito deve ser exibidaE o dinheiro não deve ser entregueE o cartão deve ser devolvido
  37. 37. Cenário 3: Realização de saquecom cartão roubadoIndependente do estado da contaDado que o cartão é roubadoQuando alguém solicitar o saqueEntão a polícia deve ser avisadaE o dinheiro não deve ser entregueE o cartão deve ser retido
  38. 38. Saber quando parar!
  39. 39. Guiar o processo por testes
  40. 40. Story Smell: User Story iniciada sem ao menos um teste de aceitação criado.
  41. 41. Escrevendo User Storiesutilizando o conceito INVEST
  42. 42. Independent
  43. 43. Problemas com priorização e estimativa
  44. 44. Como resolver os problemas de dependência a seguir:“O cliente deseja pagar com Visa” E se existirem outros cartões? (Master, Dinners, AMEX)
  45. 45. Solução 1: Juntar tudo em uma só User Story
  46. 46. Solução 1: Juntar tudo em uma só User StorySolução 2: Encontrar outro modo de dividir as User Stories
  47. 47. Solução 1: Juntar tudo em uma só User StorySolução 2: Encontrar outro modo de dividir as User Stories Solução 3: Colocar duasestimativas, uma se a User Story for feita antes, outra depois
  48. 48. Negotiable
  49. 49. User Stories não são contratos!
  50. 50. “Considere o cartão uma descrição de alto nível”
  51. 51. Capturar a essência, sem sepreocupar tanto com os detalhes
  52. 52. Valuable
  53. 53. As User Stories devem agregar valor para o Cliente
  54. 54. Evitar “User Stories” do tipo:“Alterar protocolo de comunicação”“Criar nova query para...”“Realizar migração de base dedados...”Muitas vezes esses tipos podem ser considerados como atividades!
  55. 55. Estimable
  56. 56. Razões para não conseguir estimar uma User Story:1 – Os desenvolvedores não estãoacostumados com a tecnologia.2 – Falta conhecimento sobre odomínio de negócio envolvido.3 – A User Story é tão grande queexiste incerteza.
  57. 57. Criar uma prova de conceitos
  58. 58. Small
  59. 59. Qual é o tamanho ideal?
  60. 60. Quanto maior, aumenta da incerteza
  61. 61. Não tenha medo dos épicos!
  62. 62. Épicos são compostos por User Stories relacionadas e podemrepresentar toda uma área do sistema. Por exemplo: Sistema de Matrículas
  63. 63. Testable
  64. 64. User Roles
  65. 65. Alguns exemplos de User Roles:• Pessoas em busca de emprego• Empresa em busca defuncionários• Avaliador de currículo• Profissional de RH realizandopesquisa salarial
  66. 66. Story-Writing Workshop
  67. 67. Antes do início do projeto ou antes de cada release
  68. 68. Foco na quantidade
  69. 69. Pensando alto nível
  70. 70. Não julgar as ideias
  71. 71. Story Smell: Perder o focotentando entrar em detalhes específicos da User Story

×