28 lines
1.9 KiB
Markdown
28 lines
1.9 KiB
Markdown
---
|
||
title: User Stories
|
||
localeTitle: 用户故事
|
||
---
|
||
用户故事是敏捷方法的一部分，有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包括一两句话，更重要的是，有关所需功能的一系列对话。
|
||
|
||
用户故事通常使用以下模式编写：
|
||
|
||
#### 作为\[用户类型\]，我想\[某个目标\]以便\[某些原因或需要\]
|
||
|
||
用户故事应该从用户的角度以非技术术语编写。故事应该强调用户的需要，而不是如何。用户故事中不应该提供解决方案。
|
||
|
||
编写用户故事时遇到的一个常见错误是从开发人员或解决方案的角度编写。请务必说明目标和需求，以及稍后的功能要求。
|
||
|
||
#### 调整用户故事：史诗和更小的故事
|
||
|
||
史诗是一个大而粗糙的故事。它通常会随着时间的推移分成几个用户故事 - 利用用户对早期原型和产品增量的反馈。您可以将其视为更详细故事的标题和占位符。
|
||
|
||
从epics开始，您可以绘制产品功能，而无需提交详细信息。这对于描述新产品和功能特别有用：它允许您捕获粗略的范围，并且您可以花时间了解有关如何最好地满足用户需求的更多信息。
|
||
|
||
它还减少了整合新见解所需的时间和精力。如果您在产品待办事项中有许多详细的故事，那么将反馈与相应的项目相关联通常会非常棘手且耗时，并且存在引入不一致的风险。
|
||
|
||
在考虑可能的故事时，考虑“误用户案例”和“不愉快路径”故事也很重要。系统如何处理异常？您将向用户提供什么样的消息？恶意用户如何滥用此应用程序功能？这些故事可以节省返工，并成为QA中的有用测试用例。
|
||
|
||
#### 更多信息：
|
||
|
||
* [Mountain Goat软件用户故事指南](https://www.mountaingoatsoftware.com/agile/user-stories)
|
||
* [Roman Pichler用户故事指南](http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/) |