51Testing软件测试论坛

标题: CMM已经落伍了，敏捷才是王道 [打印本页]

作者: woza 时间: 2009-6-21 12:22
标题: CMM已经落伍了，敏捷才是王道
首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CMM的那些文档感觉有些浪费。

看看那些文档，看看那些流程。想想那些伟大的软件作品，哪个是用CMM开发出来的？

作为测试工程师，程序员的你在CMM流程管理下，是不是觉得不爽？你喜欢写那一堆又一堆的文档吗？你喜欢看那一堆又一堆文档吗？你喜欢你的老板整天指手画脚其实完全没有帮助？你喜欢看到需求不停变更但是计划永远不变，结果就是压缩测试时间，或者发布延期？答案当然是否定的，没有人喜欢。

软件开发是一个创造的过程。工程师是人不是机器。符合人类天性的开发模式才是好的开发模式。

软件开发的核心问题:沟通障碍，需求变化，产品质量等等。在CMM模式中都没有被很好的解决。敏捷提供了一种全新的思维方式。敏捷的核心思想就是以人为本，持续改进。

回帖的童鞋们似乎对于文档的问题很感兴趣，那我就说说敏捷对于文档的态度。
首先，敏捷并不是没有文档。敏捷只是省略掉了不必要的文档。
其次，一个商业软件发布时应该有的文档，敏捷开发全部都有。比如说，release note, Help等等。

文档的作用是用来沟通，交流和传递信息。但是文字本身并不是一个完美的载体。语言永远比文字更能够清晰的表达思想。所以在敏捷开发中，类似于测试计划，方案，任务分配，简报之类的都可以省略。我能够花三分钟说明白的事情，为什么要花十分钟去写，而且还要接收者再花十分钟去阅读。这不是白白浪费了十七分钟。

当你加入一个新团队的时候，你希望看到一大堆产品说明，还是喜欢有个人手把手的指导你？我想多数人喜欢后者吧。

敏捷团队中，所有的知识都是共享的。所以完全不需要担心，由于某个成员的缺失而造成知识断层。同样的，由于这种担忧而产生的文档也可以省略掉。顺便提一句，虽然我不知道为什么，但是敏捷团队的人员流动率非常低。我公司里面的测试人员在实施敏捷之后的若干年里面，一个离职的都没有。

[ 本帖最后由 woza 于 2009-6-24 12:24 编辑 ]

作者: 愚人 时间: 2009-6-21 14:46
不是所有行业都适合敏捷开发的吧~~~

对于一些做产品的公司，CMMI更有用些！！！

作者: liufeng 时间: 2009-6-21 21:31
你可以说敏捷才是王道，但说CMM已经落伍了有点不合适！
赞同2楼所说

作者: woza 时间: 2009-6-22 07:51
做产品的公司当然可以用敏捷。你说丰田，诺基亚，IBM，Google，暴雪是不是做产品的？
敏捷是一种思维方式，几乎所有类型的公司都可以用敏捷。这个和是不是软件公司，是不是做产品的一点关系没有。
CMM自有它可取之处。我不否认使用CMM也能做出成功的软件。但是，达到同样的目的，CMM花费的代价比敏捷要高出许多倍。中国的软件企业本来底子就薄，敏捷比CMM更加适合现状。

作者: drdrtracy 时间: 2009-6-22 08:30
我觉得适合才是王道吧,不管是CMM还是敏捷,用适合的,用好了才是王道

作者: chengxq 时间: 2009-6-22 09:27
标题: 回复 5# 的帖子
这个才是正解，我遇到一个公司，什么叫敏捷，敏捷的定义就是非CMMI，就是CMMI要求的我都不做了，
既然是敏捷，那就是快，什么都没有了，他们的理解就是什么管理文档都不要做，只根据进度表走进度
很敏捷！！！

作者: woza 时间: 2009-6-22 10:44
楼上讲的那个公司有些步入歧途了。

敏捷并不是完全不要文档。敏捷也不是一味的求快。如果做出来的产品质量有问题，速度再快也没有用。

而且敏捷和CMM并不是完全对立的。CMM设立这么多文档的目的，在于避免由于沟通障碍而造成的损失。敏捷的思路是如果这些文档很好的解决了沟通问题，那就继续写文档；如果没有解决沟通问题，或者文档本身就造成了沟通障碍，那自然就要寻找更好的解决方案。

不要看到敏捷，就以为它和文档是对立关系。敏捷关注的是整个项目过程中，所有造成浪费的环节。发现浪费，就要处理；发现有节约的好方法，就要做到极致。不停的反思和总结。

作者: 静月思 时间: 2009-6-22 17:09
标题: 敏捷是代表什么？
CMM是个啥子？::xsjsn:::

作者: mx2001 时间: 2009-6-22 17:49
敏捷是以人为本不错，但是整个过程控制，对于一个项目经理来说，测试经理，以及开发经理是考验，做的不好，反倒更耗费精力。。。不要人云亦云。。。国内一直都是新技术的试验场，其实在国外，没有像我们这样天天尝鲜，风险控制也是很重要的。。。

作者: zhongmg108 时间: 2009-6-22 18:04
标题: 适合才是王道!
敏捷、XP、RUP、CMM/CMMI等，都不是王道，能够高效地解决组织的问题，适合公司的过程才是最重要的。如果项目的规模很小、功能也很简单，团队规模也不大而且比较稳定，而且是一锤子买卖，那就可以能省的文档都省掉。如果公司想获得可持续发展的能力，想赢得客户的长期信赖，一些文档还很有必要的。如果只是站到项目经理或成员自身角度来看，一些文档是会消耗成本而不给项目带来效益的，但是如果站在整个组织或公司的长期发展角度看，一些过程和管理文档必不可少。这里还有一个整体与局部的关系问题，公司应该建立整体与局部利益的一致性机制，这样项目组就会少一些抱怨。

作者: 愚人 时间: 2009-6-22 18:05
诺基亚是网络部门在搞敏捷吧，后来效益不好跟效益不好西门子的网络部门合并了

[ 本帖最后由愚人于 2009-6-22 19:59 编辑 ]

作者: 愚人 时间: 2009-6-22 18:39
同意10楼的说法

作者: nitint520 时间: 2009-6-23 18:43
敏捷迭代开发并不代表就放弃文档
CMMI并不代表要把项目都框死在文档里面
其实我们并不需要关注 CMMI PK 敏捷迭代的结果这两个不是PK关系
重要的是如何在两者之间找到一个平衡点，怎样才适合自己的项目团队。

作者: elong602 时间: 2009-6-23 21:05
适合自己的就是最好的！

作者: woza 时间: 2009-6-23 21:39
敏捷和CMMI其实是思考问题的两种不同方式。和文档不文档没什么关系。

CMMI是管理者喜欢的模式。管理者通过流程管理，来确保开发过程的可控性。它试图避免由于人的因素造成任何不可控的事件发生。

敏捷则是以人为核心。是工程师喜欢的模式。敏捷试图以团队的进步来带动整个组织的进步。敏捷认为再好的规范也需要人去执行。与其关注规范，不如关注人。但是管理者未必喜欢这种想法。因为这意味着决定权的下放。

作者: luoyear 时间: 2009-6-23 21:56
严重怀疑楼主是否懂敏捷或实践过敏捷？
敏捷并未就是否需要文档，及一些具体的工程实践方面提出建设性的意见。
敏捷的意义在于通过高度透明的研发过程，充分考虑人性的因素，高度的可视性使得团队效能被最大程度调动。
当然，敏捷也提出了诸如持续集成，测试驱动等实践，但这屈指可数的实践完全可以被融入CMMI相应的过程域中。

[ 本帖最后由 luoyear 于 2009-6-23 21:57 编辑 ]

作者: woza 时间: 2009-6-24 12:33
敏捷能否被融入CMM，我个人表示怀疑。

CMM能够让工程师自己制定开发计划吗？CMM能够允许每个团队使用不同的流程，不同的标准吗？CMM能够允许工程师们自我管理吗？CMM能够取消那些评审活动吗？

作者: 愚人 时间: 2009-6-24 13:51
据说某些专家开始研究敏捷和CMMI的融合了，能不能成功就不知道了
可以google一下

作者: liuchunyanli 时间: 2009-6-24 15:52
本人觉得“敏捷”在国内不太靠谱。“敏捷”强调以人为本，而国内软件企业人员流动性很强，国内企业只看重效益，不太注重人文和质量。
不能以偏盖全，至少大部分企业是不重视的。
玩一些概念，本人觉得挺没意思的，主要是到底能不能真正地去做，能不能将事业做好。概念只有理论参考意义，不是要做事情的全部。

对了，我们公司给我们做“敏捷”培训的同事已经离职了。

[ 本帖最后由 liuchunyanli 于 2009-6-24 15:54 编辑 ]

作者: bensen 时间: 2009-6-24 17:54
像你说的那种高忠诚度的员工又有几个呢？！CMMI没用的话人家老外也不会花那么长时间、那么多精力去研究了。凡事都有利弊，不可一刀切嘛。

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

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

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

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

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

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

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

作者: jlsv 时间: 2009-6-25 09:48
CMM的文档和过程是可以根据不同项目组和项目需要来裁剪和做适当调整的，并不像有些朋友说的那么差

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

作者: woza 时间: 2009-6-25 13:16
敏捷是以人来控制规则。传统开发模式是以规则来控制人。如果CMM能够让工程师来制定规则，自我管理，那也可以很敏捷。

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

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

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

作者: 47385024 时间: 2009-6-25 22:44
呵呵  看了半天帖子  不知道各位是怎么理解敏捷和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 时间: 2009-6-25 23:30
CMMI文档多点，周期长点，但是还是很有计划，这样不容易有大的偏差。

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

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

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

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

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

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

作者: zhongmg108 时间: 2009-6-26 11:29

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

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

作者: woza 时间: 2009-6-26 14:32
谢谢31#提醒。因为我觉得CMM和CMMI一脉相承，所以我一直用CMM代替两者。

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

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

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

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

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

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

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

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

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

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

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

作者: woza 时间: 2009-6-28 10:54
就目前情况来看，敏捷实施起来确实需要一些时间，但是仍然比CMM要容易很多。

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

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

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

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

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

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

作者: nijp2004 时间: 2009-6-29 12:57

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

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

作者: woza 时间: 2009-6-29 16:13
敏捷和文档不文档完全没有关系。敏捷只是减少浪费。不管这个浪费是文档，沟通，管理还是技术。

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

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

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

作者: zz402236991 时间: 2009-7-1 10:45

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

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

作者: oscarli 时间: 2009-7-1 14:46
找到公司合适的模型才是王道，如我们公司一个测试人同时跟踪几个项目，如果没有文档，根本无法工作。如果有测试人员与开发人员1：1，那样道是可以省不少文档。

作者: woza 时间: 2009-7-1 20:59
敏捷并不仅仅是几个实践模型。更重要的在于它的思想。敏捷提供了一个全新的思路。敏捷的核心在于人。所以并不需要依赖太多客观条件。在瀑布模式下也可以局部实施敏捷。只要能有持续改进的恒心就好。说到底，模型都素浮云。

作者: nijp2004 时间: 2009-7-2 12:02
凡事比较的帖子总是容易变成水帖，讨论了这么久，我想个人起码可以明确几点
1、大多数观点是适合的就是好的，但对于实践，不能今天采取A方案，明天采取B方案，所以，重要的是分析目前还有哪些需要改进，哪些优先级最高，然后再考虑哪种改进方法比较好，当然，什么都没有规范下来的组织可以更多的来选择学习对象，学习成熟的案例。企业过程改进不是找试验田，当然，内部找个team试验是可以的。

2、CMM2、3甚至ISO都是管理基础，起码有些扫盲工作可以做，比如配置管理的概念，很多小公司如果连这个意识也没有的话，那就不用考虑敏捷了。容易被误导的，这就和不管哪种运动，都要确保身体基础没有问题，有病先治病，然后再健身。

3、无论CMM或者敏捷，知识的转移和传承都是很重要的，团队在一起工作是为了沟通，即使在不同国家看起来也可以通过网络沟通，但越分散沟通质量会降低，还是需要文字做为媒介，因此，用Wiki或blog或者doc，本质都是一样的，当然，从技术上方面来说，wiki完全是颠覆了doc的概念。可以这么说，WiKi是王道，文档落伍了。

作者: 傲然 时间: 2009-7-2 15:52
棉结国内有几个真正做到的？？？还不是畸形的吗

作者: nijp2004 时间: 2009-7-2 16:52
LS，不好这样问的，起码就我就知道一个。绝对不知名的公司，项目周期不紧张，资源也比较多，总之不差钱。
集团公司，主营业务和软件无关。所以研发老总自我发挥的余地很大。产品目标是集团自己管理用的，如果做的好，可以卖给同行。最终结果如何，我不得而知。因为前同事离职了。
这个真的是敏捷模式的。

[ 本帖最后由 nijp2004 于 2009-7-2 16:55 编辑 ]

作者: kuailederen 时间: 2009-7-2 17:02
别讨论了，我发现无论怎么样的模式，不如找个有能力的领导，一句话就搞定模式搞不定的问题

作者: woza 时间: 2009-7-3 08:19
我们公司就是用敏捷的。感觉还不错。效率，质量提高了很多。

作者: simp 时间: 2009-7-3 10:58
敏捷对人的要求太高了，国内有多少人能做起敏捷来？
现在n多冲着敏捷去的，就是冲着不需要写文档，不需要有思考过程去的。往往结果都很悲惨。往往是眼高手低。

作者: kiddy 时间: 2009-7-3 14:09
个人体会敏捷应该是在cmm下进行精简，去掉糟粕留下精华。
cmm有太强的通用性，各个公司应该根据自己实际情况进行调整，找到最适合的方式方法。
说实话，感觉了大中小三种公司，其实国内很多做软件的前期调查定位不足（主要是产品经理方向及要点把握不好）导致中后期太多小调整，小变动，周期不确定性严重扰乱了cmm的流程减低了其实际效果，所以才凸显了敏捷的优点，小周期迭代！这样快速处理快速跟进更能发挥作用~就此同意楼上部分同学的看法“国内还是敏捷好！”
但如果架构一个大型的，周期长，功能结构复杂系统，cmm才能发挥作用！
这就是“一寸长一寸强” 与“短小精悍”的区别！

作者: movestar 时间: 2009-7-3 16:58
有的时候真的不知道什么是适合的，怎么判断是不是适合呢？

作者: woza 时间: 2009-7-3 17:16
标题: 回复 50# &51#的帖子
如果需求变更非常少，那用什么模式开发都一样。用瀑布也可以做的很好。之所以大家觉得瀑布有不足，就是因为需求不变的开发项目几乎不存在。

既然现实无法改变，那自然只能改变自己。所以敏捷出现了。我不明白为什么大型软件不能使用敏捷模式。事实上，我觉得目前来说，敏捷的不足仅仅在于没有一张类似CMM之类的证书。对于客户来说，开始的时候不那么容易判断软件企业是否能够提供高质量的软件。一点客户和敏捷团队合作过之后，就会发现他们应对需求变化的能力绝对不是传统模式的团队能够比拟的。

回 51#：
很多时候确实很难判断哪种模式更适合自己。最好的办法是，都试一下。如果做不到，那就选实验成本低的先试一下。

作者: ydz123456 时间: 2009-7-3 19:27
标题: 回复 1# 的帖子
有道理

作者: sk_svenska 时间: 2009-7-4 06:52
CMMI是一个庞大的系统，她存在的意义是不可否认的，对于任何试图尝试她的组织来说都要花费不少的气力可是真的有必要教条似的照搬么？抓住要义然后结合实际应用来取舍岂不敏捷哉！

作者: woza 时间: 2009-7-7 13:39
CMMI就象一张大学文凭。企业有这个文凭，找项目容易一些。但是并不是说拿到一张文凭就万事大吉了。这个东西只能证明你接受了某种程度的教育，但是无法证明你有多么高的水平。况且国内（包括国外也一样）掏钱买文凭的居多，认真学习的较少。所以这个文凭的水份不是一般的多。

作者: fluter 时间: 2009-7-8 10:36
标题: 各有长短，扬长避短即可
敏捷是武术师，请不要让他们打大规模战争。
CMM是军队，请不要拿去单挑。

作者: aliceella 时间: 2009-8-5 09:54
敏捷开发是指的快速的进入开发吧，省去一些文档或者最后再补文档！

作者: 天空下下雨 时间: 2009-8-5 10:25
这个世界没有银弹。可以去javaeye的敏捷频道看看。

作者: kf_rainbow 时间: 2009-8-6 14:37
所谓敏捷,起码要在CMMI达到一定程度才能做的!
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??
技术骨干走了,光敏捷,怎么进行之后的产品研发?

作者: yiding_he 时间: 2009-8-6 22:19

原帖由 kf_rainbow 于 2009-8-6 14:37 发表
所谓敏捷,起码要在CMMI达到一定程度才能做的!
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??
技术骨干走了,光敏捷,怎么进行之后的产品研发?

第一句话我不认同，但是后面两句话说到点子上了。CMMI 的核心价值观，就是将人看成是最大的风险，CMMI 所有的一切都是为了应对这个风险。人的风险越低，说明企业越 “成熟”。

作者: woza 时间: 2009-8-7 08:21
那么为什么人会有风险呢？如果搞了CMMI，大家干活不happy，流动率高，当然就有风险了。而敏捷提倡enjoy，事实证明，我们公司流动率超级低。

即使人员流动无法避免，那么依靠文档是最好的经验传递方法吗？人才是传递经验的最好载体。在敏捷团队中，知识经验能够快速分享，即使走掉个把人也没什么。再说，敏捷团队是自适应团队。不是依靠某个人，而是依靠团队合作。如果缺乏某种技术，那么团队会自己去找另外一种替代技术。

如果真的发生了一夜之间所有核心人员都走了，那就是这个公司出问题了。公司都垮了，你有再多的文档还有啥用。

最后，产品维护这种概念敏捷是不存在的。敏捷通常使用重构，但这并非是维护。所以不要把维护拿来说事。

作者: stjd139 时间: 2009-8-7 10:47
各有各的好处吧。。。

作者: yiding_he 时间: 2009-8-8 18:08
1、“cmmi 同 cmm 一样承诺给人一个美好的前景，但是任何模式都有一个使用的方式方法和约束，cmmi 却并不告诉你有这个约束，而且他们却往往给你一个他们根本就不会被约束的假象。”

2、Tom DeMarco 对 CMM 的评价（不认识没关系，就看看他说的有没有道理）：
http://www.javaeye.com/topic/971

3、

原帖由 kf_rainbow 于 2009-8-6 14:37 发表
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??

什么是知识？知识分为两种。一种是技术知识，就是这个人的本事；另一种是业务知识，就是当前项目中的需求、设计等等。技术知识是随着人走的，人走了，什么技术也留不下来；而业务知识是可以留下来的。业务知识保证了这个项目当中业务概念的可延续性。当然，业务知识不能保证产品质量，能够保证产品质量的个人能力是留不下来的。这就是为什么有的人薪水高有的人薪水低。

作者: woza 时间: 2009-8-9 09:56
标题: 说的非常好

原帖由 yiding_he 于 2009-8-8 18:08 发表
1、“cmmi 同 cmm 一样承诺给人一个美好的前景，但是任何模式都有一个使用的方式方法和约束，cmmi 却并不告诉你有这个约束，而且他们却往往给你一个他们根本就不会被约束的假象。”

2、Tom DeMarco 对 CMM 的评价 ...

由于缺乏应对变化的勇气，所以试图寻找一种以不变应万变的方法。这个就是CMM/CMMI的本质。敏捷则以莫大的勇气去拥抱变化，并积极去适应变化，从不以暂时的成功而停止探索的脚步。

那些外包企业之所以使用CMM，是因为他们根本不是在做软件开发。按照已有的设计去写代码，充其量是个体力活。这种事情做得越多，创造力就越少。本来中国在软件这个纯粹依靠创造力的产业上面，应该是有优势的。因为受教育的人口越多，产生新思维的概率就越大。要是推广外包产业，终有一天要沦为人家的劳动力批发市场。和先进的软件思想技术的差距只会越拉越大。

作者: ThinkInChaos 时间: 2009-8-10 13:38
看了大家的评论，发表一下粗浅认识：大多数了解CMMI的人不了解Agile，了解Agile的人不了解CMMI，我们应该静下来试着去了解对方，取长补短。做了2年的敏捷项目实践后，现在在CMMI5级的公司工作。我认为敏捷和CMMI的关系是：

敏捷为体，CMMI为用

CMMI的优势：很完整的框架和知识体系致命弱点：假设世界很少变化
敏捷的优势：拥抱变化，核心是它的价值观弱点：实施的障碍比较大，往往实施过程中重于形式，而非本质。

以敏捷的价值观为体，把CMMI的一些好的实践应用于敏捷。

[ 本帖最后由 ThinkInChaos 于 2009-8-10 16:39 编辑 ]

作者: xiaoyaoliuyun 时间: 2009-8-10 14:10
忽悠忽悠，
一切根据实际需要，没有什么谁落伍谁先进

作者: yangzhi984 时间: 2009-8-10 16:20
老外起步的比较早，我们还是踏踏实实走过每一步吧

作者: renhuilao 时间: 2009-8-21 16:40
我们的项目在用Agile。谈点体会吧：
1. 人与人的沟通更直接更有效。
2. 发现问题和解决问题的速度明显加快。
3.必要的文档还是需要提供（主要是最后要发布到用户那里的）

作为测试人员，在之前的模式下，我们通常会需要大量的需求文档和设计文档，但开发人员通常很难按照那一堆的标准提供我们想要的东西。由于时差和沟通的成本太大，大多数情况下会按照自己的理解来测试~~~在Agile模式下，每天（不同local至少每周一次）的scrum上可以讨论，开发、测试都把问题摆桌面上来商量，解决问题的速度快得多。

对于开发人员和测试人员不在同一个local的情况，那简直是累得要死啊~~~~~~

Agile之后，每个迭代的时间都比较短，新功能测试都有点紧张，所以regression在每个迭代当中的比例就很小了。所以在项目后期，还是会像传统那样安排一个月左右的regression和final。以保证质量

Agile对人的要求非常高。模块细化后，很可能一个scrum就是一个开发一个fvt一个gvt还有一个svt，每个人要干的工作基本上就是传统模式下leader要干的活。需要承担责任。

[ 本帖最后由 renhuilao 于 2009-8-21 16:47 编辑 ]

作者: yiding_he 时间: 2009-8-22 23:03

原帖由 ThinkInChaos 于 2009-8-10 13:38 发表
CMMI的优势：很完整的框架和知识体系致命弱点：假设世界很少变化
敏捷的优势：拥抱变化，核心是它的价值观弱点：实施的障碍比较大，往往实施过程中重于形式，而非本质。

1、怎么定义才算“实施”了？老板一声令下就算实施了？还是说必须大家都认认真真去做了才算实施了？那么敏捷和 CMMI 哪个更容易"实施"不言自明。
2、关于谁更流于形式，我重新贴一下敏捷宣言：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
完全可以看作左边就是敏捷，右边就是 CMMI。

作者: Oilio 时间: 2009-8-22 23:59
支持

作者: yiding_he 时间: 2009-8-24 08:57

原帖由 jimmyseraph 于 2009-8-23 15:48 发表
咋又翻出这个帖子来了，71楼的也不用把敏捷宣言贴出来，敏捷宣言说白了就是一群程序员为了忽悠别人相信敏捷而抛出来的美丽的谎言，不用太在意。
我在58楼就说过了“敏捷和CMMI都看做是信仰，相信就能做好”这句话， ...

这句话的意思就是，在你背上写个“佛”字，告诉你心诚便可刀枪不入，被砍死了就是你心不诚。CMMI 是万能的，就看你心诚不诚了。

作者: kojywu 时间: 2009-8-24 10:32
我觉得挺有道理的，支持一下

作者: yiding_he 时间: 2009-8-25 11:50

原帖由 jimmyseraph 于 2009-8-24 11:43 发表
典型的没有理解我的意思，我说了不管是CMMI还是敏捷，把它当成信仰就行了，项目做的失败了，和你的信仰的东西没有关系，而是要从你自己本身入手看问题。就像佛教和道教，你在背上写个“佛”字，告诉你心诚便可刀 ...

“明明是执行不到位造成的项目问题，偏偏去怪CMMI不好，极力推敏捷，而不去深究问题的根因是什么”
——我觉得更应该深究为什么 CMMI 总是会 “执行不到位”？为什么过了 CMMI 之后马上就丢到一边？根本原因是什么？这涉及到对软件、软件项目和软件工程本质上的理解。

“关键在于执行力”
——关键不是在于“执行力”，而是在于“执行的动力”。想想两者的区别。

[ 本帖最后由 yiding_he 于 2009-8-25 11:52 编辑 ]

作者: yiding_he 时间: 2009-8-26 00:45

原帖由 jimmyseraph 于 2009-8-25 12:21 发表
你是怎么得出CMMI总是执行不到位的？至少我见过不少大公司的CMMI执行都不错，项目成功率也很高。
CMMI也是经过实践检验的成功经验总结，换句话说就是符合本质的，所以要从本质上来考虑CMMI和敏捷根本就不会有结论。

只要过了 CMMI，基本上都会说自己是“成功的”。我也在 CMMI3 的公司呆过，当时过 CMMI 的时候也就是拿一两个项目做样子，疯狂的补写文档。按讲师的话就是：“大家都是这么过的”。过了 CMMI 就真的能用起来吗？CMMI 再牛也牛不过开发进度表。至于成功案例，那与项目质量无关，只要凭关系磨嘴皮让用户答应项目上线，那就是“成功”了。你说的“执行都不错”有多少水分在里面，值得怀疑。如果一定要统计数字的话，看看这里：

http://www.cnblogs.com/cmmi/archive/2008/06/12/1218204.html
“大部分的企业（近60％的企业）实施CMMI收效不甚理想，最终走向失败”

我知道你会说：他们只是把 CMMI 当成工具而不是信仰。不过我更愿意相信他们一开始对 CMMI 还是非常期望的，就像我原来所在的公司一样，老总一开始也是非常积极，直到准备实施了才发现员工们怨声载道，最后只能拿一两个项目敷衍了事。大部分企业就是差不多的这样一个过程。这时候还不去检讨 CMMI 到底出了什么问题，那这问题永远也解决不了。

[ 本帖最后由 yiding_he 于 2009-8-26 01:01 编辑 ]

作者: 狩猎者 时间: 2009-8-26 10:37
适合的就是最好的，不适合的再好也没用

作者: woza 时间: 2009-8-26 11:53
79#说的不错。
我们不说CMMI应该是什么样子，那没有意义。按照CMMI实践的情况来看，这种开发模式至少不是开发者喜欢的模式。我觉得软件开发恰恰是一种喜欢（至少不讨厌）才能做好的工作。敏捷提供给喜欢做软件的人一种可以把软件做好的思路。
如果真的能够把这个脑力工作变成体力工作，比如说对日外包，那么CMMI未必不是一种好的方法。同样对于那些只把做软件当作混口饭吃的人来说，CMMI和敏捷也没啥区别。

作者: yan_guimei 时间: 2009-9-11 13:44

作者: mentgmery 时间: 2009-9-11 14:18
CMMI喧嚣之后,又见敏捷,本人更赞同吴穹博士的观点
请见http://blog.csdn.net/adwu73/archive/2008/06/23/2577810.aspx

[ 本帖最后由 mentgmery 于 2009-9-11 14:22 编辑 ]

作者: ddzkq 时间: 2009-9-12 15:00
标题: “敏捷”是需要基础的，而最基本的基础很多团队达不到
1、企业文化非常凝固--所有人的工作习惯、态度都趋于一致
2、开发团队形成了很强的惯性--从最基本的代码要求到模块化，日志格式、帮助、界面、操作、接口通讯等等一直在延续一种惯性，而且在这整个团队中有默认的很强的评判者--某开发总监

作者: yezi121808 时间: 2009-9-14 17:49
不同的业务模型决定了不同的开发模式。思科、诺西、华为的开发模式，和快速业务定制的开发模式也不相同。电信业务比较标准，使用CMM比较合适，而有些客户需求，要求很快能与客户交流，研发能直接接触到用户的，使用敏捷就比较合适。

作者: sinojelly 时间: 2010-4-10 10:23
标题: CMM/Agile简单比较
CMM:它相信，好的流程，好的生产线，就可以生产好的软件产品，典型的机器化大生产的产物。把人当生产线上的操作工。命令式的任务分配，不能调动程序员的积极性，还容易产生各种矛盾。
Agile：它认为有优秀技能的人，才能生产出好的软件。以人为本，激发人的激情，提升人员技能。敏捷还强调消除各种浪费，做最有价值的事，很明显这比无论有用没用，流程规定就去写很多文档要好很多。
CMM的文档驱动方式，来源于一个误传，它的创始人都否认了。

作者: freexml 时间: 2010-4-26 22:11
非常同意 84/ 85L 的意见，任何技术和理念都有其使用的文化、技术、管理等层面的要求，其不是所有的公司、部门、团队都通行的。

从 LZ 的话看，我很怀疑 LZ 作为一个软件技术人员的职业素养，怀疑你的工作的严谨性。任何一种技术的诞生都是有其需求的，其产生也是有一定适用范围和使用条件的。我们技术人员应冷静看待新事物、新技术、新理念，不应该崇拜甚至神化任何一种新事物、新理论。任何新技术和理论如果有其优点，那可能有其缺点，要么在表现在使用范围上，要么是表现的使用成本上，要么是对使用起点的要求，过于偏执有失歉妥。

另外从 LZ 的经验中我很怀疑 LZ 在所谓的 CMMI4 级公司工作的经历， LZ 是否真正接触过 100W 行级大型高质量要的软件工程？大型软件项目其复杂的结构模型与设计，大量接口、模块、子系统，复杂的关联关系等，庞大的团队成员，慢长的周期，使得从项目从需求开始到最终实现上而下一整套东西的无偏差保证是非常困难的。这些不是通过沟通就能解决的（团队成员之间的技术、经验、工作方法的差异使得偏差的会大量的产生），他需要从多角度、多角色的全面论证行为、方法的可行性，并进行偏差风险控制，文档不仅是可回溯的，还是整个流程中行为的无偏差的保证。你说你在国外 CMM4 级的公司做得不怎么样，这不代表这套东西不好，可能公司做得还不算差，只是你层次不够没看到，也可能是你们没做好（不是国外的就是好的）。

邓公说过“不管白猫黑猫，能抓住老鼠的就是好猫”，这同样适用软件行业，前面大家也都说了，适用的方法才是好方法 ~~~~~~~~

[ 本帖最后由 freexml 于 2010-4-26 22:12 编辑 ]

作者: freexml 时间: 2010-4-26 22:40
说到这再罗嗦下，不知道是我理解不正确还是其他，总感觉LZ所说的从头到尾都是站在自己的角度在说，有些狭隘，有点小团队自我蛮足、扬扬自得的意味。一个真正的成功不仅仅是对内部的成功，而且对外也是是可持续、可复制的，才能算成功的。LZ可一自己分析下你们团队的经验放在其他大的、小的团队，其他大的、小的项目是否也能很好的推广？

说了这么多，没别的意思，只是觉得LZ这样借贬低其他来抬高展现自我不是很好.......

作者: acura256 时间: 2011-8-25 09:51
老板最怕的就是你舒服了忽然某一天拍拍屁股走人了什么都没留下···接下来咋办

作者: humh 时间: 2011-9-1 10:14
教条主义要不得啊,不管是敏捷还是cmmi,这些东西非的分那么清楚吗,我觉得啥好用就用才是关键.
不同的公司规模,不同的业务模式,大家都要努力寻求适合自己的道路啊,不可以认教条啊.

作者: bug731 时间: 2011-9-3 18:11
还是各取所需

作者: lyscser 时间: 2011-9-6 15:16
脑残~

作者: zw_chinese 时间: 2011-9-6 16:41
能挣钱才是王道

作者: zw_chinese 时间: 2011-9-6 16:53
能挣钱才是王道

作者: zw_chinese 时间: 2011-9-6 17:34
能挣钱才是王道

作者: zw_chinese 时间: 2011-9-6 17:35
能挣钱才是王道

作者: zw_chinese 时间: 2011-9-6 17:36
能挣钱才是王道

作者: zw_chinese 时间: 2011-9-6 17:37
能挣钱才是王道

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)