某天在网上和一个同行聊天，他突然冒了一句：“不能再关注CMM了，现在都是ITIL了”，不由一惊，想起很多年前某人几乎用同样的口气告诉我：“软件企业不能再关注ISO了，现在都是CMM了”....难道这个概念的游戏又要开始一个新的轮回了吗？
        在这个概念爆炸的时代，CMM/CMMI在中国软件这片特殊的土壤上，曾经创造了并不完美的辉煌，也面对着诸多质疑和否定，一路走来，它会最终将被证明是一个伟大的经典还是一个因水土不服而彻底失败的理论呢？后CMM时代的软件过程改进又将如何演绎呢？以下，笔者尝试从CMM/CMMI以外的三个方面来探讨这个问题.....

有效的行为模式

        据说中国第一个宇航员杨利伟是穿戴着一片成人尿不湿（俗称尿片）飞上太空的。诚然，这片尿片必将随着杨利伟的一飞冲天而永垂不朽，但这毕竟是中国航天人初试啼声时的权宜之计， 据说神六上天的时候已经没有这种令人多少有点尴尬的玩意了——这说明一个问题，有时为了一时的需要采取一些临时性的措施是无可厚非的，但这些临时性的措施应该尽可能的被及时的抛弃，但在我们日常的软件开发实践中，这片临时的尿片却往往远比我们航天员身上的来的顽固：

        当已经定义的过程告诉你需要做某些记录或编写某些文档时，因为某些原因（比如永远落后的项目进度），将这些规范“暂时”搁置一边，“留待下一次再来遵循”——当然，下一次依然还有下一次......
        那些因为一时的方便而被程序员“临时”设置的全局变量，在发布时却被发现依旧赫然存在......
        当一段代码被拷贝粘贴了数次后，因为种种原因（例如今天心情不爽，懒得....），依然被“临时性”的继续被拷贝粘贴，而不是去设计一个可重用的类或者方法。最终，这段代码被N次的拷贝到程序的各个角落......
        当发现一个有待改进但尚未构成即时的致命影响的缺陷时，不是立刻修复或者记录下来，而是“暂时”放在一边：“回头再说”——而这一回头，往往已是万水千山了
        将“临时性”的行为永久化只是我们开发过程中诸多不良行为模式中较有代表性的一种，无论我们采用什么样的软件过程，首先必须从根本上杜绝这些不良的行为模式而建立有效的行为模式。建立有效行为模式的途径，首先是要让行为受到约束，行为的约束需要靠有效的方法和手段以及有效的机制来实现的，例如：静态代码检查和走读等等。其次，量化的管理也能为我们的行为约束提供有效的帮助，我们未必都要将我们的量化管理达到CMMI4级那样的标准，但几个不多但有效的度量指标往往会给企业的管理带来意想不到的效果，如可以进行各种分类统计的缺陷率指标等....。最后，非技术层面上的管理，如有效的惩罚和激励机制等都可以帮助团队最终将良好的行为习惯固化为一种良好的行为模式 。

有效的技术支撑平台

        CMM/CMMI在为我们带来了先进理念的同时也为我们提供了实现这些理念所需的各种方法，诸如被告知我们需要根据项目的进展更新项目计划；又如我们被告知需要从需求到设计、实现及测试建立双向的可追溯性等等。然而这些方法在纯手工的情况下往往不具有可操作性，有时既便是在借助于部分工具的前提下仍然难以操作，本人曾经多少次看到软件企业的QA或PM们埋头于Project编制的计划和团队成员提交的工作日志间，辛勤而痛苦的根据工作日志所提交的任务完成情况更新项目的进展，然而不幸的是，这样做的结果往往并不理想——理由非常简单，因为MS Project（大多采用的是Pro而非Server版）并不足以提供项目跟踪所需的完整技术支撑。

        因此，所谓“工欲善其事，必先利其器”，要想有效的完成已定义的软件过程，必须首先建立有效的技术支撑平台，同时，技术平台的选择应该遵循以下原则：

        针对性——没有最好的工具，只有最合适的工具，不同的企业有不同的需求，应该根据自己特定的需求选择最具有针对性的技术支撑平台。
        整合性——软件过程是一个整体，因此在选择工具的时候应注重这些工具的整合性，若干游离的数据孤岛所带来的后果往往是严重的。
        成本——成本是每一个企业都会考虑的因素，然而这里所说的成本并不完全是指采购成本，而是全生命周期的成本，这里面除了采购成本还包括了部署和使用成本
依赖自我而不是外力构建的持续改进机制

        CMM/CMMI的导入很大程度上都是依赖于外部力量——咨询 公司，当功德圆满，咨询方和公司成员喜气洋洋的拍完全家福照后，一切回归平静，软件企业中的软件过程在大多数情况下并不是持续改进而是渐渐衰退，甚至有些企业的CMMI软件过程最终只是成为某个文件柜中一堆尘封的故纸......。

        当然CMMI评审功利性的出发点（拿证）是造成上述这种现象的一个重要原因，然而另一个重要的原因则是CMM/CMMI的导入大多数情况下其驱动力来自外部而不是来自企业本身，当这个外力消失以后，其软件过程改进往往就裹足不前甚至不进反退，因此构建基于内力而不是外力的持续改进机制是保证企业软件过程持续改进的关键。要想做到这一点，建议从以下几个方面入手：

        人力资源的培养——毋庸置疑，首先应该强调的当然是企业内部人力资源的培养，实际上一个踏踏实实的CMMI导入过程可以培养出一个合格的过程改进团队，这也许是CMMI评审 除了拿证以外另一个最为重要的意义所在了，不过，日常的团队建设也是不可或缺的，当今软件行业处于知识爆炸的时代，身处其中犹如逆水行舟，不进则退。
完善内部培训机制——内部培训是一种非常有效且经济的提升团队整体能力的手段，曾经接触过一个坚持“每日培训”的企业，着实让人佩服。但一般建议 至少做到“每周培训”，通常可以作为周例会的一个组成部分。
        介入式的咨询服务——外部的力量也可以作为一种必要的补充，但从长远来说，突击式的拿证并不能为企业带来多少收益，因此，对于企业来说，介入式的咨询服务（而不是君子动口不动手 ，隔岸观火式的咨询服务）——如QA外包则可以为企业带来一些真正的获益。