验收标准与发布就绪检查清单：从故事就绪到上线决策

本指南面向产品负责人、工程负责人及外包开发采购方，帮助您做出不仅依赖信心的发布决策。我们的软件质量治理指南阐述了质量归属及关卡如何适配供应商关系；本页提供逐项的实用检查清单。

本指南内容

• 两份清单，两个时间点
• 检查清单1：故事是否已就绪可构建？
• 按故事类型划分的标准模式
• 检查清单2：发布是否已就绪可上线？
• 根据风险调整关卡规模
• 禁止放行触发条件
• 执行上线或不上线决策
• 验收与发布工作中的AI
• 替代方案：如何设置发布关卡
• Netbase如何运行验收与发布就绪
• 存在哪些交付记录，哪些不存在
• 本指南的局限性
• 常见问题
• 下一步

两份清单，两个时间点

验收标准在故事构建前达成一致。发布就绪性在构建完成后、对可交付候选版本进行评判。将两者混淆，会导致团队在最后一周才发现没有人记录「完成」的含义。将前者保留在待办列表中，将后者保留在发布记录中，并让前者为后者提供依据：每条通过的验收标准都成为一项发布证据。

检查清单1：故事是否已就绪可构建？

Scrum指南指出，不符合完成定义的工作不能成为增量的一部分，且梳理会将条目拆解为更小、更精确的内容。当以下条件满足时，故事即就绪可构建：

• 结果可观测。未参加计划会议的测试人员，仅凭界面、数据或日志的呈现即可判断通过或失败。
• 边界已说明。关注的文件大小、数量、响应时间、支持的浏览器与设备，以及允许执行操作的角色。
• 失败场景已描述。无效输入、超时、重复点击、会话过期及支付被拒时的处理方式。
• 测试数据已命名。测试所需的角色、记录及边缘用例在测试环境中已存在。
• 非功能需求已附加。可访问性、性能与安全需求已列入标准或共享完成定义中。
• 依赖已明确。故事所等待的其他团队、系统或决策均已列出，并指定负责人。
• 大小适合一个迭代。如果标准需要整页文字，则拆分故事。
• 产品负责人已审批措辞。审批在故事进入冲刺前完成，而非在测试期间进行。

按故事类型划分的标准模式

以给定、当、则的句式编写每条标准，并将上表作为提示，而非盲目填写的模板。关键在于，失败场景在代码存在前就已被描述。

检查清单2：发布是否已就绪可上线？

Google为其自身服务编写的上线协调检查清单，涵盖架构、容量、故障模式、监控、安全与发布计划。这些领域同样适用于大多数产品，每项均需要可查阅的证据：

• 范围。发布说明列出所含故事及已接受的已知问题，每项均指定负责人。
• 功能质量。验收测试与回归套件在发布候选版本上通过，由作者以外的人员验证。
• 安全。扫描已运行，发现已审查，每项开放发现均有具名负责人予以接受。
• 性能。关键流程已按标准中约定的限制进行测量。
• 数据与迁移。每项迁移均已在真实数据形态的副本上演练，并在变更前进行了备份。
• 回滚。回滚已经过测试，或可通过功能开关关闭变更而无需重新部署。
• 运维。监控与告警覆盖新行为，运行手册已更新，支持团队了解变更内容。
• 依赖与配置。测试与生产环境中的环境设置、第三方密钥与定时任务保持一致。
• 沟通。用户会注意到变更的地方，客户通知、帮助页面与内部公告已准备就绪。
• 决策记录。记录谁在何时、依据何种证据做出决策，以及接受了哪些风险。

根据风险调整关卡规模

并非每次发布都需要每一项。三个层级可让检查清单保持活跃而非被忽视：

• 常规变更。小型修复依据自动化证据通过：测试通过、评审完成、通过重新部署回滚。
• 标准发布。使用上述完整清单，并将证据附至发布记录。
• 高风险发布。数据迁移、支付、权限或众多客户可见的变更。增加在类生产环境中的演练、分阶段发布，以及上线后的具名值班人员。

禁止放行触发条件

在会议前就此达成一致，使任何人都无法在截止日期压力下进行谈判：

• 验收标准失败或无对应测试。
• 高危或严重安全发现处于开放状态，且无具名负责人接受。
• 无法关闭的变更不存在已测试的回滚方案。
• 迁移未经演练。
• 监控无法显示新行为是否正常运行。
• 必须签字的人员不可联系或未查看证据。

替代方案：如何设置发布关卡

根据四项标准进行选择：发布频率、客户面临的失败成本、已自动化的证据比例，以及合同上谁负责签字。大多数团队结合使用前两到三行。

Netbase如何运行验收与发布就绪

Netbase在交付内部运行质量保证：验收标准与产品负责人共同编写、自动化回归、性能预算及发布就绪关卡，如质量工程与测试服务所述。交付由每周评审、KPI看板及专属客户与项目经理管理，团队规模为3至30人，涵盖分析师、开发人员、QA与设计师。安全实践包括安全代码审查、漏洞扫描与渗透测试；Netbase自身的资质涵盖Netbase的工作方式，而非客户产品。沟通语言为英语，支持时间为周一至周六，周日休息。Netbase的大多数项目采用在探索后约定的固定总价合同交付，这使书面验收标准成为范围的基础；参见专属开发团队与固定总价对比。如需在发布证据旁查看供应商的安全答复，请参见软件开发合作伙伴的安全问题；SaaS MVP路线图提供了首次发布的上线就绪清单。

存在哪些交付记录，哪些不存在

• 存在的记录。USticker和PrintLeo记录描述了具有性能与稳定性改进的商业化工作，Netbase已发布的治理模型包括每周评审与客户看板。
• 不存在的记录。目前没有Netbase记录发布了缺陷率、发布频率、回滚次数或发布关卡结果，任何案例均不作为特定检查清单防止失败的证明。此处的检查清单是通用实践，而非结果。

本指南的局限性

• 这些清单是起点；受监管产品需要添加其自身的审批，例如变更记录或审计跟踪，请寻求专业建议。
• DORA变更失败率等指标——需要立即干预的部署比例——用于衡量关卡是否随时间有效；这些是成果，而非待勾选的条目。
• 检查清单记录证据；它无法使薄弱的测试套件变强。

常见问题

谁签署发布就绪检查清单？每项均有其负责人，例如测试证据由QA负责人负责、发现由安全负责人负责、范围由产品负责人负责；一位发布负责人做出最终决策并予以记录。

验收标准应详细到什么程度？详细到从未参加规划会议的测试人员能够判断通过或失败，且不超过一个迭代的工作量。如果标准长达一页，则拆分故事。

存在开放缺陷时可以发布吗？可以，前提是每项缺陷均已知晓、已评级，并由发布记录中的具名负责人接受。未知或无负责人的缺陷是禁止放行的条件。

如果没有时间完成完整清单怎么办？对小型变更使用常规层级，并对所有发布保留禁止放行触发条件；在高风险变更上跳过证据，是失败到达客户的原因。

下一步

分享最近的一次发布、其验收标准及签字人，我们将预约解决方案评审，为您的团队调整两份检查清单。您也可以查看质量工程与测试或更多Netbase洞见。

相关服务与解决方案