由 “敏捷开发”PK“CMMI”引起的思考和困惑

由 “敏捷开发”PK“CMMI”引起的思考和困惑

 

我曾是CMMI咨询师，离开“CMMI 咨询”这个圈子也有一、两年了，久不参加行业内的活动，很想了解行业动态。因此，上个月积极参加了软件行业协会的过程改进年会，见到过去的老同事，老朋友、老同行，非常高兴。其中，观看了一场辩论赛，收获不少，也由此引发了思考和困惑。

 

 “敏捷开发”PK“CMMI”，从辩论赛的角度，还是很热闹的，唇枪舌战了一番。 “CMMI”一方因为大都是咨询师，口齿伶俐些，引经据典，“敏捷开发（Agile）”一方大都来自企业，有实际感受，却难以上升到理论高度。所以一旦说到理论，立刻就会被C方压倒，最后的辩论结果也是C方大获全胜。其实谁胜谁负并不重要。组织者和主持人也说了，并非CMMI和敏捷开发互相排斥，只是想以这种极端的方式让大家把软件工程领域的不同观点表示出来，供业内人士探讨。我虽熟悉CMMI，但对敏捷开发并无研究，这场辩论赛让我了解了很多东西，确实挺感谢组织者和双方辩手的。但有些问题一直困扰在我脑子里，久久找不到答案。

 

我对敏捷开发只知道大概，没有实践过，所以自认没有太多发言权，听辩论，似乎敏捷开发更能支持企业业务目标的实现，因为它的要旨就是“快速响应”，快速响应客户的需求，市场的需求，并且由于将广大的工程师从繁锁的流程和文档中解放出来而受到欢迎。I CMMI重在“成熟度”，成熟度的背后是能力，解决的是组织的过程要有序，有规矩；当然也反复强调要从企业的业务目标出发，但是由于其内容和要求较多，实际上操作起来是否能很好支持“业务目标”恐怕真是值得业界人士好好研究探讨一番的。

 

比如过程改进人员如果不懂业务，如何能推进过程改进活动？这是观众提出来的一个问题，如果仅从答辩的角度，不难回答，可以说过程改进活动是有很多种的，有层次的，不是非懂业务不可的，可以做组织和协调工作，一样可以推动过程改进。C方的辩手基本回答得也是这个意思。我却觉得实际上这个问题很不好回答。过程改进活动的确需要有人组织和协调，但是如果没有相当的职位，很难组织起来，而有几家公司会对不懂业务的人员委以重任呢？ 这也反映了目前企业实施CMMI的一个现状，很多企业根本不舍得投入业务骨干来做过程改进，骨干一般都很忙，根本没有精力做额外的工作。名义上，企业的EPG里有很多人，包括项目经理等绝对骨干，但主要干活的都是那几个 QA人员，我当年做咨询时，甚至有个客户要安排公司的行政人员参加EPG，被我坚决反对才换了人。

 

而我现在的公司在咨询师眼里，那可是绝佳的客户呢！

 

我们有个质量部，专门负责ISO9000的工作，老板对流程执行极为重视，各级管理者反复强调，连大部分普通员工也都有流程和规范的意识，甚至个别员工还知道拿“不遵守流程”去攻击其他同事。

 

但是大家经常发牢骚的就是“事事都要按照流程来”，明明都火烧眉毛了，还在那里慢吞吞得走流程。而真正要应付领导，似乎也不难，因为QA人员只会查查模版对不对，挑挑错别字什么的。

 

过程改进年会上，听神州数码的一位副总介绍，他们也是同样有很多困惑，CMMI做到了4级，却感觉越来越没啥用似的。他举了个例子，写风险管理计划，每个项目都写得差不多， 如风险 －“客户需求会变更”，应对措施－“加强和客户的沟通，引导需求”，风险－“工期太紧张，不能按时交付：，应对措施－“加班，加人”，写这些到底意义在哪里呢？

 

本公司、神州数码遇到的这些问题，如果以咨询师的角度，都能回答出一堆道道来。比如要留下记录啦，要注重实效啦等等。但是今天，当我自己不再是EPG Leader，不再是咨询师，而是公司核心运营部门的负责人时，我所关注的与从前完全不同，我不关注与CMMI的符合度，我关注的是如何高效得解决关键问题（“关键”二字极为要紧），如何有效得避免类似问题。

 

那么，究竟应该怎么实施CMMI呢？“敏捷”思想又怎么和CMMI搞平衡呢？