histórias de usuários

historiasdeusuario.com.br 1

Histrias de Usurio Rafael Helm e Daniel Wildt



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 WildtEDITOR: Lucas Engel

Copyright 2014 - Todos os direitos reservados3 edio publicada em novembro de 2014

historiasdeusuario.com.br



Qualidade de software comea na especificao.

- Rafael Helm



sobre os AutoresRafael 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 profissio-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 [email protected]



AgrAdecimentosAssim 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 justo 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 ao Lucas Engel pelo brilhante traba-lho 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



introduoPor 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 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 especificao dos requisitos.

No basta que sua equipe possua desenvolvedores altamente capa-citados e responsveis se a especificao que eles recebem incom-pleta, superficial, ou burocrtica demais.

Se a especificao do software ruim, o resultado do trabalho pro-vavelmente 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 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 suficiente.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 verificar 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 signifi-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 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 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 diaPOSSO consultar as ltimas compras de cada clientePARA 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 funcio-nalidade, 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 disponvelDado que o estoque da coca-cola de 50 unidadesQuando informo uma venda de 40 unidadesEnto a venda registrada

E o estoque passa a ser de 10 unidades

Cenrio 2: Estoque indisponvelDado que o estoque da coca-cola de 50 unidadesQuando informo uma venda de 60 unidadesEnto 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.



Exemplos:

Cenrio 1: Estoque disponvel, venda limitada a 30Dado que o estoque da coca-cola de 50 unidades

E a venda mxima por cliente limitada a 30 unidadesQuando informo uma venda de 20 unidadesEnto a venda registrada

E o estoque passa a ser de 30 unidades

Cenrio 2: Venda com carto indisponvel para valores abaixo de 20,00Dado que o valor da venda de 10,00

E o valor mnimo de vendas para carto de 20,00Quando informo que o meio de pagamento carto de crdito

OU informo que o meio de pagamento carto de dbitoEnto 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 fica a seu critrio.

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



o conceito investINVEST 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 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 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 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 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 confir-mar 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.



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 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: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 espe-cfica 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:Mostrar o erro que est acontecendo. Pode ser com uma identifica-o do que est acontecendo de errado - e muito importante: mos-trar contexto de negcio identificando porque a situao atual um erro.

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

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 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, 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 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 especificao dos defeitos. Afinal de contas eles no devem acontecer, mas se acontecer que pelo menos eles sejam re-solvidos na primeira tentativa. :)



exemPLo 1: sAque no cAixA eLetrnicoVamos 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 ficar 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 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 bancoPOSSO sacar dinheiro em caixas eletrnicosPARA poder comprar em estabelecimentos que no aceitam carto de dbito/crdito



Cenrio 1: Horrio limiteDado que so 5h00

E j estou autenticado no caixa eletrnicoQuando solicito sacar 10,00Ento o sistema apresenta a mensagem Os saques somente so permitidos entre 6h00min e 22h59

E o saque no realizado

Cenrio 2: Valor mximo de saqueDado que a hora atual est entre 6h00min e 22h59min

E j estou autenticado no caixa eletrnicoQuando solicito sacar 1.000,00Ento o sistema apresenta a mensagem O valor de um nico sa-que no caixa eletrnico est limitado a R$ 800,00


Cenrio 3: Saldo insuficiente (cliente no tem limite)

Dado que a hora atual est entre 6h00min e 22h59min E j estou autenticado no caixa eletrnicoE meu saldo +600,00E no tenho limite de cheque especial

Quando solicito sacar 700,00Ento o sistema apresenta a mensagem Saldo insuficiente


Cenrio 4: Saldo insuficiente (cliente tem limite)

Dado que a hora atual est entre 6h00min e 22h59min E j estou autenticado no caixa eletrnicoE meu saldo +100,00E meu limite de cheque especial 500,00

Quando solicito sacar 700,00Ento o sistema apresenta a mensagem Saldo insuficiente




Cenrio 5: Saldo disponvel (sem usar limite)

Dado que a hora atual est entre 6h00min e 22h59min E j estou autenticado no caixa eletrnicoE meu saldo +600,00

Quando solicito sacar 200,00Ento o sistema libera o dinheiro no caixa eletrnico

E meu saldo passa a ser +400,00E 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 eletrnicoE meu saldo +100,00E meu limite de cheque especial 500,00

Quando solicito sacar 500,00Ento o sistema libera o dinheiro no caixa eletrnico

E meu saldo passa a ser -400,00E a tela de emisso de impresso de recibo exibida

Cenrio 7: Emisso de recibo (confirmao de impresso)

Dado que meu saque foi autorizadoE a tela de impresso de recibo est sendo exibida

Quando eu confirmo a impresso do reciboEnto 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 autorizadoE a tela de impresso de recibo est sendo exibida

Quando eu indico no imprimir o reciboEnto o sistema retorna a tela inicial do caixa eletrnico



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 cen-rio de teste, enquanto que a histria de usurio detalha melhor cada um dos cenrios.



exemPLo 2: vALidAndo tAmAnho de ArquivoImagine 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 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 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 SIANO POSSO processar arquivos com mais de 10MbPARA que os servidores no sejam sobrecarregados

Cenrio 1: Arquivo com tamanho OK

Dado que o arquivo possui at 10mbE seu layout vlido

Quando o SIA for processar o arquivoEnto o arquivo processado normalmente

Cenrio 2: Arquivo muito grandeDado que o arquivo possui mais de 10mb

E seu layout vlido



Quando o SIA for processar o arquivoEnto o arquivo no processado

E um log gerado no sistema indicando que o arquivo no foi processadoE 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 cla-ro 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.



PriorizAndo funcionALidAdes Temos uma lista de funcionalidades. E a grande dvida saber como priorizar as funcionalidades e por onde priorizar. Existe algu-ma regra?

muito comum ouvir dos clientes que tanto faz a ordem. Eles que-rem tudo. S que uma questo de tempo para os clientes entende-rem 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 fa-zer o que precisa ser feito! A opinio deles tem valor e ajuda no de-senvolvimento do projeto.

Quando conseguimos comear a trabalhar com clientes e mostrar o quanto eles podem ganhar com um trabalho organizado de prioriza-o, 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 ne-gcio em questo.

O desenvolvimento de software um processo. E este processo funciona muito com o ritmo das entregas e o valor que consegui-mos perceber nas entrevistas e no processo de anlise de negcio. O ponto pacfico que queremos entregar funcionalidades que te-nham valor para o negcio do cliente.

Agora, como identificar o que valor? Ou qual funcionalidade que tem valor devemos priorizar? Se montarmos um quadrante anali-sando 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 tec-nologia 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



possuem risco mais alto. Uma grande dica neste processo traba-lhar 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 estrat-gia 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 garan-tindo 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 importn-cia 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 ne-cessrio.

E as de baixo valor e baixo risco? Faa por ltimo, se for realmente necessrio. Normalmente sero algumas telas de apoio para cadas-tro. De todo modo, o caso de identificar se o projeto ainda tem or-amento e pensar em fazer novas funcionalidades ou at em come-ar um novo projeto.

ALguns Lembretes vALiosos

Qualidade de software comea na especi-ficao.

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.



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 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 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 [email protected]! 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 Taskshttp://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-writ-ten/

Livro: Mike Cohn - User Stories Applied http://amzn.to/1hB6GAK

Livro: Mike Cohn - Agile Estimating and Planninghttp://amzn.to/1heiAjA

V e conte ashistrias dos

seus usurios.:)

Avisos LegaisSobre os AutoresAgradecimentosIntroduoPor que escrever histrias de usurio?Existe um padro para escrever?Como testar? BDD!O conceito INVESTCarto, conversao, Confirmao! O conceito 3C.Bugs tambm viram histrias de usurio? Exemplo 1: Saque no caixa eletrnicoExemplo 2: Validando tamanho de arquivoPriorizando funcionalidades Alguns Lembretes valiososTerminei o livro, e agora?Alguns links quentes sobre histrias de usurios

histórias de usuários

Documents