11月末，在领导的关照下，有幸参加了公司组织的所谓产品开发流程高级实务培训，从简介上看是和CMMI有关的。自己还仅仅是一名小小的开发人员，对“空洞”的方法学只是浅尝辄止，加之本身对CMM这一套一窍不通，心想只去听个热闹。
培训持续了两天，无情的占用了周末的时间。公司这样安排培训，害得大家周末两天都不能安排自己的时间，效果可想而知，周日那场去了也就一半的人，绝大部分还是我们这些住单身公寓的。
由于自己对XP、RUP小有所知，而CMM/CMMI却一直不知为何物，正想借此机会见识一下，对比一下。带着问题听课（老师在培训中也提到了这些问题），加上课间和
老师仓促的交流，倒也得到了些信息。周末当晚就将自己的所思所想写成草稿，但是一直到现在才整理出来。
老师在培训中主要讲解了所谓的IPD（集成产品开发）+CMMI=CMMI+，也就是针对产品开发定制的方法。从内容上来看，我认为IPD是贯穿与整个产品商业运作生命周期的一套高层理论。它不仅仅限于产品的研发，还有市场、投资、风险和其它的一些商业策略。在整个IPD里面，产品的设计与开发显得那么不起眼，那么渺小……
CMM/CMMI自然不用说了，这个起源于外包，在国内应用广泛而且流行的方法学。从老师的语气和多次的强调可以看出，他对CMM/CMMI是比较熟悉也比较推崇。与许CMM*对于领导最大吸引力就是：它号称能让不同的人干同样的活。这是多么美好啊，开发人员不再重要，可以像标准件一样被随意替换。但是他又谦虚得提到CMM/CMMI适用于软件模块的开发，但是不能胜任一个完整的产品的开发管理。于是便有了上面提到的CMMI+。
会上老师不失时机地评论了一下XP和RUP。他认为XP在中国是行不通的，不符合中国国情——XP对开发人员要求的素质和职业道德水平都很高；而对于RUP，RUP里面有的IPD、CMMI中都有了。而且我这才知道CMM*不等同于瀑布模型，它也是提倡迭代的——将一个产品版本拆分为几个小版本，采用迭代逐步完善。由于对RUP认识肤浅，我暂时赞同了他的观点；而对于XP，先按下不表吧。
恩，按他的理由，IPD+CMMI的确是很完美了……
那到底怎么来保证不同的人干同样的活呢？不用说了，就是繁琐的文档和评审。
那如何来解决需求的频繁变更？如何解决设计缺陷？还是文档和评审：需求的不稳定是由于各个部门、人员交流方式不当（对于产品不存在直接客户，需求由市场人员提出），而且没有采用较好的分析技巧，在分析过程中没有有力的评审；设计不好除了评审的缺失外，就是由于文档模板不够傻瓜，让人看了产生歧义照成的。
按CMMI+的观点一路走来，整个过程的关键就在于怎么写好文档和做好评审上了。文档和评审大家都不陌生吧，但就我体会看来，这两个东西都是徒有其名而已，形式大于内涵。而且过多的文档只会造成内容同步问题和时间浪费，这也是我作为程序员最反感的地方。那在
老师提倡的IPD和CMMI中怎么来保证呢？也许这就是关键——以利益驱动。
何谓以利益驱动？说的简单点就是加强绩效考核。出席评审提问数、建议数和奖金挂钩；需求整理关键点与奖金挂钩……似乎一切都明白了。看来要将这一套流程做下来，首先要改革僵化的绩效策略，变更部门的管理。这不是我小小的程序员力所能及的。
可是我不仅仅要疑问下：如果可以利益驱动来提高QA、评审人员等等的素质和职业道德水平，那么我们开发人员难道是不食人间烟火的榆木脑袋吗？如果IPD、CMMI能在一个公司高效运行起来，XP、RUP等等也能在开发中很好的运用起来。
谁料到，在最后我却得出这样一个结论：如果一个公司或者部门能高效的运转起来，能够调动每个人的积极性，管它什么方法论，都能立于不败之地。这是又想起这句话：人才是最关键的因素。
PS：老师在会上聊到了很多他自己所知的商业故事，我很感兴趣，听得也格外投入，第一次培训竟然两天都没有睡觉。
