User

Stories
Por que e como escrever requisitos
de forma gil?

RAFAEL HELM e DANIEL WILDT
Wildtech start wild, keep wild

2





Qualidade de software comea na
especificao.
Rafael Helm.


3
Sobre os autores

Rafael Helm e Daniel Wildt so scios da Wildtech, que uma
empresa de treinamento e consultoria de prticas ligadas ao
desenvolvimento gil de software.
Seu principal objetivo ajudar pessoas a serem melhores
profissionais, a realizarem mais e irem em busca daquilo que gera
felicidade, alm de ajudar times a melhorarem continuamente e
organizaes a se tornarem organizaes conscientes e em
busca de aprendizado contnuo.

Para falar com Rafael e Daniel bastar encontr-los no twitter
@rafaelhelm e @dwildt.
Ou se preferir mande email para contato@wildtech.com.br




4
Contedo

INTRO 5
Por que escrever user stories? 7
Existe um padro para escrever? 9
Como testar? BDD! 11
O conceito INVEST 14
E os bugs, tambm viram user stories? NO!!! 15
Exemplo: Saque no caixa eletrnico 20
Lembretes importantes 25
Terminei o livro, e agora? 26



5
INTRO

Por mais que as tecnologias de desenvolvimento estejam
evoluindo cada vez mais rpido, o desenvolvimento de software
ainda um processo complexo. So muitas fases envolvidas:
Anlise de negcios;
Anlise de requisitos;
Projeto de banco de dados;
Desenvolvimento;
Testes;
Implantao.

Dependendo da realidade da sua empresa ou equipe, o seu
processo pode ser mais simples ou mais complexo do que o
citado acima.
Mas pelo menos duas fases todos os processos de
desenvolvimento de software possuem: Especificao e
desenvolvimento.
Ao contrrio do que muitos acreditam, o desenvolvimento de
software no comea atravs das mos do desenvolvedor quando
elas iniciam a digitar o cdigo. O desenvolvimento de software
comea na fase de anlise, e principalmente na especificao dos
requisitos.

6
No basta que sua equipe possua desenvolvedores altamente
capacitados e responsveis se a especificao que eles recebem
incompleta, superficial, ou burocrtica demais.
Se a especificao do software ruim, o resultado do trabalho
provavelmente ser um software igualmente ruim.
Mas totalmente possvel especificar software de uma forma
muito mais efetiva, simples e at divertida do que o mercado
normalmente tem feito ao longo dos anos.
Essa forma de especificao de requisitos mais eficiente se
chama User Stories, que uma pratica gil de desenvolvimento
de software, e o tema central deste livro.
Ao longo dos captulos vamos te apresentar a motivao para
escrever requisitos utilizando user stories, tambm vamos te
ensinar como escrever, alm de citar ricos exemplos que podero
ser utilizados por voc como guias durante suas primeiras user
stories.

Importante:
Se voc no tem nenhum conhecimento prvio sobre user stories,
ns sugerimos que voc leia o livro seguindo sua sequncia
natural.
Mas se voc j tem uma noo sobre o assunto (ou j leu o livro),
voc poder navegar diretamente at determinado captulo para
relembrar conceitos e tirar dvidas.

Boa leitura!

7

Por que escrever user
stories?

Ao longo dos anos temos visto muitas empresas tratarem seus
desenvolvedores como funcionrios de uma linha de montagem.
Ou seja, algumas empresas ainda acham que o trabalho de
desenvolvimento de software algo repetitivo, e acreditam que
apenas dizer ao desenvolvedor o que fazer suficiente.
Mas acontece que o desenvolvimento de software um processo
complexo, e na maioria das vezes no se trata de um trabalho
repetitivo.
comum um desenvolvedor encontrar vrias formas de
desenvolver uma mesma funcionalidade, e para que ele possa
tomar uma deciso correta ele precisa de mais informaes do
que apenas saber o que fazer.
importante que ele saiba para quem est sendo criada a nova
funcionalidade.
Por exemplo, se o desenvolvedor souber que est desenvolvendo
um recurso que ser usado por vendedores que realizam em
mdia 50 visitas por dia, bem provvel que ele desenvolva um
design pensando mais em produtividade do que em elegncia.
Tambm vital que ele saiba o motivo desta funcionalidade, ou
seja, por que esta funcionalidade est sendo desenvolvida.

8
Dando mais um exemplo: Se um desenvolvedor sabe que est
alterando uma funcionalidade por que necessrio reduzir o
tempo mdio de um atendimento, ao terminar o desenvolvimento
ele vai se preocupar em verificar quanto tempo leva efetivamente
um atendimento com a nova interface versus o tempo deste
mesmo atendimento executado na interface antiga.

Ou seja, repare que nos exemplos citados anteriormente, informar
para quem e por que a funcionalidade est sendo desenvolvida
ajudou o desenvolvedor a tomar decises mais alinhadas com a
necessidade do cliente. Isto tem como consequncia um ganho
significativo de qualidade!

Ento por que escrever user stories?
Porque ns queremos que voc faa certo na primeira tentativa!
E o seu cliente tambm. :)


9
Existe um padro para
escrever?

Sim existem alguns padres, mas isto no importa!
Como assim? O que importa voc entender a estrutura base de
uma user story, ou seja, as informaes fundamentais que
precisam constar numa boa especificao de requisitos.

Como j vimos no captulo anterior existem 3 informaes que so
fundamentais nas user stories, so elas:

Quem? Para quem estamos desenvolvendo a
funcionalidade.

O que? Uma descrio resumida da funcionalidade em si.


Por que? O motivo pelo qual o cliente precisa desta
funcionalidade. Se possvel citando o ganho de negcio.

Normalmente para responder as trs perguntas citadas acima ns
usamos o SENDO... POSSO... PARA QUE...


10
Um exemplo:
SENDO um vendedor que realiza 50 visitas por dia
POSSO consultar as ltimas compras de cada cliente
PARA QUE ao chegar no cliente eu possa consultar qual foi sua
ltima compra, e assim conseguir negociar com ele estando
melhor informado.

Repare que no SENDO ns identificamos o perfil do usurio que
vai usar a funcionalidade, no POSSO a funcionalidade em si que
precisa ser desenvolvida e no PARA QUE a motivao da
funcionalidade, incluindo o ganho de negcio.

Com estas informaes, o desenvolvedor vai conseguir trabalhar
mais armado, e provavelmente vai criar uma funcionalidade mais
bem elaborada do que se recebesse apenas a necessidade do
cliente sem o detalhamento de quem vai usar e por que vai usar.
Entendido? Mais ainda falta uma informao muito importante,
que o como testar? Veremos isto no prximo captulo.


11
Como testar? BDD!

No captulo anterior entendemos melhor a importncia do quem,
o que, e por que, mas ainda falta um ponto muito importante para
fecharmos a estrutura de uma boa user story: O como testar?
Para isto podemos usar a tcnica do BDD (Behavior Driven
Development) de Dan North, onde as palavras chave Dado que...
Quando... Ento... nos apoiam na criao de ricos cenrios de
teste.

Exemplos:

Cenrio 1: Estoque disponvel
Dado que o estoque da coca-cola de 50 unidades
Quando informo uma venda de 40 unidades
Ento a venda registrada
E o estoque passa a ser de 10 unidades

Cenrio 2: Estoque indisponvel
Dado que o estoque da coca-cola de 50 unidades
Quando informo uma venda de 60 unidades
Ento a venda no registrada
E exibida na tela a mensagem estoque insuficiente!

12
Repare que nos exemplos anteriores ns usamos o Dado que
para indicar o cenrio atual, o quando para indicar a ao do
usurio, e o Ento para indicar como o software vai reagir.
Podemos tambm usar o E e o OU para criar cenrios de teste
ainda mais ricos.

Exemplos:

Cenrio 1: Estoque disponvel, venda limitada a 30
Dado que o estoque da coca-cola de 50 unidades
E a venda mxima por cliente limitada a 30 unidades
Quando informo uma venda de 20 unidades
Ento a venda registrada
E o estoque passa a ser de 30 unidades

Cenrio 2: Venda com carto indisponvel para valores abaixo
de 20,00
Dado que o valor da venda de 10,00
E o valor mnimo de vendas para carto de 20,00
Quando informo que o meio de pagamento carto de crdito
OU informo que o meio de pagamento carto de dbito
Ento a venda no registrada
E exibida na tela a mensagem Meio de pagamento
invlido! Para valores inferiores a 20 reais somente dinheiro.

13
Importante: Voc no precisa escrever os critrios de aceitao
exatamente desta forma. Mas e interessante que voc registre de
alguma forma os testes que devem ser realizados para que a user
story possa ser bem testada.

Ns particularmente gostamos muito de usar o Dado que,
quando, ento, mas fica a seu critrio.

Para saber mais sobre BDD acesse a Wikipdia, l voc vai
encontrar um timo artigo sobre o assunto.


14
O conceito INVEST

INVEST um acrnimo (em ingls), que pode nos ajudar a revisar
as user stories para verificar se elas foram bem escritas.

Independent (deve ser independente)
Negotiable (deve ser negocivel)
Valuable (deve agregar valor para o cliente)
Estimable (deve ser possvel estima-la)
Small (deve ser pequena)
Testable (deve ser testvel)

Resumindo: Uma boa user story no deve depender de outra,
deve ser possvel negocia-la de forma que voc possa alterar sua
prioridade e ordem de execuo com o cliente, deve agregar
valor, deve ser possvel estima-la, deve ser pequena (at para
pode ser estimada), e deve ser testvel.
Na prtica em alguns casos pode ser bem difcil escrever user
stories INVEST, mas com o tempo e prtica vai ficando mais fcil.
Ento no desista. ;)

15
E os bugs, tambm viram
user stories? NO!!!

No! Ns no escrevemos user stories para registrar erros. User
stories so uma forma gil de especificao de novos requisitos,
ou para especificao de evolues de requisitos.
Mas isto no quer dizer que ns no vamos te mostrar uma forma
efetiva de registrar relatos de bugs. ;)

Ao longo dos anos ns obtivemos muito sucesso na correo de
bugs nos times que trabalhamos. Ou seja, temos conseguido
resolver os bugs na primeira tentativa.
Ok, sabemos que os bugs no devem ocorrer, mas infelizmente
eles ocorrem.
Ento veja na pgina a seguir o nosso modelo para relato de bug.


16
LOCAL: Nome do Sistema - Mdulo e Menu relacionado

VERSO:
Identificar em que verso do sistema envolvido o problema pode
ser repetido. Importante identificar se o problema pode ser
repetido na ltima verso.

PR-CONDIES:
* Identifique o que deve estar configurado no ambiente para que
o problema pode ser repetido;
* Pode ser uma lista de configuraes a serem marcadas;
* Ou simplesmente a indicao de que uma base de dados
especfica deve ser usada.

PASSOS PARA REPRODUO DO ERRO:
1) Monte uma lista indicando os passos que devem ser realizados
para repetir o erro;
2) Voc pode ser especfico e identificar o que deve ser
preenchido em cada campo;
3) Principalmente se uma base de dados especfica est sendo
usada para trabalhar;
4) Deve ser possvel para qualquer pessoa repetir o erro lendo
esta lista de passos.

ERRO:

17
Mostrar o erro que est acontecendo. Pode ser com uma
identificao do que est acontecendo de errado - e muito
importante: mostrar contexto de negcio identificando porque a
situao atual um erro.

SITUAO DESEJADA:
Descreva a situao que o sistema de mostrar, identifique
configuraes que no esto sendo consideradas, mostre o que
deve ser modificado pensando em regras de negcio para
resolver a situao.


Segue um exemplo:

LOCAL: SoftVendas Mdulo Mobile Tela de vendas de
produtos

VERSO:
Identificado na ltima verso (03.50), o problema no ocorre em
verses anteriores.

PR-CONDIES:
* Acessar o ambiente de homologao;
* Logar com usurio alfredo, senha xyz9988;


18

PASSOS PARA REPRODUO DO ERRO:
1) Uma vez j logado no sistema mobile, acesse o menu
Vendas;
2) Selecione um cliente qualquer e abra uma nova venda;
3) Na tela de listagem de produtos, selecione qualquer produto;
4) Aps selecionar um produto informe a quantidade a ser vendida
(pode ser 10), e no campo desconto informe um desconto (pode
ser 10% de desconto).

ERRO:
Mesmo aps informar o desconto, o valor total do produto segue
sendo o mesmo que era antes (sem o desconto).

SITUAO DESEJADA:
Que o valor total do produto considere o desconto aplicado, ou
seja:
Valor total do produto = (Valor unitrio * Quantidade) Desconto.
Exemplo: Se valor do produto 90,00, e a quantidade informada
10, e o percentual de desconto informado 10%, ento o valor
total do produto deve ser 810,00.




19
Algumas consideraes sobre o exemplo citado:

Repare como as sees PR CONDIES e PASSOS PARA A
REPRODUO DO ERRO, so importantes para fazer o erro
acontecer.
Perceba tambm que na seo SITUAO DESEJADA alm de
citar a explicao do que deve ocorrer ns tambm citamos um
exemplo prtico, neste caso com um exemplo real do clculo de
preo total do produto.

Ainda sobre o exemplo, verifique que no usamos emoo no
relato do defeito, ou seja, no existe nenhuma frase parecida com
mais uma vez ocorreu um erro primrio na aplicao, ou
inadmissvel que erros como este ocorram numa funcionalidade
to importante do nosso software.
Relados carregados de emoo, frustrao ou cobrana no so
efetivos. O importante no relato de um defeito (1) mostrar como
repetir o problema, (2) detalhar o problema, (3) apresentar o
comportamento esperado.

Esperamos que este modelo de relato de bug ajude voc a
melhorar a qualidade da especificao dos defeitos. Afinal de
contas eles no devem acontecer, mas se acontecer que pelo
menos eles sejam resolvidos na primeira tentativa. :)

20
Exemplo: Saque no caixa
eletrnico
Vamos imaginar que voc trabalha em um sistema bancrio de
auto atendimento (caixa eletrnico).
Seu cliente envia para voc um email solicitando e explicando
como funciona o saque do banco:

Ol! Precisamos disponibilizar a operao de saque no caixa
eletrnico.
Segue as regras do banco para saques em caixas eletrnicos:
- Por questes de segurana o valor mximo de cada saque de
800,00;
- Os saques s esto liberados entre 6h00min e 22h59, em
qualquer dia, til ou no;
- O saldo do cliente no pode ficar negativo, exceto se ele possuir
limite de cheque especial;
- O cliente jamais poder ultrapassar seu limite de cheque
especial;
- Deve ser impresso um comprovante de saque ao final da
operao, (se o cliente assim desejar).

Como voc transformaria este email do cliente em uma user
story?

21

Segue um exemplo:

SENDO um cliente correntista do banco
POSSO sacar dinheiro em caixas eletrnicos
PARA poder comprar em estabelecimentos que no aceitam
carto de dbito/crdito

Cenrio 1: Horrio limite
DADO QUE so 5h00
E j estou autenticado no caixa eletrnico
QUANDO solicito sacar 10,00
ENTO o sistema apresenta a mensagem "Os saques somente
so permitidos entre 6h00min e 22h59"
E o saque no realizado

Cenrio 2: Valor mximo de saque
DADO QUE a hora atual est entre 6h00min e 22h59min
E j estou autenticado no caixa eletrnico
QUANDO solicito sacar 1.000,00
ENTO o sistema apresenta a mensagem "O valor de um nico
saque no caixa eletrnico est limitado a R$ 800,00"
E o saque no realizado

22

Cenrio 3: Saldo insuficiente (cliente no tem limite)
DADO QUE a hora atual est entre 6h00min e 22h59min
E j estou autenticado no caixa eletrnico
E meu saldo +600,00
E no tenho limite de cheque especial
QUANDO solicito sacar 700,00
ENTO o sistema apresenta a mensagem "Saldo insuficiente"
E o saque no realizado

Cenrio 4: Saldo insuficiente (cliente tem limite)
DADO QUE a hora atual est entre 6h00min e 22h59min
E j estou autenticado no caixa eletrnico
E meu saldo +100,00
E meu limite de cheque especial 500,00
QUANDO solicito sacar 700,00
ENTO o sistema apresenta a mensagem "Saldo insuficiente"
E o saque no realizado

Cenrio 5: Saldo disponvel (sem usar limite)
DADO QUE a hora atual est entre 6h00min e 22h59min
E j estou autenticado no caixa eletrnico

23
E meu saldo +600,00
QUANDO solicito sacar 200,00
ENTO o sistema libera o dinheiro no caixa eletrnico
E meu saldo passa a ser +400,00
E a tela de emisso de impresso de recibo exibida

Cenrio 6: Saldo disponvel (usando limite)
DADO QUE a hora atual est entre 6h00min e 22h59min
E j estou autenticado no caixa eletrnico
E meu saldo +100,00
E meu limite de cheque especial 500,00
QUANDO solicito sacar 500,00
ENTO o sistema libera o dinheiro no caixa eletrnico
E meu saldo passa a ser -400,00
E a tela de emisso de impresso de recibo exibida

Cenrio 7: Emisso de recibo (confirmao de impresso)
DADO QUE meu saque foi autorizado
E a tela de impresso de recibo est sendo exibida
QUANDO eu confirmo a impresso do recibo
ENTO o recibo impresso
E o sistema retorna a tela inicial do caixa eletrnico

24

Cenrio 8: Emisso de recibo (impresso ignorada)
DADO QUE meu saque foi autorizado
E a tela de impresso de recibo est sendo exibida
QUANDO eu indico no imprimir o recibo
ENTO o sistema retorna a tela inicial do caixa eletrnico


Repare como a user story ficou mais rica do que o email do cliente.
Nos casos em que o sistema precisou emitir uma mensagem de
erro ela j estava especificada no prprio critrio de aceitao.
Em todos os casos que o saldo foi manipulado ns registramos
exemplos prticos nos critrios de aceitao. Isto ajuda muito no
processo de teste.
Agora pare e reflita. Comparando o email do cliente com a user
story, qual especificao mais passvel de bugs?
Provavelmente o email, pois ele cita de forma superficial cada
cenrio de teste, enquanto que a user story detalha melhor cada
um dos cenrios.


25
Alguns Lembretes valiosos

Qualidade de software comea na especificao.

Se a especificao do software ruim, o resultado do
trabalho provavelmente ser um software igualmente
ruim.

Alm de o que fazer o desenvolvedor tambm merece
saber para quem e por que cada funcionalidade ser
desenvolvida.

De ateno especial aos critrios de aceitao. Eles
esto diretamente ligados a como seu software ser
testado.

Quando voc achar que uma user story est pronta
verifique se ela ficou INVEST.

Evite ao mximo escrever user stories grandes e sempre
pergunte a si mesmo se uma user story pode ser
quebrada.


26
Terminei o livro, e agora?

Legal voc no ter abandonado a leitura do livro. Muito obrigado
pela considerao!
Isto provavelmente significa que essa tal de user stories deve ter
algum sentido para voc. Ou quem sabe voc apenas no tinha
nada melhor para fazer mesmo. :)
De qualquer forma ns vamos deixar algumas sugestes sobre o
que voc pode fazer a partir de agora:
Se voc gostou do livro ento nos ajude a divulga-lo e
compartilhe o link http://historiasdeusuario.com.br no
facebook, twitter, linkedin, tumbler e etc. Junte se a ns e
vamos tornar as especificaes de requisitos de software
mais amigveis, objetivas e divertidas.

Mas se voc no gostou do livro ento nos mande email
dizendo o motivo, ns prometemos no ficar magoados.
Pode escrever para contato@wildtech.com.br

Pratique! Tente escrever algumas user stories. Comece
pelas mais simples. Use o exemplo do livro como guia de
referncia.

Ns estamos no twitter, nos siga e manda um al.
http://twitter.com/rafaelhelm / http://twitter.com/dwildt





27






V e conte as histrias
dos seus usurios. :)