敏捷用户故事的验收标准—

我们如何确保用户故事被正确完成并满足客户要求？这就是验收标准发挥作用的地方。验收标准是一份正式的需求数列，确保所有用户故事都已完成，并考虑了所有场景。简而言之，验收标准定义了用户故事被视为完成的条件。清晰且书面化的标准有助于开发团队避免对客户需求的歧义，并防止误解。

因此，在编写用户故事时，验收标准至关重要。它们帮助你的团队了解在功能开发过程中哪些是必须的，以及他们应该关注什么。

让我们深入探讨验收标准。

什么是验收标准？

验收标准使你能够定义用户故事在何时被视为完成，以及何时具备了满足用户需求的所有功能。

它们是一组用户故事必须满足的条件，才能被视为完成。它们提供了用户故事的详细范围和所需内容，使你的团队能够理解当前的问题。这样一来，每次发布新功能时，你都可以确保其达到用户应得的标准。

但在你热情地列出用户故事应满足的一系列功能标准之前，请考虑其他变量可能如何影响你功能的质量，并将它们纳入你的验收标准中。

验收标准可以包括以下细节

用户体验
当前用户故事对现有功能的影响
关键性能，例如速度
用户故事旨在实现的功能

因此，根据你正在构建的功能及其复杂程度，与团队坐下来确定其应执行的最小功能子集以及其行为方式。

如果它复杂或属于你产品的核心功能，你应该尽可能多地编写详细验收标准，以帮助团队避免任何混淆。

如何为用户故事编写验收标准

1. 验收标准应从用户的角度撰写

验收标准是从客户角度看待问题的一种方式。它们应在真实用户体验的背景下撰写。毕竟，你是在为用户构建产品，对吧？

2. 标准应清晰且简洁

验收标准不应与测试用例或文档混淆。保持标准尽可能简单和清晰非常重要。

3. 每个人都必须理解你的验收标准

如果开发人员无法理解它们，你的标准就毫无用处。如果你对清晰度存疑，就花时间提问并调整，直到一切变得清晰。

4. 验收标准不是关于如何做（如何？），而是关于做什么（为什么？）

与用户故事一样，验收标准不是任务。它们是传达用户故事的一种方式。

5. 验收标准应具体，但不应是另一层细节

以税务申报软件为例。最重要的要求是根据收入和支出准确计算应缴税款。清楚吧？你也知道无法测试每一种可能的组合——因为可能性几乎是无限的。

因此，你为该用户故事设定的验收标准将明确必须满足的具体条件或要求。这意味着更具体，而不是增加另一层细节。这有助于你的团队理解所需内容，并加快交付速度。当然，当你将当前的燃尽图与之前的进行比较时，可能会看到一些改进。

6. 验收标准可以是用户视角下对用户故事的重新表述

这仅在用户故事不过于复杂时适用。以下是我所指的例子。

对于像这样的用户故事：作为一名财务人员，我希望可以接受发票，以便跟踪所有财务报告”

其验收标准可能是：当我执行接受操作时，发票将被接受（通过检查发票记录来验证）”

给定/当/则验收标准模板

为了方便起见，这里有一个简单的模板，你可以用来编写验收标准：

给定 [上下文] 当 [执行特定操作] 时则 [应发生一组后果]

验收标准示例

对于示例用户故事：

“作为一名作者，我希望在其他人添加评论时收到通知，以便保持更新。”

以下是上述用户故事的三个验收标准示例：

给定我的手机已锁定当应用程序未打开时，则我应该收到一个横幅通知。
给定我正在撰写文档当应用程序打开时，则铃铛图标应更新以显示带有数量的未读通知。

示例 – 网站反馈提交

我们为博客评论功能指定用户故事和验收标准。登录用户可以添加评论。“添加评论”功能的用户故事如下：

作为一名已登录的用户，
我想要能够在博客文章上发表评论，
以便我可以获得关于该主题的反馈。

此功能的验收标准如下：

场景：一名已登录的用户在博客文章上发表评论
假设我是一名已登录的用户，
当我打开包含特定博客文章的页面时，
系统将在博客文章下方显示一个“评论”区域，展示其他用户添加的评论列表。
系统将在“评论”区域的顶部显示一个“添加评论”字段。
当我用我的评论填写“添加评论”字段并点击“提交”按钮时，
系统将保存我的评论。
系统将在“评论”区域的顶部显示我的评论。
系统将在我的评论左侧显示我的用户名和头像。
系统将在我的评论的另一侧显示“删除”和“编辑”图标。

如你所见，编写验收标准对客户和开发团队而言都是双赢：它不仅帮助团队清晰地理解他们必须完成的任务，还让客户能够了解开发过程，并验证交付的软件是否满足实际业务需求。