关于变更控制，我常常会产生自相矛盾的想法，一方面，我希望为改进和更好的创意打开“水闸”；但是另一方面，我又想通过限制更改保护现有的产品质量。
变更控制
变更控制非常重要。但是实现变更控制所需的努力同样让人讨厌。我们之所以害怕变更是因为代码中的一丁点混乱也会产生产品的大的失败。但是，它也可以修正bug或者增加完美的新特性。我们担心变更是因为一个“无赖”的开发人员就足以毁掉一个项目；但是很多优秀的想法也同样来源于这些“无赖”，一个繁复的变更控制流程会极大地妨碍他们的创造性工作。
我关于这个问题的矛盾心理来源于变更控制流程容易被误用这一事实。变更控制意味着风险分析，没有什么容易的或特定的方式。外加我们人类的把复杂问题过分简化的能力，变更控制可能成为盲目的拒绝变更，自动地拒绝风险而不考虑潜在的回报。
或者，很容易的，变更控制会退化成一种空洞的仪式：允许任何变更。
问题与过程
定义过程的目的是解决问题。那么我们存在什么问题呢？
在SmartPatents公司，我们的变更控制的需要主要来源于：我们希望把在试图改进产品的时候引入重大问题的机会最小化，尤其是在项目后期。我们希望最小化回归测试的代价和时间消耗。我们也需要确保关注到每一位项目成员，确保他们不会因为某些特定的更改而影响太大。而且，我们的流程需要足够灵活，让我们在开发的后期能够灵活地增加产品的功能，因为市场驱动型的软件公司就是这样竞争的。
SmartPatents公司有3个变更流程的方面：
1、 我们把所有源代码存储在源代码控制系统。
2、 我们通过一个在指定机器上的正式的构建流程来编译产品。
3、 我们在开发的后几个星期把代码冻结。
代码冻结不意味着代码停止更改了。意味着我们遵循一个正式的代码变更协议。最初，是由高级测试员Gordon来评审每个更改的。协议是通过一个表格来管理的。任何人想要请求变更都需要填入一条请求记录到表格中。Gordon周期性地审核这个表格并决定哪些版本需要重新测试，哪些版本需要丢弃。但是，如果某些人因为某些原因没有填写表格就做出了一些更改，Gordon是永远也不知道的。
很多变更是没有记录的，所以这个流程效果不大好。我不是说人们做得很差或有意推翻这个流程。而是说这个流程不适合技术型的人的工作习惯。大家会心烦意乱、忘记细节、随时改变注意。
降低风险
为了降低危险的变更带来的风险，我们需要一个更加可见、可靠的流程。所以我们让表格“退休”，安装了一个bug跟踪系统来管理变更请求。在SmartPatents公司bug报告可以是变更请求、问题报告或其他可能包括代码变更的任务安排。在代码冻结阶段的每一个代码变更，我们要求开发员把代码签入的注释写在bug数据库中，用变更请求ID来标识。在每个build之前，QA工程师会检查签入注释并验证代码更改。
这个流程是一个代码变更跟踪系统，能跟踪回变更请求和审批。开发人员还是会忘记遵循流程，但是，编译前的注释检查会发现这个问题，编译会暂停直到每个变更都被验证并记录。这个流程允许人们犯错误。
为了使这个流程不至于流于形式，我们如何决定同意哪些变更呢？我们主要通过会议，每天评审bug，从而决定是否允许变更或在下一个Release版本再改。
自从1997年12月，这个流程就成为进入代码冻结阶段后我们正式的变更控制流程。
