CMM已经落伍了，敏捷才是王道

woza

我不否定CMM的价值，就像我认为瀑布模型是非常伟大的模型。但是世界是不断发展的，以前适合的东西，不等于现在也一定适合。说不定以后哪一天，敏捷也会落伍。

我们公司的工程师和其他公司的没任何区别。他们也会抱怨工资不高，公司有时候不够重视他们的等等。但是绝大多数人没有离开，因为公司里有吸引他们的地方。我想很大程度上是因为我们实施了敏捷。他们至少在很多时候有做决定的权利。他们在多数时间是自我管理的。我相信任何一家公司，都肯定有一些工程师希望能够有足够的发挥空间。这个并不是做不到。

有兴趣的童鞋可以去我的博客看看，即使在传统模式下，敏捷也是有生存空间的。

chengxq

理论上的确很多都上可行的，但是一到中国什么都不行了，CMMI在国内虽然很多都通过了一定级别的认证，但是实际上来说，我感觉CMMI2到CMMI4之间好像就文挡多了点，项目经理等的意识都不行，或者说根本就不知道CMMI是干什么的啊

woza

ls说的有道理。我从来没见过国内哪个公司实施CMM的时候，公司内所有的团队都是按照CMM的流程规范实施。不要告诉我谁谁是几级，我在CMM4的美资公司工作过，很多东西说的和做的完全不同。当然，我也可能孤陋寡闻了。

我现在工作的公司，所有的团队都是实施敏捷的。因为很多规矩是工程师自己定的，所以没道理不能遵守。而且规矩定了也不是不能改，只要团队意见一致就可以。所以我相信敏捷在国内是可以行得通的。而且效果非常明显。门槛也比CMM要低得多。

但是实施敏捷的关键在于，管理层肯不肯放权。我相信多少工程师都会喜欢敏捷。但是多数经理不会喜欢。因为他们能够控制的东西变少了。

jlsv

CMM的文档和过程是可以根据不同项目组和项目需要来裁剪和做适当调整的，并不像有些朋友说的那么差

在规则还没有很好地遵守的国内，跳开规则光谈敏捷有点本末倒置，因为实行起来会变味。

woza

敏捷是以人来控制规则。传统开发模式是以规则来控制人。如果CMM能够让工程师来制定规则，自我管理，那也可以很敏捷。

zhongmg108

作为一个开发团队还是需要一定的规则的。CMM在实施时还是遇到了很多问题，Humphrey后来也意识到了，所以他又提出了TSP和PSP来补充，他这一解决方案从三个层面来解决问题，CMM主要解决组织层面的问题，TSP解决开发团队（主要是项目管理）层次的问题，PSP解决开发者个人层面的问题。这三者的结合理论上能兼顾原则性和灵活性，目前其有效性还有待实践来检验。
总之，软件开发是一个从实践到理论，然后再从理论到实践，不断推进、无限迭代的过程。正象列宁所说：实践高于理论。理论最终还是要回到实践，需要实践来检验，实践也是理论的动力，也需要实践来进一步提升。所以，适合性我觉得应该是最高准则吧！正象小平同志所说的：实践是检验真的唯一标准。但是，实践也需要理论来指导，不然就陷入混乱与盲目。（前一阵子又复习了一下唯物主义哲学，感觉还是挺有道理的。如果当年能有今天这样的心态，哲学应该可以学得更好一些。呵呵）

[ 本帖最后由 zhongmg108 于 2009-6-25 17:58 编辑 ]

woza

ls说的不错。ＣＭＭ本身也在不断改进中。说不定将来也会是一个很好的实践。
只不过敏捷的低成本优势，恐怕ＣＭＭ很难比得上。

47385024

呵呵  看了半天帖子  不知道各位是怎么理解敏捷和CMM的
能力成熟度模型（Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM）

什么是能力成熟度模型 (Capability Maturity Model)CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
http://baike.baidu.com/view/8110.htm

敏捷开发简介http://www.cnblogs.com/hanbing768/articles/818712.html

敏捷开发与传统软件工程的比较
传统软件工程：规范化的文档，持续改进的软件过程
敏捷开发：密切的交流与合作，逐步细化的开发过程
两者的区别好比重型武装部队与特种部队的区别
人员变更大，人数较多，成员分数，模块通信量大，耦合性强，维护时间长，开发过程有长期性，社会性的项目不益采取敏捷开发方法

感觉采用哪种开发模型是应该由项目情况而定的  不一定整个公司都采用敏捷或CMM吧
同意上面说的  适合自己的才是最好的  呵呵

wuwu0212

CMMI文档多点，周期长点，但是还是很有计划，这样不容易有大的偏差。

但是敏捷不是不可取，质量的保证我觉得是个问题。

woza

首先，敏捷并不是以放弃质量的代价来加快开发速度。相反，敏捷最优先考虑的是质量。敏捷通过减少浪费，缩短迭代周期，来做的快速提交客户可用的软件。注意：是可用的软件，而不是完整的软件。

其次，敏捷适合开发大多数商业软件。人员变更大，人数较多，维护时间长，开发周期长等等正是传统开发模式的弊病。敏捷就是为了解决传统模式的不足才诞生的。

人员分散对于所有的开发模式都是一个问题。我觉得敏捷在这方面做的比传统模式要好一些。

我不明白为什么公益项目不能使用敏捷。敏捷的成本优势如此明显，公益性项目应该使用敏捷才对。

虽然我不觉得敏捷和特种部队有什么关系。但是君不见如今的世界，特种部队的使用远远比重装部队要多吗？特种部队灵活，低成本，快速反应的优势太明显了。现在都是不到万不得已，不会使用重装部队。

zhongmg108

原帖由 woza 于 2009-6-25 20:01 发表
ls说的不错。ＣＭＭ本身也在不断改进中。说不定将来也会是一个很好的实践。
只不过敏捷的低成本优势，恐怕ＣＭＭ很难比得上。

兄弟，CMM已于2007年底结束维护，也不再改进，SEI不再授权进行以CMM为模型的评估和培训，全部切换到CMMI1.2。不过CMM中一些核心理念已经吸收到CMMI中。CMM的相关知识还是很价值的，公司可以根据自己的情况酌情吸收。其实，CMM的流程体系本身是可以裁减的，裁减以后定义的项目过程其实可以是轻量级的，也可以说采用了敏捷开发模式，我不认为它们水火不融的，无法沟通的。

woza

谢谢31#提醒。因为我觉得CMM和CMMI一脉相承，所以我一直用CMM代替两者。

我发这个贴，主要目的是把敏捷带入大家视野。敏捷是各种传统模式以外一个新的选择。我个人认为是更好的选择。

敏捷实施的条件非常简单，不需要增加任何成本。非常适合国内的情况。

starseeker

进来其实是想了解下敏捷开发下的测试应该是怎样的，结果讨论全市谁好谁坏。
我直接问楼主一句你觉得是基督教好还是佛教好？
这个是没办法回答的，我不是很了解敏捷是怎样的情况，不过核心概念有一个是持续迭代对吧，而CMMI5级是持续改进，假设敏捷的好处就是想到的去做，也许在1,2个需求变更的情况下很快，但如果需求变更50,60个呢，不用CMMI中的变更控制流程，我很怀疑最后的质量，甚至对需求的忠实程度。

【敏捷能否被融入CMM，我个人表示怀疑。
CMM能够让工程师自己制定开发计划吗？CMM能够允许每个团队使用不同的流程，不同的标准吗？CMM能够允许工程师们自我管理吗？CMM能够取消那些评审活动吗？】

楼主在这个问题我也可以解答，在5级中有《裁剪说明书》这个文档出现，它就是允许不同团队使用不同的流程的依据。CMMI不会不允许自我管理，至于最后这个评审，我想就是敏捷也没法不评审，你以为敏捷的日例会和周例会用来干嘛的。

[ 本帖最后由 starseeker 于 2009-6-26 17:13 编辑 ]

woza

CMM不是不好，更不是坏，只是过时了。CMM不是信仰，敏捷也不是。我只是看到CMM没法很好的处理需求快速变更等问题。而现实情况是，需求变化越来越快。所以说CMM过时了。

需求变更1，2个，还是50，60个，对于敏捷来说都是一样的。敏捷本来就欢迎变化。

按照ls说的，CMM要到5级才有裁剪需求。那么1-4级的时候，就不能运行团队的不同流程，那要来何用。

CMMI其实还是和CMM同源。当然改进了很多。所以比CMM相对来说灵活一些。希望哪位给我一个国内CMMI实践的比较好的例子。

敏捷有daily stand up，没有听说过周例会。每天的那个会，我非常肯定不是用来评审的。

woza

就目前情况来看，敏捷实施起来确实需要一些时间，但是仍然比CMM要容易很多。

项目以外的干扰是无法避免的。但是这些干扰是可以纳入管理的。比如说，团队收到一个项目计划外地任务，那只要Product Owner给这个任务制定了优先级，加入团队的任务列表中就可以。团队始终是按照优先级来完成任务列表。只要PO知道，加入一个新任务，必然导致某个计划内的任务可能无法完成。对于团队来说，就没有问题。

nijp2004

LZ会认为敏捷的成本更低，这样的判断来自哪些实践能否给一些案例说明。
以我个人的判断，敏捷开发的实践有很多，虽然没有规定文档必须的格式和过程，但并非没有记录啊，敏捷同样需求详细记录需求、同样需要设计、同样需要测试用例，当然，敏捷开发因为对文档没有严格固化，因此，对Team之外的人而言，阅读效率也会有些影响，但同样，由于没有固化格式，阅读者的效率相对较低，除非是team中人员有更多的冗余。比如极限开发。

我一直认为，人力成本上，敏捷流程所需要的人力资源更好，无论是项目管理方面，还是工程师方面，敏捷开发需要更多更聪明，更多拥有变通之道的人，而对于在CMM中规中矩的流程中尚且缺乏足够控制能力以应变无尽的需求和不断修改的bug的项目，我觉得敏捷意味着更多的不可控。

我的判断前提是CMM体系的执行本身是有效的、敏捷开发也是符合理论的实践，那些想当然认为CMM就是一堆文档，敏捷开发就是不需要文档的，就真的不可比了。

另外，看看那些文档，看看那些流程。想想那些伟大的软件作品，哪个是用CMM开发出来的？
这句话比较不认同，CMM本来就不是为了伟大的软件作品而来的，不怀疑一个优秀的团队会做出一个优秀的产品，但一个不是那么优秀的团队能够做出一个质量还可以的产品，这才是CMM的重点，更何况任何可以称之为伟大的作品都和软件工程的方法无关。软件工程总是先有实践，再有理论的，CMM是在大量实践下形成的经验，而且和工具的关联比较弱，大多数和工具无关联的经验本身是不会落伍的，只不过不在吸引别人注意力而已。

[ 本帖最后由 nijp2004 于 2009-6-29 12:51 编辑 ]

nijp2004

原帖由 starseeker 于 2009-6-26 17:10 发表
进来其实是想了解下敏捷开发下的测试应该是怎样的，结果讨论全市谁好谁坏。
我直接问楼主一句你觉得是基督教好还是佛教好？
这个是没办法回答的，我不是很了解敏捷是怎样的情况，不过核心概念有一个是持续迭代对吧 ...

呵呵，这个裁剪说明5级才使用的说法不正确，看组织需要而定，不是这么僵化的。

woza

敏捷和文档不文档完全没有关系。敏捷只是减少浪费。不管这个浪费是文档，沟通，管理还是技术。

成本的问题么，减少了浪费，自然成本就下来了。

LS可以去我的博客看看，或者翻翻我其他的贴，或许能回答你的疑问。

james.zhong

说白了，适合自己的才是最好的，什么CMMI和敏捷其实都是一样的，只是适不适合公司目前发展状况而已，但是对于国内目前敏捷还是有一定优势的，原因很简单它比较省钱！这就是决定性因素，CMMI这样的“大工程”太浪费了，就算过几级的公司也不一定会完全按这样的流程去做得！还有别一个原因，就是测试管理人员真的很少，基本上都是刚出道不久的！资深的很少，基本上没有什么很好的管理经验，而且管理的好坏企业也没法看的出来，除非你真的是管的很烂！
    就如前面几位楼主所说，现在乱搞“敏捷”的企业很多，一说敏捷马上，整个开发过程不会产生任何文档，更神奇的是连需求都是靠口说的，结果就实现了开发过程无文档化得局面。
    有次面试的时候，还有位无知的项目经理，还很鄙视的问我，你知道“敏捷”开发吗？我说知道啊，他结果就问了一句，那敏捷开发需要文档吗？我说基本的都要，他结果就说了一句你要写文档还有时间做测试嘛？可见这些人是怎么想敏捷测试的。

zz402236991

原帖由 zhongmg108 于 2009-6-22 18:04 发表
敏捷、XP、RUP、CMM/CMMI等，都不是王道，能够高效地解决组织的问题，适合公司的过程才是最重要的。如果项目的规模很小、功能也很简单，团队规模也不大而且比较稳定，而且是一锤子买卖，那就可以能省的文档都省掉。如 ...

嗯，并非这样落伍、那样不行，而是在模型和模式中找到适合自己的，完全可以接合实际情况来本地化，不可能软件开发什么文档都没有，当然也要考虑成本、进度及文档的进度冲突。适合的，才是最好的！