User Stories

  • 825 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • 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 !
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
825
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
1
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.brRepresentando requisitos com User Stories
  • 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. 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. Definição de requisito: Condição que se deve satisfazer para alcançar determinado objetivo. (Fonte: dicio.com.br)
  • 5. Como representar requisitos?
  • 6. Problemas com abordagens mais pesadas
  • 7. Desperdício com excesso de documentação
  • 8. O que nos impedede entregarmais cedo?
  • 9. O problema não está somente na quantidade de papel...
  • 10. Aumento da distância entre clientes e equipe
  • 11. Exposição a falhas noentendimento de documentos
  • 12. Desperdício com entregas que não atendem as expectativas!
  • 13. Por que esse tipo de problema ainda acontece?
  • 14. Materialização dacomunicação sem feedback
  • 15. User Stories tentam resolverproblemas de comunicação
  • 16. Redução da quantidade de informação preliminar
  • 17. Fortalecer a relação entre clientes e a equipe de desenvolvimento
  • 18. Uma User Story é uma descrição em alto nível sob a perspectiva do cliente
  • 19. Promessa decomunicação!
  • 20. Debate: User Stories x Use Cases
  • 21. Sacando dinheiro
  • 22. “Como cliente do banco, eu desejopoder sacar dinheiro em terminais eletrônicos para evitar filas.”
  • 23. The Three Cs of User Stories (by Ron Jeffries) Somente o cartão não basta!
  • 24. Card
  • 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. Razão 1: Falando em primeirapessoa você pode se colocar no lugar do tipo de usuário em questão
  • 27. Razão 2: Padronização do Product Backlog, pode facilitar a vida do Product Owner
  • 28. Story Smell: Falta de justificativa (Exceto em casos óbvios)
  • 29. Conversation
  • 30. Cuidado para não conversar com as pessoas erradas
  • 31. Já parou para pensar: “Por que o nome User Stories”?
  • 32. Story Smell: Todas as User Stories são focadas no mesmo usuário.
  • 33. Confirmation atravésde Testes de Aceitação!
  • 34. Descrição de cenários reais, sepossível utilizando dados válidos
  • 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. 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. 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. Saber quando parar!
  • 39. Guiar o processo por testes
  • 40. Story Smell: User Story iniciada sem ao menos um teste de aceitação criado.
  • 41. Escrevendo User Storiesutilizando o conceito INVEST
  • 42. Independent
  • 43. Problemas com priorização e estimativa
  • 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. Solução 1: Juntar tudo em uma só User Story
  • 46. Solução 1: Juntar tudo em uma só User StorySolução 2: Encontrar outro modo de dividir as User Stories
  • 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. Negotiable
  • 49. User Stories não são contratos!
  • 50. “Considere o cartão uma descrição de alto nível”
  • 51. Capturar a essência, sem sepreocupar tanto com os detalhes
  • 52. Valuable
  • 53. As User Stories devem agregar valor para o Cliente
  • 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. Estimable
  • 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. Criar uma prova de conceitos
  • 58. Small
  • 59. Qual é o tamanho ideal?
  • 60. Quanto maior, aumenta da incerteza
  • 61. Não tenha medo dos épicos!
  • 62. Épicos são compostos por User Stories relacionadas e podemrepresentar toda uma área do sistema. Por exemplo: Sistema de Matrículas
  • 63. Testable
  • 64. User Roles
  • 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. Story-Writing Workshop
  • 67. Antes do início do projeto ou antes de cada release
  • 68. Foco na quantidade
  • 69. Pensando alto nível
  • 70. Não julgar as ideias
  • 71. Story Smell: Perder o focotentando entrar em detalhes específicos da User Story