Histórias de Usuários

Histrias de Usurio
historiasdeusuario.com.br
Rafael Helm e Daniel Wildt
Histrias de Usurio
Avisos Legais
REDISTRIBUIO: Voc concorda que no ir copiar, redistribuir ou explorar comercialmente qualquer parte deste documento
sem a permisso expressa do autor.
AUTORIA: Rafael Helm e Daniel Wildt
EDITOR: Lucas Engel
Copyright 2014 - Todos os direitos reservados

3 edio publicada em novembro de 2014
Histrias de Usurio
Qualidade de software
comea na especificao.
- Rafael Helm
Histrias de Usurio
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 conscientes e em busca de aprendizado contnuo.
Para falar com Rafael e Daniel basta encontr-los no twitter
@rafaelhelm e @dwildt.
Ou se preferir mande email para contato@wildtech.com.br
Histrias de Usurio
Agradecimentos
Assim que liberamos a primeira edio do livro j comeamos a receber timos feedbacks por email. E foi assim que chegaram at ns
valiosas crticas construtivas.
Lemos todos os emails, e cada um contribuiu de alguma forma para
o lanamento desta segunda edio, revisada e ampliada.
Ento nada mais justo do que agradecer algumas pessoas que enviaram feedbacks que nos levaram a melhorar o livro, (em ordem
alfabtica).

Ademlson F. Tonato
Fabrzio de Royes Mello
Frederico Macedo
Hugo Estevam Longo
Mateus Leonardi
Vanessa Me Tonini
E um special thanks tambm ao Lucas Engel pelo brilhante trabalho realizado na diagramao e capa desta terceira edio.
Agora chega de emoo e vai ler livro! :)
CONTEDO
Avisos Legais............................................................... 2
Sobre os Autores.......................................................... 4
Agradecimentos........................................................... 5
Introduo................................................................... 7
Por que escrever histrias de usurio?....................... 9
Existe um padro para escrever?................................ 10
Como testar? BDD!...................................................... 11
O conceito INVEST...................................................... 13
Carto, conversao, Confirmao! O conceito 3C..... 14
Bugs tambm viram histrias de usurio? ................. 15
Exemplo 1: Saque no caixa eletrnico......................... 19
Exemplo 2: Validando tamanho de arquivo............... 23
Priorizando funcionalidades ...................................... 25
Alguns Lembretes valiosos.......................................... 27
Terminei o livro, e agora?............................................ 28
Alguns links quentes sobre histrias de usurios....... 29
Histrias de Usurio
Introduo
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.
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
Histrias de Usurio (user stories), que uma pratica gil de desenvolvimento de software, e o tema central deste livro.
Ao longo dos captulos vamos apresentar a motivao para escrever
requisitos utilizando histrias de usurio, tambm vamos ensinar
como escrever, alm de citar ricos exemplos que podero ser utilizados por voc como guias durante suas primeiras histrias de usurio.
Histrias de Usurio
Importante:
Se voc no tem nenhum conhecimento prvio sobre histrias de
usurio, 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),
ento voc poder navegar diretamente at determinado captulo
para relembrar conceitos e tirar dvidas.
Boa leitura!
Histrias de Usurio
Por que escrever histrias de usurio?

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.
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 histrias de usurio?
Porque ns queremos que voc faa certo na primeira tentativa! E o
seu cliente tambm. :)
Histrias de Usurio
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 histria de usurio, 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 histrias de usurio, 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 valor de negcio obtido.
Normalmente para responder as trs perguntas citadas acima ns
usamos o SENDO... POSSO... PARA QUE...
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 valor 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? Mas ainda falta uma informao muito importante, que
o como testar? Veremos isto no prximo captulo.
10
Histrias de Usurio
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 histria de usurio: 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
Ento a venda no registrada
E exibida na tela a mensagem estoque insuficiente!
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.
11
Histrias de Usurio
Exemplos:
Cenrio 1: Estoque disponvel, venda limitada a 30
E a venda mxima por cliente limitada a 30 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.
Importante: Voc no precisa escrever os critrios de aceitao exatamente desta forma. Mas interessante que voc registre de alguma forma os testes que devem ser realizados para que a histria de
usurio 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.
12
Histrias de Usurio
O conceito INVEST
INVEST um acrnimo (em ingls), que pode nos ajudar a revisar
as histrias de usurio 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 histria de usurio no deve depender de
outra, deve ser possvel negoci-la de forma que voc possa alterar
sua prioridade e ordem de execuo com o cliente, deve agregar
valor, deve ser estimvel, deve ser pequena (at para poder ser
estimada), e deve ser testvel.
Na prtica em alguns casos pode ser bem difcil escrever histrias
de usurio INVEST, mas com o tempo e prtica vai ficando mais fcil. Ento no desista. ;)
13
Histrias de Usurio
Carto, conversao, Confirmao! O

conceito 3C.
Fichas de papel, cartes de papel ou index cards, so uma excelente
forma de manter a vista novas ideias para um produto de software.
E a melhor caracterstica delas o espao limitado.
Como assim? Voc no vai conseguir colocar toda informao necessria na ficha. E isto bom, pode acreditar.
Em 2003 quando eu estava estudando eXtreme Programming, ouvi
uma histria do Ron Jeffries sobre 3C. E desde ento eu aplico e ensino isto, pelo valor que esta prtica agrega no dia a dia de um projeto.
O conceito do 3C baseado em iniciar com a escrita de uma ideia
em um carto, para que possamos lembrar. O carto o primeiro
C. E ele leva ao prximo, gerando um lembrete para a conversao.
Que o que precisamos gerar, conversas. O objetivo com isto validar as ideias, com pessoas que podem ajudar no tpico. O melhor
nestas conversas criar exemplos que ajudem a validar a mesma.
Estes exemplos acabam virando depois cenrios de aceitao da histria. Se um clculo, exemplos de clculos. Atravs deste processo,
criamos um carto executvel. E este o nosso segundo C.
Ah, um carto normalmente possui um documento auxiliar, onde
o requisito em questo documentado seguindo os padres que a
equipe utiliza.
Estas conversas ajudam o time a identificar alguns atributos para os
cartes, exemplo?

senso de valor
prioridade
risco associado
qualquer-atributo-que-o-time-consiga-ver-valor.
O terceiro C sobre confirmao. Atravs das conversas com o

time e clientes poderemos entender como validar o carto e confirmar que o que temos definido o necessrio para fazer acontecer.
E ento isto que precisamos buscar, confirmao! E dos nossos
clientes! Eles iro confirmar sua ideia e ajudar a mesma a crescer.
14
Histrias de Usurio
Bugs tambm viram histrias de usurio?

No! Ns no escrevemos histrias de usurio para registrar erros.
Histrias de usurio 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.
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 possa 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;
15
Histrias de Usurio
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:
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 vai mostrar, identifique configuraes que no esto sendo consideradas, mostre o que deve ser
modificado pensando em regras de negcio para resolver a situao.
16
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;
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, a quantidade informada
10, e o percentual de desconto informado 10%, ento o valor total do produto deve ser 810,00.
Histrias de Usurio
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.
Relatos 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. :)
18
Histrias de Usurio
Exemplo 1: 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 histria de
usurio?
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
19
Histrias de Usurio
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
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
Cenrio 3: Saldo insuficiente (cliente no tem limite)
E meu saldo +600,00
E no tenho limite de cheque especial
Ento o sistema apresenta a mensagem Saldo insuficiente
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
20
Histrias de Usurio
Cenrio 5: Saldo disponvel (sem usar limite)

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)
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
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
21
Histrias de Usurio
Repare como a histria de usurio 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 histria
de usurio, qual especificao mais passvel de bugs?
Provavelmente o email, pois ele cita de forma superficial cada cenrio de teste, enquanto que a histria de usurio detalha melhor cada
um dos cenrios.
22
Histrias de Usurio
Exemplo 2: Validando tamanho de arquivo

Imagine que voc responsvel por manter um servio de importao de arquivos, chamado SIA (Servio de Importao de Arquivos).
Este servio roda em background no servidor e no possui interface
grfica.
O servio fica monitorando um diretrio FTP e importando todos os
arquivos que caem neste diretrio.
Agora imagine que o responsvel pela infraestrutura dos servidores
te mandou o seguinte email.
Ol! Nossos servidores no esto dando conta do recado quando arquivos de importao muito grandes so
enviados pelos usurios.
Ento no podemos processar arquivos com mais de
10Mb, para que o processador do servidor no seja sobrecarregado.
Como voc transformaria este email do responsvel pela infraestrutura em uma histria de usurio?
Segue um exemplo:
SENDO o mdulo SIA
NO POSSO processar arquivos com mais de 10Mb
PARA que os servidores no sejam sobrecarregados
Cenrio 1: Arquivo com tamanho OK
Dado que o arquivo possui at 10mb
E seu layout vlido
Quando o SIA for processar o arquivo
Ento o arquivo processado normalmente
Cenrio 2: Arquivo muito grande
Dado que o arquivo possui mais de 10mb
E seu layout vlido
23
Histrias de Usurio
Quando o SIA for processar o arquivo

Ento o arquivo no processado
E um log gerado no sistema indicando que o arquivo no
foi processado
E um email enviado para o usurio que submeteu o arquivo
via FTP
Repare em algumas caractersticas interessantes desta histria:
Como estamos realizando uma mudana no sistema solicitada pelo
pessoal de infraestrutura, e este pessoal no usurio do sistema
ns acabamos utilizando no SENDO o prprio SIA.
Quando o benefcio da histria no se refere a negcio voc pode
citar o prprio mdulo do sistema na seo SENDO.
Repare que usamos o NO POSSO para indicar o que sistema no
dever mais fazer. Usamos a negao por achar que ficaria mais claro do que usar uma afirmao. Esta deciso fica ao critrio de quem
escrever a histria, o importante que fique claro para quem for ler
a histria.
No PARA ns informamos a motivao que solicitou a validao de
tamanho mximo de arquivos antes do processamento.
Sobre os cenrios:
O cenrio 1 bem bvio e previsvel, mas vale a pena analisarmos o
cenrio 2.
Repare que ns inclumos a gravao de um log e o envio de um
email, nos casos em que o arquivo no foi processado, mesmo que
isto no tenha sido solicitado pelo responsvel da infraestrutura.
Ns fizemos isto porque mesmo sendo um requisito no funcional,
ns acabaramos afetando os usurios nos casos em que os arquivos
com mais de 10Mb fossem ignorados, ento adicionamos o log e o
email para avisar os usurios.
24
Histrias de Usurio
Priorizando funcionalidades
Temos uma lista de funcionalidades. E a grande dvida saber
como priorizar as funcionalidades e por onde priorizar. Existe alguma regra?
muito comum ouvir dos clientes que tanto faz a ordem. Eles querem tudo. S que uma questo de tempo para os clientes entenderem que no bem assim. Uma das nossas tarefas ao trabalhar na
adoo de metodologias geis ajudar nossos clientes a entenderem
que eles tem uma escolha diferente com relao a simplesmente fazer o que precisa ser feito! A opinio deles tem valor e ajuda no desenvolvimento do projeto.
Quando conseguimos comear a trabalhar com clientes e mostrar o
quanto eles podem ganhar com um trabalho organizado de priorizao, isto no tem preo. Ou melhor, sim, tem preo e percebido na
qualidade do trabalho gerado no final de cada ciclo. diretamente
ligado ao alinhamento que o time de projeto consegue ter com o negcio em questo.
O desenvolvimento de software um processo. E este processo
funciona muito com o ritmo das entregas e o valor que conseguimos perceber nas entrevistas e no processo de anlise de negcio.
O ponto pacfico que queremos entregar funcionalidades que tenham valor para o negcio do cliente.
Agora, como identificar o que valor? Ou qual funcionalidade que
tem valor devemos priorizar? Se montarmos um quadrante analisando risco e valor, olhando alto e baixo risco, poderemos descobrir
algumas coisas interessantes.
O que mais se quer so funcionalidades com alto valor e baixo risco.
So atividades que podemos trabalhar sem medo, que tem a tecnologia relacionada bem resolvida, e que vo trazer benefcio direto
para os clientes.
Mas... focar primeiro nestas funcionalidades pode nos levar para
uma situao de risco, justamente por no dar ateno aos itens que
25
Histrias de Usurio
possuem risco mais alto. Uma grande dica neste processo trabalhar em tarefas que possuem risco alto, para justamente remover o
risco tcnico ou de negcio de uma determinada atividade.
Funcionalidades de alto risco e alto valor pode ser uma boa estratgia para garantir que o que precisa ser feito de verdade no projeto e
que possui grandes chances de falha, est sendo analisado primeiro.
Queremos eliminar o risco.
E olha que interessante. Olhando o que tem risco alto e valor alto, e
depois olhando o que possui risco baixo e valor alto, estamos garantindo que estamos fazendo o que o projeto pede. Com estas duas
categorias estamos fazendo o que importa.
Agora, acontece de termos que focar em atividades de risco alto e
baixo valor. No indicado mas pode aparecer em alguma atividade
regulatria, para adequar a empresa em alguma lei, por exemplo.
o tipo de atividade que vai ser feita somente em virtude do impacto
financeiro que ela causa, caso no seja realizada. E aqui a importncia de um bom processo de conversa com os clientes. Muitas vezes
estas atividades acabam ficando esquecidas e se tornam urgncias
dentro do time. Ento muito interessante identificar se o projeto
que est sendo desenvolvido tem este contexto de regulao e ficar
atento as mudanas, para que possamos responder quando for necessrio.
E as de baixo valor e baixo risco? Faa por ltimo, se for realmente
necessrio. Normalmente sero algumas telas de apoio para cadastro. De todo modo, o caso de identificar se o projeto ainda tem oramento e pensar em fazer novas funcionalidades ou at em comear um novo projeto.
26
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.
Dedique ateno especial aos critrios de
aceitao. Eles esto diretamente ligados a
como seu software ser testado.
Histrias de Usurio
Terminei o livro, e agora?

Legal voc no ter abandonado a leitura do livro. Muito obrigado
pela considerao!
Isto provavelmente significa que histrias de usurio devem ter feito 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 divulg-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 histrias de usurio. Comece pelas mais simples. Use os exemplos do livro como guias de referncia.
Ns estamos no twitter, nos siga e manda um al: @rafaelhelm / @
dwildt
28
Histrias de Usurio
Alguns links quentes sobre histrias de

usurios
Artigo:
William Wake - Invest in Good User Stories and Smart Tasks
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Artigo:
Ron Jeffries - How should stories be written
http://xprogramming.com/blog/how-should-user-stories-be-written/
Livro:
Mike Cohn - User Stories Applied
http://amzn.to/1hB6GAK
Livro:
Mike Cohn - Agile Estimating and Planning
http://amzn.to/1heiAjA
29
V e conte as
histrias dos
seus usurios.
:)

Histórias de Usuários

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Histórias de Usuários

Caricato da

Copyright:

Formati disponibili

Histrias de Usurio

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Copyright 2014 - Todos os direitos reservados

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Dependendo da realidade da sua empresa ou equipe, o seu processo

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Por que escrever histrias de usurio?

Rafael Helm e Daniel Wildt

Existe um padro para escrever?

Rafael Helm e Daniel Wildt

Como testar? BDD!

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Independent (deve ser independente)

Rafael Helm e Daniel Wildt

Carto, conversao, Confirmao! O

O terceiro C sobre confirmao. Atravs das conversas com o

Rafael Helm e Daniel Wildt

Bugs tambm viram histrias de usurio?

Rafael Helm e Daniel Wildt

3) Principalmente se uma base de dados especfica est sendo usada

Acessar o ambiente de homologao;

PASSOS PARA REPRODUO DO ERRO:

Rafael Helm e Daniel Wildt

Algumas consideraes sobre o exemplo citado:

Rafael Helm e Daniel Wildt

Exemplo 1: Saque no caixa eletrnico

Rafael Helm e Daniel Wildt

Cenrio 1: Horrio limite

Rafael Helm e Daniel Wildt

Cenrio 5: Saldo disponvel (sem usar limite)

Rafael Helm e Daniel Wildt

Repare como a histria de usurio ficou mais rica do que o email do

Rafael Helm e Daniel Wildt

Exemplo 2: Validando tamanho de arquivo

Rafael Helm e Daniel Wildt

Quando o SIA for processar o arquivo

Rafael Helm e Daniel Wildt

Rafael Helm e Daniel Wildt

Alguns Lembretes valiosos

Rafael Helm e Daniel Wildt

Terminei o livro, e agora?

Rafael Helm e Daniel Wildt

Alguns links quentes sobre histrias de

Potrebbero piacerti anche