验收标准
我们建造了合适的产品吗？并且，我们是否正确构建了产品？
验收标准很重要。不幸的是，我们经常忽视或低估它作为迭代规划过程的一个方面。这是超级重要的，因为项目成功或失败，基于团队满足客户的能力记录和感知验收标准。当我们在前面清晰地定义标准时，我们就可以避免在sprint或发布结束时出现意外，并确保更高级别的客户满意度。换句话说，我们能够回答这两个重要的问题:我们创造了正确的产品吗?我们的产品做得对吗?
什么是验收标准?
它们是软件产品必须满足用户，客户或在系统级功能，消费系统的情况下接受的条件。
接受标准是一组声明，每一个都有一个明确的通过/失败结果，它指定了功能性和非功能性需求，并且适用于Epic、Feature和Story级别。验收标准构成了我们的“已完成的定义”，这里的“已完成”指的是完成得很好。
我们在这里谈论的不是马蹄铁，也不是部分接受:要么满足接受标准，要么不满足。
何时定义我们的验收标准？
一个陷阱，我鼓励我的团队避免在发展开始后写作验收标准。这导致仅验证功能构建的作品，而不是验证功能满足用户需求和期望。如果我们在实施开始前写下并查看标准，我们更有可能捕获客户意图而不是发展现实。
是什么才能验收标准？
验收标准定义工作项目完成并按预期工作。表达标准清楚，简单的语言客户将在没有关于预期结果的模糊性的情况下使用。这将我们的测试人员设置成功，因为他们将接受我们的标准并将它们翻译成自动化测试作为我们持续集成构建的一部分运行的案例。
什么。不是如何。
另一个陷阱，我教导我的团队避免是如何陷阱。标准应该陈述意图，而不是解决方案。(例如，“用户可以批准或拒绝发票”而不是“用户可以单击复选框批准发票”)。标准应该独立于实现，并讨论期望什么，而不是如何实现功能。
格式
给定的/When/Then格式是指定标准的有用方式:
当我做一些动作时，我期待一些结果
当以这种格式编写验收标准时，它提供了一致的结构。此外，它还帮助测试人员确定何时开始和结束对特定工作项的测试。
有时难以使用给定的，当，然后格式化时构建标准。特别是在处理系统级时用户故事。在这些情况下，我发现使用验证清单运行良好。
验证检查表的另一个优点是，它们也可以简单地单独标记完成我们实现的功能。
评论(23)
克里斯汀舒伯特
我看到帮助非软件开发团队（业务团队）了解验收标准的含义的挑战。亚博vip9通道清单可用于说明最终结果。我有时建议团队尝试支持用户故事。因此，请开始列出首先需要的项目。它可以帮助企业团队新的敏亚博vip9通道捷理解用户故事的目的以及验收标准的目的。
鲍勃·塔尔恩
我也认为可以提前写入验收标准。当用户故事首次捕获时，我有客户在项目开头编写所有接受标准。我建议他们准备在迭代计划会议上审查迭代的迭代条例，这些故事将被开发
Justin Mancinelli.
>>>“用户可以批准或拒绝发票”而不是“用户可以单击复选框以批准发票”<<<
复选框不是面向用户的，因此是用户所期望的吗?
当我想到“如何实施功能”时，我想到了不是用户面对的事情，例如“批准或被拒绝的发票将存储在Postgres表中”。
也就是说，决定复选框可能太小，详细介绍了验收标准，除非用户测试已经显示了这是用户期望的。否则，我认为这样的小细节可以遗留出验收标准，并且在实现功能后，用户可以给出反馈，如“我真的希望这是一个简单的复选框”那么你可以在下一个冲刺中更改它。
迈克尔
我认为要点是，在概述一个特性时，通常没有必要描述实现细节，而是必须描述交付业务价值所需满足的一组标准。亚博vip9通道批准或拒绝发票的商亚博vip9通道业价值可以通过复选框、下拉选择或甚至滑动手势来实现。无论实现哪种方法，用户都应该仍然能够实现他们批准或拒绝发票的目标。
通常情况下，实现细节可能会被暗示为在整个应用程序中维护一致的UX的一部分，在这种情况下，开发团队在实现任何故事时都需要遵循这些细节。但是，除非一个特定的实现对于交付业务价值是至关重要的(例如，对于最终用户来说，相同的价值无法通过相同功能的不同实现实现)，否则通常没有亚博vip9通道必要提及“如何实现”。
麦克希尔曼
如果您不具体，那么QA如何知道测试什么？
雷埃德加
这不是一个规范。他们与PO / BA / DEVS合作。这是一个故事的位置。
veronica
我同意——以我的经验，验收标准和测试用例是可以互换的，而且往往需要非常具体，包括用户交互——这确实需要列出“这应该是一个dropbox”之类的东西。在一个理想的世界里，我能够提供这样的设计指导:“用户需要能够从选项列表中进行选择”，这可能转化为下拉菜单，也可能不转化为下拉菜单。在实践中，设计、工程和测试几乎总是需要更多的细节。同样对于分析，例如，我被要求指定应该触发什么事件——当然不是面向用户，但对于正确的分析需求(和可测试的)是非常重要的细节。
大卫墨菲
我发现迈克级的验收标准表明在故事级别就足够了，然后在故事中进入特定功能（例如复选框V一些其他方法时，将细节肉体变化。它确实依赖于UI如何发展和当您了解它的细节时，它是关注业务价值的关键，而不是在过程中早期详细的功能。亚博vip9通道
达利亚约翰逊
谢谢你的文章。真正的验收标准必须在开发开始之前创建。反过来做是没有意义的。
基思筹码
我已被提交给这篇帖子，作为使用验收标准的团队（MIS）的同事提供“验收标准的敏捷标准”的敏捷性观点，以提供另一种要求的详细程度。在我看来，帖子和讨论缺少几点。
1.验收标准通常比要求更具体，但它们不是另一个细节水平。这可能看起来矛盾，但它的意义是标准应该参考需求的实例（或实例），而要求本身更为一般。考虑税务准备计划。可能是最重要的要求是它正确计算了各种各样的收入和出境的税收。显然，您无法测试所有可能的组合，因此您的验收标准将指定特定值，或者如何生成有效的随机值。更具体，但不是另一个细节。
2.有时，验收标准只是重述要求。批准或拒绝发票的示例是这样的。要求可能是“我希望能够接受发票的财务人员”，接受标准可能是“当我执行接受行动时，接受发票（通过检查发票的记录）”。真的不再细节了。
3.测试员是否需要知道是否单击复选框，这是测试用例定义的一部分，而不是接受的标准。
基思，感谢您添加您的积分。我相信我们的读者会发现他们有帮助。
基思筹码
我应该说我确实同意文章的主要前锋。
安迪
错误警告:“何时定义接受标准?”
“是”应该是“我们的”。
固定的。
Mateo Diaz Granados.
谢谢你的文章。
我注意到你在第一句中有一个错字。
验收标准是一个重要的。不幸的是，我们经常忽视或低估它作为......
验收标准是一个重要的？
javi.
谁应该定义/写接受标准？
大卫墨菲
我领导的团队采用了一种协作的方法，QA和PO一起决定和评估。开发人员也可能是其中的一部分，也可能是BA(如果项目有BAs)的一部分。如果需要，PO可能涉及其他业务用户。亚博vip9通道
如果涉及UIS，也需要考虑可用性和可访问性，这可能需要一些更大的前正式工作来定义项目的设计原则，并确保涉及受影响的人员。
Vijayanand.
谢谢你。这真的很有帮助。
Jaroslavas.
好主意
将要
“标准应该独立于实施，并讨论预期的内容，而不是如何实现功能。”
关于这句话，我想知道敏捷过程的哪个步骤定义了“如何实现功能?”“我开始调查故事，但不是这样的，然后我想到了接受标准，并想“啊哈，这一定是你定义如何实现的地方”，但然后……不，似乎不是这样做的。我知道敏捷并不依赖于规范，但是为了实现功能，某些人在某些时候需要明确地定义如何实现功能。我只是想知道在敏捷过程中这一步是否有一个名字，是否应该被记录下来，如果有的话，是否有一个文档的名字。
非常感谢，这篇文章对我回答关于敏捷过程和工作流的问题非常有帮助。
内特
我对敏捷的理解是它主要关注用户价值和业务价值，因此用户故事和功能将定义何种内容。亚博vip9通道如何大多数由DEV团队弄清楚，这可以通过DEV和UX / UI之间的讨论来完成。大多数情况下，这将在开发阶段之前讨论，并且团队将更多或更少了解它必须开发和如何发展。但是，敏捷的主要观点是，DEV团队可以在似乎最适合满足用户（复选框，下拉等）的方式中自由实施功能，AC在此处确保正确交付的内容。如果如何更改，那么它可以在另一个迭代中完成。
B.
问题 - 您是否觉得验收标准绝对是强制性的？我的想法将是“不”，然后向上回来我会说，如果用户故事的愿景是绝对清楚的，我的团队很高，而且理解产品所有者的要求非常清楚，而不是可以遗漏验收标准。我已经从缺乏经验的Scrum大师那里推回来，他们说这是不可接受的。但验收标准只是在满足所有这些需求时定义故事所需的业务水平要求。亚博vip9通道
约翰·T。
你说“验收标准构成了我们所做的定义”。不确定这是否是错误的或真的你的意思。我会为准备定义制定标准。在指定的AC之前，还没有准备好估计用户故事。