很多项目是一直到版本快要交付之前，才突然发现一个问题：代码明明已经封版了，测试也跑完了一轮，可是需求的追踪、缺陷的关闭、风险的说明、配置的基线，还有评审的记录，这几样东西并没有完全对齐，发布评审要解决的，并不是简单判断一下“这个东西能不能打包发出去”，它真正要确认的，是这个版本是不是真的具备了可以作为交付依据的条件，后面一旦遇到客户审核或者过程评估，项目组能不能把这一切都讲得清清楚楚。

　　一、ASPICE发布评审怎么准备

　　ASPICE发布评审的准备，不能等到发布的前一天，才临时去收拢各种材料，评审看的，是版本的状态、交付的范围、质量上的风险，还有过程里的证据，在准备的时候，我们就应该围着这几类内容，一项一项地去核对。

　　1、先把发布的范围确认下来

　　在发布之前，我们要把本次版本到底包含了哪些需求、修了哪些缺陷、做了哪些变更，还有纳入了哪些配置项，都给弄清楚，版本号、要交付给谁、适用在哪个车型或者哪个项目阶段、还有对应的是哪一份客户需求的基线，这些也都要写明白，如果一个版本里面，同时包含了新增的功能和对问题的修复，那就需要把它们的来源分别说清楚，免得在评审的时候，只能靠着口头去解释。

　　2、去整理需求和它们的追踪状态

　　我们要提前去检查一下，从需求到设计、从设计到代码、从需求到测试用例、再从测试用例到测试结果，这几层之间的追踪关系是不是还通着，那些断了链的、没有被覆盖到的，还有需求状态显示异常的情况，是不适合一直等到发布会现场才被发现的，对于那些暂时还不打算在这个版本里实现的需求，也要有一份延期的说明和批准过的记录放在那里。

　　3、检查一下测试和缺陷的状态

　　在正式的发布评审之前，我们需要把测试的报告、测试的覆盖情况、哪些项目没有通过、还剩下哪些遗留的缺陷，还有风险接受的记录，都给准备好，对于缺陷，不能只是简单地标一句“这是已知问题”就完了，还要说明它的严重程度、影响的范围有多大、有没有什么办法可以临时避开它、还有它到底会不会影响到这次的交付，那些还没有被关闭的缺陷，要是也跟着进了发布的版本，就必须有一份明确的评审结论才可以。

　　4、确认配置和基线是一致的

　　代码的版本、需求的版本、设计的文档、测试的用例、测试的报告、发布的说明、构建的脚本，还有最后要交出去的包，这些东西，都应该对应着同一条基线，现场很容易碰到的一种情况是，文档里写的明明是一个版本，测试报告对应的却是另一个版本，而最后交出去的包，又是来自一次全新的构建，这种情况在ASPICE的评审里面，是极其容易被人追着问的。

　　二、ASPICE发布评审结论怎么归档

　　对ASPICE发布评审的结论做归档，是为了让后面接手的人，能够看得明白，当时到底是因为什么，才允许把这个版本给放出去的，放出去的时候，是带着哪些限制条件的，还有哪些事情，是需要后面继续去跟踪的，只是单单保存一张签了字的纸，那个证据的力度通常是不太够的。

　　1、把评审的会议记录归档

　　会议记录里面，要把评审的时间、都有谁参与了、评审的对象是什么、版本号是多少、输入了哪些材料、主要讨论了什么问题，还有最后得出来的结论，都给包含进去，结论这一栏，不要就只写“通过”这两个字，可以把它写成是允许发布、带着某些条件才能发布、暂时缓一缓再发布，或者是要退回去整改，这样一来，后面再回过头来看的时候，一眼就能知道当时做出的决策，到底处于一个什么状态。

　　2、把输入材料的清单也归档

　　在发布评审中用过的那些材料，是要形成一张清单的，这里面，要包括需求的基线、设计的基线、测试的报告、缺陷的列表、变更的记录、风险的清单、配置项的列表，还有发布的说明，在这张清单里面，要把文件的名称、版本号、存放在哪个位置，还有谁是负责人，都给写清楚，这么做，是为了避免材料散落在邮件的往来里、网盘里，或者是谁的个人电脑里面。

　　3、归档问题项和关闭它们的证据

　　在评审当中被提出来的问题，是不能只让它们待在会议纪要的纸面上的，每一个问题项，都得有一个明确的负责人、规定好的关闭期限、处理它的方式，还有最后关闭它的证据，如果有些问题，是必须在发布之前就要被干掉的，那就要在发布的结论里面，单独把它给标出来；如果是允许先发布出去，后面再接着跟踪的，那也要写清楚，是谁接受了这个风险，后面又打算怎么去验证。

　　4、把发布的批准记录归档

　　批准发布的记录，应当能够体现出，到底是谁同意的这次发布、是在什么前提条件下同意的、这个版本最后要交到谁的手上，审批的邮件、电子流里跑的流程、签了字的页面，还有系统里留下的审批记录，这些东西都可以拿来当证据用，但是，它们是需要跟这次发布的版本绑定在一起的，千万不能出现，审批通过的是A版本，可实际交付出去的却是B版本，像这样断开了的情况。

　　三、ASPICE发布评审怎样减少返工

　　想让ASPICE的发布评审少一些返工，那在平时的时候，就要注意把证据按照不同的版本，一点一点地沉淀下来，不能什么事都堆到快要发布的那个阶段，才开始去补以前欠下的旧账，很多的问题，其实并不是在发布当天才突然冒出来的，而是在平时处理需求变更、缺陷关闭还有基线管理的时候，就没有同步好。

　　1、去建立一份发布用的检查表

　　项目组可以提前准备一份发布检查表，把需求的状态、设计的状态、代码的基线、测试的结论、缺陷的状态、风险的接受情况、要交付的包，还有批准记录，一项一项地给列出来，每一次发布之前，都拿着同样的一张表去检查，这样做，是能够减少遗漏的。

　　2、提前去做一次预评审

　　在开正式的发布评审会之前，可以先在内部做一次预评审，预评审的重点，就是去看证据是不是都齐了、版本之间是不是一致的、还有那些遗留的问题是不是都能说得清楚，预评审不用搞得太重，但是它的目的，是要能提前帮我们把材料上的缺口给找出来。

　　3、把结论和版本绑定在一起

　　发布的结论、会议的记录、要交付出去的包、测试的报告，还有配置的基线，这些东西，应该被放在同一个版本的归档目录下面，或者是同一个配置库的路径里面，这样到了后面，当客户要追溯的时候，就能根据一个版本号，直接找到它背后一整套完整的证据，而不需要到处去翻聊天记录和邮件了。

　　总结

　　关于ASPICE的发布评审要怎么去准备，还有评审完了以后那个结论又要怎么去归档，这里面关键的一点，就是在发布之前，我们需要把范围、基线、测试的情况、缺陷的状态、风险，还有批准的关系，都给整理得清清楚楚，等到对评审结论做归档的时候，也不能只保存“通过”那两个干巴巴的字，而是要把输入的材料、被发现的问题项、用来关闭问题的证据，还有批准的记录，都一块儿保存下来，这样，等版本交付出去以后，项目组不管是面对客户的审核、内部的复盘，还是ASPICE的评估，就都能够把发布背后的依据，给说得完完整整了。