28 lines
2.6 KiB
Markdown
28 lines
2.6 KiB
Markdown
---
|
|
title: User Stories
|
|
localeTitle: Histórias de Usuários
|
|
---
|
|
As histórias de usuários são parte de uma abordagem ágil que ajuda a mudar o foco de escrever sobre os requisitos para falar sobre eles. Todas as histórias de usuários ágeis incluem uma sentença escrita ou duas e, mais importante, uma série de conversas sobre a funcionalidade desejada.
|
|
|
|
As histórias do usuário geralmente são gravadas usando o seguinte padrão:
|
|
|
|
#### Como \[tipo de usuário\], quero \[algum objetivo\] para que \[algum motivo ou necessidade\]
|
|
|
|
As histórias de usuários devem ser escritas em termos não técnicos da perspectiva do usuário. A história deve enfatizar a necessidade do usuário, e não o como. Não deve haver nenhuma solução fornecida na história do usuário.
|
|
|
|
Um erro comum cometido ao escrever histórias de usuários é escrever da perspectiva do desenvolvedor ou da solução. Certifique-se de declarar a meta e a necessidade, e os requisitos funcionais vêm depois.
|
|
|
|
#### Dimensionando uma história de usuário: epopeias e pequenas histórias
|
|
|
|
Um épico é uma história grande e grosseira. Normalmente, ele é dividido em várias histórias de usuários ao longo do tempo - aproveitando o feedback do usuário sobre os primeiros protótipos e os incrementos de produtos. Você pode pensar nisso como uma manchete e um espaço reservado para histórias mais detalhadas.
|
|
|
|
Começar com épicos permite esboçar a funcionalidade do produto sem se comprometer com os detalhes. Isso é particularmente útil para descrever novos produtos e recursos: ele permite que você capture o escopo aproximado e adquira um tempo para aprender mais sobre como melhor atender às necessidades dos usuários.
|
|
|
|
Também reduz o tempo e o esforço necessários para integrar novos insights. Se você tem muitas histórias detalhadas no backlog do produto, muitas vezes é complicado e demorado relacionar o feedback com os itens apropriados, o que acarreta o risco de introduzir inconsistências.
|
|
|
|
Ao pensar em possíveis histórias, também é importante considerar histórias de "casos de usuários mal-intencionados" e "caminhos infelizes". Como as exceções serão tratadas pelo sistema? Que tipo de mensagens você fornecerá ao usuário? Como um usuário mal-intencionado abusaria dessa função de aplicativo? Essas histórias ruins podem economizar o retrabalho e tornar-se casos de teste úteis no controle de qualidade.
|
|
|
|
#### Mais Informações:
|
|
|
|
* [Guia de software de cabra de montanha para histórias de usuário](https://www.mountaingoatsoftware.com/agile/user-stories)
|
|
* [Roman Pichler Guia para Histórias de Usuários](http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/) |