PQ e Como Escrever Requisitos de Forma Agil

historiasdeusuario.com.
br 1
Histrias de Usurio Rafael Helm e Daniel Wildt
historiasdeusuario.com.br 2
AVISOS LEGAIS
REDISTRIBUIO: Voc concorda que no ir copiar, redistri-
buir 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
2 edio publicada em junho de 2014
historiasdeusuario.com.br
Qualidade de software
comea na especifcao.
- Rafael Helm
SOBRE OS AUTORES
Rafael Helm e Daniel Wildt so scios da Wildtech, que uma em-
presa de treinamento e consultoria de prticas ligadas ao desenvol-
vimento gil de software.
Seu principal objetivo ajudar pessoas a serem melhores profssio-
nais, 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
AGRADECIMENTOS
Assim que liberamos a primeira edio do livro j comeamos a re-
ceber 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 ajusto do que agradecer algumas pessoas que en-
viaram 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 a Lucas Engel pelo brilhante traba-
lho realizado na diagramao e capa desta segunda 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, Confrmao! 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
Alguns Lembretes valiosos ......................................... 25
Terminei o livro, e agora? ........................................... 26
Alguns links quentes sobre histrias de usurios ...... 27
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: especifcao e desenvolvimento.
Ao contrrio do que muitos acreditam, o desenvolvimento de sof-
tware 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 especifcao dos requisitos.
No basta que sua equipe possua desenvolvedores altamente capa-
citados e responsveis se a especifcao que eles recebem incom-
pleta, superfcial, ou burocrtica demais.
Se a especifcao do software ruim, o resultado do trabalho pro-
vavelmente ser um software igualmente ruim.
Mas totalmente possvel especifcar 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 especifcao de requisitos mais efciente se chama
Histrias de Usurio (user stories), que uma pratica gil de de-
senvolvimento 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 utiliza-
dos por voc como guias durante suas primeiras histrias de usu-
rio.
Importante:
Se voc no tem nenhum conhecimento prvio sobre histrias de
usurio, sugerimos que voc leia o livro seguindo sua sequncia na-
tural.
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!
POR QUE ESCREVER HISTRIAS DE USURIO?
Ao longo dos anos temos visto muitas empresas tratarem seus de-
senvolvedores como funcionrios de uma linha de montagem.
Ou seja, algumas empresas ainda acham que o trabalho de desen-
volvimento de software algo repetitivo, e acreditam que apenas
dizer ao desenvolvedor o que fazer sufciente.
Mas acontece que o desenvolvimento de software um processo
complexo, e na maioria das vezes no se trata de um trabalho repe-
titivo.
comum um desenvolvedor encontrar vrias formas de desenvol-
ver uma mesma funcionalidade, e para que ele possa tomar uma de-
ciso 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 pen-
sando 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 alte-
rando uma funcionalidade por que necessrio reduzir o tempo
mdio de um atendimento, ao terminar o desenvolvimento ele vai
se preocupar em verifcar quanto tempo leva efetivamente um aten-
dimento com a nova interface versus o tempo deste mesmo atendi-
mento 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 ne-
cessidade do cliente. Isto tem como consequncia um ganho signif-
cativo de qualidade!
Ento por que escrever histrias de usurio?
Porque ns queremos que voc faa certo na primeira tentativa! E o
seu cliente tambm. :)
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 especifcao 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 funcio-
nalidade. 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 l-
tima compra, e assim conseguir negociar com ele estando melhor
informado.
Repare que no SENDO ns identifcamos o perfl do usurio que vai
usar a funcionalidade, no POSSO a funcionalidade em si que preci-
sa 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.
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 Develo-
pment) 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 insufciente!
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
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 invli-
do! Para valores inferiores a 20 reais somente dinheiro.
Importante: Voc no precisa escrever os critrios de aceitao exa-
tamente desta forma. Mas interessante que voc registre de algu-
ma 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, quan-
do, ento, mas fca a seu critrio.
Para saber mais sobre BDD acesse a Wikipdia, l voc vai encon-
trar um timo artigo sobre o assunto.
O CONCEITO INVEST
INVEST um acrnimo (em ingls), que pode nos ajudar a revisar
as histrias de usurio para verifcar 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 fcando mais f-
cil. Ento no desista. ;)
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 ne-
cessria na fcha. E isto bom, pode acreditar.
Em 2003 quando eu estava estudando eXtreme Programming, ouvi
uma histria do Ron Jefries sobre 3C. E desde ento eu aplico e en-
sino isto, pelo valor que esta prtica agrega no dia a dia de um pro-
jeto.
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 conversa-
o.
Que o que precisamos gerar, conversas. O objetivo com isto va-
lidar 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 his-
tria. 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 identifcar alguns atributos para os
cartes, exemplo?
senso de valor
prioridade
risco associado
qualquer-atributo-que-o-time-consiga-ver-valor.
O terceiro C sobre confrmao. Atravs das conversas com o
time e clientes poderemos entender como validar o carto e confr-
mar que o que temos defnido o necessrio para fazer acontecer.
E ento isto que precisamos buscar, confrmao! E dos nossos
clientes! Eles iro confrmar sua ideia e ajudar a mesma a crescer.
BUGS TAMBM VIRAM HISTRIAS DE USURIO?
No! Ns no escrevemos histrias de usurio para registrar erros.
Histrias de usurio so uma forma gil de especifcao de novos
requisitos, ou para especifcao 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 resol-
ver 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:
Identifcar em que verso do sistema envolvido o problema pode ser
repetido. Importante identifcar se o problema pode ser repetido na
ltima verso.
PR-CONDIES:
Identifque o que deve estar confgurado no ambiente para
que o problema possa ser repetido;
Pode ser uma lista de confguraes a serem marcadas;
Ou simplesmente a indicao de que uma base de dados espe-
cfca 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 especfco e identifcar o que deve ser preenchido
em cada campo;
3) Principalmente se uma base de dados especfca 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 identifca-
o do que est acontecendo de errado - e muito importante: mos-
trar contexto de negcio identifcando porque a situao atual um
erro.
SITUAO DESEJADA:
Descreva a situao que o sistema vai mostrar, identifque conf-
guraes que no esto sendo consideradas, mostre o que deve ser
modifcado pensando em regras de negcio para resolver a situao.
EXEMPLO:
LOCAL:
SoftVendas Mdulo Mobile Tela de vendas de produtos
VERSO:
Identifcado 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 to-
tal do produto deve ser 810,00.
Algumas consideraes sobre o exemplo citado:
Repare como as sees PR CONDIES e PASSOS PARA A RE-
PRODUO DO ERRO, so importantes para fazer o erro aconte-
cer.
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, verifque 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 efe-
tivos. O importante no relato de um defeito (1) mostrar como re-
petir o problema, (2) detalhar o problema, (3) apresentar o compor-
tamento esperado.
Esperamos que este modelo de relato de bug ajude voc a melhorar
a qualidade da especifcao dos defeitos. Afnal de contas eles no
devem acontecer, mas se acontecer que pelo menos eles sejam re-
solvidos na primeira tentativa. :)
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 eletr-
nicos:
- 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 fcar negativo, exceto se
ele possuir limite de cheque especial;
- O cliente jamais poder ultrapassar seu limite de che-
que especial;
- Deve ser impresso um comprovante de saque ao fnal
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
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 sa-
que no caixa eletrnico est limitado a R$ 800,00
Cenrio 3: Saldo insufciente (cliente no tem limite)
E meu saldo +600,00
E no tenho limite de cheque especial
Ento o sistema apresenta a mensagem Saldo insufciente
Cenrio 4: Saldo insufciente (cliente tem limite)
E meu saldo +100,00
E meu limite de cheque especial 500,00
Ento o sistema apresenta a mensagem Saldo insufciente
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 (confrmao de impresso)
Dado que meu saque foi autorizado
E a tela de impresso de recibo est sendo exibida
Quando eu confrmo 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
Repare como a histria de usurio fcou mais rica do que o email do
cliente.
Nos casos em que o sistema precisou emitir uma mensagem de erro,
ela j estava especifcada 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 refita. Comparando o email do cliente com a histria
de usurio, qual especifcao mais passvel de bugs?
Provavelmente o email, pois ele cita de forma superfcial cada cen-
rio de teste, enquanto que a histria de usurio detalha melhor cada
um dos cenrios.
EXEMPLO 2: VALIDANDO TAMANHO DE ARQUIVO
Imagine que voc responsvel por manter um servio de importa-
o de arquivos, chamado SIA (Servio de Importao de Arquivos).
Este servio roda em background no servidor e no possui interface
grfca.
O servio fca 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 reca-
do 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 so-
brecarregado.
Como voc transformaria este email do responsvel pela infraestru-
tura 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
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 fcaria mais cla-
ro do que usar uma afrmao. Esta deciso fca ao critrio de quem
escrever a histria, o importante que fque 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 fzemos 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.
ALGUNS LEMBRETES VALIOSOS
Qualidade de software comea na especi-
fcao.
Se a especifcao 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.
TERMINEI O LIVRO, E AGORA?
Legal voc no ter abandonado a leitura do livro. Muito obrigado
pela considerao!
Isto provavelmente signifca que histrias de usurio devem ter fei-
to 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, Linke-
dIn, Tumbler e etc. Junte-se a ns e vamos tornar as especifcaes
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 fcar magoados. Pode escrever para
contato@wildtech.com.br
Pratique! Tente escrever algumas histrias de usurio. Comece pe-
las mais simples. Use os exemplos do livro como guias de refern-
cia.
Ns estamos no twitter, nos siga e manda um al: @rafaelhelm / @
dwildt
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 Jefries - How should stories be written
http://xprogramming.com/blog/how-should-user-stories-be-writ-
ten/
Livro:
Mike Cohn - User Stories Applied
http://amzn.to/1hB6GAK
Livro:
Mike Cohn - Agile Estimating and Planning
http://amzn.to/1heiAjA
V e conte as
histrias dos
seus usurios.
:)

PQ e Como Escrever Requisitos de Forma Agil

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PQ e Como Escrever Requisitos de Forma Agil

Hochgeladen von

Copyright:

Verfügbare Formate

historiasdeusuario.com.

Das könnte Ihnen auch gefallen