锐英源精品原创，禁止全文或局部转载，禁止任何形式的非法使用，侵权必究。点名“简易百科”和闲暇巴盗用锐英源原创内容。

软件开发验收标准示例和最佳实践

最近完成上市公司项目，需要验收，准备软件开发验收报告，在外文网站mobindustry上找到本文，深受启发，特此翻译深入学习下，一切权利归mobindustry所有，本文可告知下架。

国内很多公司不重视需求和标准，在开发过程中导致很多不开心的事情，本来是双方获利的合作，最终变成了扯皮，所以甲方要认大方向，有时候能吃亏。乙方要尽量避免扯皮，人月神话是个天大的陷阱。锐英源软件接触过不同层次的甲方，如果需要软件工程合作，欢迎联系。

下面是翻译正文：

 

在 Mobindustry，我们采用敏捷方法运营。这意味着我们使用敏捷组件，例如用户故事和验收标准。高绩效团队和组织在他们的产品 backlog 中有这些组件，他们知道如何创建和有效地使用它们。如果你想创建一个 MVP，验收标准是需要考虑的最重要的事情之一。

如果您的产品待办事项缺少用户故事和验收标准——或者如果它们没有明确定义——你的期望可能与现实不一致。用户故事和验收标准负责代表最终用户将如何使用您的应用程序以及您的开发团队应如何执行每项开发任务。当我们开始开发新产品时，我们的团队会与客户合作定义用户故事。

用户故事是从想要使用该功能的人的角度对产品功能的简短描述。用户故事用于定义敏捷开发工作流程中的产品待办事项。

产品 backlog 本质上是用户故事的集合，它们为特定产品或服务的功能规范和功能开发提供信息。用户故事由三部分组成：故事所针对的用户角色、用户所需功能的描述以及功能满足需求的说明。

以下是编写用户故事的方法：

作为（用户）我想要一个（功能），以便我可以（满足需要）。

让我们看一下用户故事的外观。我们将以 Airbnb 为例。让我们想象一个典型的用户故事可能会如何寻找像 Airbnb 这样的产品。

“作为用户，我想搜索目的地，这样我就可以预订外国城市的住宿。”

 

验收标准的定义

现在，我们需要确保正确完成用户故事并满足客户的需求。

验收标准是软件产品必须满足的条件才能被用户、客户或在系统级功能的情况下为消费系统所接受。

验收标准是一组陈述，每个陈述都有明确的通过/失败结果，可以衡量并指定功能和非功能要求。

编写验收标准不仅对确定客户对产品的期望很重要，而且对开发过程也很重要。自然，不同的人会从不同的角度看待同一个问题。明确定义的验收标准提供了您计划实施的功能的统一视图。

任何人都应该能够走到 Scrum 板前，抓取产品待办事项项目，阅读验收标准，并清楚地看到需要完成的所有内容，才能将该特定项目移至已完成列。验收标准告诉您要完成产品的特定部分需要做什么。

为什么我们需要验收标准？

• 定义界限。验收标准帮助开发团队定义用户故事的边界。它们用作确认应用程序按预期工作的一种形式，这意味着用户故事已完成。
• 达成共识。验收标准允许开发团队与客户处于同一页面上。他们告知开发团队必须满足哪些条件，并确保客户知道对应用程序的期望。
• 简化验收测试。验收标准是用户故事验收测试的基础。每个验收标准都应该独立测试，并有明确的成功或失败场景。
• 计划和估算。验收标准允许您跨任务分发用户故事，以便对其进行适当的评估和安排。
• 描述负面情景。例如，接受标准可能要求系统识别弱密码并阻止用户继续操作。输入错误的密码格式是用户输入错误数据或行为异常的负面场景的一个示例。验收标准识别这些场景并解释系统应如何响应它们。

谁编写验收标准？

编写验收标准有助于在产品所有者和开发团队之间建立关于解决客户问题或创建产品功能的共识。由于验收标准与客户和团队有关，因此它们应该由客户或团队成员编写。

在 Mobindustry，我们的业务分析师会编写用户故事的所有验收标准。业务分析师了解客户的需求以及开发人员需要知道什么才能满足项目要求。

在项目开始之前记录和确认验收标准，因为团队和客户需要就哪些结果将满足客户的要求达成一致。

带有验收标准的用户故事示例

现在您已经清楚地了解了用户故事和验收标准是什么，让我们看一些示例。

示例 1

用户故事：作为用户，我希望能够在服务中注册，以便开始在线购物。

验收标准：

• 用户只能通过填写所有必填字段来提交表单。
• 用户提供的电子邮件不得由免费电子邮件服务提供。
• 同一个IP在30分钟内只能提交3次。
• 用户注册成功后会收到通知邮件。

 

示例 2

用户故事：作为用户，我可以在收到通知后立即在我的设备上访问它。

验收标准：

• 滑动/点击通知将用户直接带到消息。
• 视图显示对话——如果新消息是回复，则显示在原始消息上方。
• 消息计数已更新。
• 消息在显示后被标记为已读。

验收标准的类型

有许多类型的选择标准。但是，以下类型是最受欢迎的：

• 面向场景的验收标准。这种类型的验收标准以场景的形式呈现，并说明了每个标准。此外，敏捷团队广泛使用它们，因为它们允许他们满足需求并使用脚本进行手动和自动验收测试。
• 面向规则的验收标准。与基于情景的资格标准相反，基于规则的资格标准情景以列表的形式呈现。

编写良好验收标准的 7 个技巧

验收标准不容易写。尽管格式简单，但编写文本是一项挑战。这里有七个提示，可帮助您在编写验收标准或查看团队成员编写的标准时避免常见错误。

• 在开发过程开始之前记录标准。这样，团队更有可能提前捕捉到客户的所有需求。最初，为少量用户故事设置标准以完成两个 sprint 的积压工作就足够了。然后，开发人员使用文档化的验收标准来规划技术过程。
• 不要让验收标准太窄。过于具体的验收标准使开发人员几乎没有回旋余地。为避免这种情况，请记住验收标准应该是意图的表达，而不是最终决定。此外，狭窄的接受标准可能不会考虑所有用户操作。
• 保持你的标准可以实现。有效的验收标准定义了您可以提供的合理的最小功能量。但是，如果你不断地描述所有的小细节，那么你的团队就有可能陷入数百个小任务中。
• 避免过于宽泛的接受标准。广泛的接受标准使用户故事变得模糊。有效的验收标准必须概述工作范围，以便开发人员可以正确计划和估计他们的工作。
• 避免技术细节。验收标准应以通俗易懂的语言书写。您的利益相关者和经理可能没有技术背景，因此使用简单的语言将使每个人都能理解标准。
• 达成共识。团队成员和利益相关者可以根据他们的观点以不同的方式解决相同的问题。确保将您的验收标准传达给利益相关者和团队成员并达成共同协议。
• 编写可测试的验收标准。这将使测试人员有机会确保满足所有要求，并使开发人员能够知道用户故事是否完整。

如何编写验收标准

这里有五个通用规则，可以帮助您解决验收标准措辞方面的问题。这些规则将使您节省宝贵的时间，并在产品所有者和开发团队之间建立理解。

规则#1：避免“不”

“不”意味着“在任何情况下”，因此没有足够的时间来验证是否符合此类条件。如果你在不使用“not”的情况下重写需求，它会更清晰，最重要的是，它是可验证的。

例子：

用户故事

不要：作为用户，我不希望每次访问我的帐户时都必须输入密码。
做：作为用户，我希望我的密码被记住并自动填写，这样我就可以在不重新输入密码的情况下访问我的帐户。

验收标准

不要：系统不能失败。
Do：系统的可用性应不低于 90%。

例外

您可以在接受标准中使用“不”来引入逻辑上的反对，例如“登录表单不应该是红色的”。在大多数情况下，这将适用于非功能性需求。在此示例中，我们制定了一个可以轻松验证的约束条件，如果明确定义了红色的阴影范围（例如，以 RGB 格式指定）。