本章主要介绍软件项目的会诊（Triage），软件按时发布的招数：DCR、ZBB，以及项目的总结和回顾。
15.1 从代码完成到发布
从软件的代码完成（Code Complete）到最后发布，我们要经历哪些步骤，先了解一下几个基本概念：
Alpha：指集成了主要功能的第一个试用版本。在这个版本中有些小功能并未实现。事实上很多软件的Alpha版本只是在内部使用。给外部用户使用的Alpha版本会起一个比较美妙的名字，例如，技术预览版（Tech-nical Preview），等等。
Beta：功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有Beta1、Beta2、Beta3……
ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小时前）记录的Bug都解决掉。
RC（Release Candidate）：发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短。
RTM（Release To Manufacturer）：最终发布版本。如果某一个RC版本没有很大的问题，那么这一RC就会成为最终的版本，通常情况下，软件公司会把最终的版本和相关的文件及其他资料交给另一个团队（Manu-facturer）去包装、刻制光盘。在AppStore/Marketplace的年代，我们有相应的RTM（Release To Market）。
RTW（Release To Web）：和RTM类似，对于网络应用来说，我们无须依赖“Manufacturer/Market”制作软件的光盘或者管理软件的发布渠道，但是要依赖“Web”来发布我们的最终版本。如果软件产品是一个网站服务，则一般会交给网站运营团队（Opera-tion Team）去管理，这样的发布也可以叫做RTO（Release To Operation），运营团队和研发团队一起决定什么时候系统上线（Go Live）。把软件提交到各个应用商店则可以称为Release To Store。
15.1.1 会诊小组（Triage Team）
软件团队的各个角色代表（PM/Dev/Test/UX等）组成了会诊小组，处理每一个影响产品发布的问题。
修复（Fix）//小组同意修复一个问题。
设计本来如此（As Designed）//用户或测试人员可能对功能有误解，或者功能的解释不完备。
不修复（Won't Fix）//这是一个问题，但是这个软件版本不打算修复。
推迟（Postpone）//如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本。在大型复杂项目中，软件团队还会进行更为复杂的会诊工作。
15.1.2 复杂项目的会诊
第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。
- Bug是什么；
- 危害是什么，如果不修复，有何后果；
- 用户会有什么变通办法；
- 是否经过代码复审，是否经过伙伴测试。
第二步：会议决定是否同意修改方案。决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。
- Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过。
- More Info——需要更多的信息，可能的原因有：1）缺陷的影响不明确，例如，这个缺陷是在任何情况下都发生，还是只在某一特定情况下才出现？后果如何？因此不能马上做出决定；2）相关的测试不完备；3）解决方案有缺陷（会诊会议成员可以复审解决方案和代码的改动）。
- No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求。
- Like——可能，不一定必须修复，但是解决方案相对比较安全。
第三步：执行。
15.1.3 招数：设计变更（Design Change Request， DCR）
经过Alpha/Beta阶段，得到的用户的反馈，需要做一些改进工作。项目的当前阶段是一个阻尼振荡的过程，要收敛和稳定。等到下一个版本开始的时候再进行发散的思考。如果你觉得目前的设计有问题，我们要用DCR来管理。
如何提出DCR？
在DCR的描述文字中，说明：
a. 问题在哪里，问题的影响；
b. 如果不修改，会有什么后果？
c. 几种修改方案，各种方案的优缺点和成本。
如何决定DCR的执行次序？
1）会诊所有DCR。
2）按照影响、成本排序，得到一个自上而下的名单，根据现有资源，按照名单执行。
15.1.4 招数：Zero Bug Build，ZBB
ZBB = Zero BugBuild，即这一版本的构建把所有已知的Bug都解决掉了。Zero Bug Bounce：通常在一个ZBB之后，Bug数目会以惊人的速度反弹，故称Bounce。系统要经历几次反弹，像阻尼振荡一样，Bug的数目在反弹了几次之后，最后固定在（或者无限逼近于）0。
15.1.5 招数：最后回归测试
项目临近结束时，所有人员（开发、管理、测试）都要回归测试所有的Bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的“回归”。为便于管理，我们可以考虑新增一个字段，标记某个Bug已做过回归测试。
15.1.6 招数：砍掉功能
有一个模块看来不能实现预期的设计需求，时间快到了，怎么办？砍！
15.1.7 招数：修复Bug的门槛逐渐提高
在Beta期间，修复Bug的门槛要逐渐提高。在Alpha阶段，如果开发人员拿到一个Bug，那他/她就可以马上去修复，只是在签入之后告诉大家做了什么样的修改。
15.1.8 招数：逐步冻结
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。
15.2 不同频率和不同覆盖范围的渐进发布
上文提到的Alpha，Beta，Beta1，Beta2等发布方式，发布的间隔是一个月以上，一般来说，后一个发布是前一个版本的升级，发布的目标人群也类似。
以MIUI为例，MIUI有三个更新频率，一天一更新，面对的用户大概是几千个，这个用户组我们叫荣誉内测组；一周一更新，面对几百万用户，这个组叫开发组；一个月一更新，面对的是90%的普通用户，有几千万，推出的版本叫稳定版。
15.3 发布之后——事后诸葛亮会议
牢记会议的核心问题：“如果你可以重新来过，什么方面可以做得更好？”
例如：软件发布后用户报告了一个大问题。“为什么？”
因为程序没有考虑某种边界条件。“为什么在测试阶段没有测出来？”
因为这个代码是测试的最后阶段才加进去的。“为什么不通知PM/Test？”
因为Dev认为没有问题的，是很简单的修改。“为什么不通知别人？”
因为Dev认为那些都是软件工程无聊的规定……Dev是大牛人，不必遵守的。“为什么？！”
问到这个层次，就把问题根源暴露出来了。
