软件过程改进的一些想法

帮朋友写的作业，CMM的作业。

 

软件过程改进，听这个名字很熟悉，总是和CMM放在一起说，但CMM明明是能力成熟度模型，为啥放在一

起我一下子搞蒙了。不过很快转过来，CMM就是为了做软件过程改进的。

 

0304年我们部门就开始做CMM2的评估工作，有幸参与，所以也了解了一些。又经过几年，参与过用了CMM

的项目和不用的CMM的项目，感受也累积了不少，正好写下来。总体而言，我的意见就是还是要因地制宜

，生搬硬套那就sb了。

 

关于软件过程改进的一些想法

前言

         说起过程改进，难免都会想到CMM，有人会把这两者等同看待。然而极限编程XP也占据一方，不可小觑。这两种过程，我都支持。但哪种最适合，就看企业管理者的功力了。

 

软件过程改进和CMM

软件过程改进的本意就是：为了更有效的达到优化软件过程的目的而实施的改善或改变其软件过程的系列活动。但谈到软件过程改进，人们总是首先想到CMM/CMMI，浏览各大网站和相关书籍，通常都把两者混为一谈。但是，从定义可以看出，软件过程改进并不是CMM。CMM是专家们的理想，试图制定出软件开发的指导规范，把软件生产变成麦当劳一样的通用生产。CMM的确指出了一条通往最完美开发过程的“康庄大道”，而这条路像实现共产主义一样并不好走。

　　 

对CMM的质疑

CMM在中国大行其道也有五六年了，风光一时无两，一时间，各大企业都标榜自己CMM级别，颇为自豪。现在不能说是偃旗息鼓，但也声势渐渐降了下来。我有个比喻不是很贴切，但是这个意思：以前过年才吃鸡肉，觉得有鸡吃，那是无比幸福的事，现在天天吃鸡，平淡得离奇，甚至是个负担，于是有鸡吃时也不想再吃，要去吃素。

CMM，能力成熟度模型，按照项目的实施水平，分为5个级别：1、初始级（Initial）2、可重复（Repeatable）3、已定义级（Defined）4、已管理级（Managed）5、优化级（Optimizing）。每个级别的定义可以去网上查，这里不在赘述。企业评估达到的CMM级别越高，说明软件开发过程越“成熟”，开发出的软件质量越高。在这样论调下，各大公司特别做外包的公司，都急于拿到一张“体检合格证”，表明自己身体健康，而且有能力有方法有经验，干起活来不含糊。

CMM的具体做法，不在这里赘述，查书查网站吧。我想说的是，网上已经出现了各种各样的质疑CMM的声音。可以归纳为几点：

　　1）多数企业评估CMM的动机不纯，为了迎合客户的要求而参与评估，只是为了拿证，变成一种应试教育。尽管每个公司都会说自己不仅是为了通过CMM而CMM，而是同时为了改进自己的软件开发过程。但根据我了解的多个通过CMM的企业，不是根本没有执行所制定的过程，就是剪裁得过分。稍微好的剩下点影子，QA对着评估时留下的过程督促一下项目组而已。倒是跟客户介绍时，万分自豪地对着烫金的证书夸耀一番。于是，虽然最后是通过了CMM，最后也不会认真执行。

　　2）CMM咨询公司为了自己的商业目的，把关不足。CMM咨询公司为了拿到你的钱，开始肯定告诉你CMM有多好多先进，然后协助你参加“考试”，最后甚至和你配合弄虚作假，肯定会让你通过，而主任评估师拿了评估费，一般也不会为难你，不然下次生意就难做了。

　　3）CMM的前提条件往往不满足。CMM的各个过程里，都会强调组织要给项目组足够的设备，合适的人手，相关的培训，高层的支持。事实上没有几个企业具有如此充足的资源，就算有，也不愿意投入。一方面，企业自己还吃不饱穿不暖，能把项目糊弄过去就是最大的目标，靠CMM评估拿到单后，能省的资源就尽量省吧。另一方面，比较业界的其他公司，不实施CMM，或者部分实施，也能取得市场的领先优势，既然胜局已定，再下苦功夫实行CMM，当然就没必要了。整个行业如此，并不是一两次的评估就能改变的。所以，CMM咨询公司也这么建议：对于大公司，实行CMM是必要的，对于小公司则未必，但也可以作为一面镜子。

　　4）CMM的可操作性不高。CMM为了放之四海而皆准，关键评估点都是相同的。由于软件项目千差万别，不可能所有的公司都用相同流程、相同的文件、相同的软件。于是通过CMM评估的公司之间，实际做法也是千差万别的。不同的做法，不同的人，不同的过程文件，难道还能产生出同一质量的软件？

        5）过分强调了过程而忽略了人的因素。再好的过程，也是需要人去完成的，而且在软件行业中，人的因素最为重要。CMM的初衷，本来也是为了降低人的因素对项目的影响。某些CMM鼓吹者认为，有了CMM，人就不重要了，可以让IT从业人员成为蓝领，成为企业大机器的一颗螺丝钉。人员流失了也不怕，下一个人看着文档就能 起工作。但事实是靠文档来交接工作根本不靠谱。其一，写文档很难做到知无不言言无不尽；其二，就算想吧自己的工作和经验完全写下下来，由于书面表达的先天性劣势，也不能完全把精髓写下来。一个做了CMM工作5年的工程师，在他的博客当中也表明了自己的困惑：企业人员不断流失，让他的工作不断重复， 放弃的念头出现了多次。

        6）CMM的效果并不明显。一个很显然的原因是，项目的过程只是决定最后结果的很多因素中的一个，很难衡量它的作用。就算不搞CMM，项目也能做，可能还做得很不错，用了CMM，项目也可能做得很糟糕。要经过长期，大量的项目来检验CMM的价值。

         7）CMM在国外的公司并不受推崇。如微软等大公司在自己的发展过程中已经形成了自己的一套管理方法和工具，和CMM不冲突，但他们没有必要再去进行CMM的评估，靠一纸证书证明自己。而一般的小公司，有自己的一个生存方法，也不需要靠CMM镀金。最需要的，就是外包公司，在合作方互不了解的情况下，可以作为保证质量的一个佐证。

         CMM作为一个打破众人思维，要求众人改变的理论受到挑战是很正常的事。也是好事，可以让大家都了解得更清楚。

 

与CMM理论唱反调的敏捷开发

　　与CMM的管理层层把关相比，敏捷开发的思想则剑走偏锋，有点放任自流的味道。有人说，想出这个方法的一定是开发人员出身，而且厌倦了编写繁杂的文档。

摘录敏捷开发的宣言如下：

　　1）个体和交互 胜过 过程和工具

　　2）可以工作的软件 胜过 面面俱到的文档

　　3）客户合作 胜过 合同谈判

　　4）响应变化 胜过 遵循计划

可以看出，敏捷开发更看重人与人之间的交流，尽量避免过程和文档，以实现快速开发和应对多变的需求变更。谈到敏捷开发，就不能不谈到极限编程XP，XP就是一种敏捷开发，两者相辅相成。至于现有敏捷开发还是先有XP，也不必要考证了。

极限编程XP有几个典型代表性的工作方法：

1、 开放的工作环境：XP强调沟通，建议项目组的所有人都在一个大房间工作，有问题可以及时交流，互相督促。但不鼓励加班，使大家有充足的精力应对每周的40小时。

2、 小故事的需求管理：把大的需求分成一个个可以比较准确预测工作量的小场景，大家集中讨论后，把注意事项和工作量评估写在卡片上（storycard）。然后由程序员自己认领stroycard，去开发完成。由于是自己参与了讨论和主动认领，工作起来会更卖力和自觉。

3、 测试驱动型的开发方法：先写测试方法再开发测试代码，可以使开发人员明白自己要开发出的模块究竟是干什么的，而且由于有了测试方法，开发完成后可以立即进行测试，保证开发质量。

4、 结对编程：XP提倡两个人一起写同一段程序（PairProgramming）。一起编程可以让开发人员更多地交流，工作也更负责，新手还可以很快从老手中学习到经验，另外，还可以承受一定的人员流失。要注意的一点是，PairProgramming不是要求坐在一起编程，而是强调互相交流和检查。

5、 Dailybuild： 每天都完成一次全系统的编译集成，并且利用之前测试方法，进行系统的自动化测试。如果这个工作能放到晚上自动运行，那么第二天一早，就马上能报告出前一天工作发现的问题，再由项目组及时修正。

6、 用户的参与：XP的比较推崇快速开发出一个原型版本，然后请用户提意见。尽早的发现需要变更的需求，避免在项目快结束时才发现错误的需求，那时对整个项目的冲击几乎是无可挽回的。

这些管理机制，几乎找不到一点CMM的影子，但不能说这种开发方法就不好。有成功案例证明，这种组织结构和工作方法，在资源不足，项目团队比较小时，工作效率很高，软件的质量也能得到保证。

         当然XP也不是万能的，它需要一个强有力的项目经理，需要高素质的项目骨干。

        

没有唯一，只有最适合

         CMM和XP，两种截然不同，甚至是对立的项目开发过程，共同在当今的软件业存在，实在是很精彩的一件事情。他们都可以算做是软件项目管理过程改进，因为他们的诞生都是为了更好地把项目做好，都是为了保证项目的开发质量。如果把CMM比喻成计划性强的社会主义，那XP就是自由的资本主义，哪种制度更好？现实社会已经展示了一部分结果，资本主义国家初期远远跑在社会主义国家前面，但如果不解决自身过度自由的弊端，就会频繁地产生伤害巨大的经济危机。社会主义如果不实行市场经济，经济发展也会陷入桎梏。

         每个企业不同，每个项目组不同，该使用何种过程，也应该具体情况具体分析，采用最合适的管理方法。项目团队越小，越好管理，管理的工作就应该越简单，重度的管理反而是生产力的浪费；项目团队越大，沟通成本急剧上升，管理就越应该加强，放任自流就会让项目组形成散沙，形不成合力，也是生产力的浪费。企业越大，项目越大，越应该走类似CMM的道路，规模化的生产也可以降低CMM的平均成本。但小项目组，那还是算啦吧，极限编程很适合，否则效果就等同于大炮打蚊子。

         而且，CMM和XP也不是水与火，有些部分是可以结合的。XP的结对编程，测试驱动，也可以在大项目组中采用，CMM的过程控制在小项目的某些阶段也是可以参考的。对于从小壮大的项目，人少的先期采用XP，人多的后期转为CMM，也是合情合理的做法。

         没有唯一的过程，只有最适合的过程。