敏捷开发之——什么是验收标准?Acceptance Criteria What is Acceptance Criteria?

在敏捷中,验收标准是指必须满足的一组预定义要求,才能将用户故事标记为完整。接受标准有时也称为“完成的定义”,因为它们确定了开发人员必须考虑的用户故事完成情况的范围和要求。

作为产品经理或产品所有者,您可能负责为产品积压中的故事编写验收标准。在本文中,我们将定义验收标准,查看一些示例,并探索一些最佳实践来编写验收标准。

本文禁止演绎和转载;
点击右侧可联系我!
文末可下载PDF,进群也可下载!

在敏捷方法中,接受标准是指必须满足的一组预定义要求,才能将用户故事标记为完整。它们是敏捷需求文档的一种形式。与大多数敏捷一样,接受标准的定义也各不相同。

接受标准定义1:“软件产品必须满足的条件才能被用户,客户或其他利益相关者接受。” (通过Microsoft Press)
验收标准定义2: “产品或项目必须满足的预先建立的标准或要求。” (通过Google)
验收标准有时也称为“完成的定义”,因为它们定义了用户故事的范围和要求。它们为开发人员提供了执行用户故事所需的上下文。

有效接受标准的几个特点是什么?

验收标准应该是可测试的。由于这些要求有助于为您的工程师制定完成的定义,因此它们需要易于测试。这些测试的结果必须没有解释的余地​​。测试应显示简单的是/否或通过/失败结果。

标准应该清晰明了。您不是在这里编写全面的文档。保持您的条件尽可能简单明了。

每个人都必须了解您的接受标准。如果您的开发人员听不懂您的标准,那就没有用了。如果不确定是否清楚,请花点时间问一下并进行调整,直到清楚为止。

验收标准应提供用户观点。接受标准是从客户的角度看待眼前问题的一种手段。它应该在真实用户体验的背景下编写。

为什么需要用户故事接受标准?

接受标准对跨职能团队有多种用途。

管理期望

定义范围并减少歧义
建立质量检查的测试标准
防御范围蔓延中期冲刺
让我们进一步研究接受标准的好处。

用户故事本身就留下了很大的解释空间。接受标准以具体方式阐明了用户故事的预期结果。它还为开发人员和质量检查人员提供了一种明确的方法来确定故事是否“完成”。

由于多种原因,您希望将这些要求合并到流程中。首先,当您在开发开始之前定义所需的结果时,您将有助于促进一致性和共识。这种理解有助于减少意外发生的可能性。

除了帮助产品人员设定和管理期望之外,接受标准对开发人员也有帮助。所添加的上下文不仅可以减少歧义,而且还可以很好地抵御范围蔓延。如果未在冲刺开始时就定义和设置需求,则在中间进行潜行会更加困难。最后,验收标准通常会定义要通过的失败/通过测试,以确定用户故事是否完整。

谁负责撰写录取标准?

实际上,跨职能团队中的任何人都可以编写用户故事的接受标准。通常由产品所有者或经理负责编写验收标准,或至少促进有关验收标准的讨论。其背后的想法是确保在编写需求时就牢记客户需求,与产品人员相比,谁能更好地了解客户需求?也就是说,广泛建议将书面接受标准作为包括dev和QA代表在内的小组活动。

在定义接受标准时,让开发人员和质量检查人员参与将带来许多好处。首先,它为您提供了另一个与开发人员就产品策略和愿景进行交流的机会。其次,开发人员和质量检查人员可以帮助指出任何遗漏的内容或确定以前可能不清楚的依赖项。最后,这些讨论可以帮助您作为产品所有者,通过开发人员的眼光更好地了解您的用户故事。因此,只要有可能,就一起定义完成。

何时应编写用户故事接受标准?

许多产品经理和产品所有者选择在积压培训会议上编写验收标准。然后,他们将此标准带入冲刺计划会议,与开发人员讨论并根据他们的反馈意见进行完善。但是没有专门规定何时写出这些要求的规则。

最迟应在开发开始之前定义接受标准。否则,您将首先错过拥有它的许多好处。还值得注意的是,过早编写接受标准也可能适得其反。请记住,敏捷方法鼓励根据新发现频繁地重新确定优先级。这意味着您可以从sprint到sprint重新排列用户故事的优先级。

平衡这种不确定性的一种方法是,仅在您决定将某些内容移入sprint待办事项列表时才编写接受要求。这样,您就不必花费时间来编写最终被剥夺优先级的用户故事规范。将用户故事移至sprint待办事项列表之后,可以肯定的是接下来要讨论的内容。因此,您可以继续并宽松地定义验收要求,然后在冲刺计划会议期间讨论并最终确定它们。

您应该如何格式化用户故事接受标准?

为用户故事编写接受标准没有唯一的对或错方法。最终,您需要建立一种格式和过程来创建对团队始终有效的接受标准。如果您是新手,请期待一些尝试和错误。大多数敏捷组织使用两种格式之一作为其接受标准:

给定/何时/然后验收标准
用户故事要求的“给定/何时/那么”样式类似于用户故事本身的传统格式。标准的用户故事遵循以下模板:“作为(目标用户),我要(目标行动),以便(目标/行动结果)。” 用户接受的标准格式/时间/当时格式遵循模板:“方案:(解释方案)。给定(事情如何开始),何时(采取行动),然后(采取行动的结果)。”

直到您看到用户案例与给定/何时/然后接受标准配对的现实示例为止,这似乎有点令人困惑。所以这是一个例子。

验收标准示例–给定/何时/然后
用户故事:

作为产品经理。

我想给潜在的想法打分。

这样我就可以决定要在产品路线图中包括哪些内容。

该用户故事的接受标准可以是:

场景:产品经理添加潜在的想法,并根据收益与成本对最佳想法进行排名。

假设我添加了两个或更多的想法,并使用“收益与成本”评分模型对它们进行了评分

当我单击“排名”按钮时

然后将想法与得分最高的想法排在顶部。

验证清单验收标准

将用户故事需求格式设置为清单是另一种可行的选择。这也非常简单。您只需团队协作即可定义功能必须满足才能被标记为完整的通过/失败语句的列表。

归根结底,您接受标准的格式与其实用性无关紧要。如果您的团队理解并能够解决问题,那么您就可以创建有效的验收标准。不管格式是什么样。

最后:

接受标准是敏捷团队工作的每个用户故事的重要组成部分。它清楚地定义了交付团队正在使用的功能的范围,期望的结果以及测试标准。创建并就接受标准达成一致的过程本身也是开发人员与产品之间宝贵的交流机会。

分享不易,请支持本站其他资源

全球手机话费充值:http://www.globalrecharge.cn/
新版axureshop产品原型网:http://www.axureshops.com
AxureShop商城:http://axure.amynik.com/
情趣商城:http://sex.chanpindashi.com/
Axure工具集下载:http://www.chanpindashi.com/2019/12/02/1997.html
产品大师:http://www.chanpindashi.com/
源码商城:http://mall.amynik.com/list/1
axureshop产品原型网(旧版停止更新):http://axureshop.amynik.com/
产品经理论坛:http://bbs.amynik.com
淘宝优惠券:http://taobao.chanpindashi.com/
京东优惠券:http://jd.chanpindashi.com/?chanpindashi.com

最后编辑:2020年05月28日 ©著作权归作者所有

发表评论

×