user stories

5/25/2018 User Stories

1/27

UserStories

Por quee comoescrever requisitosde forma gil?

RAFAEL HELM e DANIEL WILDT

Wildtech start wild, keep wild


2/27

2

Qualidade de software comea naespecificao.

Rafael Helm.


3/27

3

Sobre os autores

Rafael Helm e Daniel Wildt so scios da Wildtech, que umaempresa de treinamento e consultoria de prticas ligadas aodesenvolvimento gil de software.

Seu principal objetivo ajudar pessoas a serem melhoresprofissionais, a realizarem mais e irem em busca daquilo que gera

felicidade, alm de ajudar times a melhorarem continuamente eorganizaes a se tornarem organizaes conscientes e embusca de aprendizado contnuo.

Para falar com Rafael e Daniel bastar encontr-los no twitter@rafaelhelm e @dwildt.

Ou se preferir mande email para [email protected]


4/27

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/27

5

INTRO

Por mais que as tecnologias de desenvolvimento estejamevoluindo cada vez mais rpido, o desenvolvimento de softwareainda 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 seuprocesso pode ser mais simples ou mais complexo do que ocitado acima.

Mas pelo menos duas fases todos os processos dedesenvolvimento de software possuem: Especificao e

desenvolvimento.Ao contrrio do que muitos acreditam, o desenvolvimento desoftware no comea atravs das mos do desenvolvedor quandoelas iniciam a digitar o cdigo. O desenvolvimento de softwarecomea na fase de anlise, e principalmente na especificao dosrequisitos.


6/27

6

No basta que sua equipe possua desenvolvedores altamentecapacitados e responsveis se a especificao que eles recebem incompleta, superficial, ou burocrtica demais.

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

Mas totalmente possvel especificar software de uma formamuito mais efetiva, simples e at divertida do que o mercadonormalmente tem feito ao longo dos anos.

Essa forma de especificao de requisitos mais eficiente sechama User Stories, que uma pratica gil de desenvolvimentode software, e o tema central deste livro.

Ao longo dos captulos vamos te apresentar a motivao paraescrever requisitos utilizando user stories, tambm vamos teensinar como escrever, alm de citar ricos exemplos que poderoser utilizados por voc como guias durante suas primeiras userstories.

Importante:

Se voc no tem nenhum conhecimento prvio sobre user stories,ns sugerimos que voc leia o livro seguindo sua sequncianatural.

Mas se voc j tem uma noo sobre o assunto (ou j leu o livro),voc poder navegar diretamente at determinado captulo pararelembrar conceitos e tirar dvidas.

Boa leitura!


7/27

7

Por que escrever userstories?

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 dedesenvolvimento de software algo repetitivo, e acreditam queapenas dizer ao desenvolvedor o que fazer suficiente.

Mas acontece que o desenvolvimento de software um processocomplexo, e na maioria das vezes no se trata de um trabalho

repetitivo. comum um desenvolvedor encontrar vrias formas dedesenvolver uma mesma funcionalidade, e para que ele possatomar uma deciso correta ele precisa de mais informaes doque apenas saber o que fazer.

importante que ele saiba para quemest sendo criada a nova

funcionalidade.Por exemplo, se o desenvolvedor souber que est desenvolvendoum recurso que ser usado por vendedores que realizam emmdia 50 visitas por dia, bem provvel que ele desenvolva umdesign pensando mais em produtividade do que em elegncia.

Tambm vital que ele saiba o motivo desta funcionalidade, ou

seja, por queesta funcionalidade est sendo desenvolvida.


8/27

8

Dando mais um exemplo: Se um desenvolvedor sabe que estalterando uma funcionalidade por que necessrio reduzir otempo mdio de um atendimento, ao terminar o desenvolvimentoele vai se preocupar em verificar quanto tempo leva efetivamente

um atendimento com a nova interface versus o tempo destemesmo atendimento executado na interface antiga.

Ou seja, repare que nos exemplos citados anteriormente, informarpara queme por quea funcionalidade est sendo desenvolvidaajudou o desenvolvedor a tomar decises mais alinhadas com a

necessidade do cliente. Isto tem como consequncia um ganhosignificativo de qualidade!

Ento por que escrever user stories?

Porque ns queremos que voc faa certo na primeira tentativa!E o seu cliente tambm. :)


9/27

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 queprecisam constar numa boa especificao de requisitos.

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

Quem? Para quem estamos desenvolvendo afuncionalidade.

O que?Uma descrio resumida da funcionalidade em si.

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

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


10/27

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 sualtima compra, e assim conseguir negociar com ele estandomelhor informado.

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

Com estas informaes, o desenvolvedor vai conseguir trabalharmais armado, e provavelmente vai criar uma funcionalidade mais

bem elaborada do que se recebesse apenas a necessidade docliente sem o detalhamento de quemvai usar e por quevai usar.

Entendido? Mais ainda falta uma informao muito importante,que o como testar?Veremos isto no prximo captulo.


11/27

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 parafecharmos a estrutura de uma boa user story: O como testar?

Para isto podemos usar a tcnica do BDD (Behavior DrivenDevelopment) de Dan North, onde as palavras chave Dado que...

Quando... Ento... nos apoiam na criao de ricos cenrios deteste.

Exemplos:

Cenrio 1: Estoque disponvelDado queo estoque da coca-cola de 50 unidades

Quandoinformo uma venda de 40 unidades

Entoa venda registrada

Eo estoque passa a ser de 10 unidades

Cenrio 2: Estoque indisponvel

Dado queo estoque da coca-cola de 50 unidades


Entoa venda no registradaE exibida na tela a mensagem estoque insuficiente!


12/27

12

Repare que nos exemplos anteriores ns usamos o Dado quepara indicar o cenrio atual, o quando para indicar a ao dousurio, e o Ento para indicar como o software vai reagir.

Podemos tambm usar o E e o OU para criar cenrios de testeainda mais ricos.

Exemplos:

Cenrio 1: Estoque disponvel, venda limitada a 30

Dado queo estoque da coca-cola de 50 unidades

Ea venda mxima por cliente limitada a 30 unidades


Entoa venda registrada

Eo estoque passa a ser de 30 unidades

Cenrio 2: Venda com carto indisponvel para valores abaixode 20,00

Dado queo valor da venda de 10,00

Eo valor mnimo de vendas para carto de 20,00

Quandoinformo que o meio de pagamento carto de crdito

OUinformo que o meio de pagamento carto de dbito

Entoa venda no registrada

E exibida na tela a mensagem Meio de pagamentoinvlido! Para valores inferiores a 20 reais somente dinheiro.


13/27

13

Importante: Voc no precisa escrever os critrios de aceitaoexatamente desta forma. Mas e interessante que voc registre dealguma forma os testes que devem ser realizados para que a userstory 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/27

14

O conceito INVEST

INVEST um acrnimo (em ingls), que pode nos ajudar a revisaras 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 dependerde outra,deve ser possvel negocia-lade forma que voc possa alterar suaprioridade e ordem de execuo com o cliente, deve agregarvalor, deve ser possvel estima-la, deve ser pequena(at parapode ser estimada), e deve ser testvel.

Na prtica em alguns casos pode ser bem difcil escrever userstories INVEST, mas com o tempo e prtica vai ficando mais fcil.

Ento no desista. ;)


15/27

15

E os bugs, tambm viram

user stories? NO!!!No! Ns no escrevemos user stories para registrar erros. Userstories so uma forma gil de especificao de novosrequisitos,ou para especificao de evoluesde requisitos.

Mas isto no quer dizer que ns no vamos te mostrar uma formaefetiva de registrar relatos de bugs. ;)

Ao longo dos anos ns obtivemos muito sucesso na correo debugs nos times que trabalhamos. Ou seja, temos conseguido

resolver os bugs na primeira tentativa.Ok, sabemos que os bugs no devem ocorrer, mas infelizmenteeles ocorrem.

Ento veja na pgina a seguir o nosso modelo para relato de bug.


16/27

16

LOCAL:Nome do Sistema - Mdulo e Menu relacionado

VERSO:

Identificar em que verso do sistema envolvido o problema podeser repetido. Importante identificar se o problema pode serrepetido na ltima verso.

PR-CONDIES:

* Identifique o que deve estar configurado no ambiente para queo problema pode ser repetido;

* Pode ser uma lista de configuraes a serem marcadas;

* Ou simplesmente a indicao de que uma base de dadosespecfica deve ser usada.

PASSOS PARA REPRODUO DO ERRO:

1) Monte uma lista indicando os passos que devem ser realizadospara repetir o erro;

2) Voc pode ser especfico e identificar o que deve serpreenchido em cada campo;

3) Principalmente se uma base de dados especfica est sendousada para trabalhar;

4) Deve ser possvel para qualquer pessoa repetir o erro lendoesta lista de passos.

ERRO:


17/27

17

Mostrar o erro que est acontecendo. Pode ser com umaidentificao do que est acontecendo de errado - e muitoimportante: mostrar contexto de negcio identificando porque asituao atual um erro.

SITUAO DESEJADA:

Descreva a situao que o sistema de mostrar, identifiqueconfiguraes que no esto sendo consideradas, mostre o quedeve ser modificado pensando em regras de negcio pararesolver a situao.

Segue um exemplo:

LOCAL: SoftVendas Mdulo Mobile Tela de vendas deprodutos

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/27

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 (podeser 10% de desconto).

ERRO:

Mesmo aps informar o desconto, o valor total do produto seguesendo o mesmo que era antes (sem o desconto).

SITUAO DESEJADA:

Que o valor total do produto considere o desconto aplicado, ouseja:

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 valortotal do produto deve ser 810,00.


19/27

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 erroacontecer.

Perceba tambm que na seo SITUAO DESEJADA alm decitar a explicao do que deve ocorrer ns tambm citamos umexemplo prtico, neste caso com um exemplo real do clculo depreo total do produto.

Ainda sobre o exemplo, verifique que no usamos emoo norelato do defeito, ou seja, no existe nenhuma frase parecida commais uma vez ocorreu um erro primrio na aplicao, ou inadmissvel que erros como este ocorram numa funcionalidadeto importante do nosso software.

Relados carregados de emoo, frustrao ou cobrana no soefetivos. O importante no relato de um defeito (1) mostrar comorepetir o problema, (2) detalhar o problema, (3) apresentar ocomportamento esperado.

Esperamos que este modelo de relato de bug ajude voc a

melhorar a qualidade da especificao dos defeitos. Afinal decontas eles no devem acontecer, mas se acontecer que pelomenos eles sejam resolvidos na primeira tentativa. :)


20/27

20

Exemplo: Saque no caixa

eletrnicoVamos imaginar que voc trabalha em um sistema bancrio deauto atendimento (caixa eletrnico).

Seu cliente envia para voc um email solicitando e explicandocomo 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 chequeespecial;

- 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 userstory?


21/27

21

Segue um exemplo:

SENDO um cliente correntista do banco

POSSO sacar dinheiro em caixas eletrnicos

PARA poder comprar em estabelecimentos que no aceitamcarto 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 somenteso 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 22h59minE j estou autenticado no caixa eletrnico

QUANDO solicito sacar 1.000,00

ENTO o sistema apresenta a mensagem "O valor de um nicosaque no caixa eletrnico est limitado a R$ 800,00"



22/27

22

Cenrio 3: Saldo insuficiente (cliente no tem limite)

DADO QUE a hora atual est entre 6h00min e 22h59min


E meu saldo +600,00

E no tenho limite de cheque especial


ENTO o sistema apresenta a mensagem "Saldo insuficiente"E o saque no realizado

Cenrio 4: Saldo insuficiente (cliente tem limite)



E meu saldo +100,00

E meu limite de cheque especial 500,00


ENTO o sistema apresenta a mensagem "Saldo insuficiente"


Cenrio 5: Saldo disponvel (sem usar limite)




23/27

23

E meu saldo +600,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 22h59minE j estou autenticado no caixa eletrnico

E meu saldo +100,00

E meu limite de cheque especial 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/27

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 deerro ela j estava especificada no prprio critrio de aceitao.

Em todos os casos que o saldo foi manipulado ns registramosexemplos prticos nos critrios de aceitao. Isto ajuda muito no

processo de teste.

Agora pare e reflita. Comparando o email do cliente com a userstory, qual especificao mais passvel de bugs?

Provavelmente o email, pois ele cita de forma superficial cadacenrio de teste, enquanto que a user story detalha melhor cadaum dos cenrios.


25/27

25

Alguns Lembretes valiosos

Qualidade de software comea na especificao.

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

ruim.

Alm de o que fazer o desenvolvedor tambm merecesaber para quem e por que cada funcionalidade serdesenvolvida.

De ateno especial aos critrios de aceitao. Elesesto diretamente ligados a como seu software ser

testado.

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

Evite ao mximo escrever user stories grandes e semprepergunte a si mesmo se uma user story pode ser

quebrada.


26/27

26

Terminei o livro, e agora?

Legal voc no ter abandonado a leitura do livro. Muito obrigadopela considerao!

Isto provavelmente significa que essa tal de user stories deve teralgum sentido para voc. Ou quem sabe voc apenas no tinhanada melhor para fazer mesmo. :)

De qualquer forma ns vamos deixar algumas sugestes sobre oque voc pode fazer a partir de agora:

Se voc gostou do livro ento nos ajude a divulga-lo ecompartilhe o link http://historiasdeusuario.com.br nofacebook, twitter, linkedin, tumbler e etc. Junte se a ns evamos tornar as especificaes de requisitos de software

mais amigveis, objetivas e divertidas.

Mas se voc no gostou do livro ento nos mande emaildizendo o motivo, ns prometemos no ficar magoados.Pode escrever para [email protected]

Pratique! Tente escrever algumas user stories. Comece

pelas mais simples. Use o exemplo do livro como guia dereferncia.

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


27/27

27

V e conte as histriasdos seus usurios. :)

user stories

Documents