(Source: User Stories)

用户故事与用例具有相同的用途,但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写,作为系统需要为他们执行的操作。它们与使用场景类似,不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子,没有技术语法。

用户故事也推动了验收测试的创建。 必须创建一个或多个自动验收测试以验证用户故事是否已正确实施。

用户故事最大的误解之一是它们与传统的需求规范有何不同。最大的区别在于细节层次。用户故事应该只提供足够的细节,以便对故事实施的时间进行合理的低风险估计。在实施故事的时候,开发人员将转到客户并获得面对面的要求的详细描述。

clipboard.png

极限编程流程图

开发人员估计故事可能需要多长时间才能实现。每个故事将在“理想的开发时间”中得到1,2或3周的估计。这个理想的开发时间是在代码中实现故事所需的时间,如果没有干扰,没有其他任务,并且您确切知道该做什么。超过3周意味着您需要进一步打破故事。不到一周的时间,你的水平太过细致,结合了一些故事。大约80个用户故事加上或减去20是在发布计划期间创建发布计划的完美数字。

故事和需求文档之间的另一个区别是关注用户需求。您应该尝试避免特定技术,数据库布局和算法的详细信息。您应该尝试将故事集中在用户需求和优势上,而不是指定GUI布局。


Warren2Lynch
211 声望57 粉丝

国际IT公司创始人,博士学位,30多年软件工程和企业架构研发经验