《构建之法》阅读笔记03
当一个软件项目快接近尾声的时候，我们如果还没有完成预定的任务的话，那么，
我们是把项目交给用户，还是不交给用户呢？在现实中，答案是当然的。
做软件的目的，不过就是完成用户的需求，提交给他们想要的软件。
也许有很多公司在规定时间到来的时候，仍然有很多的任务没有完成，那么，这个软件到底是发布还是不发布。
所以在探讨这个问题之前，我们需要首先介绍几个名词。
Alpha:集成了主要功能的第一个试用版本，多数在内部使用。
Beta:功能基本完备，稳定性相对Alpha来说有所提高，适合小范围使用
ZBB：某天的版本要把之前的Bug都解决掉
RC:发布候选版本
RTM：最终发布版本
通常情况下，软件团队的各个角色代表组成了会诊小组，处理每一个影响产品发布的问题。
对于每一个Bug,会诊小组要决定采取下面哪一种行动：修复：小组同意修复这一问题。
设计本来如此：用户或测试人员可能对功能有误解，或者功能的解释不完备。
不修复：这是一个问题，但是这个软件版本不打算修复
推迟：如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本。
除了有会诊小组之外，对于复杂的项目，还有复杂项目的会诊。会诊会议也会有更高的要求，包括一下三个方面：
1.开发者提交参加会诊的Bug和修改方案
2.会议决定是否统一修改方案
3.执行
当发布Alpha/Beta之后，通常我们会收到很多用户的反馈，我们会发现，原来的设计也有不少要改进的地方。
于是乎，很多人会嚷嚷着DCR，那么DCR该怎么提出呢？说明：
1.问题在哪里，问题的影响；
2.如果不修改，会有什么后果
3.几种修改方案，各种方案的优缺点和成本。
作为一个软件团队，我们要有解决Bug的能力，其中有一个招数叫做ZBB，即这一版本的构建把所有已知的Bug都解决掉了。
在项目临近结束的时候，所有人员都要回归测试所有的Bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的“回归”。
当然，如果一个模块不能够实现预期的设计需求，时间快到了，怎么办？
一个字：砍！
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。
发布之后，我们要总结经验教训，我们需要对整个软件的开发过程进行解剖，这个过程叫做：事后诸葛亮会议
个人感受：
书的这一部分我想到了我们团队，我发现自己虽然扮演“猪”的角色，虽然全身心投入到我们的项目中，自然等到以后绩效打分的时候，扮演“猪”角色的得到的是最多的。但是主动承担太多，也有一个坏处，那就是我没有办法了解到其他团队成员的工作状态，那这个时候我是否可以既做猪又做鹦鹉呢？在完成个人工作的同时去监督帮助团队其他成员以求达到完美的团队协作？