今天读了《构建之法》的第15章：稳定和发布阶段
Alpha：指集成了主要功能的第一个试用版本。
Beat：功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用。
ZBB：某天的版本把在之前记录的Bug都解决掉
RC：发布候选版本
RTM：最终发布版本
RTW：和RTM类似
会诊小组
软件团队的各个角色代表组成了会诊小组，处理每一个影响产品发布的问题。
决定对每一个Bug采取以下哪一种行动：
1.修复
2.设计本来如此
3.不修复
4.推迟
复杂项目的会诊
第一步：开发者提交惨叫会诊的BUG和修改方案
第二步：会议决定是否同意修改方案
第三步：执行
开发者需要报告的内容如下：
1.Bug是什么？
2.危害是什么，如果不修复，有何后果？
3.用户会有什么变通方法？
4.是否经历过代码复审、伙伴测试？
修复等级：
1.Must：必须修复
2.More Info：需要更多信息
3.No：不能接受
4.Like：可能，不一定会修复
项目接近尾声时，要确保门槛越来越高。今天的Must必须必昨天以及前天的No严重性要高，这样才能不断提高系统的稳定性。
设计变更DCR：
在提交一个DCR时，选用任务作为工作件类型，并在标题中标明DCR
在DCR的描述文字中，要说明：问题在哪里，问题的影响，如果不修改，会有什么后果，几种修改方案，各种方案的优缺点和成本
对于DCR的次序，首先会诊所有DCR，然后按照影响、成本排序，得到一个自上而下的名单，根据现有资源，按照名单执行