回答。

历史上，验收标准的制定通常由测试人员或开发团队负责。然而，随着向灵活的可扩展流程（SAFe，LeSS，Scrum-of-Scrums）的过渡，没有正式测试场景的情况下，大型项目不同参与者的期望可能会出现偏差：业务、测试、开发和支持可能会对任务的完成情况有不同的解释。

在多团队或分布式项目中，问题在于：不同的责任区域、不同的流程和工具、团队之间的语言或文化差异。即使是详细处理的要求也可能转化为冲突或不完整的验收标准，从而导致缺陷和业务不满。

解决方案是在形成验收标准的早期阶段吸收系统分析师，协调团队之间的要求，严格形式化并在共同的演示或小组研讨会上讨论场景和边界情况（edge-cases）。

关键特点：

• 验收标准必须明确、可测量、可重复和可验证。
• 预先协商标准（手动检查清单 + 预期数据/行为示例）。
• 相互追溯：标准必须始终引用要求、案例和用户故事，以便跟踪每个目标。

有陷阱的问题。

是否可以将验收标准的制定完全留给测试人员？

不可以，分析师必须参与。只有他掌握完整的业务上下文，并了解所有要求的细节。

是否只需覆盖验收标准的正面场景？

不，必须添加负面和边界案例（edge cases），否则会在实现和测试中出现空白。

在多团队项目中可以口头确定验收标准吗？

不可以，口头协议无法承受分布式交互的压力并会导致冲突。标准必须以正式的方式接受（例如，以Gherkin/BDD或结构化检查清单的形式）。

常见错误和反模式

• "默认"的验收标准制定，没有引用要求和规范。
• 缺乏最终团队的反馈。
• 忽略不同团队之间组件交互的场景，特别是在集成时。

生活中的例子

负面案例： 在银行应用程序中，转账功能的验收标准仅与一个团队达成一致。第二个团队在未考虑第一个标准块的情况下实现了自己的内部接口，导致事务 ID 格式的不一致。

优点：

• 快速开始实现。

缺点：

• 需要重构 API。
• 处理冲突所浪费的时间。

正面案例： 分析师召开了针对所有参与团队的系列研讨会，提供了可视化场景和细节，并在 Confluence/JIRA 中对验收标准进行了书面记录，且与要求进行了双向追溯。

优点：

• 消除了歧义。
• 快速检测并避免潜在缺陷。

缺点：

• 项目初期协调时间增加。