关于软件工程的思考14：稳定和发布阶段
稳定和发布阶段
一个团队经历了计划、设计、开发等阶段，达到代码完成这一目标，似乎后面的事情是水到渠成的，但是软件生命周期的最后阶段往往就是最考验团队的，考验团队的项目管理水平、应变能力。
所有的软件公司都希望修正所有缺陷后再发布软件，但是这几乎是不可能的，只有优秀的软件公司才能找到一个平衡点，能够及时发布软件的同时及时修改软件中的问题。
说到质量时，我们不提全面质量管理，因为如果大家都将全面质量管理，则意味着我们的质量管理没有抓到点子上。
在最后的稳定和发布阶段，有一些常用的名词：
1、Alpha：指集成了主要功能的第一个试用版本，仅仅在内部使用，给外部用户使用的Alpha版本会起一个比较美的名字，如技术预览版（Technical Preview）
2、Beta：功能基本完备，稳定性也比Alpha要好，用户可以在实际工作中小范围使用
3、ZBB（Zero Bug Build）：某天的版本要把在这之前（例如48小时前）记录的Bug都解决掉
3、RC（Release Candidate）：发布候选版本，RC1/RC2。。直到RTM为止，版本间隔时间较短
4、RTM（Release To Manufacturer）：最终发布版本，会把最终的版本和相关的文件资料交给另一个团队去包装、刻制光盘。
5、RTW（Release To Web）：对于网络应用来说，我们需要依赖web来发布最终版本，一般会交给网站运营团队去管理，这样的发布也可以叫做RTO（Release To Operation），把软件提交到各个应用商店则可以成为Release To Store。
从代码完成到发布
从代码完成到最终发布软件的流程：
会诊小组Triage Team
会诊小组是软件团队各个角色代表组成的小组，处理每一个影响产品发布的问题。
对于每一个bug，会诊小组会决定采取下面哪一个行动：修复/设计本来如此/不修复/推迟
随着项目进展和发布日期的接近，团队还要保证修改方案不会给产品带来负面的影响，这时会诊会议中开发者提交参加会诊的bug和修改方案，由会议决定是否同意修改方案。
提交参加会诊的bug和修改方案中，主要要报告的是：
会议讨论的结果有以下几种：
1、Must：必须修复，修复方案可行，相关的测试都通过
2、More info：需要更多信息，可能是缺陷的影响不明确，后果不明确，相关测试不完备或者解决方案有缺陷
3、No：不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
4、Like：可能，但不一定必须修复，但是解决方案相对比较安全。这个属于一种中间状态，在相对简单的项目中可能没有这种状态，如果在当天的会诊中有Must，那么处于Like状态的修复就可以一起集成到代码库；如果没有Must，那么LIke就只能处于待命状态，直到出现Must为止，如果一直没有Must，那么这些修复就只能等到下一个里程碑了。这样做的好处是最终版本不会因为小问题而不断更新，消耗过多的测试资源。
此外，项目接近尾声时，达到Must的标准要越来越高，这样做可以放走一些无伤大雅的Bug，让项目能如期完成。在Alpha阶段，拿到一个bug可以马上修复，在Beta阶段就要得到大家的同意再修复，在RC（Release Candidate）阶段，一般要通过会诊来决定是否值得花时间。
如果修改方案被拒绝，也不意味着努力是白费的，可以将修改方案签入另外的源代码分支中。
设计变更Design Change Request
当经过Alpha/Beta阶段，就会收到不少用户的反馈，原来的设计也有不少要改进的地方，此时就可以提出DCR。
提出DCR时，要指明问题在哪里，问题的影响，如果不修改会有什么后果，然后列出几种修改方案以及各种方案的优缺点和成本。
然后会诊DCR，按照影响和成本排序，根据现有资源，按照排序来重新设计。
ZBB
ZBB新的构建把已知的bug都解决掉，当团队修复了所有bug，下一个版本发布之后，测试人员和用户会有很多机会使用到新的功能和场景，此时bug数会以惊人的速度反弹，故ZBB又称为Zero Bug Bounce。系统要经历几次反弹，最后接近0.
在ZBB的定义中并不是追求bug数量绝对的0，因为bug是一直在新增的，而是处理一段时间前所有的bug，如处理掉48小时前出现的bug。
回归测试
项目临近结束时，所有人员都要回归测试所有的bug，每个人都要帮助团队确保这些bug是被修复了，而且没有导致功能的回归。
砍掉功能
来不及实现预期设计需求的处理方式就是取消掉一个功能。不能因为沉没成本而不舍得修改，不能因为以前花了成本，就要去以后一定要完成某个任务。
逐步冻结
随着程序功能的完善，我们要让程序的各个方面有次序的冻结，这样才能把稳定的软件交给用户。一般来说，程序的人机交互界面最先开始冻结，不能再随意修改。当功能冻结后，bug都解决掉，然后在下一个版本前不要再碰于此功能相关的代码，如果有新的功能要加入就在源代码的基础上创建分支，让当前版本和将来版本工作分开进行。
渐进发布
在互联网时代，出现了一个产品同时对不同的目标用户用不同的频率来发布的情况，如小米公司的MIUI对几千人的荣誉内测组是一天一更新，对几百万开发组一周一更新，对几千万普通用户推出稳定版本。微软在windows10发布的过程中，也采用了同样的方式：
每日构建的测试用户群是金丝雀，早期矿工用金丝雀来检测瓦斯泄漏，说明金丝雀非常敏感。如果金丝雀用户能认定当前的windows通过了基本测试，那么这个版本就能推向更大的用户群。
postmortem事后诸葛亮会议
一个里程碑结束的时候要组织会议讨论，会议的核心问题是如果可以重新来过，什么方面可以做的更好。多问几次为什么，找到问题的根源。
会议模板：
这个会议在进行的时候要保持会议轻松愉快的氛围，当大官的最好不要出现，让大家畅所欲言，即使出现，也要低调，不能为自己的行为辩护。坚持对事不对人，把重点放在改进，而不是挖旧账。让所有人都有充分发言的机会，记录改进意见并投票，最好执行票数最高的一些改进意见。
传说中的拐点
在软件项目中，有这样一个拐点存在，在这一点之前，新的bug产生的数量大于bug解决的数量，在这一点之后，bug解决数量大于bug新增的数量，bug曲线就向下移动。对于日期驱动型的项目来说，必须要控制这个拐点出现的时间，如果bug数量不断上升则无法保证以后bug会下降，此时就应该主动让拐点发生，如推迟一些bug、砍掉一些功能、升高bug的标杆等。
银弹之战
为了避免项目成员为了一些问题争执不休，可以采用银弹Silver Bullet，每个角色的代表在项目过程中可以使用有限次的“停止争论，按我说的办”的武器，也就是银弹。银弹一出大家就要听话，银弹的数量是受到限制的。
