今天读了《构建之法》的第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，然后按照影响、成本排序，得到一个自上而下的名单，根据现有资源，按照名单执行

[读书报告]构建之法(八)