你能澄清满意条件（COS）和接受标准之间的区别吗？

Question

到目前为止我的理解:(如果我错了，请纠正我）

• 理想情况下，产品所有者在Sprint计划中尽早指定COS，以促进对话。它们可以被视为一个抽象定义，它将构成用户故事或特征的接受标准的基础。
• 验收标准由团队制定，并由产品负责人进行验证（通过对话确保双方共同承诺）。它们是在Sprint周期内的任何时间开发的。它们可用于指导和设定自动化测试的重点。
• 总结一下，我们可以说：COS ---＆gt; 验收标准 ---＆gt; 验收测试套件。

虽然从理论的角度来看这是合理的，但我觉得我需要更多的细节（理想情况下，一个书面的例子）来更好地掌握这个概念。

Answer 1

Answer 2

我认为在SCRUM中这些术语的含义相同：

• 接受标准（最常见的用户故事）
• 完成的定义
• 满意的条件（我认为这来自传统的项目管理，如ITIL）

当我们定义用户故事时，我们始终从产品所有者处收集验收标准。除非您收集验收标准，否则用户故事不存在。开发团队从不定义它们。 PO的责任是定义验收标准。在冲刺期间，为sprint选择的用户故事的接受标准不应更改。原因是团队根据对初始验收标准所做的估计来承诺这些用户故事。用户故事仅在sprint期间通过验收标准测试时才会完成。

结论：对我来说，接受标准是满意度和用户故事（和对话）的边界条件。

示例：作为客户，我需要使用信用卡支付订单，以便我可以进行在线购物。 验收标准：

• 接受Visa和MasterCard

此时我们表示必须支持Visa和MasterCard，但例如AMEX没有。

Answer 3

@Ladislav实际上，虽然我不确定验收标准与CoS之间有多大差异，但完成的定义有点不同。每个故事必须经过验证才能被认为是完整的;它们是技术标准，而验收标准和CoS似乎是业务验收标准的不同变体。

示例：

• 录取标准：签证和 万事达卡被接受。
• 定义 完成：所有故事必须通过质量保证 没有严重的错误。

Answer 4

接受标准是故事的具体内容。这些主要是业务规则，故事必须经过考虑才能完成。

满意度条件只是AC的另一个术语。

这种混淆来自这样一个事实：有人，一位着名的教练，教练和从业者，在第二任期内开始为AC命名。

AC之外的任何内容都应该被赋予AC以外的特定名称。

敏捷性的核心原则之一是透明度。在此之下，使用共同语言，共同理解，帮助我们描述和实现我们的目标。这个问题和相关的混淆是透明度在敏捷性方面如此重要的一个很好的实例。

我的第一句话主要是＃34;这并非偶然。在里面。这是因为所有用户故事中的一些常见事物未在每个用户故事中列出。国防部是一个共同性的例子，它被排除在AC之外，因为它是众所周知的，并且是一种共同的理解＆＃34;被大家。

接受的答案只会让人更加困惑。

我希望有所帮助。