Scrum - 用户故事



如您所知,用户故事通常用于描述产品功能,并将成为 Scrum 工件的一部分 – **产品待办事项** 和 **冲刺待办事项**。

用户故事

在软件开发中,产品功能起着至关重要的作用。最终用户希望在最终产品中使用这些功能。在一般术语中,它们被称为需求。软件开发项目的成功在于准确地理解用户需求,并将其适当地实施到最终产品中。因此,开发项目团队需要充分了解需求或产品功能。

1999 年,Kent Beck 提出了用户故事这一术语来描述产品功能。他描述了用户故事是从用户的角度叙述的,关于他或她想要什么,而不是系统能为他做什么。因此,视角完全从产品转向了用户,用户故事成为了所有敏捷框架中需求的事实标准。

在 Scrum 项目中,产品待办事项是用户故事的列表。这些用户故事会被优先级排序,并在冲刺计划会议中纳入冲刺待办事项。

估算也基于用户故事,产品的大小以用户故事点数进行估算。

用户故事结构

用户故事结构如下:

作为 <用户类型>

我想要 <执行某些任务>

以便 <我能够实现某些目标/收益/价值>

让我们来看一下如何为银行客户从 ATM 取款的场景构建用户故事。

用户故事:客户取款

作为 客户

我想要 从 ATM 取款

以便 我不用在银行排队等候

用户故事验收标准

每个用户故事都定义了验收标准,以便通过基于验收标准的验收测试来确认用户故事实现的正确性。

以下是客户取款用户故事示例的验收标准样本。

验收标准 1

如果账户信用良好

  • 并且卡片有效
  • 并且出钞机有现金,

客户请求取款

确保账户被扣款

  • 并且确保现金被发放
  • 并且确保卡片被退回。

验收标准 2

如果账户透支

  • 并且卡片有效

客户请求取款

确保显示拒绝消息

  • 并且确保现金未被发放
  • 并且确保卡片被退回。

编写用户故事

产品负责人负责产品待办事项,因此也负责用户故事。但这并不意味着只有产品负责人才能编写用户故事。Scrum 团队中的任何人都可以编写用户故事,并且随着需求的完善和新功能的添加,该活动可以在整个项目中展开。

用户故事中的非功能性需求

也可以将非功能性需求纳入用户故事中。在给定的 ATM 示例中,ATM 需要 24x7、365 天全天候可用,这是一个非功能性需求,可以用用例来描述。

管理用户故事

用户故事在产品待办事项中进行管理。用户故事按优先级排序。优先级最高的用户故事会被细化到粒度级别,而优先级最低的用户故事则保持较低的细节级别。对于每个冲刺,都会将优先级最高,因此粒度更高的用户故事纳入冲刺待办事项。如果要向产品待办事项添加用户故事,则首先确定其优先级,并根据其优先级将其放置到相应的位置。用户故事可以随时重新排序。如果需要,也可以删除任何用户故事。

用户故事的优势

  • 用户故事的主要优势在于其以用户为中心的定义本身。这是因为,最终,用户将在相关的用户场景中使用该产品。它将最终用户与团队成员联系起来。

  • 用户故事的语法本身确保捕获用户想要实现的目标、收益或价值。

  • 由于验收标准本身是用户故事的一部分,因此这对 Scrum 团队来说将是一个额外的优势。

  • 可以在项目执行过程中对用户故事进行更改。如果用户故事的范围变得很大,则需要将其拆分为较小的用户故事。验收标准中的条件也可以更改。

  • 由于在每个冲刺结束时都会向用户交付可工作的产品增量,因此 Scrum 团队可以在冲刺评审会议中获得用户的反馈。这使得能够持续将反馈纳入产品中。

结论

Scrum 的用户故事将用户与 Scrum 团队联系得更紧密,并防止出现最后一刻的意外。

广告