共计 576 个字符，预计需要花费 2 分钟才能阅读完成。
(Source: User Stories)
用户故事与用例具有相同的用途，但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写，作为系统需要为他们执行的操作。它们与使用场景类似，不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子，没有技术语法。
用户故事也推动了验收测试的创建。必须创建一个或多个自动验收测试以验证用户故事是否已正确实施。
用户故事最大的误解之一是它们与传统的需求规范有何不同。最大的区别在于细节层次。用户故事应该只提供足够的细节，以便对故事实施的时间进行合理的低风险估计。在实施故事的时候，开发人员将转到客户并获得面对面的要求的详细描述。
极限编程流程图
开发人员估计故事可能需要多长时间才能实现。每个故事将在“理想的开发时间”中得到 1,2 或 3 周的估计。这个理想的开发时间是在代码中实现故事所需的时间，如果没有干扰，没有其他任务，并且您确切知道该做什么。超过 3 周意味着您需要进一步打破故事。不到一周的时间，你的水平太过细致，结合了一些故事。大约 80 个用户故事加上或减去 20 是在发布计划期间创建发布计划的完美数字。
故事和需求文档之间的另一个区别是关注用户需求。您应该尝试避免特定技术，数据库布局和算法的详细信息。您应该尝试将故事集中在用户需求和优势上，而不是指定 GUI 布局。
正文完
