在敏捷软件开发场景中，验收标准在汇集客户需求和为应用性能设定基准方面发挥着关键作用。具体而言，它们在产品、开发和质检团队的各角色间传达功能。这些描述帮助团队成员理解用户的请求。
验收标准帮助开发者理解单个用户故事，同时为编码和测试特定应用提供必要细节。团队必须确定如何调整验收标准以满足特定业务需求和目标。深入了解验收标准在敏捷开发中的目的，学习组织如何使用不同标准风格来加强需求收集工作。
什么是软件项目的验收标准？
验收标准是一组条件，产品或服务功能必须满足这些条件才能被视为完成。这些条件帮助确保产品或服务功能提供积极的客户体验，使开发团队与用户期望和需求保持一致。
对开发团队而言，验收标准明确了用户在寻找什么功能以及应用应如何表现。验收标准应包含以客户为中心的重点，使开发团队能在整个编码过程中确保实现预期功能。理想情况下，产品团队应在开发团队介入前，在用户故事中定义验收标准。
从测试角度看，验收标准为应用质检团队和用户验收测试员（UAT）提供具体目标。标准应描述客户就应用功能和特性提出的要求和需求。理想情况下，产品经理或团队应与用户故事一同创建验收标准，并将这些标准描述转化为可测试的基准。
编写验收标准有两种独特方法：基于场景的和基于规则的。每种方法侧重点略有不同，各有其适用场景。两者都能在定义用户需求和设计目标中发挥关键作用。
验收标准与用户故事
验收标准和用户故事都是相似的敏捷开发概念。验收标准旨在描述界定功能或产品何时完成的具体、可测试条件，而用户故事是从用户角度对产品或服务功能的高层次描述。
这两个概念都与用户视角相关，但用户故事更侧重于从用户角度看产品的“是什么”和“为什么”，而验收标准则侧重于如何让产品或服务功能以满足用户需求的方式表现。
验收标准应包含什么
验收标准中的所有陈述都应简洁且切中要点，这很重要。它们应准确描述特定应用功能的运作方式以及用户对它的期望。验收标准还应考虑到开发者和测试者的功能性与非功能性需求，例如：
时间节点。开发团队需要验收标准明确说明某些依赖项或集成点（如通过API实现的数据库更新）何时生效。这有助于传达应用功能的预期范围，并指导下一步更新功能的过程。
清晰度。对质检专业人员和UAT而言，验收标准需提供明确定义且易于测试的工作流预期。例如，若用户保存的信息通过API传递到数据库，测试者需要知道该事务何时及如何发生。这样，当事情出错时，他们就能确切知道该关注什么。
范围。验收标准应准确描述某项目或功能应做什么。它们还应说明产品或服务功能不应做什么，依据是用户故事和体验。这能通过聚焦客户需求帮助减少困惑。
一致性。标准应清晰书写，以便每项要求被一致解读。清晰书写的预期将帮助团队理解待完成工作的范围，最大限度减少误解的可能。
持续改进。每次交付后应审查验收标准，以持续改进和优化质量。
如何选择验收标准方法
验收标准的采用方法通常取决于团队成员的整体偏好。团队成员应就哪种验收标准格式最有效达成一致。两种常见方法包括基于场景的和基于规则的验收标准。
当描述包含多个入口或出口点的工作流，或新功能添加到已复杂的功能序列中时，基于场景的验收标准很有用。另一方面，基于规则的验收标准文档几乎不留解释空间，在限制范围蔓延上往往更有效。团队务必包含所有规则，且每条规则都需清晰描述预期结果。
验收标准的格式并非最重要。重要的是产品团队传达客户需求，以便开发和测试团队理解。
基于场景的验收标准
基于场景的方法旨在描述某个功能或一般应用任务在用户场景背景下的运作方式。使用基于场景的验收标准格式，会强化对用户预期工作流和应用导航模式的关注。
这个过程可能遵循一种称为“给定-当-那么”语法的做法，也叫Gherkin验收标准：
•给定场景开始，
•当做出特定动作，
•那么预期结果发生。
在某些情况下，会在末尾添加额外的“并且”步骤，以表示任何先前陈述的延续。
例如，设想一个医疗追踪应用，能让患者创建每日用药日志。在基于场景的验收标准格式中，用户交互的每个字段的范围以及他们需要执行的动作，界定了具体工作流步骤和预期应用行为：
基于场景的格式
用户通过专用登录屏幕每日登录应用。应用成功验证用户身份后，他们进入一个屏幕，显示其在特定药物剂量计划中的进度。界面使用MM/DD/YYYY格式，叠加在月度日历背景上。每次登录时，界面显示三个数据输入字段：
•服用剂量
•给药方式
•患者签名
一旦患者输入服用剂量和给药方式字段（药丸、注射或贴片），就需提供签名以确认信息准确。用户需在应用保存和记录数据前完成所有字段。保存后，屏幕刷新，显示包含更新信息的患者截至目前进度。
在“给定-当-那么”格式中，这个过程可能是：
•给定一位患者登录医疗追踪应用。
•当患者提交填写完所有必填字段的每日用药日志。
•那么系统保存数据并显示患者的最新进度。
基于规则的验收标准
类似地，基于规则的验收标准定义用户故事的范围和功能，但通过对照一系列功能和行为参数来实现。这种基于规则的验收标准格式与传统瀑布开发场景中常见的需求文档极为相似，后者会单独列出每个预期功能。
以上述同一患者日志应用为例，基于规则的验收标准风格如下：
基于规则的格式
用户通过验证后，进入每日日志界面屏幕。该屏幕包含三个数据输入字段——服用剂量、给药方式、患者签名——显示在月度日历背景上。这些数据字段是可操作的。
•在“服用剂量”字段，用户必须从针对其药物的有效剂量下拉列表中选择一个数值。
•在“给药方式”字段，用户必须从有效方法的下拉列表中选择：口服、注射或粘贴。
•“患者签名”字段必须由用户手动签名，光标充当虚拟笔。启用表单底部的“保存并继续”按钮需要此签名。
用户点击“保存并继续”按钮后，应用记录数据，并让用户返回显示其更新进度的屏幕。
谁应编写验收标准？
编写验收标准通常是协作过程，跨职能团队中的任何人都能提供意见。不过，通常由产品负责人或经理编写验收标准——或至少负责它。
开发团队通常也对验收标准有意见，因为他们有技术知识来贡献现实且可测试的标准。同样，质检团队也通过确保标准可验证和可测试来影响验收标准——同时还能识别额外标准。
其他可以编写、补充或推动围绕验收标准讨论的人包括Scrum主管、需求分析师和业务分析师。
何时编写验收标准？
尽管最好在软件开发开始前编写验收标准，但它们也可以在冲刺的不同阶段编写。例如，它们可以在以下阶段编写：
•初始规划。项目开始时，团队为前几个冲刺定义验收标准。一开始就创建验收标准会带来清晰方向。
•每个冲刺前。在每个冲刺的规划阶段创建验收标准。这确保每个冲刺开始前就商定工作范围。
•冲刺待办事项。可在冲刺待办事项期间创建或调整验收标准，让团队有机会进一步澄清需求并减少不确定性。
•冲刺中期。只要不干扰正在进行的工作，可在冲刺中期调整或更改验收标准。这不太理想，但对适应突然变化可能有用。
编写软件验收标准的常见挑战
尽管验收标准通过澄清产品或服务功能被视为完成必须满足的条件来帮助组织，但仍存在诸多挑战。例如：
•模糊性。使用不清晰的语言和团队间沟通不畅会导致不同解读，使验收标准效果降低。
•利益相关者间的分歧。团队成员可能难以在不太具体也不太模糊的标准之间找到平衡。
•过度复杂化。有些团队制定标准时过于具体，使过程过于繁琐。
•范围扩大。向开发中的项目添加内容可能改变所需验收标准，使过程中更改标准更困难。
•不一致性。在基于规则和基于场景的标准间切换会使标准定义更复杂。
•协作问题。未让相关团队（如开发、质检、产品经理或分析师）参与，可能导致知识缺口。
在基于规则和基于场景的标准间切换会使标准更难遵循。了解更多各自运作方式及如何在两者间选择。
