|
在敏捷刚提出的时候，敏捷的推崇者和CMM的支持者一直处于对立面，敏捷的推崇者们甚至认为CMM对于软件开发没有帮助。 《程序员》曾经刊发过Tom DeMarco对CMM的抨击段落（刊于2003年第4期）： 《程序员》：我想知道您对CMM的态度。您认为CMM对哪些企业会有帮助？又会有哪些副作用？
Tom DeMarco：帮助？CMM？对于如今的软件企业，CMM有百害而无一利。CMM已经有超过20年的历史，它的成功经验都是在1985年以前获得的。CMM试图将一个固定的模型强加于一个日新月异的行业之上，它鼓励你效仿IBM在20世纪70年代所采用的软件开发方法。僵化，不敢面对变化，这是如今的软件业最忌讳的。所以我要说，对于绝大多数的软件开发，CMM毫无帮助。
当然，一定的过程是有必要的。但是，在这个变化的时代里，过程也必须拥抱变化，否则就不是好的过程。你一定还记得，CMM 2级的特征是“可重复”，我认为这根本就是一个悖论：我们的每个项目都完全不同，我们的开发环境每年都在更新，如何去寻找一个“可重复”的过程呢？你看，所有伟大的软件企业，有哪一家做的事情是“可重复”的呢？
《程序员》：可是（为什么）有那么多人、那么多企业热衷于CMM呢？
Tom DeMarco：他们根本就是无所适从——他们无法适应变化，他们无法在这种全新的环境中找到自己的位置，所以他们总得给自己找点什么东西来信仰。
不过，对于只做外包项目的企业（如很多印度软件公司）来说，CMM倒是一个不错的能力衡量标准。只有对于这种不需要动脑筋、不需要创新的企业，CMM才有意义。如果让我来评价，我会认为CMM是软件企业的耻辱符：等级越高，说明企业越缺乏创造力。 Tom DeMarco这些话虽然有些偏激，但有些观点还是值得思考。 CMM收集了软件业界已有的经验，但是这些经验是否会适合当前的项目？软件的发展日新月异，新的开发、测试工具不断出现，软件开发环境也不断更新，那么历史上有些优秀实践在如今可能就不合适了。 CMM的后续版本，特别是从CMMI 2.0开始，已经拥抱敏捷了。它的很多实践都增加了敏捷的活动实例。这说明CMM的支持者已经接受Tom DeMarco的意见。 的确，环境的变化使得软件开发完全的可重复是不可能的。但是，生命周期模型是可重复的，一些实践是可重复的。 相对于敏捷来说，CMM因为“可重复”，确实不会有创新的机会。 所以，在CMM拥抱敏捷之前，说CMM对软件开发没有帮助也不是完全没有道理。 这正是： 敏捷模型自古争，重复未必真可行
若论变化谁适应，敏捷无疑第一名 参考书目：不敢止步：一个软件工匠的12年，作者：熊节，出版社：人民邮电出版社 |
