使用敏捷方法完善用户故事和验收标准
介绍
用户故事是敏捷框架的核心组成部分，它将重点从软件需求转移到以用户为中心的所需功能描述。用户故事刻意简短明了，专注于从系统用户而非系统开发人员的角度编写的一项特定功能。
它们与传统的软件系统需求不同，因为它们将最终用户置于对话的中心，采用更非正式的语言为系统开发人员提供背景信息。因此，用户故事构成了一个最终目标，即从用户角度出发的期望功能，不一定用技术术语表达，也与它所需的工程工作无关。
作为产品所有者或团队负责人，您（和您的团队）的工作是完善用户故事，使其构成敏捷框架（如 Scrum 或 Kanban）中小型的“原子”工作单元。例如，在 Scrum 中，用户故事被添加到冲刺中，并在冲刺期间“燃烧”，在这种情况下，用户故事足够小以适合冲刺非常重要。建立一套明确的验收标准也很重要，这通常需要与最终用户进行讨论。在本指南中，您将学习如何使用敏捷框架完善用户故事和验收标准。
用户故事指南
一个完善的用户故事应该如下：
- 简单而精确（可以在一次冲刺内进行编程、测试和集成）
- 有用（它应该为最终产品提供价值）
- 专注于特定的用户目标
用户故事通常以角色+需求+目的的形式来表达。它通常用一个简单的句子来写，其结构如下：
“作为 [角色]，我 [想要 ...]，以便 [...]”
例子：
“作为用户，我希望能够安全地登录系统，以便只有我能访问我的信息。”
完善用户故事
细化用户故事的第一步是考虑实现该功能所涉及的工作量。这通常取决于可能已经实现或尚未实现的其他下游功能。例如，在上面给出的示例中，如果系统已经具备大多数用户注册功能（使用用户名和密码注册、更改密码、记住密码等），那么这个用户故事的范围可能足够小，因为它可能涉及在后端添加用户会话处理并在前端添加登录按钮。但是，让我们假设我们从头开始。在这种情况下，我们将把这个用户故事变成一个史诗。
这个史诗将包括以下较小的用户故事：
- 作为新用户，我想通过创建用户名和密码进行注册，以便系统记住我和我的数据。
- 作为注册用户，我希望使用我的用户名和密码登录，以便系统可以对我进行身份验证，并且我可以信任它。
- 作为注册用户，我希望能够偶尔更改密码以确保其安全。
- 作为注册用户，我希望能够请求一个新密码，以便在我忘记密码的情况下不会永远失去对我的数据的访问权限。
这些较小的用户故事现在在范围上更加精确和细化，并且更有可能在单个冲刺中适应。
验收标准
验收标准确定软件产品必须满足的具体条件才能被用户接受并满足用户的期望。它也是验收测试阶段的基础。
在细化过程中，随着较大的用户故事变成史诗并被分解为较小范围的用户故事，推理验收标准并为每个用户故事列出候选名单变得更加容易（列出的标准少于五个，理想情况下为一到三个标准，这是一个好的经验法则）。如果任何用户故事的验收标准列表太大，则可能表明该用户故事的范围太大，可能需要进一步细分。
定义验收标准的一些指导原则是：
- 每个验收标准都应该可以独立测试
- 每个验收标准测试都应该有明确的通过/失败结果
- 验收标准应该侧重于最终结果（功能），而不是实现该结果的机制
- 如果相关，应包括“隐藏的”非功能性标准
验收标准通常用以下结构的句子来表达：
“给定[先决条件]，当我[采取某些行动]时，我期待[结果]”。
在上面的例子中，前两个故事的验收标准可能是：
| 用户故事 | 验收标准 |
|---|---|
| 作为新用户，我想通过创建用户名和密码进行注册，以便系统记住我和我的数据。 | 假设我是新用户，当我转到注册页面并输入用户名和密码并单击注册时，我即成功注册并能够使用我选择的凭据登录。 |
| 作为注册用户，我希望使用我的用户名和密码登录，以便系统可以对我进行身份验证，并且我可以信任它。 | 1. 假设我是一名注册用户并已注销，如果我转到登录页面并输入我的用户名和密码并单击“登录”，那么与我的用户相关的数据应该是可访问的。2 . 假设我是一名注册用户并已注销，如果我转到登录页面并输入我的用户名但密码不正确并单击“登录”，则登录失败并显示一条错误消息，指出用户名或密码错误。 |
添加非功能性需求
如前所述，定义验收标准的一个好的做法是还包括非功能性需求，即与系统质量和属性相关的需求，这些需求不一定与功能直接相关，但对于满足用户对系统行为的期望至关重要。
例如，根据用户故事的验收标准列表构建：
“作为注册用户，我希望使用我的用户名和密码登录，以便系统可以对我进行身份验证，并且我可以信任它。”
我们可以添加以下标准：
“假设我是一名注册用户并且已注销，如果我进入登录页面并输入我的用户名和密码并点击登录，那么我的用户登录会话将在不到八秒的时间内加载。”
该标准涵盖了系统设计的两个基本特质，即：
- 高可用性（请求不能因没有可用资源而超时），以及
- 可扩展性（请求不能花费太长时间，因为服务器无法处理负载）。
非功能性需求也可以被捕获到添加到同一父史诗中的新用户故事中，特别是当它涉及需要开发人员实施工作的新功能时。与用户帐户安全相关的一个示例是：
“作为注册用户，如果我的用户名登录尝试三次失败，我希望收到通知，以便我采取措施保护我的帐户安全。”
尽管没有任何用户明确说明，但这种“非功能性”能力只是作为常识而预期的，或者有时它们可能被产品所有者视为设计或安全最佳实践而包含在内。
其他“修饰”任务
最后，值得注意的是，细化用户故事不仅包括调整大小和将较大的故事拆分为较小的故事，还涉及以下任务：
- 删除不再相关的用户故事
- 审查并重新评估故事的优先级
- 为尚未分配预算的故事分配预算
- 根据新信息修正估计
- 根据新讨论添加、编辑或删除验收标准
- ETC。
结论
敏捷待办事项列表旨在成为活生生的信息体。因此，没有必要从项目一开始就将所有用户故事分解为更小、更精细的故事，并制定相应的估算和验收标准。但重要的是，在任何时候，待办事项列表中都有足够的精细故事可供添加到下一个冲刺或待办事项迭代中。
敏捷项目与传统软件开发项目没有什么不同，因为它也容易出现“范围蔓延”，即用户故事不会真正为产品增加任何实质性价值，但在创建时听起来很棒。因此，持续努力管理积压工作并根据内部讨论或与最终用户的讨论完善用户故事是避免预算超支或产品不符合预期的关键。
免责声明：本内容来源于第三方作者授权、网友推荐或互联网整理，旨在为广大用户提供学习与参考之用。所有文本和图片版权归原创网站或作者本人所有，其观点并不代表本站立场。如有任何版权侵犯或转载不当之情况，请与我们取得联系，我们将尽快进行相关处理与修改。感谢您的理解与支持！
请先 登录后发表评论 ~