面向变更的开发-Adams Wang

“稳定状态的生产思想特别不适合项目工作。我们倾向于忘记这一点：项目的全部目的就是让自己死亡。项目生命中的唯一稳定状态是死后僵硬……”（Peopeware）；

“软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。”——“未雨绸缪（Plan to Throw One Away）”

软件开发本身就是一个具有无序趋势的活动。当人们四处游走，寻找一个类似于计算机硬件那样流水线化的方式方法时，可能应该静静思考一下，这本身就是与开发内在发展规律相悖。并且，软件开发是人类的思维创造活动，同诗歌、乐曲一样，好像人类历史上还没有什么为上述创造进行流水线化的尝试。

从软件开发产物的角度而言，CMM规范2级中的配置管理一般包括四个活动：配置标识、版本控制、变更控制和度量。配置标识和版本控制都是为了给变更提供一个稳定的承载基础。而Brooks对360机器开发的进行了描述“在System/360工程模型中，在一大堆常规的黄颜色电线中，常常可以不经意地看到紫色的电线束。……这些更改过的接线使用紫色电线，看上去就像伸着一个受了伤的大拇指。”体现了配置管理的雏形，进一步提出了在软件项目中“……软件开发也需要用到“紫色线束”的手法。对于最后成为产品的程序代码，它更迫切地需要进行严密控制和深层次的关注。……而且需要文档化。”——“整体部分（The Whole and the Parts）”

在CMM试点项目以及后来的项目实践中，为项目的文档产出物进行标识是比较容易实现的。Internet上有大量的资料和模板可供参考。版本控制可以使用VSS或者Open Source的CVS，而CMM规范中反复出现的“基线（baseline）”概念，在配置管理实践的初期或者小规模的项目中，并不是强制性的。当配置标识和版本控制实践到一定的程度之后，再推广基线和变更控制，就相对容易得多。

即对于某种类型的项目，可以采用制定配置标识规范、识别文档类型、确定该类项目的目录结构、建立版本控制机制来进行初期的实践，具有一定的成熟度之后，再实施变更管理。变更使用“阶段（量子）化、定期变更……量子（阶段）化变更方法非常优美地容纳了紫色线束技术：直到下一次系统构件的定期发布之前，都一直使用快速补丁；而在当前的发布中，把已经通过测试并进行了文档化的修补措施整合到系统平台。”这种方法能在一定程度上缓解项目压力、变更和质量之间的矛盾。

http://www.mmmbook.com/review/pratice.htm