有下过厨的朋友想象一下：
一锅烧的沸腾的油，倒一勺水。
一锅烧的沸腾的水，倒一勺油。
-----------------------------------------------------------------
呵呵，前一种情况是炸锅了，后一种情况是很安静。
项目就是一锅水，大家在公司里面都知道，项目成功了，并且有机会进入公司核心产品系列，对个人而言是一个非常大的成就感，也会对个人的职业规划起到重要的影响。美好的结果是可以想象的，但过程是曲折的。
需求就是一锅油，用户、老板、产品经理、销售、高管等等形形色色的角色会站在各自理解和观念上提出没完没了的需求。
油和水的相互碰撞，能烧出我们想要的美味盛宴吗？
所以我们要控制，不但要控制好油，也要控制好水，控制的基础就是标识出哪些是可控的，哪些是不控制的，哪些是介于可控和不可控之间。然后把标识出来的内容做分类隔离，这个过程就是配置的过程，配置会分为四种锅。
第一种锅：开发库。这里是油水最前沿，各种炸锅，在这里会表现出各种各样有意思的现象，如需求老变、返工、代码失控、同一个错误重复发生、各种文档与开发脱节等等，在一个长周期开发后，已经很难判读出这个库是不是还保持很清纯的样子。这样显然不是我们期望的，因此要引出第二类锅。
第二种锅：测试库。站在怀疑一切的态度上，我们要把开发库中的代码做验证，如果没有有效的方式，我们对开发库中代码做的验证都是全范围的，谁都有可能会犯错，一次不注意的提交都可能引发出大面积的错误。因而我们需要一个技巧，每次验证的内容都是（上次通过验证部分）+（本次从开发库拉来的代码），这样可以控制验证的范围，就好像一锅水中慢慢添油，每次都是在可控的范围内引入一定范围的不可控的部分。
第三种锅：受控库。存放2类东西，一是在测试库中被验证的代码，二是在开发库中被审批的文档。这个锅是各种版本的代码和文档的基线库。这里也有一个技巧，要出历史版本的补丁时，一定要从这口锅到测试库，验证后再回来，千万不要在开发库中做，那样很大几率会出现各种死。
第四种锅：产品库。存放的就是各种版本被验证通过的安装包、补丁包。这个就不解释了。
其它技巧：
1、 开发库中的需求文档、设计文档如果是用WORD来编写，善用审阅功能，每次迭代验证结束后，打上标签，然后接受审阅，重新开始审阅，这样能保证在每个迭代中很清楚的知道哪些是本次不可控的部分。
2、 这四种锅可以用SVN/CVS/VSS来配置，个人比较喜欢VSS，因为标签比较好打。标签是比较容易区分出可控不可控的做法。这样在测试库中引入开发库中不可控的部分比较容易操作
以上内容可以在一张图中表示，提供给大家分享：
