Rodrigo Branas tem experiência em desenvolvimento Java, gerenciamento de projetos e certificações. Ele trabalhou para várias empresas e ministrou treinamentos sobre diversos tópicos de tecnologia.

1. Rodrigo Branas – @rodrigobranas - http://www.agilecode.com.br
Representando requisitos
com User Stories

3. @rodrigobranas
rodrigo.branas@gmail.com
http://www.agilecode.com.br
Formação Acadêmica
Ciências da Computação – UFSC
Gerenciamento de Projetos - FGV
Certificações
SCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM

4. Rodrigo Branas – rodrigo.branas@gmail.com
10 anos de experiência na plataforma Java
1000 horas em sala de aula
Mais de 50 palestras em eventos
Líder da área de desenvolvimento na Gennera
Autor da revista Java Magazine
Palestrante
Instrutor da Academia Java e Agile da Globalcode
Criador dos treinamentos de Clean Code, Selenium e
Maven da Agile Code
Trabalhou com as empresas: EDS, HP, GM, Citibank,
OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed,
Suntech, Vale do Rio Doce, Senai, NET.

5. Definição de requisito: Condição que
se deve satisfazer para alcançar
determinado objetivo.
(Fonte: dicio.com.br)

6. Como representar requisitos?

7. Problemas com abordagens
mais pesadas

8. Desperdício com excesso de
documentação

9. O que nos impede
de entregar
mais cedo?

10. O problema não está somente na
quantidade de papel...

11. Aumento da distância entre
clientes e equipe

12. Exposição a falhas no
entendimento de documentos

13. Desperdício com entregas que não
atendem as expectativas!

14. Por que esse tipo de problema
ainda acontece?

15. Materialização da
comunicação sem feedback

16. User Stories tentam resolver
problemas de comunicação

17. Redução da quantidade de
informação preliminar

18. Fortalecer a relação entre clientes
e a equipe de desenvolvimento

19. Uma User Story é uma descrição
em alto nível sob a perspectiva
do cliente

20. Promessa de
comunicação!

21. Debate: User Stories x Use Cases

22. Sacando dinheiro

23. “Como cliente do banco, eu desejo
poder sacar dinheiro em terminais
eletrônicos para evitar filas.”

24. The Three C's of User Stories
(by Ron Jeffries)
Somente o cartão não basta!

25. Card

26. 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)

27. Razão 1: Falando em primeira
pessoa você pode se colocar no lugar
do tipo de usuário em questão

28. Razão 2: Padronização do Product
Backlog, pode facilitar a vida do
Product Owner

29. Story Smell: Falta de justificativa
(Exceto em casos óbvios)

30. Conversation

31. Cuidado para não conversar com
as pessoas erradas

32. Já parou para pensar: “Por que o
nome User Stories”?

33. Story Smell: Todas as User Stories
são focadas no mesmo usuário.

34. Confirmation através
de Testes de Aceitação!

35. Descrição de cenários reais, se
possível utilizando dados válidos

36. Cenário 1: Realização de saque em
uma conta com crédito
Dado que a conta tem crédito
E o cartão está na validade
E o terminal tem dinheiro
Quando o cliente solicitar o saque
Então o débito deve ser realizado
E o dinheiro deve ser entregue
E o cartão deve ser devolvido

37. Cenário 2: Realização de saque em
uma conta sem crédito
Dado que a conta está sem crédito
E o cartão é valido
Quando o cliente solicitar o saque
Então a mensagem de aviso de
crédito deve ser exibida
E o dinheiro não deve ser entregue
E o cartão deve ser devolvido

38. Cenário 3: Realização de saque
com cartão roubado
Independente do estado da conta
Dado que o cartão é roubado
Quando alguém solicitar o saque
Então a polícia deve ser avisada
E o dinheiro não deve ser entregue
E o cartão deve ser retido

39. Saber quando parar!

40. Guiar o processo
por testes

41. Story Smell: User Story iniciada
sem ao menos um teste de
aceitação criado.

42. Escrevendo User Stories
utilizando o conceito INVEST

43. Independent

44. Problemas com priorização e
estimativa

45. Como resolver os problemas de
dependência a seguir:
“O cliente deseja pagar com Visa”
E se existirem outros cartões?
(Master, Dinners, AMEX)

46. Solução 1: Juntar tudo em uma
só User Story

47. Solução 1: Juntar tudo em uma
só User Story
Solução 2: Encontrar outro modo
de dividir as User Stories

48. Solução 1: Juntar tudo em uma
só User Story
Solução 2: Encontrar outro modo
de dividir as User Stories
Solução 3: Colocar duas
estimativas, uma se a User Story
for feita antes, outra depois

49. Negotiable

50. User Stories não são contratos!

51. “Considere o cartão uma
descrição de alto nível”

52. Capturar a essência, sem se
preocupar tanto com os detalhes

53. Valuable

54. As User Stories devem agregar
valor para o Cliente

55. Evitar “User Stories” do tipo:
“Alterar protocolo de comunicação”
“Criar nova query para...”
“Realizar migração de base de
dados...”
Muitas vezes esses tipos podem ser
considerados como atividades!

56. Estimable

57. Razões para não conseguir
estimar uma User Story:
1 – Os desenvolvedores não estão
acostumados com a tecnologia.
2 – Falta conhecimento sobre o
domínio de negócio envolvido.
3 – A User Story é tão grande que
existe incerteza.

58. Criar uma prova de conceitos

59. Small

60. Qual é o tamanho ideal?

61. Quanto maior, aumenta da
incerteza

62. Não tenha medo dos épicos!

63. Épicos são compostos por User
Stories relacionadas e podem
representar toda uma área do
sistema.
Por exemplo: Sistema de
Matrículas

64. Testable

65. User Roles

66. Alguns exemplos de User Roles:
• Pessoas em busca de emprego
• Empresa em busca de
funcionários
• Avaliador de currículo
• Profissional de RH realizando
pesquisa salarial

67. Story-Writing Workshop

68. Antes do início do projeto ou
antes de cada release

69. Foco na quantidade

70. Pensando alto nível

71. Não julgar as ideias

72. Story Smell: Perder o foco
tentando entrar em detalhes
específicos da User Story